Vulnerability management: a work queue, not a report
Deduplicate the findings, rank them by whether they are actually reachable, give each one an owner and a remediation, and track it until a rescan confirms it is gone.
What is Vulnerability Management?
DevOpsArk vulnerability management is the module that consolidates vulnerability findings from every scanner, deduplicates and prioritises them by real exposure, assigns ownership, and tracks each finding through remediation to verified closure.
What Vulnerability Management is for
The conditions this module removes. If none of these are familiar, you probably do not need it yet.
- The vulnerability report has 12,000 rows and produces no decisions.
- The same base-image CVE is counted 300 times because 300 services share the layer.
- Severity is CVSS, which does not know whether the affected code is ever loaded.
- A finding has no owner, so it stays open until someone runs the report again.
- A fixed vulnerability reappears next month because the fix was applied to a running container rather than the image.
Findings from every scanner and every source are consolidated into one model and deduplicated: a vulnerability in a shared base image becomes one item affecting many services rather than many identical items. Each item is then scored on exposure (is the workload internet-reachable, is the vulnerable package actually loaded at runtime, does the workload hold credentials, what data can it reach), which reorders the list into something worth working from top to bottom. Ownership comes from the application catalogue, so a finding arrives at a team rather than in a queue. Remediation is stated concretely: the base image version to move to, the dependency version to bump, or the configuration to change, together with the number of services the same action would fix. Closure is verified by rescan of the rebuilt artifact, so a fix applied to a running container without rebuilding the image does not count as closed.
What Vulnerability Management does
The 8 capabilities that make up Vulnerability Management.
Consolidation and deduplication
One item per distinct vulnerability, with the list of affected services attached rather than one item per service.
Exposure-based risk scoring
Reachability, runtime loading, credential access and data sensitivity, combined with severity to produce a working order.
Owner assignment
Findings reach the team that owns the affected service, with escalation when a service level target is at risk.
Concrete remediation
The specific version or configuration change, plus how many other services the same change resolves.
Verified closure
A finding closes when a rescan of the rebuilt artifact confirms it, not when someone marks it done.
Remediation SLAs
Time-to-fix targets per severity and exposure class, with ageing visible per team.
Risk acceptance with expiry
Accept a risk explicitly, with a justification, an approver and an expiry date after which it returns.
Backlog trend
Whether the backlog is shrinking, and which teams are keeping pace with inflow.
How Vulnerability Management fits together
Outcomes
- 12,000 rows become a few hundred distinct problems.
- The top of the list is genuinely the most urgent work.
- Fixing one base image closes hundreds of findings in one action.
- Closure is verified, so the number reflects reality.
- Accepted risks expire instead of quietly becoming permanent.
Using Vulnerability Management, step by step
The path from connecting a source to getting value, in the order it happens.
- 1Ingest findings
Results from every scanner and source arrive in one model.
- 2Deduplicate
Distinct vulnerabilities are separated from repeated ones.
- 3Score exposure
Reachability, loading, credentials and data access set the working order.
- 4Assign and target
Owners are set from the catalogue and SLA clocks start.
- 5Remediate
The stated change is applied through the normal delivery path.
- 6Verify
A rescan of the rebuilt artifact confirms closure.
Where teams apply Vulnerability Management
Turn a scan report into a work queue
Deduplicate, prioritise by exposure and assign owners so the list produces action.
Fix hundreds of findings at once
Identify the shared base image behind the largest cluster of findings and rebuild the affected services in one pass.
Track remediation performance
Watch time-to-fix and backlog trend by team rather than a single organisation-wide count.
Evidence a remediation process
Show SLA adherence, verified closures and expiring risk acceptances from one record.
What Vulnerability Management works with
Named integrations link to their own page. The rest are supported runtimes and formats.
Vulnerability Management: frequently asked questions
The 8 questions teams ask most often before adopting Vulnerability Management.
Vulnerability management is the continuous process of identifying, prioritising, remediating and verifying security weaknesses across software and infrastructure. Scanning produces findings; vulnerability management is what turns those findings into completed work.
CVSS describes how bad a vulnerability could be in general. Risk-based prioritisation adds context specific to your environment: whether the workload is internet-reachable, whether the vulnerable code path is actually loaded, whether the workload holds credentials and what data it can reach. The resulting order is usually very different.
Because many services share a base image, so one vulnerable package produces one finding per service. DevOpsArk collapses these into a single item with the affected services listed, which also makes the efficient fix obvious: rebuild the base image once.
By rescanning the rebuilt artifact. A finding does not close because someone marked it done, and a change applied to a running container without rebuilding the image does not close it either, because the next deployment would reintroduce it.
A time-to-fix target for a class of finding, typically set by severity and exposure, for example, internet-reachable critical findings within seven days. DevOpsArk tracks ageing against the target per team so the conversation is about specific overdue items.
Yes, explicitly: with a justification, a named approver and an expiry date. When the date passes the finding returns to the queue, so an acceptance does not silently become permanent.
Yes. Cloud and cluster posture findings enter the same queue with the same prioritisation, ownership and verification, so teams work from one list rather than two.
Scanners feed findings in, and pipeline policy gates read the same data, so a service with unresolved critical findings can be prevented from producing a new releasable artifact until the backlog is addressed.
See Vulnerability Management against your own environment
A 30-minute walkthrough with a platform engineer, not a sales deck. Bring a cluster and a problem.