Continuous Automated Scanning — Four Layers

The vulnerability scanning programme operates across four layers, each targeting a distinct component category. Application dependency scanning (Snyk, Dependabot, pip-audit) runs on every code commit via the CI pipeline, alerting on vulnerabilities in the project’s dependency tree. Container image scanning (Trivy, Grype, Snyk Container) runs on every container build and periodically on deployed images, catching vulnerabilities in base images and OS packages disclosed after the image was built.

Infrastructure-as-code scanning (Checkov, tfsec, KICS) runs on every IaC change, catching security misconfigurations before deployment. Operating system scanning (Qualys, Nessus, OpenVAS) runs periodically on the deployed infrastructure, catching OS-level vulnerabilities that arise from unpatched systems or newly disclosed exploits.

Each layer has a defined remediation SLA: 24–72 hours for critical findings, one to two weeks for high-severity findings, and the next planned maintenance window for medium-severity findings. The four-layer architecture ensures that no component category is a blind spot. Findings from all four layers feed into the unified vulnerability management register.

Key outputs

• Four-layer scanning architecture (dependencies, containers, IaC, OS)
• Continuous scanning in CI pipeline and periodic production scanning
• Per-layer remediation SLAs
• Module 9 AISDP evidence

CI Pipeline & Production Scanning

Vulnerability scanning operates on two cadences. CI pipeline scanning catches vulnerabilities before deployment: every code commit, container build, and infrastructure change triggers the relevant scanning layers. Findings that meet the blocking threshold (critical or high severity) prevent the build from proceeding, ensuring that known-vulnerable components do not reach production.

Production scanning catches vulnerabilities disclosed after deployment. A vulnerability in a dependency that was clean at build time may be disclosed days, weeks, or months later. Daily or weekly scans of deployed container images, dependency manifests, and infrastructure configurations against continuously updated vulnerability databases detect these post-deployment disclosures. Snyk Monitor provides continuous monitoring of the deployed dependency tree, alerting within hours of a new disclosure.

The two cadences are complementary. CI scanning prevents introduction; production scanning detects emergence. Both feed findings into the vulnerability management register with the same severity classification and remediation SLAs. The scanning configuration, cadence, and blocking thresholds are documented in Module 9 and Module 2.

Key outputs

• CI pipeline scanning with merge/build blocking on critical/high findings
• Production scanning on a daily or weekly cadence
• Continuous monitoring (Snyk Monitor) for post-deployment disclosures
• Module 9 and Module 2 AISDP evidence

Vulnerability Management Register

The vulnerability management register is a structured record that tracks every identified vulnerability across all scanning layers and testing activities. Each entry records the vulnerability identifier (CVE or equivalent), the severity (CVSS score), the affected component, the discovery source (which scanning tool or test identified it), the discovery date, the remediation deadline (derived from the severity-based SLA), the remediation status, the responsible person, and the verification date (when re-testing confirmed remediation).

The register serves as the single source of truth for the organisation’s vulnerability posture. The current vulnerability count by severity and the remediation status are reported to the governance team as Module 9 compliance metrics. Trends in vulnerability discovery and remediation rates provide leading indicators of the security programme’s effectiveness.

Vulnerabilities that are accepted through an exception process (where remediation is not feasible within the SLA) are documented with the exception justification, compensating controls, and an expiry date. The register is a Module 9 evidence artefact, retained for the ten-year period.

Key outputs

• Structured vulnerability register with per-finding tracking
• Severity-based remediation SLAs and status tracking
• Exception documentation for accepted vulnerabilities
• Module 9 AISDP evidence