Security Audits Belong in Every Pull Request

A security audit describes the code that was reviewed at a particular point in time. It does not protect the next endpoint, the next permission change, or the next dependency update. My preferred approach is to make security review part of every pull request, with deeper audits at meaningful checkpoints.

Cloudflare's security-audit-skill is a useful starting point: it organizes agent-assisted review around architecture mapping, vulnerability investigation, separate verification, and structured findings. It also carries evidence between runs. That makes it interesting as a repeatable engineering workflow rather than a one-off chat prompt.

Why a clean report expires

Imagine a service where users can download their own documents. The first implementation checks both authentication and document ownership. A later PR adds a batch download endpoint and reuses the file-loading service, but forgets the ownership check for each item. Nothing about the earlier audit changed; the new access path simply was not there when it ran.

The same pattern appears with cache keys that omit the user ID, a webhook with a new trust assumption, or a file export moved into a background worker. The relevant unit of review is the changed behavior and the boundaries it crosses, not just the modified lines.

What I would check on every PR

I would start from the base commit and PR head, then read the diff together with its callers, middleware, persistence rules, and configuration. A change to a shared authorization helper can affect routes that the diff never mentions.

For a document endpoint, I would ask: who supplies the identifier, where is ownership checked, which user context reaches storage, and can a second account reproduce an unauthorized read? For an LLM-backed feature, I would also trace external text into prompts, tool arguments, and rendered output. Treating retrieved content as instructions can create a new trust path even when the HTTP endpoint itself looks ordinary.

A focused review should leave a small, inspectable record: the reviewed commit, affected boundaries, tests performed, unresolved questions, and any confirmed findings. It should also say what was outside its scope. “No confirmed findings in this review” is a useful statement; “the application is secure” is not a justified conclusion.

A practical PR workflow

1. Describe the change. Record the base/head commits and the data flow being added or modified.
2. Review the connected surface. Follow the changed behavior through authorization, storage, external calls, and deployment settings.
3. Challenge a suspected issue. Try to disprove the claim with a realistic counterexample before treating it as a defect.
4. Fix and add a regression check. A two-account authorization test is stronger evidence than a screenshot of a warning.
5. Review the final revision. A fix can move the problem to another branch of the code. Attach the result to the final commit, not an earlier PR version.

This is my proposed review policy, not a claim that the repository installs an automatic GitHub check. A skill still needs an agent runner, permissions, time limits, result storage, and a deliberate CI integration.

Keep the runner outside the PR's control

PR code and repository text are untrusted input to the audit process. I would run target builds and tests in an isolated environment without production secrets. Fork PRs should not receive privileged credentials merely because a security job needs to inspect them. The review instructions and pinned tool revision should come from a trusted configuration rather than an arbitrary replacement supplied by the PR.

For example, a test that passes only after the job uploads environment variables is evidence of an unsafe test request, not a reason to expand the runner's permissions. Keep review artifacts private when they contain exploitable details.

Every PR, plus deeper checkpoints

Reviewing every PR does not mean spending the same full-audit budget on a typo and a login redesign. I would require a change-focused check for each PR, then broaden it for authentication, authorization, payment, upload, dependency, and infrastructure changes. Regular full-repository reviews help revisit shared assumptions and areas that individual diffs miss.

I would block merging for verified, unacceptable risks, send uncertain findings for human triage, and record explicit exceptions with an owner and revisit date. An unavailable runner should report an incomplete check rather than silently claim success. The team can tune the budget and merge policy without pretending an AI verdict replaces engineering judgment.

The durable result is a review habit: examine changes, preserve evidence, verify fixes, and return to the parts that remain uncertain. Running an audit once is a baseline. Repeating the review as the system changes is what keeps that baseline useful.

Sources

• Cloudflare security-audit-skill — tool description and repeatable audit workflow.
• Build your own vulnerability harness — Cloudflare's broader engineering context.

Tool details checked on 29 October 2026. The PR cadence and merge policy above are my recommendations; they are not a security guarantee or a statement that this integration is already deployed.