Procedure 05 TECHNICAL
Vulnerability Management Policy — how Revique implements this rule today, and how an auditor verifies it.
Policy 05 · PCI DSS Req 6.3, 11.3 · 1 of 6 policy statements fully met · AWS facts collected read-only 2026-08-13
← All 21 procedures
📘← Back to Policy 05 — Vulnerability Management PolicyThe rule this procedure implements
How Revique implements this today
Container images are built through CodeBuild and pushed to ECR. All five ECR repositories across the estate are configured with immutable tags, so a published image tag cannot be silently replaced. The native application repository in the dev account has scan-on-push enabled, so every image is scanned for known CVEs as it is pushed. Runtime threat detection in production is provided by GuardDuty (Procedure 03/10). Dependency vulnerabilities are surfaced at build time by the toolchain rather than by an AWS service.
The rule against the current state
Each row takes a statement from Policy 05 and states what is actually configured. Meets = implemented as written. Partial = implemented, but not everywhere or not to the full standard. Gap = not implemented. N/A = not verifiable from infrastructure configuration.
| The rule | Current state | Verdict |
|---|
| Container images scanned for known vulnerabilities before deployment | Scan-on-push is enabled on 1 of 5 ECR repositories — the native application repository in dev. The four CDK asset repositories (one per account/region) have it disabled. | Partial |
| Vulnerability scanning on a regular defined schedule | No scheduled scanning service is enabled. Amazon Inspector is disabled in all three accounts and both regions, for EC2, ECR and Lambda alike. | Gap |
| Vulnerabilities ranked by risk | ECR scan findings carry CVE severity; without Inspector there is no estate-wide ranked view. | Partial |
| Critical/high remediated within a defined window | Remediation tracking is procedural; no AWS-side SLA enforcement exists. | Partial |
| A defined process to learn of new vulnerabilities | Administrative — relies on the engineering team's monitoring of upstream advisories. | Partial |
| Image tags cannot be overwritten | All 5 ECR repositories set imageTagMutability = IMMUTABLE. | Meets |
🔍 Auditor verification — where to log in and what you will see
Scan-on-push settingConsole → ECR → Repositories → select a repository → Scan on push. Enabled on the native application repository (dev account, us-e****-1); disabled on the CDK asset repositories.
Tag immutabilitySame screen → Tag immutability = Enabled on all repositories.
Scan findingsECR → Repositories → select repository → Images → a scanned image shows its vulnerability count and CVE list.
Inspector statusConsole → Amazon Inspector → Account management, in each account and both regions — expect Disabled.
Team process
Engineering remediates findings as part of normal sprint work; the Security Officer owns the process and tracks critical and high findings to closure. Image rebuilds go through the same CodePipeline and, for production, the same manual approval gate described in Procedure 02.
⚠️ Where reality does not meet the policy
- Amazon Inspector is disabled everywhere (all three accounts, both regions, all resource types). There is therefore no continuous, scheduled vulnerability assessment of EC2 instances, container images or Lambda functions — the policy's “regular, defined schedule” requirement is not met.
- Scan-on-push covers only 1 of 5 ECR repositories, and the production account has no application image repository of its own — production images are consumed from elsewhere, so pre-deployment scanning of what actually runs in production is not evidenced.
- No ranked vulnerability register with remediation deadlines exists; the policy's [X]-day remediation window is undefined and unenforced.
Evidence location. Dependency scan output and remediation tickets are held in the build system and issue tracker.
📘Back to the PolicyPolicy 05 — Vulnerability Management Policy (PCI DSS Req 6.3, 11.3)←