SAST and SCA Rollout Playbook: Phased Implementation

Most code scanning rollouts fail the same way: the tool is switched on across every repository at once, produces thousands of findings nobody owns, gets broad read access to all source code and CI secrets, and is quietly bypassed within a quarter. This playbook covers rolling out static application security testing (SAST), software composition analysis (SCA) and related code scanning (secrets and infrastructure as code) as a programme: scoping, giving the scanner the narrowest access it needs, baselining existing findings, choosing where scans run and what blocks a merge, triage and ownership, and measuring whether it works. It is vendor-neutral and written for AppSec, platform and DevSecOps engineers. What each tool type finds and how it fits a secure development lifecycle is in the Application Security Guide; hardening the scanning platform itself is in Securing the SAST, SCA and code scanning tool itself. This page links them rather than repeating them.

Key takeaways

Baseline before you block. Record existing findings as a baseline and gate only on new, high-confidence findings; legacy debt goes to a separate, owned backlog.
The scanner is a privileged identity. It reads source code and often CI secrets, so its tokens need the narrowest repository scope, short lifetimes and an owner.
Pin and verify the scanner itself. Scanners run inside pipelines with access to secrets; an unpinned scanner action or image is a supply chain entry point.
Route findings to code owners, not to the security team. A finding without an owner and a due date is noise.
Measure fix rate, not finding count. Mean time to remediate, gate bypass rate and false positive rate show whether developers trust the tool.

Scope and sequencing

NIST SP 800-218, the Secure Software Development Framework (SSDF) v1.1, asks organisations to review or analyse human-readable code and to test executable code for vulnerabilities, and to configure the tools that do it (practices PW.7 and PW.8). NIST SP 800-53 Rev. 5 control SA-11(1) Static Code Analysis and RA-5 Vulnerability Monitoring and Scanning express the same expectation for systems in scope of those controls. Neither says to scan everything on day one.

Scanner type	What it finds	Usual first-wave value	Typical noise source
Secrets scanning	Credentials in code and history	High: findings are concrete and urgent	Test fixtures and example keys
SCA	Known vulnerable or malicious dependencies, licences	High: findings map to CVEs and fixed versions	Vulnerable code never reached; transitive depth
SAST	Insecure patterns in first-party code (injection, unsafe deserialisation, weak crypto)	Medium to high once rules are tuned	Generic rules on unfamiliar frameworks
Infrastructure as code (IaC) scanning	Misconfigured cloud, container and Kubernetes definitions	High for cloud-native teams	Policies that do not match your standards
Container image scanning	Vulnerable OS packages in images	Medium: depends on base image hygiene	Unfixable OS package CVEs

Decision guidance: start with secrets and SCA, because their findings are easiest to act on, then add SAST with a curated rule set. The OWASP DevSecOps Guideline recommends pairing SAST with SCA for third-party code and with IaC scanning for files such as Terraform, Helm and Ansible. A small organisation with a few repositories can enable all three on its main services in one go if someone owns triage. A large organisation should pick a pilot of five to ten repositories across its main languages, owned by teams that volunteer, before going wider. See the Software Composition Analysis (SCA) Guide and the Git Secret Scanning Guide.

Phase 1: access, identities and the scanner's own supply chain

Before the first scan, decide what the tool can reach. A code scanner commonly holds read access to every repository, write access to pull request comments and statuses, and sometimes CI variables. That makes its credentials a high-value non-human identity (ATT&CK T1213.003 Code Repositories; T1552.001 Credentials In Files for what an attacker would find).

Integration	Narrowest workable access	Avoid
Source control	An app-style installation scoped to selected repositories, read code, write checks and comments	A personal access token from an administrator
CI pipeline	A per-pipeline token issued at run time (for example OIDC federation) to upload results	A long-lived upload token stored in every repository
Package registries (SCA)	Read-only token to private registries, if needed	Publish rights
Ticketing	Create and update issues in specific projects	Administrator rights
Single sign-on for the console	Federated sign-in with MFA; roles mapped from groups	Local console accounts

