Module vulnerability_management 

Security and Vulnerability Management Metrics

Security debt is measured the same way technical debt is measured (see crate::technical_debt): by severity and by how long it is carried. For every discovered vulnerability, the primary metric is time from discovery to genuine remediation — a deployed fix, not a closed ticket or an unmerged patch — tracked against an explicit target that varies by severity, commonly days for critical issues and weeks for lower-severity ones.

Formula

Time to remediate  = remediated at − discovered at
Within target        when time to remediate ≤ remediation target for severity

Why it matters

Using a standardized external scoring system, such as CVSS, as the primary basis for severity classification resists the same lenient-drift risk that inconsistent, purely internal judgement invites elsewhere in this book: an externally anchored score is harder to quietly redefine downward than a purely internal one. Building a genuinely non-punitive disclosure culture matters just as much as the metric itself — an engineer or researcher who reports a vulnerability is providing a valuable service, and punishing disclosure reliably drives real risk underground rather than into a managed remediation process.

Example

use software_engineering::vulnerability_management::{
    VulnerabilitySeverity, remediation_target_days, time_to_remediate_days,
    is_remediated_within_target,
};

// A critical vulnerability discovered on day 100, remediated on day 105.
let elapsed = time_to_remediate_days(100.0, 105.0);
assert_eq!(elapsed, 5.0);
assert_eq!(remediation_target_days(VulnerabilitySeverity::Critical), 7.0);
assert!(is_remediated_within_target(VulnerabilitySeverity::Critical, elapsed));

// The same 5 days would miss no severity's target, but 10 days misses
// Critical's 7-day target.
assert!(!is_remediated_within_target(VulnerabilitySeverity::Critical, 10.0));

Pitfalls

• Measuring remediation to ticket-closed rather than genuinely deployed — overstates how quickly real risk was actually reduced.
• Tracking a raw, unweighted vulnerability count instead of time-to-remediate by severity — hides whether the highest-risk items are being fixed fastest.
• Relying entirely on internal, inconsistent severity judgement instead of a standardized external scale like CVSS where one is available.
• Punishing vulnerability disclosure, internally or externally — discourages exactly the reporting the entire management system depends on.
• Letting accepted-risk vulnerabilities disappear into an invisible status instead of the same visible, quantified technical debt backlog used elsewhere.

Sources

• Chapter 6.4, Security and vulnerability management metrics.
• FIRST.org, Common Vulnerability Scoring System (CVSS).

Topic doc: software-engineering-metrics/locales/en-001/chapters/06-04-security-and-vulnerability-management-metrics.md

Enums

VulnerabilitySeverity

A vulnerability severity level, following a CVSS-like scale.

Functions

is_remediated_within_target

Whether an actual remediation time met the target for its severity.

remediation_target_days

A common, documented remediation-time target for a severity level, in days.

time_to_remediate_days

Time from discovery to genuine remediation — a deployed fix, not a closed ticket or an unmerged patch.