Cloud vulnerability management for audits
Auditors do not test whether you have vulnerabilities. Everyone does. They test whether you find them on a schedule and fix them within the time your own policy promises.
A cloud vulnerability management program that passes an audit scans four layers continuously: virtual machines, container images, serverless functions and application dependencies. It sets remediation targets by severity in a written policy, routes findings to tickets with owners, and keeps the history showing most findings closed within target and the rest documented as exceptions. The native scanners on all three providers cover the first three layers.
What should be scanned, and with what?
| Layer | AWS | Azure | Google Cloud |
|---|---|---|---|
| Virtual machines | Amazon Inspector | Defender for Servers vulnerability assessment | VM Manager vulnerability reports, SCC |
| Container images | Inspector with ECR | Defender for Containers | Artifact Analysis |
| Serverless functions | Inspector for Lambda | Defender for App Service or Functions | Artifact Analysis for build artifacts |
| Application dependencies | Dependabot, Renovate, Snyk or similar in the repository | ||
| External attack surface | An external scan and an annual penetration test | ||
Remediation targets
Your policy sets the targets, and the auditor tests against them. Pick numbers you can meet, because a policy that promises seven days for criticals and a history showing forty is an exception in the report.
| Severity | Typical target | Note |
|---|---|---|
| Critical, internet-exposed or known exploited | 7 days or less | Anything on the CISA Known Exploited Vulnerabilities list belongs here |
| Critical, internal | 14 days | |
| High | 30 days | |
| Medium | 90 days | |
| Low | Next scheduled update or accepted |
PCI DSS v4.0.1 sets its own rule: critical and high vulnerabilities addressed according to your risk ranking, with critical patches applied within one month of release for in-scope systems.
Exceptions
Some findings cannot be fixed on time: a vendor has not released a patch, or the fix breaks something. Record an exception with the reason, a compensating control, an owner and an expiry date. Auditors accept documented exceptions. They do not accept findings silently past their target.
Rebuild, don't patch
In the cloud the simplest remediation is often a new image. If your infrastructure is defined in code and deployed through a pipeline, patching means updating the base image, rebuilding and redeploying. The pipeline history then doubles as remediation evidence, and nothing drifts.
Evidence an auditor asks for
- The vulnerability management policy with targets.
- Proof scanning covers all in-scope resources: Inspector or Defender coverage reports.
- A sample of findings from the period, each with discovery date, ticket and close date.
- The exception register.
- The latest penetration test report and evidence that its findings were fixed. Cloud penetration testing covers what each provider allows.
Does SOC 2 require vulnerability scanning?
SOC 2 CC7.1 expects you to detect vulnerabilities and configuration changes. It does not name a scanner or a frequency, but every auditor expects regular scanning with remediation tracked against your policy.
Is Amazon Inspector enough for vulnerability scanning?
For EC2 instances, ECR images and Lambda functions, yes. It does not scan your application code's logic or your external attack surface, so pair it with dependency scanning in the repository and an annual penetration test.
How do we handle a flood of findings when we first turn scanning on?
Baseline them. Fix criticals first, create a dated plan for the backlog, and start the remediation clock from the day scanning began. Auditors care that the process runs from the start of the window, not that the backlog was zero on day one.
Need a vulnerability program that runs itself?
Firms in the network set up scanning, ticket routing and the policy.
Get matched