Your company has been running production containers for 18 months. Nobody has ever run a vulnerability scan on them. You just got asked by a prospective enterprise customer for your vulnerability management policy. You do not have one.
You need a working program in 90 days. Here is how.
Why Most First-Time Programs Fail?
The most common mistake when building a vulnerability management program is starting with policy instead of practice. You write a document describing your process before you understand what your actual state is, what tools you have, or what your team can sustainably maintain.
The document exists. The program does not.
A working program starts with practice. Get your tools running, get your data, understand your actual state. The policy documents what you are actually doing, not what you aspire to do.
“A vulnerability management policy written before you have run a single scan is a compliance artifact. A policy written to document a functioning program is evidence of maturity.”
Month 1: Establish Visibility
You cannot manage what you cannot see. The entire first month is about getting real data.
Week 1-2: Inventory Your Assets
Pull a complete list of every container image in your registry. For each image, record:
- Image name and tag
- When it was last updated
- Whether it is currently deployed to production
- What team or service owns it
This is your asset inventory. It will have gaps and unknowns. That is fine. Write down what you find.
Week 3-4: Run Your First Scans
Scan every image in your inventory. You want to know:
- Total CVE count by severity (Critical, High, Medium, Low)
- Which images have the most exposure
- What base images are contributing the most vulnerabilities
Secure container software scanning at this stage gives you the baseline. This is your before picture. It will be alarming. That is the point.
Month 2: Establish Process
Now that you know your state, you can build a process to improve it.
Define Your Policy Thresholds
What is acceptable? Most organizations settle on:
- Critical CVEs: must be remediated within 7-14 days of discovery
- High CVEs: must be remediated within 30 days
- Medium/Low: tracked but not time-constrained
These thresholds should be achievable given your team’s capacity. Start conservatively and tighten over time.
Integrate Scanning Into CI/CD
Scanning only your existing images once is not a program. It is an audit. A program catches CVEs continuously, on every new image build.
Add scanning to your CI/CD pipeline. Gate builds on your Critical CVE threshold. Every new image that ships gets scanned automatically.
Software supply chain security practices require catching vulnerabilities at build time, not after deployment. Shifting left is cheaper, faster, and more effective than scanning in production.
Establish a Triage Workflow
Define how findings move from detection to remediation:
- Scanner detects CVE
- Finding routed to image owner
- Owner assesses and prioritizes
- Remediation completed within SLA
- Re-scan confirms fix
This does not need to be complex. A spreadsheet or a simple ticketing workflow works in month two.
Month 3: Automate and Measure
You have visibility. You have a process. Month three is about making it sustainable.
Automate Remediation for the Common Case
The majority of CVEs in most container images are in unused components. Automated hardening can address these without engineer intervention. Set up automated hardening in your pipeline: when a build fails the CVE gate, automated hardening runs first. If it resolves the gate, the build continues. If not, a human review ticket is created.
This automation dramatically reduces the manual load on your team. The 60-80% of CVEs in unused components become automatic. Your team focuses on the 20-40% that require real engineering decisions.
Start Measuring Progress
By end of month three, you should be tracking:
- Baseline CVE count (your month one snapshot)
- Current CVE count (trend down over time)
- Mean time to remediation (days from discovery to fix)
- CI/CD gate pass rate (percentage of builds that pass on first attempt)
These numbers tell you whether your program is working and give you defensible data for your enterprise customer.
Frequently Asked Questions
How do you build a vulnerability management program from scratch?
Start with practice, not policy: run your first scans in month one to establish a real baseline of CVE exposure across all container images before writing any documentation. Month two adds CI/CD integration and a triage workflow with defined remediation SLAs. By month three, automated hardening handles the 60-80% of CVEs in unused components, and you have measurable metrics — MTTR, CVE trend, gate pass rate — that prove the program is working.
What are the first steps to establish a vulnerability management program?
The first two weeks should focus on asset inventory: pull a complete list of every container image in your registry, recording name, tag, last update date, deployment status, and owning team. Weeks three and four run your first scans against every inventoried image to establish the baseline CVE count by severity. This “before picture” is alarming by design — it tells you exactly where to focus remediation effort.
What metrics should a vulnerability management program track?
Track four core metrics: baseline CVE count from your initial scan (your starting reference point), current CVE count over time (should trend down), mean time to remediation in days from discovery to fix, and CI/CD gate pass rate as the percentage of builds passing on first attempt. These four numbers give engineering leadership defensible evidence that the program is functioning and improving, which is exactly what enterprise customers and auditors ask for.
How long does it take to build a vulnerability management program?
A functioning vulnerability management program — continuous scanning, CI/CD integration, automated hardening, defined SLAs, and documented triage workflow — can be operational in 90 days. Month one establishes visibility through asset inventory and baseline scans. Month two adds process through pipeline integration and triage workflows. Month three achieves sustainability through automation and metric tracking. The key is building the practice before the policy.
What to Tell Your Enterprise Customer?
You can now accurately describe your vulnerability management program:
- Continuous scanning integrated into every image build
- Policy thresholds with defined remediation SLAs
- Automated hardening for unused component CVEs
- Documented triage and escalation workflow
- Quarterly risk metrics reviewed by engineering leadership
That is a mature vulnerability management program, built in 90 days. The documentation reflects reality because you built the practice first.