AI code security in CI/CD: the order to set it up

Set up AI code security in CI/CD in this order: harden the pipeline itself, add secrets scanning, add dependency scanning with reachability, add code analysis, then gate pull requests and tune the noise. Each step makes the next one trustworthy. Skipping to a gate before the earlier steps usually produces a gate nobody believes.

Why does AI-written code change anything?

It changes volume and review habits more than the kinds of bugs. Code arrives faster, from assistants that may suggest a package that does not exist, an outdated API, or a hardcoded credential copied from an example. Reviewers see more diffs and read each one less closely. NIST's Secure Software Development Framework, SP 800-218, is a common vocabulary for producing software with fewer vulnerabilities, and it applies whoever or whatever typed the code. The CI/CD pipeline is where those practices become automatic.

Step 1: harden the pipeline

Your scanners run inside CI, so a weak pipeline weakens everything. GitHub's secure use guidance recommends pinning third-party actions to a full-length commit SHA, setting the default token to read-only and raising permissions per job, avoiding the pull_request_target trigger when it is not necessary, and using OIDC instead of long-lived cloud credentials. Do this first.

Step 2: secrets scanning

Secrets in code are the quickest damage an assistant can cause, because a pasted key works immediately. Scan commits and pull requests for credentials and fail the check on a real finding. Pair it with a rule that any exposed secret is rotated, not just deleted.

Step 3: dependencies, with reachability

Scan the lockfiles and the resulting SBOM for known vulnerabilities. Add a check for packages that are newly introduced and very young or unknown, since assistants can name packages that attackers register on purpose. Reachability analysis separates flaws your code can actually call from those it cannot, so the failing list stays short enough that people read it.

Step 4: code analysis

Static analysis catches injection patterns, unsafe deserialization and weak crypto in the new code. Run it on the diff first, because a full-repository scan on day one produces thousands of old findings and a team that stops looking. Optional model-assisted analysis can add context, and a Zero AI mode that runs without a model is useful where policy forbids one. Safeguard supports Full AI, Zero AI and bring your own model, and its CLI outputs SARIF and JUnit so results appear in standard CI reporting.

Step 5: gate the pull request

Only now add blocking rules. Start with the narrowest: block on exposed secrets and on reachable critical vulnerabilities. Warn on the rest. Give developers an override path that records who overrode what and why.

Open the pull request gate demo

Step 6: tune weekly

Track three numbers: how many findings blocked a merge, how many were overridden, and how many overrides later proved wrong. If overrides dominate, the rules are too noisy. If nothing ever blocks, they are too loose or the scanners are not seeing what you think.

What are the honest limits?

Scanners find known patterns. They do not judge whether a feature is designed safely, and they cannot tell if an assistant misunderstood the requirement. Keep human review for authentication, authorization and data handling changes, and give reviewers the scanner output beside the diff.

What to do

1. Pin actions to commit SHAs, set read-only default token permissions and use OIDC.
2. Turn on secrets scanning for commits and pull requests, with a rotation rule.
3. Add dependency and SBOM scanning, plus a check for new unknown packages.
4. Enable reachability so the failing list stays short.
5. Run code analysis on the diff, then widen scope later.
6. Gate on secrets and reachable critical flaws, and warn on the rest.
7. Record every override and review the numbers weekly.
8. Require human review for authentication, authorization and data handling changes.

Quick check

Sources

• NIST SP 800-218: Secure Software Development Framework
• GitHub Docs: Secure use reference
• CISA alert on the tj-actions compromise

Last reviewed: 18 October 2026.