AI security scanning in CI/CD: shift-left security guide

SAST (Static Application Security Testing) analyses source code without executing it, running at pre-commit or pull request stage and scanning for vulnerability patterns in the code itself. It is fast and catches vulnerabilities early but may produce false positives because it cannot fully model runtime behaviour. DAST (Dynamic Application Security Testing) tests a running application by simulating attacker behaviour — sending malicious inputs, probing endpoints — and catches vulnerabilities that only manifest at runtime, such as authentication bypasses and injection vulnerabilities in complex data flows. Both are needed for comprehensive coverage; SAST runs earlier in the pipeline and DAST runs against deployed staging environments.

False positive management is critical for developer adoption of shift-left security. Use structured suppression — annotate false positives with suppression comments and justification in the code rather than turning off entire rule categories. Configure severity thresholds so only critical and high-confidence findings block merges; lower-severity findings are informational. Invest in tuning tool configurations with your codebase — most tools provide custom rule configuration. Track false positive rates as a programme metric; anything above 20% for pipeline-blocking findings requires tool reconfiguration before developer backlash erodes the programme.

Start with secret detection (Gitleaks or GitHub push protection) because it has the lowest false positive rate, requires minimal configuration, and addresses an immediate risk — exposed credentials. Next prioritise SCA (Snyk or Dependabot) because open-source dependency vulnerabilities represent the majority of exploitable vulnerabilities in most applications. Add SAST only after SCA is stable and developers have built the habit of remediating findings. Starting with SAST, which typically has the highest false positive rate, is the most common programme failure mode because it creates developer resistance before the programme establishes trust.

Legacy codebase onboarding requires a baseline acceptance approach: scan the full repository, accept all existing findings as a baseline, and configure pipeline gates to fail only on new findings introduced in each pull request. This allows teams to stop the bleeding immediately while addressing legacy debt through a separate remediation programme. Prioritise legacy findings by exploitability and asset criticality rather than CVSS severity — many high-severity legacy findings are in code paths that are never actually reached in production. Tackle the highest-risk 20% of findings that represent 80% of actual risk before attempting comprehensive remediation.

AI fix suggestions from mature tools like GitHub Copilot Autofix and Snyk's DeepCode AI are production-safe for standard vulnerability patterns — parameterised query suggestions for SQL injection, proper sanitisation for XSS, correct cryptographic API usage. They require human review for complex architectural changes, cases where the vulnerability is a symptom of a deeper design issue, and any fix that changes application behaviour rather than just hardening implementation. Treat AI fixes as a starting point for code review rather than auto-accepted changes, at least until your team has calibrated confidence in the tool's fix quality for your codebase patterns.

Security findings routed through a centralised security team queue create bottlenecks and slow remediation. Best practice is developer-owned remediation: findings appear directly in pull requests, in developer-facing dashboards, and in the repository's security tab, with the owning team responsible for remediation SLAs. Security teams set policy — which finding types block merges, remediation SLA targets, escalation thresholds — but do not sit in the remediation path. This model scales with engineering growth and aligns incentives correctly: the team that introduces the vulnerability owns fixing it.

Key programme metrics include: mean time to remediate (MTTR) by severity — track trends rather than absolute values; vulnerability escape rate (findings discovered post-deployment versus pre-deployment — target below 5%); false positive rate per tool — track to identify tools needing reconfiguration; developer adoption rate (percentage of repositories with scanning enabled); and open critical/high finding count trending over time. Avoid vanity metrics like total findings detected, which increases as coverage improves without reflecting security improvement. The most important leading indicator is MTTR declining over time as developers internalise secure coding patterns.

Container image scanning is a critical complement to application code scanning that is often missed because it operates at the infrastructure layer rather than the application code layer. Container base images (Ubuntu, Alpine, Node) contain OS-level packages with their own CVEs independent of application code. Trivy and Grype scan container images as part of the container build pipeline step, failing builds with critical OS-level CVEs. Establish a base image policy using approved, regularly rebuilt images; unmanaged base images accumulate OS vulnerabilities over time at a rate that often exceeds application vulnerability accumulation.