APP-007 Patch and Dependency Management
Description
Third-party software components, libraries, and frameworks are inventoried (software bill of materials). 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.
Rationale
The majority of production applications consist largely of third-party dependencies. Unpatched dependencies are one of the most common breach vectors and are trivially exploitable once a CVE is published.
Framework Mappings (5)
| AIS-07 | Application Vulnerability Remediation | partial |
| 8.19 | Installation of software on operational systems | partial |
| SA-22 | Unsupported System Components | full |
| SI-2 | Flaw Remediation | full |
| CC6.8 | Controls to Prevent or Detect and Act Upon the Introduction of Unauthorized or Malicious Software | partial |
Evidence (2)
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 — confirm in the pipeline run history (confirms the gate is functional).
Questions (2)
Is a software bill of materials (SBOM) or equivalent inventory of third-party dependencies maintained, and are dependencies monitored for known vulnerabilities?
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?
Automated SCA in CI with deployment gates is the baseline expectation. Manual-only processes introduce delays that leave known vulnerabilities unaddressed for extended periods.