Teams should not treat them as separate choices. Package scanning finds risky components, but CI/CD access governance determines who can introduce or approve them. In a high-velocity pipeline, governance over build identities and promotion rights is the control that keeps scanning findings from becoming live exposure.
How to think about the first control to prioritise
The right sequencing question is not “scanning or governance?”, it is “which control stops bad change from becoming release?”. Package scanning improves detection, but CI/CD access governance controls who can introduce, approve, and promote software in the first place. When pipelines move fast, build identity and promotion rights are the higher-leverage control because they shape what scanning ever gets to inspect.
That means the practical priority is to secure the pipeline decision points first, then use scanning as a validation layer. If teams can merge, sign, publish, or promote without clear ownership, least privilege, and approval boundaries, scanning often becomes a late signal rather than a preventive control.
For the governance side of the problem, CI/CD Pipeline Identity Security Guide is the clearest match because it focuses on the identities, tokens, and trust paths that determine whether a pipeline can be safely controlled.
Why package scanning and access governance solve different problems
Package scanning answers “what is in the software?”, while access governance answers “who can put it there and who can ship it?”. Scanning is strongest when it catches vulnerable or malicious components early, especially in dependency-heavy builds. Governance is stronger when the main risk is unauthorized introduction of code, credentials, or build artefacts through overbroad pipeline permissions.
Teams often overestimate scanning because it is visible and measurable. In practice, a clean scan does not protect a pipeline that allows an overprivileged build identity to pull in unreviewed code, publish unsigned artefacts, or bypass promotion rules. That is why governance is usually the more fundamental control in high-velocity CI/CD environments.
Useful reference material on the broader lifecycle side is NHI Lifecycle Management Guide, because CI/CD access governance is not just about granting access, it is also about rotation, revocation, and removing stale build identities.
For the component-risk side, Guide to the Secret Sprawl Challenge reinforces why package and pipeline scanning matter, but it also shows that exposed secrets and hidden credentials are often part of the same problem set.
What good prioritisation looks like in a delivery pipeline
A sensible order is: establish who can act in the pipeline, then verify what the pipeline consumes and emits. Concretely, that means tightening build-service permissions, limiting who can approve releases, and separating trusted from untrusted execution paths before expecting scanning to carry risk reduction on its own. Scanning is still necessary, but it should not be the only gate that stands between a risky dependency and production.
Governance becomes even more important when a pipeline uses short-lived tokens, OIDC federation, or automated publishing. Those controls reduce secret exposure, but they also increase the need for precise authorization because the pipeline itself becomes a powerful actor. A team that has not bounded that actor can end up with fast, well-instrumented, but still overly permissive delivery.
For implementation patterns, CI/CD Pipeline Identity Security Guide and Guide to the Secret Sprawl Challenge are complementary because one addresses pipeline authority and the other addresses credential and secret exposure.
Risk and Threat Considerations
When CI/CD access is too broad, the pipeline becomes a high-value abuse path: an attacker only needs one weak approval boundary, token leak, or compromised maintainer account to alter what gets built or released. Package scanning may still detect a bad component, but it can arrive too late if the attacker can also change the build logic, suppress checks, or promote a tampered artefact.
Failure mechanism: Excessive pipeline privilege lets malicious or compromised identities insert code, replace dependencies, or bypass release controls before scanning can stop the change.
Impact: The organisation can ship compromised software, leak secrets, or inherit a persistent supply-chain foothold that is harder to detect than a simple vulnerable package.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while OWASP ASVS and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | CI/CD build identities and release tokens can be overly permissive. |
| NHI-07 — Long-Lived Secrets | Pipeline tokens and credentials often persist longer than needed. | |
| NHI-02 — Secret Leakage | CI/CD scanning and release exposure often begin with leaked tokens or keys. | |
| Recommendation — Restrict pipeline identities to the minimum permissions needed for build and publish actions. Replace durable CI/CD credentials with short-lived, tightly scoped credentials. Scan and protect pipeline secrets, artefacts, and logs that can expose credentials. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Release and approval actions in CI/CD are privileged functions that need authorization. |
| Recommendation — Authorize pipeline functions separately from ordinary developer operations. | ||
| OWASP ASVS | V8 — Authorization | The question is about who can perform release-relevant actions. |
| Recommendation — Verify that release, approval, and publish actions require explicit authorization paths. | ||
| SLSA | Supply-chain integrity | CI/CD governance and package scanning both contribute to build provenance and release integrity. |
| Recommendation — Strengthen provenance, signing, and trusted build paths before promoting artefacts. | ||
| MITRE ATT&CK | Credential Access and Supply Chain Abuse | Compromised CI/CD access is a common route to tamper with builds and deploy malicious code. |
| Recommendation — Map pipeline abuse paths to attacker techniques and monitor for privileged build account misuse. | ||
Practitioner Guidance
What to prioritise: Treat CI/CD access governance as the control that determines release authority, and treat package scanning as the verification layer that checks what that authority introduced. If you can only harden one area first, harden the identities, tokens, and promotion rights that can move software toward production.
What to verify: Confirm that build identities are narrowly scoped, approval paths are explicit, and release permissions are separable from routine developer access. If the same principal can change code, approve it, and publish it, scanning is compensating for a governance gap rather than reducing risk on its own.
Practitioner takeaway: The best sequencing is to stop unauthorised software movement first, then inspect the software for what remains. Governance sets the boundary; scanning validates the contents.
Related resources from NHI Mgmt Group
- Should organisations prioritise external exposure or internal credential governance first?
- When should teams prioritise CI/CD hardening over broader secret scanning?
- How should security teams choose between developer-first DAST and security-team-led production scanning in modern CI/CD environments?
- Should security teams prioritise access governance or audit automation first?