NIS2 Supply Chain Security — Auditing Third-Party Components in CI/CD

by

NIS2 Article 21(2)(d): Supply Chain Security Requirements

NIS2 Article 21(2)(d) requires essential and important entities to address supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers. For organisations that build and deploy software through CI/CD pipelines, this requirement has far-reaching implications.

The modern CI/CD pipeline is, by its nature, a supply chain. Every build incorporates third-party libraries, base images, external services, and tooling from multiple vendors. A single compromised component anywhere in this chain can propagate through automated pipelines into production environments within minutes. Auditors must therefore assess not only the organisation’s own controls but the governance framework surrounding every third-party element that enters the delivery pipeline.

Third-Party Risks in CI/CD Environments

Understanding the categories of third-party risk in CI/CD is essential for scoping an audit. The following areas represent the primary risk surface:

Open-Source Dependencies

Most modern applications incorporate dozens to hundreds of open-source libraries. Each dependency — and its transitive dependencies — represents a potential vulnerability or attack vector. Risks include known vulnerabilities in outdated packages, malicious packages published under similar names (typosquatting), and compromised maintainer accounts.

CI/CD Platform and SaaS Tooling

Organisations frequently rely on third-party SaaS platforms for source control, build execution, artifact storage, and deployment orchestration. These platforms have privileged access to source code, secrets, and production environments. A breach of any such provider could compromise the entire delivery pipeline.

Shared and Hosted Build Runners

Build environments that are shared across projects or hosted by third parties introduce risks of cross-contamination, data leakage, and insufficient isolation. If a build runner is compromised, every pipeline that uses it is potentially affected.

Base Images and Container Registries

Container-based deployments depend on base images that are often sourced from public registries. These images may contain vulnerabilities, unnecessary components that expand the attack surface, or in rare cases, deliberately malicious content.

SCA and SBOM as Supply Chain Governance Tools

Two key capabilities support supply chain governance in CI/CD environments. Auditors should understand what each provides and verify that the organisation uses them effectively.

Software Composition Analysis (SCA)

SCA provides visibility into the third-party components present in an application. From a governance perspective, SCA delivers:

  • Component inventory: A comprehensive list of all third-party libraries and their versions used in each build
  • Vulnerability identification: Mapping of components against known vulnerability databases
  • Licence compliance: Identification of licence obligations that may create legal or operational risk
  • Policy enforcement: The ability to block builds that include prohibited or high-risk components

Auditors should verify that SCA is integrated into the pipeline as a mandatory gate — not an optional advisory step — and that policy violations result in blocked deployments with documented exception processes.

Software Bill of Materials (SBOM)

An SBOM is a formal, machine-readable inventory of all components in a software artifact. For supply chain governance, SBOMs provide:

  • Transparency: A complete record of what is included in each deployed artifact
  • Incident response support: The ability to quickly determine whether a newly disclosed vulnerability affects any deployed software
  • Regulatory evidence: Demonstrable proof of supply chain awareness and management
  • Supplier accountability: A basis for holding suppliers responsible for the components they provide

Auditors should confirm that SBOMs are generated for every production release, stored with appropriate retention periods, and that the organisation can query them to identify affected systems when new vulnerabilities are disclosed.

Vendor Assessment Framework for CI/CD Tooling Suppliers

Organisations must assess the security posture of their CI/CD tooling suppliers with the same rigour applied to any critical service provider. The following framework outlines the key assessment areas:

Security Certifications and Attestations

  • Does the vendor hold relevant certifications (ISO 27001, SOC 2 Type II)?
  • Are audit reports current and available for review?
  • Does the vendor undergo regular penetration testing by independent assessors?

Data Handling and Isolation

  • How does the vendor isolate customer data and build environments?
  • Where is data stored, and does this comply with applicable data residency requirements?
  • What encryption is applied to data at rest and in transit?

Access and Authentication

  • Does the vendor support and enforce MFA for administrative access?
  • What access does vendor personnel have to customer environments and data?
  • Are privileged access events logged and available to the customer?

