CI/CD Security Gates for AI-Written Code

AI-written code needs four security gates before it merges: secrets scanning, static analysis (SAST) on the changed code, dependency scanning for new packages and a required senior review. Run all four on every pull request. Block the merge only when a finding is both high-confidence and high-severity, warn on everything else, and keep every result as release evidence.

What security gates does AI-written code need before merge?#

It needs the same gates as code a person wrote, but they have to be enforced, not left optional. AI coding assistants write code that compiles and looks clean, yet Veracode's 2026 GenAI Code Security Report found that about 44% of AI code generation tasks introduced a risky vulnerability. The average security pass rate across models was 56%, almost unchanged from the first report. A later update covered in the trade press still found vulnerabilities in 38% of tasks.

The risk is not the same in every language. In the same Veracode report, Java code passed security tests far less often than Python, JavaScript or C#.

Secrets are the second problem. In a GitGuardian sample of about 20,000 repositories where Copilot was active, 6.4% leaked at least one secret. The minimum gate set is:

1. Secrets scanning, before the code reaches the remote and again in CI.
2. SAST on the diff, so injection, weak crypto and unsafe deserialisation are caught in the lines the assistant wrote.
3. Dependency scanning (SCA) for every package added or upgraded, including a check that the package exists in your approved registry.
4. Required human review from a code owner who understands the module.

Our Quality Engineering work follows the same rule: tests, security checks and senior review on every change, whether a person or an AI wrote it.

Which checks belong on every pull request and which only on release?#

Run fast, diff-scoped checks on every pull request. Save the slow checks that need the whole system for the release pipeline or a nightly run.

A pull request gate should finish while the author still has the context. A release gate can take longer, because it looks at the built artefact and the running system.

Check	Pull request	Release	Default action
Secrets scan (pre-commit + CI)	Yes	Full history scan	Block on verified secret
SAST on changed files	Yes	Full repo scan	Block new critical/high
Dependency scan (new/changed packages)	Yes	Full SBOM scan	Block critical CVE with a fix available
Infrastructure-as-code scan	Yes, if IaC changed	Yes	Block policy violations
Required code owner review	Yes	—	Block until approved
Container image scan	—	Yes	Block critical with a fix available
DAST against staging	—	Yes	Warn, triage before release
Licence compliance	Warn	Yes	Route to owner
SBOM generation	—	Yes	Store as evidence

If your pipeline also deploys infrastructure, our guide to infrastructure as code security in CI/CD covers scanning plans on each pull request.

How do you configure SAST, dependency and secrets scanning in CI/CD?#

Run each scanner as its own named CI job. Each one scans only what changed, writes results in a standard format and reports a pass or fail status that the branch rules can check.

The pull request flow, from the engineer's commit to the merge:

SAST setup

• Run the scanner in diff-aware mode on pull requests and report only new findings. Pre-existing findings go into a baseline and a backlog, so authors aren't blocked for code they didn't touch.
• Output SARIF so findings appear inline on the pull request.
• Add rules for the patterns assistants tend to repeat in your codebase, such as string-built SQL queries or disabled TLS checks.

Dependency setup

• Scan the lockfile diff, not just the manifest.
• Fail a new dependency that isn't on your internal registry or allow-list. Assistants can suggest packages that don't exist or that nobody has vetted.
• Pin versions and let an update bot open the upgrade pull requests, so each upgrade goes through the same gates.

Secrets setup

• Add a pre-commit hook on developer machines. Then turn on server-side protection: GitHub's push protection blocks pushes that contain secrets and raises an alert whenever someone bypasses the block.
• Scan the full history again in CI on release branches.
• When a secret is found, rotate it first. Removing the line doesn't make a leaked key safe.

Name every job uniquely. GitHub warns that reusing job names across workflows can produce ambiguous status results and block merges.

How do you enforce policy so a failing scan blocks the merge?#

Make the scanner jobs required status checks on the protected branch, so that the platform blocks the merge, not the author.

On GitHub, rulesets can require status checks to pass before merging. A code scanning rule can also block a pull request when a required tool finds an alert at or above a severity you set. The same page lists a rule that requires secret scanning alerts to be resolved, which is currently in public preview. Other platforms have equivalent merge checks. Turn on "require a pull request", "require code owner review" and "require branches to be up to date" alongside them.

Then decide, for each finding, whether to block or warn:

Three rules keep the gate credible:

• Block on high confidence only. A gate that fails on noise teaches engineers to bypass it.
• Nobody bypasses alone. Admin overrides should need a second person, and every override is recorded.
• Treat AI reviewers as advisory. An AI review bot is useful as an extra pair of eyes, but it shouldn't count as the required approval. We explain why in what AI code review catches and misses.

Who owns exceptions and how are they logged as release evidence?#

The code owner of the affected module and a named security lead own each exception together. Every exception is time-boxed and recorded in the same place as the scan results.

An exception record should include:

• the finding ID and severity
• why it can't be fixed now
• the compensating control, such as a WAF rule or a feature flag that's turned off
• the two approvers
• an expiry date

Store it as a file in the repository or as a ticket linked from the pull request, not in a chat thread.

For each release, put together one evidence bundle tied to the commit SHA:

• SAST, dependency and secrets results (SARIF or JSON)
• the SBOM
• container and DAST results
• review approvals
• open exceptions with their expiry dates

This maps cleanly to NIST's Secure Software Development Framework (SP 800-218). NIST has also finalised SP 800-218A, which adds practices specific to generative AI. When an auditor or customer asks how a release was checked, you hand over the bundle instead of rebuilding the story.

How do you tell whether the gates are slowing delivery too much?#

Track gate time, false positives and bypasses alongside delivery and stability metrics. The gates are too slow when lead time rises and change failure rate doesn't fall.

This matters because AI speed alone doesn't make delivery better. The 2024 DORA report found that AI adoption raises individual productivity but hurts delivery stability and throughput. It concludes that fundamentals like small batches and robust testing still matter. RedMonk's summary of the report puts the estimate at a 7.2% drop in stability for every 25% increase in AI adoption.

Watch five signals each month:

1. PR gate duration (p50 and p90). Set a time budget and treat going over it as a defect in the pipeline.
2. False positive rate per rule. Tune or remove rules that are mostly dismissed.
3. Bypass and exception count. A rising count means a gate is too strict or the code is getting worse. Find out which.
4. Lead time for changes. If it rises after a gate goes live, find the slowest job.
5. Change failure rate and escaped vulnerabilities. These show whether the gates are catching anything.

If gates are slow, the usual fixes are:

• scan only the diff
• run scanner jobs in parallel
• cache dependency databases
• move full scans to nightly or release runs

Don't make the block threshold looser to save time. Our guide to DORA metrics when AI writes your code shows how to read these numbers together.

Conclusion#

Start with the four pull request gates: secrets, diff-scoped SAST, dependency checks and code owner review. Make them required status checks. Block only on verified secrets and new high-severity findings, record every exception with an owner and an expiry date, and bundle the results as evidence for each release. Then measure gate time next to stability, so security stays a check on speed rather than a brake.

Our Security & DevSecOps practice finds the gaps in your pipeline, ranks them by risk and builds these checks into it, starting with a paid pilot.

Want these gates in your pipeline? Talk to an engineering lead →