Pin the scanner: reference pipeline actions by commit hash and container images by digest, and update them through a reviewed change. The 2026 Trivy supply chain attack and the Checkmarx KICS attack show security scanners themselves being turned into credential stealers through their release paths.
Do not give scanners secrets they do not need: run scan jobs in a separate pipeline stage without deployment credentials. The Codecov breach showed how a tampered CI script can harvest every secret in the environment it runs in.
Treat findings as sensitive: SAST and secrets findings are a map of exploitable weaknesses and live credentials. Restrict who can see them and how long they are kept.

NIST SP 800-204D covers integrating software supply chain controls into CI/CD pipelines, and is the right reference for where the scanner sits in the pipeline's trust model. See the DevSecOps Guide.

Phase 2: baseline and tune

Run a full scan in report-only mode on the pilot repositories. Nothing blocks; nothing is ticketed yet.
Record the baseline: store the result set so later scans show only new findings. SARIF 2.1.0, the OASIS standard format for static analysis output, defines baselines and stable result fingerprints for exactly this purpose, so result management systems can tell new findings from existing ones across runs.
Tune rules with developers: sample findings per rule, mark false positives, and disable or narrow rules with a false positive rate the team cannot live with. Record each suppression with a reason, an owner and an expiry. The SAST Triage Guide covers triage technique.
Prioritise SCA findings: rank by whether the vulnerability is in CISA's Known Exploited Vulnerabilities catalog, then by exploit likelihood and reachability, before raw CVSS severity. Treat a package flagged as malicious as an incident, not a backlog item: the code already ran on developer machines and build runners.
Rotate every live secret found: a secret in history is compromised whether or not it is deleted. See Developer Secret Scanning Triage.
Turn the baseline into a backlog: legacy findings become owned tickets with due dates by severity, not a gate.

Phase 3: where scans run and what blocks

Point	What runs	Blocks?	Notes
Developer IDE and pre-commit	Secrets, fast SAST rules	Advisory	Fastest feedback; cannot be enforced, so never the only control
Push to the source platform	Secret push protection	Yes, with a recorded bypass reason	Stops credentials entering history; see How to enable GitHub secret scanning push protection
Pull request	Diff-aware SAST, SCA on changed manifests, IaC	Yes, for new high-confidence critical and high findings	The main gate; must finish within minutes
Default branch, scheduled	Full SAST and SCA	No	Catches new CVEs in unchanged code; feeds the backlog
Release or build	SCA on the built artefact; SBOM generation	Yes, for known exploited vulnerabilities	The SBOM records what shipped; see the SBOM Guide

Gate design: block on a narrow set at first, for example new critical findings from rules with a measured low false positive rate, new dependencies with a known exploited vulnerability, and new verified secrets. Widen the gate only as false positive rates fall. Every gate needs a documented exception route (security approval with an expiry), or developers will find their own.

Phase 4: wave rollout and ownership

Pilot (weeks 1 to 6): five to ten volunteer repositories across main languages; baseline, tune, and enable the pull request gate in advisory mode.
Enforce in the pilot: switch the gate to blocking for the agreed narrow set; measure merge delay and bypasses.
Wave by business criticality: internet-facing and regulated services next, then internal services, then libraries and tooling. Onboard by organisation or team so a named owner exists for each wave.
Default on for new repositories: repository templates include scanning from creation, so coverage stops depending on the AppSec team noticing.
Champions: one trained developer per team triages first and feeds rule tuning back to AppSec.

Ownership: map repositories to owning teams through code owner files or the service catalogue, and route findings there. The AppSec team owns rules, gates and exceptions; product teams own fixes. Remediation targets are a policy decision; a common starting point (our recommendation) is 7 days for critical, 30 for high and 90 for medium on internet-facing services.

Per-repository onboarding record

Owner: the team and a named contact from code owner files or the service catalogue.
Criticality tier: internet-facing, regulated, internal or tooling, which sets the gate and the remediation targets.
Languages and build system: confirms the SAST rule set and whether SCA reads lockfiles or needs a build.
Baseline reference: the stored result set and the date it was taken.
Exceptions: approved suppressions and gate exceptions, each with expiry.
Retired tools: any older scanner the repository used, and the date its integration and tokens were removed. Replacing a scanner without revoking the old one's repository access leaves a second privileged identity nobody watches.

