Security teams should shift third-party risk management from procurement checks to code-level controls. That means continuously inventorying direct and transitive dependencies, scanning packages and container images before merge or deploy, and enforcing policies on malware, licenses, and provenance. The goal is to control what actually runs in the software supply chain, not just what appears on a vendor register.
Why This Matters for Security Teams
Vendor questionnaires are useful for procurement, but they are a weak control for software delivery because they describe promises, not runtime reality. CI/CD pipelines create the actual trust boundary: dependencies are fetched, images are built, artifacts are signed or not signed, and policy either blocks unsafe code or allows it through. That is where third-party risk becomes operational, especially when transitive packages, build tooling, and container bases are updated faster than contracts or assessments can keep up.
Security teams need controls that can verify what enters the pipeline, not just who supplied it. Standards such as SLSA and NIST SSDF (SP 800-218) both push this model toward provenance, integrity, and secure build practices, which is a better fit for modern supply-chain risk than static due diligence alone. In practice, many teams discover exposure only after a compromised package, poisoned build, or inherited library has already reached production.
How It Works in Practice
Effective third-party software risk management in CI/CD starts with visibility, then adds enforcement. Teams should inventory direct dependencies, transitive dependencies, build-time tools, container layers, and signed artifacts, because each of those can introduce risk even when the original vendor is approved. The goal is to make the pipeline a verification system, not a pass-through.
Operationally, that means shifting controls left and right at the same time. Before merge, the pipeline should scan source dependencies and lockfiles for known malware, high-risk versions, and license conflicts. During build, it should verify provenance, enforce reproducible or traceable builds where possible, and check that artifacts come from approved sources. Before deploy, it should block unsigned or untrusted images, reject unexpected package drift, and require policy exceptions to be explicit and recorded.
- Maintain an inventory of packages, images, build plugins, and transitive dependencies.
- Scan code, artifacts, and containers at commit, build, and pre-deploy stages.
- Enforce provenance checks for high-trust releases and critical environments.
- Track policy violations separately from vulnerability findings so exceptions are visible.
- Reassess exposure whenever a dependency changes, not only on an annual review cycle.
This approach works best when pipeline policy is tied to release gates and ownership is shared between AppSec, platform engineering, and application teams, so findings cannot be ignored as “just a vendor issue.” It tends to break down in environments that allow ad hoc package installation or manually promoted artifacts, because those paths bypass the very controls meant to prove what actually shipped.
Common Variations and Edge Cases
Tighter third-party controls often increase build friction and maintenance overhead, so teams have to balance release speed against assurance. The right level of control depends on how critical the software is, how much it can affect customer data or production systems, and how often the dependency graph changes.
One common variation is vendor-provided SaaS or managed services that do not ship code through the organisation’s own pipeline. In those cases, questionnaires still have value, but they should be supplemented with contract terms, attestation, logging requirements, and integration reviews, because the risk shifts from artifact integrity to service trust and operational dependency. Another edge case is open source software, where there may be no traditional vendor at all; here, provenance, maintainership, and package ecosystem health matter more than procurement paperwork.
Best practice is evolving around provenance and build integrity, especially for teams that rely on shared runners, public registries, or fast-moving dependency ecosystems. The practical question is not whether a third party is “approved,” but whether the team can prove what was built, what was deployed, and whether anything untrusted entered along the way.
Risk and Threat Considerations
Third-party software risk in CI/CD is primarily a supply-chain exposure problem. The main risks are malicious package substitution, dependency confusion, compromised maintainer accounts, and build-path tampering, all of which can turn a trusted delivery pipeline into an attack path.
Failure mechanism: Attackers exploit the fact that pipelines often trust upstream registries, shared build services, and transitive dependencies by default. If a package, image layer, plugin, or build step is poisoned, the pipeline may ingest and distribute the compromise before any questionnaire-based review could detect it.
Impact: Compromised artifacts can reach production, expose data, create backdoors, or undermine signing and release integrity across many downstream systems at once.
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 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-01 — Cyber Supply Chain Risk Management | CI/CD third-party risk is a supply-chain governance problem. |
| PR.DS-08 — Integrity of Software, Firmware, and Information | Pipeline controls must verify software integrity before deployment. | |
| DE.CM-09 — Monitoring for unauthorized software and malware | Pipeline scanning and policy enforcement depend on detecting malicious code or artifacts. | |
| Recommendation — Define supply-chain controls for dependencies, artifact trust, and supplier oversight. Verify software integrity for packages, images, and build outputs before release. Continuously monitor CI/CD inputs for unauthorized or malicious software. | ||
| NIST SP 800-63 | AAL1 — Authenticator Assurance Level 1 | Vendor questionnaires alone are weak evidence; strong assurance requires verifiable controls. |
| Recommendation — Require stronger verification than self-attestation when trust affects software delivery. | ||
| CIS Controls v8 | 8.2 — Inventory of Software Assets | You must know which dependencies and build assets are present in the pipeline. |
| 16.12 — Boundary Defense for Integrity Verification | Artifact verification at build and deploy time is central to supply-chain protection. | |
| 10.4 — Malware Defenses | Scanning packages and images for malicious content is a core control requirement. | |
| Recommendation — Maintain an inventory of dependencies, build tools, and container images. Block untrusted artifacts by enforcing integrity and provenance checks in the pipeline. Scan dependencies and containers for malware before merge and deployment. | ||
| NIST Zero Trust (SP 800-207) | 4.0 — Zero Trust Architecture | Pipeline trust should be based on continuous verification, not supplier reputation alone. |
| Recommendation — Apply continuous verification to artifacts, registries, and build trust decisions. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secret Sprawl and Exposure | CI/CD third-party risk often emerges through exposed tokens, keys, and pipeline secrets. |
| NHI-05 — Overprivileged Non-Human Identities | Build and deploy automation frequently relies on service accounts with excessive privilege. | |
| Recommendation — Harden pipeline secrets and prevent exposed credentials from enabling supply-chain compromise. Restrict pipeline identities to the minimum access needed for each build step. | ||
Practitioner Guidance
What to prioritise: Treat the highest-risk dependencies as the ones with production reach, build-time execution, or broad transitive fan-out. Those are the packages and images that deserve enforced policy first, not just review notes.
What to verify: Verify that every release can be traced to a known source, that unsigned or unexpected artifacts are blocked, and that exceptions are time-bound and visible. If you cannot explain where a dependency came from, the pipeline is not controlling it.
Decision rule: If a third-party component can execute during build or run in production, require artifact scanning and provenance checks before release; if it only appears in procurement records, treat the questionnaire as supplementary evidence, not the control itself.
Practitioner takeaway: The real test is whether the pipeline can prove trust at the point of build and release, because that is where third-party risk becomes executable.
Related resources from NHI Mgmt Group
- How should security teams use third-party risk questionnaires in vendor onboarding?
- How should security teams manage third-party vendor risk across external applications?
- How should security teams secure Python applications that rely on third-party packages and CI/CD pipelines?
- How should security teams manage third-party cyber risk in practice?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
