DevMeth
C48

Public web surface

CI Secret Exposure Check — Can a Pull Request Steal Your Deploy Keys?

DevMeth checks the 48 known AI-code failure patterns — not a penetration test or a security guarantee.

What the issue is

A workflow that checks out PR code in a pull_request_target job runs attacker-authored code with your secrets attached — one 'fix my tests' PR steals your deploy keys.

Why AI tools generate it

AI scaffolds copy the pull_request_target + checkout recipe because it makes CI run on every PR — without understanding which half carries trust.

How DevMeth detects it

A code scan parses GitHub Actions YAML and flags jobs that combine a pull_request_target/workflow_run trigger, a checkout of PR-head refs, and secrets usage in the same job. Base checkouts and pull_request triggers are not flagged.

C48
What a finding looks like
High

CI workflows give untrusted PR code access to secrets

WHAT WE FOUND

C48 — masked sample

Sample — illustrative and masked exactly as a real report shows it. Run a free scan to see your own results.

The fix, in three steps

Split the workflow: reviewed code with secrets on pull_request, untrusted builds on pull_request without secrets — pass artifacts, never the checkout.

Run a free scan and each finding carries a paste-ready fix prompt you can act on.

Try a free scan

FAQ

What makes pull_request_target dangerous?

It runs in the base repo's context — secrets and write token attached — before anyone reviews the PR. That's by design, for commenting and publishing. The danger is executing the PR's code inside that context.

I need secrets to run tests on PRs.

Then the tests run maintainer-side: trigger on pull_request (reviewed merge commit) — secrets stay safe because the code tested is code someone merged. Testing the raw contributor code must happen secret-less.

What's the fix?

Split trusted and untrusted halves into separate jobs/workflows and hand off artifacts. Pin third-party actions to commit SHAs while you're in the file.

DevMeth checks the 48 known AI-code failure patterns — not a penetration test or a security guarantee. A clear result means each known pattern was checked and found clear or not applicable for your app; it is not a guarantee of security.