APP-007 Software Supply Chain and Dependency Management
Description
Third-party software components, libraries, frameworks and open source dependencies are inventoried in a software bill of materials generated for each production build. Dependencies are monitored for known vulnerabilities and outdated versions. Security patches for critical vulnerabilities are applied within defined timeframes. Unsupported or end-of-life components are replaced or mitigated. Binary or machine-executable components from a source that provides neither source code nor a warranty are not used, and an exception is granted only on a recorded operational justification approved by the named owner with a review date.
Rationale
Most of a production application is third-party code, and unpatched dependencies are among the commonest breach vectors once a vulnerability is published. A binary-only component from an unwarranted source is worse than an unpatched one: nobody can read it, nobody is contractually obliged to fix it and a composition analysis tool reports only what its metadata claims. Recording the exception, instead of banning the case outright, keeps the rule from being routed around silently.
Applicability (9 profiles)
The deployer's own builds. The product's bill of materials is the provider's, obtained under VND-002 where contracted.
The deployer's own builds. The product's bill of materials is the provider's, obtained under VND-002 where contracted.
Framework Mappings (17)
| AIS-07 | Application Vulnerability Remediation | partial |
| MDS-12 | Open Model Risk Assessment | informative |
| STA-09 | Service Bill of Material (BOM) | partial |
| AIS-07 | Application Vulnerability Remediation | partial |
| STA-09 | Service Bill of Material (BOM) | partial |
| 5.21 | Managing information security in the ICT supply chain | informative |
| 8.19 | Installation of software on operational systems | informative |
| AML.M0016 | Vulnerability Scanning | informative |
| AML.M0023 | AI Bill of Materials | informative |
| NIS2-CIR-6.1 | Security in Acquisition of ICT Services or ICT Products | partial |
| CM-7(8) | Least Functionality | Binary or Machine Executable Code | full |
| SA-22 | Unsupported System Components | full |
| SI-2 | Flaw Remediation | full |
| SR-4 | Provenance | partial |
| ASI04 | Agentic Supply Chain Vulnerabilities | partial |
| LLM04 | Supply Chain | partial |
| CC6.8 | Controls to Prevent or Detect and Act Upon the Introduction of Unauthorized or Malicious Software | partial |
Evidence (4)
Software Composition Analysis (SCA) scan output showing a current software bill of materials (SBOM) and the status of known vulnerabilities in third-party dependencies.
Example: Snyk Open Source, Dependabot, OWASP Dependency-Check, or equivalent SCA tool report for the main repository, run within the last 7 days, listing all third-party dependencies, their current version, available patched version, associated CVEs, and severity ratings.
Test: Request the latest SCA scan report. Verify: (1) the scan covers all production application repositories, (2) the report was run within the last 7 days (or is triggered on every PR), (3) all critical and high CVEs in dependencies have a remediation ticket with a target date within the policy SLA, (4) any dependency flagged as end-of-life or unsupported has a documented migration plan.
CI/CD pipeline configuration showing that dependency vulnerability checks run automatically and that failing checks (above a defined severity threshold) block deployment.
Example: GitHub Actions, GitLab CI, or CircleCI pipeline configuration file (e.g. .github/workflows/sca.yml) showing an SCA step that runs on every PR and fails the build if any dependency with a CVSS score above the defined threshold (e.g. ≥ 7.0) is detected.
Test: Review the CI pipeline configuration files for the SCA step. Verify: (1) the SCA check runs on every pull request and on every merge to the main branch, (2) the severity threshold for build failure is documented and aligns with the vulnerability management SLA policy, (3) the pipeline has blocked at least one PR in the last 90 days due to a dependency finding, confirmed in the pipeline run history (confirms the gate is functional).
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.
Exception register for binary-only components that carry neither source availability nor a supplier warranty.
Example: Binary component exception register, 2026 Q3
Test: Request the dependency inventory and the exception register. Verify: (1) the inventory distinguishes components supplied as source from binary-only components, (2) every binary-only component in a production build appears on the register, (3) each entry carries the operational justification, a named approver and a review date that has not passed, (4) a component whose exception has expired is absent from the current build or carries a renewed approval, (5) the register is reconciled against the current bill of materials rather than maintained separately from it.
Questions (2)
Is a software bill of materials generated for each production build?
Monitoring must be continuous, not just at the time of initial selection. SCA tooling integrated into CI is the expected mechanism, not periodic manual checks.
Which dependency and patch management practices are in place?
Options run from the most commonly in place to the least. Automated composition analysis in the pipeline with a deployment gate is the baseline; manual-only review leaves published vulnerabilities unaddressed for weeks. A binary-only component from an unwarranted source is worse than an unpatched one: nobody can read it, nobody is obliged to fix it, and the scanner reports only what its metadata claims.