Manage vulnerability risk

Manage vulnerability risk

Move validated findings to verified closure. Treat scanner severity as one input, not the decision.

Establish the program boundary

1. Define the covered organizations, environments, asset classes, finding sources, decision owners, and reporting period.
2. Confirm the asset inventory or use map-attack-surface to expose coverage gaps first.
3. Record policy constraints: remediation windows, maintenance windows, regulatory duties, risk-acceptance authority, exception expiry, and evidence retention.
4. Preserve the source finding and scanner identity. Do not silently edit upstream evidence.

Route adjacent work

• Use dependency-vuln-scan, secret-scan, security-audit, or an authorized assessment process to produce findings.
• Use vulnerability-hardening, secure-coding, identity-management, or input-sanitization to guide specific fixes.
• Use assess-security-controls to evaluate whether the management process itself is designed and operating.
• Use threat-model when business consequence or plausible attack paths are unclear.

This skill owns prioritization and lifecycle, not discovery or exploitation.

Run the lifecycle

1. Normalize and deduplicate

Create or update assets/vulnerability-register-template.md. Preserve:

• source, source identifier, first and last observed dates;
• affected asset, component, version, environment, and owner;
• vulnerability identifier and weakness class where known;
• original severity, evidence, and detection method; and
• duplicate relationships without discarding distinct affected assets.

Do not merge findings merely because they share a CVE. Different exposure, controls, or owners can require different remediation decisions.

2. Validate material findings

Confirm the affected asset and version, current exposure, fix state, and whether the evidence is stale or a false positive. Use safe configuration, version, code-path, or authenticated read-only evidence. Do not exploit a live target to prove impact.

Label findings confirmed, likely, unconfirmed, false positive, or stale, with a reason and reviewer.

3. Prioritize risk

Read references/triage-and-prioritization.md. Consider:

• known exploitation and credible threat activity;
• reachability and plausible attack path;
• required access, privilege, and user interaction;
• business criticality, data sensitivity, and blast radius;
• compensating controls and detection;
• fix availability, confidence, and operational risk; and
• the cost of delay.

Use current official sources for time-sensitive exploitation status. Never prioritize solely from CVSS, scanner labels, or the volume of findings.

4. Select treatment and ownership

Choose one documented treatment:

• remediate through patch, upgrade, configuration, code, removal, or isolation;
• mitigate temporarily with a compensating control and a permanent plan;
• accept for a stated business reason through the authorized risk owner;
• transfer contractually without pretending accountability disappeared; or
• reject as false positive with reproducible evidence.

Assign a technical owner, risk owner, target date, validation method, dependencies, and escalation path. Exceptions must state residual risk, approval, compensating controls, expiry, and review date.

5. Verify closure

Retest using the original detection method where possible, plus a method that verifies the intended control or fixed state. Record evidence, date, tool or procedure, version, and reviewer. Reopen a finding when the fix is incomplete, the asset reappears, or compensating controls expire.

6. Measure and report

Read references/program-and-metrics.md. Report inventory and scanner coverage before counts. Segment by criticality, exposure, exploit status, age, owner, environment, and exception state. Explain material changes and blind spots.

Use an independent reviewer for contested risk decisions and a verifier to sample closure evidence when available.

Guardrails

• Do not install or require a paid scanner or service.
• Do not weaken a security check to improve closure statistics.
• Do not mark a finding closed because a ticket was created, code was merged, or a patch was scheduled.
• Do not let an exception remain open-ended or approved by the person solely responsible for delivery.
• Keep secrets and sensitive exploit details in appropriately restricted evidence, not broad reports.

Completion standard

The program is decision-ready when asset and source coverage are explicit, material findings are validated and prioritized transparently, every open risk has accountable ownership and a time-bound treatment, closed items have retest evidence, and residual risk and exceptions are visible.