Skip to content

Latest commit

 

History

1 Commit

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Vulnerability Management Program

A reference design for vulnerability management as a governed program — scope, ownership, risk-based prioritisation, remediation coordination across teams you do not manage, exceptions, validation, and executive reporting — rather than as the operation of a scanner.

What this demonstrates

Assess and govern, primarily: risk-based prioritisation that goes beyond CVSS, asset discovery and coverage measurement, an ownership and service-level model, exception governance with worked records, validation of corrective action, and a metrics and executive reporting pack. Secure appears in the remediation coordination model and in the compensating-control design for environments where patching is not available.

The material is written around the decisions that determine whether a program works: how to order finite remediation capacity, how to get work done by teams that do not report to you, when to grant an exception and how to stop it becoming permanent, how to prove a fix worked, and how to report all of it to an executive without either alarming or reassuring them inaccurately.

Scope and boundaries

  • Synthetic reference implementation. Every finding, asset, metric, exception record, coverage gap, and report in this repository is invented for illustration. The metrics are generated by a script from a deterministic synthetic population and are labelled as such wherever they appear.
  • No employer, client, or customer data. No real estate, finding, architecture, organization, or person is represented.
  • No proprietary architecture or control inventories. Tool references are limited to naming the category of platform a capability would come from.
  • Not legal or audit advice. Standards mappings indicate where the practice aligns to a control objective; they are not a compliance attestation.
  • Out of scope: incident response (see the sibling repository), penetration testing methodology, secure development lifecycle, and product-specific scanner configuration.

Standards implemented

Standard Version Where it is applied
NIST SP 800-40 Rev 4 Patch and vulnerability management process design; maintenance-window and patch-ready backlog planning in remediation/ot-vulnerability-handling.md
NIST SP 800-53 Rev 5 RA-5 vulnerability monitoring and scanning, SI-2 flaw remediation, CA-7 continuous monitoring, CM-family; evidence retention in remediation/validation-of-corrective-action.md
NIST CSF 2.0 ID.AM asset management, ID.RA risk assessment, PR.PS platform security across program/
ISO/IEC 27001 2022 A.5.9 inventory of assets, A.8.8 management of technical vulnerabilities
ISA/IEC 62443 Series Zone and conduit model, IACS patch management and compensating controls in remediation/ot-vulnerability-handling.md
NIST SP 800-82 Rev 3 ICS scanning constraints and passive discovery methods
CVSS v4.0 (v3.1 inputs supported) Technical-severity input to the risk model, weighted at 0.10
EPSS Current model Exploitation-likelihood input to the risk model
CISA KEV catalog Current Known-exploited input, scoring gates, and emergency-response activation criteria
SSVC Current Conceptual basis for decision-oriented prioritisation
CycloneDX 1.7 (ECMA-424 2nd Edition) SBOM ingestion for dependency-class coverage
SPDX 3.0.1 Alternate SBOM ingestion format

Repository structure

vulnerability-management-program/
  README.md
  DECISIONS.md
  LICENSE
  .gitignore
  program/
    program-design.md                     accountability, asset classes, criticality,
                                          ownership, SLAs, lifecycle, cadence, intake
    asset-discovery-and-coverage.md       multi-source reconciliation, coverage metrics,
                                          the coverage gap register, worked gaps
  prioritization/
    why-cvss-fails.md                     the argument, with the counter-arguments
    risk-scoring-model.md                 the formula, factor mappings, gates, governance
    scorer/
      README.md
      risk_score.py                       runnable scorer with 21 self-test checks
      sample_findings.json                14 synthetic findings across asset classes
      weights.json                        alternative weight set for change testing
  remediation/
    remediation-coordination.md           getting work done by teams you do not manage
    exception-framework.md                types, authority, decision tree, worked records
    validation-of-corrective-action.md    validation methods, sampling, recurrence
    ot-vulnerability-handling.md          constrained environments, patch-ready backlog
    emergency-response.md                 actively-exploited and critical response
  metrics/
    metrics-and-reporting.md              the core five, self-measurement, exec one-pager
    generate_metrics.py                   synthetic metrics pack, 18 self-test checks

How to use this

Standing up a program. Read program/program-design.md first and settle three things before any tooling decision: the asset classes in scope, the ownership model, and who holds exception approval authority. Programs that start with the scanner and derive scope from what it can see inherit that tool's blind spots as their program boundary.

Adopting the prioritisation model. prioritization/why-cvss-fails.md is the argument to make internally; risk-scoring-model.md is the specification; scorer/risk_score.py runs it. Start by scoring your existing backlog with the default weights and comparing the result to your current ordering — --compare does this against CVSS directly. Expect a substantial reordering, and expect to calibrate the weights. Record the calibration and the reason, because the model's credibility rests on being documented and stable rather than on being correct to the decimal.

Fixing the remediation problem. remediation/remediation-coordination.md is the highest-value document here for a program that already detects well and remediates poorly, which is the common case. The two changes with the largest immediate effect are grouping findings by remediation action instead of by CVE, and routing work into each team's existing tooling at their planning cadence.

Running the reporting. python3 metrics/generate_metrics.py produces the full pack from synthetic data so the format and the arguments each metric supports can be reviewed before any real data is involved. The executive one-page structure in metrics/metrics-and-reporting.md section 5 is the part worth copying.

Testing the code.

python3 prioritization/scorer/risk_score.py --selftest
python3 metrics/generate_metrics.py --selftest

Both are standard library only, require no installation, and print a pass line with the check count.

Related

Sibling repositories in this portfolio: incident-response-playbooks.

About

Risk-based vulnerability management as a program: scoring beyond CVSS, coverage gaps, cross-team remediation, exception frameworks, OT constraints, executive metrics

Topics

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages