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.
NIS2 Supply Chain Auditor Checklist
The sections above describe what auditors look for and why. The checklist below turns those expectations into a structured, ten-part review that mirrors how NIS2 supply chain requirements are actually examined by auditors and supervisory authorities—emphasising governance, technical enforcement, and evidence rather than high-level policy statements. Use it to assess readiness before an audit, or to guide evidence preparation once supervision is under way.
1. Scope and Supplier Identification
Auditor focus
Are all relevant suppliers identified and in scope?
Checklist
- ⬜ Supplier inventory exists and is maintained
- ⬜ Inventory includes:
- software vendors
- CI/CD platforms
- cloud and infrastructure providers
- outsourced ICT services
- ⬜ Suppliers are mapped to supported services or systems
- ⬜ Supply chain scope is formally documented
Typical red flags
- CI/CD providers excluded from supplier scope
- Incomplete or outdated supplier lists
2. Supplier Criticality and Risk Classification
Auditor focus
Are supply chain risks assessed proportionally?
Checklist
- ⬜ Suppliers are classified by criticality
- ⬜ Classification criteria include:
- impact on essential services
- level of privileged access
- data sensitivity
- substitutability
- ⬜ Risk assessments are documented and repeatable
- ⬜ Critical suppliers are clearly identified
Typical red flags
- No distinction between critical and non-critical suppliers
- Risk assessments performed informally
3. Supplier Governance and Ownership
Auditor focus
Who is accountable for supplier risk?
Checklist
- ⬜ Each supplier has a clearly assigned internal owner
- ⬜ Supplier governance roles are defined
- ⬜ Periodic supplier reviews are performed
- ⬜ Supplier-related risks are escalated appropriately
Typical red flags
- Supplier ownership unclear or implicit
- No evidence of ongoing supplier oversight
4. Procurement and Contractual Controls
Auditor focus
Are cybersecurity requirements enforceable?
Checklist
- ⬜ Cybersecurity requirements integrated into procurement
- ⬜ Contracts include:
- security obligations
- incident notification requirements
- cooperation clauses
- ⬜ Security clauses applied consistently to critical suppliers
- ⬜ Contract exceptions are documented and justified
Typical red flags
- Security requirements applied inconsistently
- No traceability between contracts and risk assessments
5. CI/CD Supply Chain Controls
Auditor focus
How is supply chain risk enforced technically?
Checklist
- ⬜ CI/CD pipelines are mandatory for production changes
- ⬜ Access to CI/CD platforms is restricted (RBAC, MFA)
- ⬜ Pipeline modifications are controlled and logged
- ⬜ Segregation of duties is enforced via approvals
- ⬜ Third-party integrations in CI/CD are governed
Typical red flags
- Manual or out-of-band deployments
- Over-privileged CI/CD service accounts
6. Dependency and Software Integrity Controls
Auditor focus
How do you trust what you deploy?
Checklist
- ⬜ Dependency inventories exist for critical applications
- ⬜ Dependency scanning (SCA) is performed
- ⬜ Critical vulnerabilities trigger remediation or decision
- ⬜ SBOMs are available for critical systems (where applicable)
- ⬜ Artifact integrity and provenance are ensured
Typical red flags
- No visibility into dependencies
- Inability to trace deployed artifacts
7. Third-Party Access Management
Auditor focus
Do suppliers have controlled access?
Checklist
- ⬜ Third-party and service accounts are inventoried
- ⬜ Access follows least privilege principles
- ⬜ Privileged access is approved and logged
- ⬜ Periodic access reviews are performed
- ⬜ Access revocation procedures exist
Typical red flags
- Long-lived supplier accounts without review
- Shared or undocumented credentials
8. Monitoring and Detection
Auditor focus
Can you detect supply chain-related events?
Checklist
- ⬜ CI/CD pipeline activity is monitored
- ⬜ Dependency vulnerability alerts are monitored
- ⬜ Supplier-related anomalies are detectable
- ⬜ Alerts have defined escalation paths
Typical red flags
- Logs exist but are not reviewed
- No alerting for CI/CD or dependency issues
9. Incident Response and Supplier Coordination
Auditor focus
Are you prepared for supplier incidents?
Checklist
- ⬜ Incident response plans include supplier scenarios
- ⬜ Supplier escalation and notification paths are defined
- ⬜ Ability to revoke supplier access quickly
- ⬜ Incident simulations or tests performed
- ⬜ Post-incident reviews documented
Typical red flags
- Supplier incidents handled ad hoc
- No documented coordination process
10. Evidence Retention and Auditability
Auditor focus
Can evidence be produced on demand?
Checklist
- ⬜ Evidence retention periods are defined
- ⬜ CI/CD logs and security records are retained
- ⬜ Supplier documentation is archived
- ⬜ Historical evidence can be retrieved
Typical red flags
- Short retention periods
- Evidence scattered across systems
Final Auditor Assessment Questions
Before closing an audit, supervisors typically ask themselves:
- Are supply chain risks clearly understood?
- Are controls enforced technically, not just documented?
- Is evidence reliable, complete, and retrievable?
- Is CI/CD treated as part of the regulated environment?
If these questions can be answered confidently, NIS2 supply chain readiness is usually considered satisfactory.
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.
Related for Auditors
- Glossary — Plain-language definitions of technical terms
- DORA Article 28 Explained
- NIS2 vs DORA Comparison
- Core CI/CD Security Controls
New to CI/CD auditing? Start with our Auditor’s Guide.