Rollback

Gate rollback: switch a blocking check back to advisory for a repository or rule, through configuration under version control, rather than disabling the scanner.
Rule rollback: a new rule pack that floods pull requests is reverted to the previous pinned version while it is tuned.
Never roll back by removing the scan: a missing scan looks the same as a clean one on a dashboard.

Small and large organisations

Decision	Small team (under about 50 developers)	Large organisation
Tool model	Scanning built into the source platform, or open source tools in CI	Central platform with result aggregation across many source systems
Triage	One owner shared with engineering leads	AppSec team plus champions per team
Gates	Secrets and known exploited dependencies only at first	Tiered gates by service criticality
Rule management	Vendor or community defaults, lightly tuned	Curated rule sets per language with change control
Reporting	Monthly fix rate and open criticals	Per-team dashboards, SLA tracking and audit evidence

The open source AppSec tools landscape guide is useful when choosing tools, and the AI-Assisted Code Review and AI SAST Guide covers AI-generated findings and fixes, which need the same baseline and triage discipline.

Detection and measurement

Metric	What it shows	Target (our recommendation)
Coverage: share of active repositories scanned on each pull request	Whether the programme reaches the code that ships	Above 90% of in-scope repositories
Mean time to remediate new critical and high findings	Whether owners act	Within the policy targets
False positive rate per rule (sampled)	Developer trust in the gate	Rules above 30% removed or narrowed
Gate bypasses and suppressions without expiry	Quiet erosion of the control	Every bypass reviewed; zero suppressions without expiry
Live secrets found and time to rotate	Real exposure closed	Rotated within 24 hours
Legacy backlog trend	Debt reduction	Falling each quarter

Also log the scanner's own activity: changes to rules and gates, suppressions, new integrations and token use, and send them to the SIEM. An attacker who wanted a vulnerability to ship would suppress the finding, not delete the scanner.

Common failure patterns

Big bang enablement: every repository scanned and gated at once; developers drown in legacy findings and learn to bypass.
Admin token integration: the scanner connects with a personal administrator token that outlives its owner and can write to every repository.
Unpinned scanner in the pipeline: a compromised scanner release runs in jobs that hold deployment secrets.
Suppressions without owners: findings are marked "won't fix" with no reason or expiry, and the same pattern returns in new code.
Secrets deleted, not rotated: the commit is rewritten but the credential stays valid.
Dashboard counts as success: finding totals are reported upwards while fix rates and bypasses are not measured.

Framework mapping

Activity	NIST SP 800-53 Rev. 5	NIST CSF 2.0	Other
Static analysis and testing in the pipeline	SA-11, SA-11(1)	PR.PS-06	NIST SSDF PW.7, PW.8
Dependency and vulnerability scanning	RA-5, SI-2	ID.RA-01	CISA KEV
Toolchain and process standards	SA-15	PR.PS-06	NIST SP 800-204D
Third-party components and provenance	SR-3, SR-4	GV.SC-07	ATT&CK T1195.002
Scanner identities and tokens	IA-5, AC-6	PR.AA-01, PR.AA-05	ATT&CK T1213.003, T1552.001
Inventory of repositories and software	CM-8	ID.AM-02	Not mapped
Rule, gate and suppression changes	CM-3, AU-6	PR.PS-04	Not mapped

Practitioner checklist

Start with secrets scanning and SCA on a pilot of volunteer repositories across the main languages.
Connect the scanner with an app-style, repository-scoped integration and short-lived CI tokens, never an admin's personal token.
Pin scanner actions by commit hash and images by digest, and keep scan jobs away from deployment secrets.
Run report-only, store a baseline, and gate only on new high-confidence findings.
Record every suppression with reason, owner and expiry.
Rotate every live secret found, then prevent new ones with push protection.
Route findings to code owners with remediation targets, and keep legacy findings in a separate backlog.
Make scanning default for new repositories through templates.
Measure coverage, time to remediate, false positive rate and bypasses, and log rule and gate changes.

SAST, SCA and code scanning tool rollout playbook: phased implementation with security built in