Summary
Dependency and vulnerability scanning identifies known vulnerabilities (CVEs) in third-party dependencies, libraries, container images, and other software components before they are deployed to production.
Description
Modern software relies heavily on open-source and third-party components, which may contain publicly disclosed vulnerabilities (CVEs) or be subject to supply chain compromise. Dependency and vulnerability scanning provides automated, continuous analysis of all software components to detect known security flaws, outdated packages, and license compliance issues. In regulated financial services environments, unpatched vulnerabilities in production systems represent a material operational and compliance risk. Dependency scanning maintains visibility into the software supply chain, enabling rapid response when new vulnerabilities are disclosed.
Requirements
- Application repositories MUST be scanned for known vulnerabilities in direct and transitive dependencies as part of the software development lifecycle
- Dependency scanning MUST be automated — manual-only dependency review is not sufficient as a primary control
- The point(s) and frequency at which dependency scans are executed MUST be defined based on development practices, risk profile, and pipeline architecture
- Container images MUST be scanned for operating system and application-level vulnerabilities as part of the build and deployment process
- Scanning tools MUST be configured to check for vulnerabilities in all relevant ecosystems used by the organisation (e.g., npm, PyPI, Maven, NuGet, Go modules, system packages)
- Vulnerability scanning results MUST be classified by severity and tracked to resolution
- A documented exception and risk-acceptance process MUST exist for vulnerabilities that cannot be immediately remediated, with appropriate approvals and time-bound waivers
- Audit logs of all scan results, remediation actions, and exceptions MUST be retained in accordance with the organisation’s record retention policy
Examples & Commentary
- CI/CD Integration: Configure Software Composition Analysis (SCA) tooling to run on every pull request. Builds targeting production branches should fail if critical or high severity CVEs are detected without an approved exception
- Scheduled Scanning: Even without code changes, new CVEs are disclosed daily. Recurring scans of the default branch and deployed artefacts ensure newly published vulnerabilities are detected against existing codebases
- Container Scanning: Scan base images and final application images in the container registry. Alert on images with known vulnerabilities and enforce policies that prevent deployment of non-compliant images
- Dependency Pinning & Lock Files: Ensure all projects use lock files (e.g.,
package-lock.json,go.sum,Pipfile.lock) to guarantee reproducible builds and prevent silent dependency changes - Triage & Prioritisation: Not all CVEs are equally exploitable. Organisations should consider reachability analysis and environmental context when prioritising remediation efforts, but must still track all findings to closure
- Complementing Component Inventory: This control works alongside Component Inventory (mi-9), which provides the SBOM. Dependency scanning uses the inventory to detect which components are affected when new vulnerabilities are disclosed