A SAST, SCA or code scanning tool reads every repository you own, runs inside your pipelines next to your deployment secrets and keeps a ranked list of your unfixed vulnerabilities, so a compromised scanner is both a source code leak and a supply chain attack waiting to happen. Static analysis, software composition analysis and related code scanners connect to source control with broad tokens, check out and sometimes build code, resolve dependencies from public and private registries, post results to pull requests and gate releases. This guide is for application security leads, DevSecOps and platform engineers who run such a tool, hosted or self-hosted. It covers what the tool holds, admin roles, the source control and CI credentials it uses, scan runners, findings and suppressions, the scanner's own supply chain, logs and lifecycle. How to build an application security programme is in the Application Security Guide; this page is about protecting the tool itself. It is vendor-neutral: confirm exact setting names in your vendor's documentation.
Key takeaways
- The source control integration is the crown jewel. An app or token that reads every repository, and often writes comments, statuses or fix branches, deserves the same governance as a deploy key.
- The scanner is itself a dependency. In 2026 attackers turned a widely used open source scanner into a credential stealer inside customer pipelines; pin, verify and isolate scanner versions.
- Scan runners execute untrusted code. Resolving dependencies and building projects runs install scripts, so runners must hold no secrets beyond what one scan needs.
- Suppressions are security decisions. Ignore rules, baselines and gate overrides hide real vulnerabilities; require a reason, an owner and an expiry.
- Findings and code snapshots are sensitive data. They include secrets found in code and a list of exploitable weaknesses; scope access by project.
What the tool holds and can do
NIST SP 800-218, the Secure Software Development Framework (SSDF) version 1.1, includes practice PO.3, Implement Supporting Toolchains, whose task PO.3.2 asks organisations to follow recommended security practices to deploy, operate and maintain tools and toolchains. Practice PO.5 asks for development, build, test and distribution environments to be separated and protected. A code scanner sits across all of those environments.
| Component | What it holds or can do | If an attacker controls it | Primary control |
|---|---|---|---|
| Console and organisation settings | Users, roles, projects, policies, gates, integrations | Reads all findings, disables gates, adds admins | SSO with phishing-resistant MFA, few admins, scoped roles |
| Source control integration | App installation or token with read on repositories, often write for comments, statuses or fix branches | Clones all code; pushes changes if write is granted (T1199) | Installation scoped to needed repositories, minimum permissions, short-lived tokens |
| Code snapshots and caches | Copies of source, sometimes build artefacts | Source code theft (T1213) | Retention limits, encryption, residency checks |
| Findings, secrets findings and SBOMs | Vulnerabilities with code locations, secrets found in code, dependency inventory | An exploitation list and working credentials (T1552.001) | Project-scoped access, masked secrets, export alerts |
| CI tokens and pipeline steps | Run scans and upload results from pipelines | Malicious scanner step steals pipeline secrets (T1195.001) | Pinned, verified scanner versions; scoped per-project tokens |
| Scan runners and agents | Check out, build and resolve dependencies | Install scripts run with runner credentials | Ephemeral, isolated runners with no standing secrets |
| Registry credentials | Pull private packages for SCA resolution | Reads or publishes private packages | Read-only, per-registry credentials |
| Policies, gates and suppressions | What blocks a release and what is ignored | Lets vulnerable code ship silently | Change approval, audit and expiry |
Admin roles and console access
- Role design: separate platform administrator (settings, integrations, roles), policy owner (rules, gates, severity thresholds), project owner (onboards repositories, manages that project's suppressions), developer (sees and fixes findings for their projects) and auditor. Changing global policy or gates is a high-impact right.
- Scope by project: developers should see findings for the repositories they work on. Organisation-wide findings access belongs to a handful of AppSec staff.
- Authentication: SSO with phishing-resistant MFA, roles from identity provider groups, and one tested break-glass account. The CISA and FBI Secure by Demand guide suggests asking whether SSO is offered at no extra cost and whether MFA or passkeys are on by default. See the Break-Glass Account Guide.
- Admin devices: follow the NCSC secure system administration principles, including trusted management devices and logging of all administration. See the Privileged Access Workstations Guide.
- Personal access tokens: developers and IDE plugins often create API tokens to query results. Set a maximum lifetime, scope them to read, and expire them when people leave.
Source control and CI credentials
The OWASP Top 10 CI/CD Security Risks lists CICD-SEC-8, Ungoverned Usage of 3rd Party Services, and recommends vetting third parties before granting access, granting minimum permissions, keeping visibility of each integration method, its granted permissions and the permissions it actually uses, and removing integrations no longer needed. CICD-SEC-6, Insufficient Credential Hygiene, recommends short-lived credentials, no reuse across contexts, binding credentials to conditions such as source addresses, and scoping pipeline secrets to the steps that need them.
| Credential | Needs | Avoid | Pattern |
|---|---|---|---|
| Source control app or integration | Read code; write statuses and comments | Organisation admin, write to code or workflow files | App installation on selected repositories, short-lived installation tokens, no code write unless fix branches are approved |
| Fix branch or auto-remediation bot | Open branches and pull requests | Direct pushes to protected branches | Separate identity, branch protection and human review on every change |
| CI scan token | Upload results for one project | Organisation-wide admin tokens in pipeline variables | Per-project token from the CI secret store, or federated pipeline identity where supported |
| Private registry credentials | Resolve dependencies for SCA | Publish rights, shared developer credentials | Read-only token per registry |
| Self-hosted runner registration | Enrol a runner with the platform | One shared, non-expiring key | Per-runner credential, revoked at retirement |
| Ticketing and chat integrations | Create tickets, post alerts | An employee's personal token | Service account with project-level rights |
- Inventory them: review the scanner's installations and tokens alongside every other source control integration. See How to audit GitHub Apps and OAuth apps in an organisation and the CI/CD Pipeline Identity Security Guide.
- Monitor use: alert when the scanner identity clones repositories outside scan schedules, from unexpected addresses, or calls write permissions it does not normally use.
The scanner's own supply chain
Scanners run inside pipelines that hold cloud keys, signing keys and registry tokens, which makes them an attractive target. In the Trivy supply chain attack in 2026, a stolen token and an incomplete credential rotation let attackers turn a security scanner into a credential stealer, and credentials stolen that way were then used in the Checkmarx KICS supply chain attack to poison scanner container images and IDE extensions. The OWASP CI/CD guidance cites the earlier Codecov breach, where a CI tool was used to steal environment variables from builds.
- Pin versions immutably: reference scanner pipeline steps by commit hash and container images by digest, not by mutable tags. See How to Pin GitHub Actions to Commit SHAs.
- Verify before use: check signatures or checksums where the project publishes them (NIST SP 800-53 CM-14 Signed Components).
- Stage upgrades: move to new scanner versions through a test project before the whole organisation, and read release notes for changed permissions.
- Run with least privilege: give the scan step no access to deployment secrets; run it in its own job with only the scan token. CICD-SEC-8 recommends third parties running in builds operate in a restricted context with strict ingress and egress filtering.
- Watch IDE plugins: scanner extensions in developer IDEs hold tokens too; allow only approved publishers and versions. See the GlassWorm VS Code Extension Worm Guide.
Scan runners and build isolation
- Ephemeral runners: SCA and some SAST engines must build or resolve dependencies, which executes package install scripts. Use a fresh, disposable runner per scan so nothing persists between projects. See the Self-hosted CI/CD Runners and Build Agents guide.
- Restrict egress: allow the runner to reach the platform, approved registries and source control only; block cloud metadata endpoints.
- Separate trust levels: do not scan untrusted forks and internal production repositories on the same runner pool.
- No standing secrets: inject the scan token for the job, then discard it with the runner.
Findings, suppressions and AI features
- Scope and mask: limit findings to project teams, and mask secrets detected in code; send each live secret to revocation through the Secrets Management Guide process rather than leaving it in a findings list.
- Suppression discipline: inline ignore comments, baseline files and rule disables in the console all hide findings. Require a reason and expiry, review suppressions of critical and high findings, and alert when a gate is bypassed. See the SAST Triage Guide.
- Protect policy as code: if scanner configuration lives in repositories, protect those files with code owner review so a pull request cannot quietly disable rules.
- AI fix and explanation features: find out whether code is sent to an external model provider, whether it is retained or used for training, and turn the feature off for sensitive repositories until that is settled. See the AI-Assisted Code Review and AI SAST Guide.
- Retention and residency: set retention for code snapshots and findings, confirm where a hosted service keeps them, and ask how vendor staff access is approved and logged.
The tool's own logs
| Event to capture | Why it matters | Alert? |
|---|---|---|
| Role, SSO or user change; API token created | Persistence and widened access (T1098) | Always for admin |
| Source control integration permissions changed or repositories added | Wider code access or new write rights (T1199) | Always |
| Global policy, rule or gate changed | Vulnerable code allowed to ship | Always |
| Suppression of critical or high finding; gate override | Hides real weakness | Bulk or critical |
| Findings export, code snapshot download, bulk API read | Data theft (T1213) | Above baseline |
| Runner registered or scanner version changed | Rogue runner or tampered scanner (T1195.001) | Always for registration |
- Export it: stream the audit log to a SIEM the tool's admins cannot change (NIST SP 800-53 AU-9(2), AC-6(9)). Also collect source control audit events for the scanner's identity, since that is where code access shows up.
- Retention: Secure by Demand asks SaaS providers to keep security logs for at least six months at no extra charge; export if your plan keeps less.
Lifecycle
| Stage | Security actions |
|---|---|
| Buy | Ask the Secure by Demand questions; confirm project scoping, minimum source control permissions, short-lived tokens, secret masking, audit export, signed releases, AI data handling and residency. See the SAST, SCA and code scanning tool buyer's guide. |
| Deploy | SSO first; roles and projects; integration installed on selected repositories; pinned scanner versions; ephemeral runners; audit export on day one. See the SAST, SCA and code scanning tool rollout playbook. |
| Run | Quarterly review of roles, tokens, integration permissions and suppressions; staged scanner upgrades; runner patching. |
| Respond | If the scanner, its integration or a scanner release is suspected compromised, follow If your SAST, SCA and code scanning tool is compromised: revoke the integration and tokens, rotate every secret the scan jobs could reach, and review commits and pull requests made by the scanner identity. |
| Retire | Uninstall the source control integration, revoke API, CI and registry tokens, remove pipeline steps, decommission runners and obtain written confirmation that code snapshots and findings are deleted (MP-6). |
Roll back a hardening change, such as removing a permission from the source control integration, by restoring only the permission a failing feature needs and recording why, never by granting organisation admin.
Choosing controls by size
- Small teams: focus on scoping the source control integration, pinning scanner versions and keeping the scan step away from deployment secrets. These three controls address the main ways scanners have been abused.
- Large organisations: add project-scoped findings, dual approval for global policy changes, ephemeral runner pools by trust level and quarterly suppression reviews.
- Open source scanners in pipelines: you are the operator; there is no vendor console, so pinning, verification and pipeline least privilege carry the full weight.
Detection and measurement
- Source control integrations with permissions beyond read code plus write statuses and comments (target: zero unapproved).
- Scanner pipeline steps and images pinned to a hash or digest (target: 100 per cent).
- Scan jobs that can reach deployment secrets (target: zero).
- Suppressions of critical and high findings without reason or expiry (target: zero).
- Users with organisation-wide findings access (target: five or fewer, our suggestion).
- API tokens older than their maximum lifetime or unused for 30 days.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | Threat addressed |
|---|---|---|---|
| Console roles and project scoping | AC-2, AC-6, AC-6(5) | PR.AA-05 | T1078 Valid Accounts |
| Source control and CI credentials | IA-5, AC-6 | PR.AA-01 | T1528 Steal Application Access Token |
| Scanner integrity and versions | CM-14, SI-7, SR-3 | GV.SC-07 | T1195.001 Compromise Software Dependencies and Development Tools |
| Testing toolchain and gates | SA-11, SA-15, RA-5 | PR.PS-06 | Vulnerable code released |
| Findings and code snapshots | SC-28, MP-6 | PR.DS-01 | T1213 Data from Information Repositories |
| Audit log protection | AU-9(2), AC-6(9) | PR.PS-04 | T1098 Account Manipulation |
Common failure patterns
- All repositories, write access: the integration was installed organisation-wide with write rights to enable one fix-branch feature.
- Floating scanner tags: pipelines pull the latest scanner image or action on every run, so a poisoned release reaches every build at once.
- Scan step in the deploy job: the scanner runs in the same job as cloud and signing credentials.
- Long-lived runners: one runner builds every project and keeps caches and credentials between jobs.
- Permanent suppressions: critical findings ignored in a baseline file nobody reviews.
- Secrets left in findings: detected secrets sit in the scanner and in tickets, unrevoked.
Practitioner checklist
- Enforce SSO with phishing-resistant MFA, group-based roles and a tested break-glass account.
- Scope the source control integration to selected repositories with minimum permissions and short-lived tokens.
- Separate platform, policy, project owner and developer roles, and scope findings by project.
- Pin scanner steps and images by hash or digest, verify signatures and stage upgrades.
- Run scans on ephemeral, egress-restricted runners in jobs with no deployment secrets.
- Use read-only, per-registry credentials for dependency resolution.
- Require reason, owner and expiry for suppressions and gate overrides, and review them quarterly.
- Mask detected secrets and route each to revocation.
- Export the tool's audit log and the integration's source control activity to a SIEM.
Standards and references
- NIST: SP 800-218 Secure Software Development Framework (SSDF) Version 1.1
- OWASP: Top 10 CI/CD Security Risks
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- NCSC: Secure system administration
- CISA and FBI: Secure by Demand Guide
- MITRE ATT&CK: Compromise Software Dependencies and Development Tools
Related NHI Mgmt Group resources: Application Security Guide · SAST, SCA and code scanning tool health check · SAST, SCA and code scanning tool integration security guide · Software Supply Chain Security Guide · Securing the DAST and API security testing tool itself