Vulnerability Management and Attack Surface Management — DedSec Project

Purpose: Move from one-time scanning to a continuous process for knowing assets, identifying weaknesses, prioritizing real risk, remediating, and proving closure.

Vulnerability management lifecycle

1. Know the assets.
2. Collect vulnerability/configuration evidence.
3. Validate and deduplicate findings.
4. Enrich with exposure and threat context.
5. Prioritize.
6. Assign an accountable owner.
7. Remediate or mitigate.
8. Retest.
9. Measure and improve.

Asset inventory comes first

A scanner cannot tell you whether an unknown host is abandoned, critical, ownerless, temporary, or duplicated. Maintain identifiers, owner, business service, environment, exposure, platform, data sensitivity, and lifecycle status.

Severity is not priority

CVSS v4.0 describes technical severity. Remediation priority should also consider:

• internet/external exposure;
• exploitability and known exploitation;
• asset criticality;
• reachable vulnerable feature;
• privileges required;
• compensating controls;
• business deadlines/dependencies;
• fix availability.

CISA KEV is useful evidence when a vulnerability is known to be exploited in the wild.

Attack surface management

Attack surface management focuses on discovering and understanding externally or internally reachable assets and exposures over time. The goal is not “scan everything harder”; it is maintaining ownership and reducing unexpected exposure.

False positives and validation

Keep evidence of why a finding is valid or invalid. Suppressions need owner, reason, scope, and expiry/review date.

Patch versus mitigation

Sometimes a patch cannot be deployed immediately. Temporary mitigations may include disabling a feature, restricting network access, removing exposure, adding authentication, or increasing monitoring. Track temporary controls until the underlying issue is resolved.

End-of-life software

Unsupported software creates accumulated risk because future vulnerabilities may not receive fixes. Migration plans should be treated as risk-reduction projects, not postponed indefinitely.

SLAs and risk-based timelines

Use remediation targets that reflect risk. “All critical findings in X days” is simple but can mis-prioritize isolated assets while lower-severity internet-facing weaknesses wait.

Retest

A ticket marked fixed is not proof. Validate the vulnerable condition is gone and that the remediation did not create a new failure.

Metrics

Useful measures:

• critical assets with current scan/config evidence;
• known-exploited vulnerabilities open;
• age of high-priority findings;
• percentage of findings with owners;
• mean/median remediation time by risk tier;
• recurring root causes;
• unsupported assets;
• retest pass rate.

Lab — Prioritization board

Create ten fictional assets and ten fictional findings with different CVSS scores, exposure, criticality, exploit status, and compensating controls. Rank remediation work and explain each top-five decision.

Then add one new fact—credible active exploitation—and show how priorities change.

Learning goal: vulnerability management is an operational risk process, not a sorted scanner report.

Primary references

• FIRST CVSS v4.0: https://www.first.org/cvss/v4.0/
• CISA KEV: https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Vulnerability-management depth

Vulnerability management is a continuous control loop: discover assets, assess, validate, prioritize, remediate, verify, learn, and improve the asset inventory.

Asset context

Every finding should link to an owner, service purpose, environment, exposure, data sensitivity, criticality, and lifecycle status. Unowned assets are themselves a risk signal.

Prioritization

Use severity with context: exploitability, known exploitation, reachability, external exposure, privileges, compensating controls, business impact, and recovery difficulty. CISA KEV can be one important exploitation signal, but organizations still need local asset context.

Exceptions

An exception should include reason, compensating controls, responsible risk owner, expiration/review date, and measurable condition for closure. Permanent undocumented exceptions turn backlog into hidden risk.

Verification

Do not close a finding solely because a patch ticket says “done.” Re-assess the affected control/version/configuration and ensure the service still functions. Track recurrence so systemic causes can be fixed in build images, templates, dependency policy, or provisioning.

Guided study workflow

Before you begin

Modules 05, 19, and 22.

Practice task

Create an attack-surface inventory for a fictional service, link assets to owners/exposure, add sample findings, prioritize remediation, track exceptions, and verify closure.

Continue with

Recommended next modules: 42, 59.