VND-005 ICT Supply Chain Risk Management
Description
Risks in the ICT supply chain are identified, assessed and managed. This includes software dependencies, hardware components, open source libraries and third-party development. A documented supply chain inventory is maintained. Controls are applied to prevent tampering, counterfeit components or insertion of malicious code through the supply chain.
Rationale
Software supply chain attacks (e.g. SolarWinds, XZ Utils) demonstrate that third-party code components are a primary attack vector. SaaS products that embed third-party software must manage this risk explicitly.
Framework Mappings (7)
| STA-01 | Supply Chain Risk Management Policies and Procedures | partial |
| STA-08 | Supply Chain Inventory | full |
| 5.21 | Managing information security in the ICT supply chain | full |
| A.10.3 | Suppliers | partial |
| PM-30 | Supply Chain Risk Management Strategy | partial |
| SR-2 | Supply Chain Risk Management Plan | full |
| SR-3 | Supply Chain Controls and Processes | full |
Evidence (2)
Software Bill of Materials (SBOM) or dependency inventory listing third-party libraries and components embedded in the product, with current vulnerability status.
Example: SBOM export (CycloneDX or SPDX format) generated from CI/CD pipeline (e.g. Syft, OWASP Dependency-Track) — listing all direct and transitive dependencies with: package name, version, license, and known CVE status at last scan
Test: Request the current SBOM or dependency scan output. Verify: (1) SBOM covers all production application dependencies (direct and transitive), (2) scan was run within the last 30 days, (3) all HIGH and CRITICAL CVEs are either patched or have documented risk acceptance with a remediation timeline, (4) SBOM is regenerated as part of the CI/CD pipeline on each build.
ICT supply chain risk management policy or software composition analysis procedure documenting how third-party software components are vetted, monitored and updated.
Example: Software Supply Chain Security Policy (Confluence), approved by CISO — defining: SBOM generation requirements, OSS licence approval process, dependency vulnerability scanning in CI/CD, time-to-patch SLAs by severity (e.g. Critical ≤7 days, High ≤30 days), and prohibited dependency categories
Test: Request the software supply chain policy. Verify: (1) requires SBOM generation for production builds, (2) specifies vulnerability scanning of dependencies as a CI/CD gate, (3) defines time-to-patch SLAs by severity, (4) addresses open source licence approval, (5) approved within 24 months.
Questions (2)
Does your organisation maintain an inventory of third-party software components (including open source libraries) embedded in your products, and are these inventories scanned for known vulnerabilities?
A Software Bill of Materials (SBOM) should be generated for every production build. Dependency vulnerability scanning should be integrated into the CI/CD pipeline. Critical and High CVEs must have documented remediation timelines.
How are third-party software components and open source dependencies managed in your development process?
Automated SBOM generation and CI/CD-integrated vulnerability scanning are the baseline expectation for SaaS products. Manual-only dependency management is insufficient given the pace of vulnerability disclosures.