Incident Notification

  • What are the vendor’s incident notification commitments and timelines?
  • Do contractual SLAs align with NIS2 Article 23 reporting timelines?
  • Has the vendor demonstrated incident notification in practice?

Supply Chain Transparency

  • Does the vendor disclose its own third-party dependencies and sub-processors?
  • What controls does the vendor apply to its own supply chain?
  • Can the vendor provide SBOMs for its products?

Supply Chain Risk, Controls, and Evidence Mapping

Supply Chain Risk Control Evidence for Auditors
Vulnerable open-source dependency Mandatory SCA scanning at build time with policy-based blocking of critical/high vulnerabilities SCA scan reports per build; blocking policy documentation; exception/waiver records with justification and expiry dates
Malicious package injection (typosquatting, dependency confusion) Approved package registry with namespace controls; dependency pinning and integrity verification Approved registry configuration; package allowlists; integrity verification logs (checksum/signature validation)
Compromised base image Approved base image catalogue; image scanning before use; image signing and verification Approved image list with review dates; image scan reports; signature verification records
CI/CD platform provider breach Vendor risk assessment; contractual security requirements; contingency planning for provider failure Vendor assessment reports (current within 12 months); contracts with security clauses; business continuity plans covering CI/CD platform loss
Shared runner cross-contamination Dedicated or ephemeral build environments; runner isolation policies; post-build environment cleanup Build environment architecture documentation; isolation configuration attestations; cleanup verification logs
Compromised CI/CD plugin or integration Plugin/integration approval process; periodic review of installed plugins; least-privilege permissions for integrations Approved plugin registry; plugin review records; permission matrices for integrations
Lack of component traceability SBOM generation for every production release; SBOM storage and query capability SBOMs for recent releases; evidence of SBOM query capability (e.g., response to a test vulnerability query); retention policy compliance
Vendor lock-in preventing security migration Multi-vendor strategy assessment; data portability evaluation; exit planning Vendor dependency analysis; data export capability documentation; exit plan

Red Flags Auditors Should Watch For

During a supply chain security assessment of CI/CD environments, the following findings should raise immediate concern:

  • No dependency governance policy: The organisation has no documented policy governing the use of third-party components in builds. This suggests a fundamental gap in supply chain awareness.
  • SCA scanning is advisory only: Vulnerability scans run but do not block deployments. Developers can (and do) deploy with known critical vulnerabilities. Look for evidence of builds proceeding despite high-severity findings.
  • No SBOM generation: The organisation cannot produce a component inventory for its deployed software. This makes it impossible to assess exposure to newly disclosed vulnerabilities.
  • Stale vendor assessments: CI/CD tooling vendors were assessed once (perhaps during procurement) but have not been reassessed. Look for assessment dates older than 12 months.
  • Unrestricted public registry access: Builds pull dependencies directly from public registries without an intermediary approved registry or integrity verification. This is a direct exposure to dependency confusion and typosquatting attacks.
  • No base image governance: Teams use arbitrary base images from public sources without scanning, approval, or version pinning. Each unvetted image is a potential entry point for compromise.
  • Shared runners with no isolation evidence: The organisation uses shared build infrastructure but cannot demonstrate that builds are isolated from one another.
  • Missing contractual security requirements: Agreements with CI/CD tooling providers contain no security clauses, no incident notification obligations, and no audit rights.
  • No exception management process: When supply chain controls are bypassed (e.g., a vulnerable dependency is accepted), there is no formal exception process with documented justification, risk acceptance, and expiry date.
  • Plugins and integrations without review: CI/CD platforms have numerous third-party plugins installed with no evidence of security review or approval process.

Related Resources

For a comprehensive examination of NIS2 supply chain security requirements and their implications for CI/CD and vendor management, see NIS2 Supply Chain Security Deep Dive: What It Really Means for CI/CD and Vendors.

For a ready-to-use audit checklist, see NIS2 Supply Chain Auditor Checklist.

Related for Auditors

New to CI/CD auditing? Start with our Auditor’s Guide.