The queue is already sorted. The decision is not.
A scanner can report the CVE, affected CI, and technical severity. It cannot tell you whether vulnerable code is active, reachable from a plausible attacker origin, or able to expose a critical service. When that context is missing, the loudest ticket consumes the sprint while a more consequential weakness keeps running.
Vulnerability analysis closes that gap. It turns a raw finding into a treatment decision another analyst can reproduce, challenge, and verify.
Four questions expose where the score stops being useful:
- When does “package present” fail to prove applicability?
- Which control actually permits or breaks the attack path?
- When does one finding reveal a fleet-wide root cause?
- What evidence is sufficient to remediate, contain, accept, or reopen the record?
Written by Anastasiia Sukhareva and technically reviewed and consulted by Valentin Kel, this method draws on FIRST CVSS v4.0, FIRST EPSS, CISA KEV, NIST SP 800-30 Rev. 1, and NIST SP 800-115. Cloudaware product statements are limited to current Vulnerability Management and CMDB sources. All uncited scenarios and counts are illustrative.
Key insights
For weekly triage, these are the rules worth carrying into the queue:
- A finding is ready for action only when its applicability, plausible attack path, impact, and treatment are documented.
- CVSS preserves technical severity. Local exposure, exploit evidence, privileges, service criticality, and compensating controls determine review order.
- Keep the scanner score and vector intact. Add environmental evidence instead of replacing source data with an unexplained internal number.
- A shared image, dependency, or policy can make one finding a fleet-wide remediation problem. That does not prove an exploitable path.
- Record the missing fact most likely to reverse the rating, assign an owner to obtain it, and set a reassessment time.
What is vulnerability analysis?
Vulnerability analysis is the disciplined examination of a known weakness in its deployed context to determine whether it applies, how an attacker could exploit it, what the consequences would be, why the condition exists, and which treatment the evidence supports. It starts with a finding and ends with a reviewable decision.
The surrounding terms describe different jobs:
| Activity | Working question | Expected output |
|---|---|---|
| Vulnerability assessment | What weaknesses did testing uncover? | Scoped and validated findings |
| Vulnerability analysis | What does this finding mean here? | Evidence-backed priority and treatment recommendation |
| Vulnerability management | How will the work be governed through closure? | Ownership, deadlines, exceptions, verification, and reporting |
NIST SP 800-115 uses assessment broadly enough to include testing, analysis, and mitigation planning. Operationally, narrower boundaries make handoffs clearer: a cloud security assessment finds the weakness, analysis interprets it, and the cloud vulnerability management lifecycle carries the decision through remediation and verification.
Consider two findings from the same scan. One has a CVSS score of 9.8 on a stopped development VM with no public route. The other scores 7.5 in a library loaded by an internet-facing production API whose workload identity can read customer records. The second finding may need containment first, but the descriptions alone do not justify the change.
Before reordering the queue, confirm the affected version and configuration, runtime reachability, attacker path, prerequisites, and post-exploit permissions. The stopped VM still needs a disposition, such as removal, isolation, or patching before restart. Dormancy changes the attack conditions; it does not close the record.
FIRST states the scoring boundary directly:
“The CVSS Base Score should be supplemented with an analysis of the environment (Environmental Metrics), and with attributes that may change over time (Threat Metrics).”
Preserve the base score and vector. Then attach the evidence that changed the local priority. Overwriting the vendor score destroys provenance because a reviewer can no longer tell whether the vulnerability changed or the environment did.
A six-step vulnerability analysis method
A repeatable vulnerability analysis plan moves one finding through six decisions. Each stage must add evidence another analyst can inspect. Otherwise, the final priority is an opinion wearing a score.
The visual below makes the handoffs auditable. Each gate should leave a record another analyst can reproduce before the finding advances.
A finding advances only when the current gate leaves inspectable evidence. If reachability or impact remains unknown, record the gap, assign the next evidence owner, and keep confidence explicit.
- Identify and confirm the finding. Check scanner evidence, observation time, asset identity, component, installed version, configuration, and CVE or CWE mapping against the vendor advisory. Package presence is not enough when the vulnerable function is disabled or the scanner matched an obsolete file. Rejecting a finding requires the conflicting evidence and validation method, not a bare “false positive” status.
- Characterize exploitability. Retain the CVSS vector, then add access requirements, authentication, user interaction, working exploit availability, EPSS probability, and the CISA KEV data repository. EPSS estimates the probability of exploitation in the next 30 days; KEV records observed exploitation. Neither proves that this asset is exploitable.
- Prove exposure and reachability. Choose an attacker origin and trace the route to the vulnerable interface. An external review may cross DNS, a load balancer, listener rules, security groups, Kubernetes ingress, and the listening process. Record the first control that permits or breaks the path. Test lateral and administrative routes separately.
- Assess impact. Map likely post-exploit access to confidentiality, integrity, availability, connected systems, sensitive data, and the affected business service. Write an observable consequence. “The service identity can alter release artifacts” supports a decision; “impact is high” merely repeats the rating.
- Determine root cause and scope. Trace the condition to its patch process, configuration, dependency, design, image, or ownership rule. Query for other active assets with the same source. A patched instance is temporary relief when the deployment image will recreate it.
- Decide, assign, and define verification. Record priority, confidence, treatment, owner, deadline, containment, durable fix, exception approver, and closure test. The analyst recommends treatment. An authorized business or risk owner accepts residual risk.
The method still needs a human rule for incomplete evidence. Use the reviewer’s firsthand judgment here only if it adds a criterion the workflow cannot supply on its own.
A useful answer will expose a decision rule another analyst can test. Anything less is decoration.
Katie Moussouris, founder and CEO of Luta Security, warned against treating threat evidence as a universal patch order:
“Now it has become the signal of what to patch first, which might not be applicable to a particular situation.”
NIST ISPAB October 2023 meeting minutes
Known exploitation should accelerate review. Applicability, reachability, impact, and root cause still determine what that evidence means for the affected asset.
The method stays constant across environments; the evidence carrying the most weight changes:
| Review context | Decisive inputs | Failure to avoid |
|---|---|---|
| Network vulnerability analysis | External and lateral paths, exposed listeners, segmentation, trust boundaries | Treating a private subnet as proof that no attack path exists |
| Computer or host analysis | Installed version, running service, loaded module, local privilege, patch and reboot state | Equating an installed package with reachable vulnerable code |
| Technical vulnerability analysis | Function-level reachability, configuration, dependency chain, image or infrastructure-as-code source | Repairing one instance while its source keeps recreating the flaw |
| Cybersecurity vulnerability analysis | CVSS, EPSS, KEV, observed activity, identity permissions, data, and service context | Letting one score or feed make the final decision |
One operating rule prevents false certainty: record the missing fact most likely to reverse the decision. Name who will obtain it and when the finding will be reassessed. A time-boxed “likelihood pending” is defensible; an unqualified rating built on an untested route is not.
Vulnerability impact analysis: combine consequence with likelihood
Vulnerability impact analysis asks what would happen if a specific weakness were exploited on a specific asset. Keep consequence separate from likelihood until both are supported. Combining them too early hides weak assumptions inside a single risk label.
Build the impact statement from four evidence groups:
- Security effect: Name the data an attacker could disclose, the actions they could perform, and the service capacity they could interrupt.
- Blast radius: Trace reachable workloads, identities, secrets, queues, administrative APIs, and trust relationships.
- Data sensitivity: Identify PII, PHI, payment data, credentials, source code, or other controlled information in the path.
- Business function: State the customer journey, production dependency, financial process, or deadline at risk. “Production” alone is not an impact statement.
For example, place a remote-code-execution finding in a document-conversion API behind a public load balancer. Its workload identity can read a PII claims bucket and publish to the claims-processing queue. A useful impact statement says exploitation could expose submitted documents, alter generated files, and stop claim intake. On a disconnected test runner with synthetic data and no durable credentials, CVSS remains unchanged while the impact falls.
Risk and vulnerability analysis adds likelihood. NIST SP 800-30 Rev. 1 supports qualitative, semi-quantitative, and quantitative approaches, so do not force weak evidence into fake numerical precision. Its guidance is explicit:
“Organizations make explicit the uncertainty in the risk determinations, including, for example, organizational assumptions and subjective judgments/decisions.”
Assess likelihood from confirmed reachability, exploit prerequisites, working exploit availability, current threat evidence, and verified controls. A high-impact weakness with no credible path may rank below a reachable, actively exploited weakness with moderate impact.
Program-level treatment, risk appetite, and reporting belong in the broader cloud security risk assessment process.
Use one analysis record for the decision and its reversal conditions:
| Record field | What to capture |
|---|---|
| Finding provenance | Scanner, source ID, CVE or CWE, first and last observation time |
| Affected state | Asset, component, version, configuration, runtime status |
| Applicability | Decision, validation method, conflicting evidence |
| Attack path | Attacker origin, route, identity, first control that permits or blocks access |
| Threat evidence | Exploit or KEV status, EPSS value, source date |
| Consequence | Data, service, and post-exploit actions at risk |
| Root cause and cohort | Shared image, dependency, policy, or configuration plus the affected-asset query |
| Decision | Priority, confidence, missing evidence, treatment, owner, due date, exception approver |
| Closure | Rescan source, path test, replacement cohort, and reassessment trigger |
At closure, repeat the evidence-producing test. Test a network path from the same source zone. After replacing an image, rescan every active replacement rather than the retired instances. A control-based exception remains valid only while that control blocks the documented route.
Build a decision-ready vulnerability queue with Cloudaware
Cloudaware connects scanner findings with asset, exposure, ownership, and dependency context. The analyst remains responsible for applicability, likelihood, impact, and treatment.
Vulnerability analysis slows down when the ticket contains a CVE and an IP address but not the service, owner, exposure, or related resources. Cloudaware Vulnerability Management relates findings from configured scanners to CMDB records so the analyst can review available technical and business context together. The scanner remains the source of the finding. Connector coverage and maintained relationships bound the result.
Before using that context in a decision, test three conditions: all in-scope accounts report through a configured source; owner, environment, and last-seen values are fresh enough; and the relationship graph contains the dependencies needed for the question. Missing context should lower confidence, not silently become evidence of absence.
Compare the context that can change priority
Start with a cohort captured in the same review window. Keep source severity visible, then compare the fields that can change treatment order.
A product screenshot is useful only if it proves that the comparison can be assembled from real fields. Build it from one active cohort, not an all-estate summary.
The evidence should make one point: equal source severity does not create equal response order. The dashboard supports comparison; the analyst still validates applicability and the attack path.
| Finding | Scanner evidence | Deployment context | Initial analyst action |
|---|---|---|---|
| A | CVSS 8.8; no current exploitation evidence | Public production API; customer-facing service; privileged workload identity; owner confirmed | Validate the external route and contain first if it is reachable |
| B | CVSS 8.8; no current exploitation evidence | Non-public development worker; synthetic data; stopped; owner confirmed | Prevent restart, then validate or remove on the normal path |
This comparison is illustrative. Inside Cloudaware, use dashboards and filters to assemble a comparable cohort, then inspect exposure, service, ownership, age, and remediation status before changing priority. Confirmed exploitation against Finding B would reverse the starting order. So would stale or incorrect service mapping.
Cloudaware CMDB provides the asset and relationship layer behind that review. It does not prove runtime reachability. Network rules, identity permissions, and application controls still need validation from the chosen attacker origin.
For this workflow, four product capabilities matter:
- Ingest findings from configured scanners while preserving the source record and severity.
- Filter dashboards and reports by scanning coverage, vulnerability age, asset exposure, tags, applications, and cloud accounts.
- Relate affected CIs to applications, environments, owners, and dependencies through the CMDB.
- Route and update remediation work through configured workflows and ticketing integrations.
Together, these capabilities create a review cohort and an owner path. They do not prove exploitability or perform the fix.
Separate remediation scope from reachable blast radius
One AWS finding can produce two different questions. Suppose a vulnerable package is reported on a production EC2 instance. Matching its Amazon Machine Image and Launch Template across active configuration items reveals the same image on 18 instances serving three applications. That evidence expands the remediation cohort from one instance to 18 and moves the durable fix to the image pipeline.
The relationship view must show the source of the recurring flaw without implying reachability. Pair the graph with the filtered asset cohort.
The closure plan follows the cause: correct the image, replace the affected cohort, rescan every replacement, and confirm the old image is no longer deployable. Opening 18 independent patch tickets may clear a dashboard temporarily while leaving the source intact.
When the cause sits in a base image or dependency pipeline, carry the same cohort into the DevSecOps vulnerability management loop so the replacement and post-deploy rescan share one release record.