Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
What is vulnerability management?
Last verifiedVulnerability management is the continuous program of discovering, assessing, prioritizing, remediating, verifying, and reporting security weaknesses across systems and software. It is not a one-time scan, a pen test, or an audit. This page is not legal advice.
Vulnerability-management primer, last verified 9 September 2026 against NIST SP 800-40 Revision 4, NIST SP 800-53 Revision 5 control RA-5, CIS Control 7 (Continuous Vulnerability Management), ISO/IEC 27001:2022 Annex A control A.8.8, and CISA vulnerability-management materials including the Known Exploited Vulnerabilities catalog. NIST and CISA texts are guidance unless a statute, Binding Operational Directive, or certified ISMS makes a cited control a requirement for YOU. CIS Controls are best practice. This page is not legal advice, not a determination that any control applies, and not a complete vulnerability-management program.
This is a program, not a scan
Audience: a CTO, CISO, founder, engineering lead, auditor, or compliance owner who needs a defensible vulnerability-management program rather than a one-off scanner run. This page is not legal advice. It does not determine that any statute, Binding Operational Directive, or certified control applies. Reading it does not start a clock.
Vulnerability management is the ongoing cycle of finding weaknesses, judging which matter, fixing or otherwise treating them, proving the treatment landed, and reporting the state of that work. A scanner output is an input to that cycle, not the program. Last verified 9 September 2026. Not legal advice.
- Legal requirement versus guidance versus best practice versus SRM-recommendation: a cited article, annex, or Binding Operational Directive is a legal requirement only if it applies to YOU. NIST SP 800-40 Revision 4 and NIST SP 800-53 RA-5 are NIST guidance unless a contract, FISMA overlay, or policy adopts them. CIS Control 7 is best practice. Ranking findings with CISA KEV, FIRST EPSS, and CVSS in this product is an SRM-recommendation, not a legal determination.
- A dedicated program-checklist, how-to-prioritize-vulnerabilities, remediation-SLAs, and how-ShipReadyMetrics-prioritizes-risk guide is not on this site yet. Naming them is not a link.
- The vulnerability-management glossary entry on this site is the education page under glossary. That page is a different kind and a different path from this help cluster. This cluster does not reuse that slug.
The vulnerability-management lifecycle
The table below is an accessible lifecycle diagram — six stages in order, no widget. Organizations name the stages differently; NIST SP 800-40 Revision 4 frames enterprise patch management as identifying, prioritizing, acquiring, installing, and verifying patches, updates, and upgrades. CIS Control 7 asks for a plan to continuously assess and track vulnerabilities in order to remediate. This page uses discover → assess → prioritize → remediate → verify → report as a vendor-neutral map of that cycle. Last verified 9 September 2026. Not legal advice.
| Stage | What happens | Kind of text | Last verified |
|---|---|---|---|
| Discover | Inventory reachable assets and collect findings from scanners, dependency feeds, secret scanning, SAST, DAST, and other sources. Discovery that never ran is a blind spot, not a clean result. | Best practice — CIS Control 7 continuous assessment. NIST SP 800-53 RA-5 is vulnerability monitoring and scanning; a legal requirement only if that control applies. | 9 September 2026 |
| Assess | Normalize each finding: identity (CVE or equivalent), affected asset, severity, and whether the source actually scanned the asset. Deduplicate the same weakness seen in many repos or by many scanners. | Best practice. Cross-source identity is an SRM-recommendation in this product, not a legal determination. | 9 September 2026 |
| Prioritize | Rank what to treat first. Severity alone is not a work queue. Exploitation evidence (CISA KEV), exploitation probability (FIRST EPSS), asset exposure, and your own overdue clock change the order. | CISA KEV remediation timeframes are a legal requirement for FCEB agencies under BOD 26-04 (issued 10 June 2026; BOD 22-01 was revoked the same day). For everyone else they are CISA guidance. EPSS and CVSS are scoring schemes — guidance, not a statute. A dedicated how-to-prioritize-vulnerabilities guide is not on this site yet. Naming it is not a link. | 9 September 2026 |
| Remediate | Patch, upgrade, configuration-change, mitigate, or accept. Acceptance is a recorded risk decision by a named human, not a silent skip. This product does not apply patches to YOUR estate. | ISO/IEC 27001:2022 A.8.8 (management of technical vulnerabilities) is a legal requirement only if that ISMS control applies. NIST SP 800-40r4 is guidance on enterprise patch management. A dedicated remediation-SLAs guide is not on this site yet. Naming it is not a link. | 9 September 2026 |
| Verify | Confirm the treatment landed: rescanned clean, package upgraded, secret rotated, or compensating control in place. A ticket marked done is not verification. | Best practice. This product does not prove remediation by itself. A dedicated prove-remediation guide is not on this site yet. Naming it is not a link. | 9 September 2026 |
| Report | Tell owners, leadership, auditors, and (where a regime applies) regulators what is open, overdue, accepted, and verified. Reporting is an output of the cycle, not a substitute for it. | A reporting duty is a legal requirement only if a cited regime applies. This page does not start a clock and does not file. | 9 September 2026 |
Continuous versus point-in-time
CIS Control 7 is titled Continuous Vulnerability Management: develop a plan to continuously assess and track vulnerabilities on enterprise assets in order to remediate, and monitor public and private sources for new threat and vulnerability information. NIST SP 800-53 RA-5 similarly frames vulnerability monitoring and scanning as an ongoing control, not a single appointment. Last verified 9 September 2026. Not legal advice.
Point-in-time work still has a place. A pen test, a certification audit, and an annual scanner burst are snapshots. They do not watch the next CVE published against a dependency you already ship. A component that was clean yesterday can become vulnerable today with no change to your code. Continuous discovery is the operating layer; point-in-time work samples whether that layer is working.
- Continuous: ingest findings as scanners and feeds produce them; re-rank when KEV, EPSS, or your overdue clock changes; verify after each treatment.
- Point-in-time: a scheduled scan window, a pen-test engagement, or an audit period. Useful evidence. Not a substitute for the cycle.
- This product's findings ingest is a continuous operating layer over connected sources. It is not an enterprise-wide asset inventory, and it is not a complete vulnerability-management program.
How this differs from pen testing and one-time audits
Do not paste one activity onto another. A penetration test is a scoped, usually human-led attempt to exploit a defined target at a point in time. An audit (including ISO/IEC 27001 certification or a SOC 2 examination) tests a sample of controls over a period or at a date. Vulnerability management is the repeating cycle that those snapshots inspect. Last verified 9 September 2026. Not legal advice.
| Activity | When it runs | What it typically covers | Kind of text |
|---|---|---|---|
| Vulnerability management | Continuous cycle: discover → assess → prioritize → remediate → verify → report. | Known weaknesses across the estate you actually inventory and scan, ranked and treated over time. | Program. CIS Control 7 is best practice. ISO/IEC 27001:2022 A.8.8 is a requirement only if that control applies. |
| Penetration test | Point-in-time engagement with a scope, start, and end. | Whether a tester can exploit a path in that scope. It will not enumerate every CVE in every dependency. | Best practice as an independent test. Not a substitute for continuous discovery. |
| One-time audit or certification exam | A period or a date the auditor samples. | Whether sampled controls, including vulnerability handling if in scope, operated as described. | Legal or contractual requirement only if you are in that examination. Passing it is not a determination that every CVE is closed. |
Cluster glossary strip — names, not links
This strip names unpublished siblings in this cluster so a reader can see the map. None of the names below are links. A dedicated program-checklist, how-to-prioritize-vulnerabilities, remediation-SLAs, and how-ShipReadyMetrics-prioritizes-risk guide is not on this site yet. Naming them is not a link. Last verified 9 September 2026. Not legal advice.
| Topic | What a later page would cover | On this site? |
|---|---|---|
| Program checklist | Build-or-audit steps: inventory, coverage, ownership, SLAs, exceptions, evidence. | Not on this site yet. Naming the program-checklist guide is not a link. |
| Vulnerability vs exploit vs risk | The flaw, the weaponization, and business risk in context. | Not on this site yet. Naming it is not a link. |
| CVE vs CWE vs CVSS | Identifier, weakness class, and severity scheme — what each is not. | Not on this site yet. Naming it is not a link. |
| What is KEV | CISA Known Exploited Vulnerabilities catalog, and who BOD 26-04 binds (BOD 22-01 was revoked 10 June 2026). | Not on this site yet. Naming it is not a link. The KEV glossary entry on this site is live. |
| How to prioritize vulnerabilities | Work-queue order from exploitation evidence, probability, severity, and exposure. | Not on this site yet. Naming the how-to-prioritize-vulnerabilities guide is not a link. The KEV and EPSS learn guide on this site is live. |
| Exploitability vs severity | Likelihood of use versus impact if used. | Not on this site yet. Naming it is not a link. |
| Remediation timeframes and SLAs | Who a due date binds, versus an internal policy target. | Not on this site yet. Naming the remediation-SLAs guide is not a link. A named human still owns SLAs, exceptions, and risk acceptance. |
| SBOM, end-of-life dependencies, and open-source packages | What a software bill of materials is, how end-of-life components show up, and how vulnerable open-source packages are detected. | Not on this site yet. Naming them is not a link. The SBOM glossary entry on this site is live. |
| Zero-days, prove remediation, and accepted risk | How to handle a vulnerability without a patch, how to show a fix landed, and how to record risk a named human accepted. | Not on this site yet. Naming them is not a link. |
| How ShipReadyMetrics prioritizes risk | Product explainer for KEV + EPSS + CVSS ranking, multi-source ingest, and cross-source dedup — not a complete program. | Not on this site yet. Naming the how-ShipReadyMetrics-prioritizes-risk guide is not a link. |
Legal requirement versus guidance versus best practice versus SRM-recommendation
The table below labels each text. Do not treat guidance as a statute, and do not treat a product ranking as a legal determination. Last verified 9 September 2026. Not legal advice.
| Text | What it is | What this page does not do |
|---|---|---|
| CISA Binding Operational Directive 26-04 and the Known Exploited Vulnerabilities catalog | Legal requirement for U.S. federal civilian executive branch agencies. BOD 26-04 (10 June 2026) carries forward the KEV catalog criteria from BOD 22-01, which was revoked the same day. For other organizations, CISA recommends using the catalog as an input — guidance, not a statute that binds YOU. | Does not find that BOD 26-04 binds YOU. Does not start a KEV clock. |
| NIST SP 800-53 Revision 5 control RA-5 (vulnerability monitoring and scanning) | A NIST control. A legal requirement only if a FISMA overlay, contract, or policy adopts it for YOU. Otherwise NIST guidance. | Does not apply RA-5 to YOUR systems. |
| NIST SP 800-40 Revision 4, Guide to Enterprise Patch Management Planning | NIST guidance on identifying, prioritizing, acquiring, installing, and verifying patches, updates, and upgrades. Not a statute. | Does not treat SP 800-40r4 as a legal command. This product does not apply patches. |
| CIS Control 7 — Continuous Vulnerability Management | Best practice. The CIS Controls are a prioritized set of safeguards, not law. | Does not treat CIS Control 7 as a legal requirement. |
| ISO/IEC 27001:2022 Annex A control A.8.8 — management of technical vulnerabilities | A requirement of a certified or claimed ISO/IEC 27001:2022 ISMS only if that control is applicable. The standard is not a Union regulation and not a U.S. statute. | Does not find that YOUR ISMS includes A.8.8. Does not issue ISO certificates. |
| CISA vulnerability-management pages, the KEV catalog for non-FCEB readers, and CISA vulnerability-response playbooks | CISA guidance. Agency materials, not a statute, unless a cited directive applies. | Does not treat a CISA recommendation as YOUR legal duty. |
| ShipReady Metrics ranking of ingested findings (CISA KEV, FIRST EPSS, CVSS, overdue clock) | SRM-recommendation. A default work-queue order over connected sources. Not a legal determination, not a complete program, and not a patch. | Does not decide YOUR SLA, exception, or risk acceptance. A named human still owns those. |
What to do now
The list below is operational preparation. It is not a legal command, not a determination that any control applies, and not a complete program. Walk it with a named owner. Last verified 9 September 2026. Not legal advice.
- Name a human who owns the vulnerability-management cycle, including SLAs, exceptions, and risk acceptance. A dedicated program-checklist guide is not on this site yet. Naming it is not a link.
- Write down which assets you actually inventory and scan, and which you do not. A zero from a scanner that never ran is a blind spot.
- Prefer continuous discovery over a single annual scan or a one-time pen test. Keep pen tests and audits as independent samples of the cycle, not as the cycle.
- Rank by exploitation evidence and likelihood, not severity alone. A dedicated how-to-prioritize-vulnerabilities guide is not on this site yet. Naming it is not a link.
- Set internal remediation targets as policy. They are not CISA BOD 26-04 timeframes unless that directive applies. A dedicated remediation-SLAs guide is not on this site yet. Naming it is not a link.
- Verify that each treatment landed. This product does not apply patches to YOUR estate.
- Record accepted risk under a named human. Silence is not acceptance.
Checklist
This is a question list, not a filing, and not YOUR program. Walk it with a named owner. The vulnerability-management glossary entry on this site is the education page under glossary.
- Is there a named owner for discover, assess, prioritize, remediate, verify, and report? This page does not assign one.
- Is discovery continuous on the assets you claim to cover, or a point-in-time burst?
- Does prioritization use exploitation evidence (KEV) and probability (EPSS), or only a severity sort?
- Are SLAs an internal policy, a contract, or a directive that actually binds YOU? This page does not decide.
- Is every exception and accepted risk recorded to a named human, with an expiry?
- Is verification a rescan or a ticket status? A ticket is not verification.
- A dedicated program-checklist, how-to-prioritize-vulnerabilities, remediation-SLAs, and how-ShipReadyMetrics-prioritizes-risk guide is not on this site yet. Naming them is not a link.
Where this shows up in ShipReady Metrics
If you already have a session: signed-in app → Security → Findings holds ingested findings enriched with CISA KEV (known exploited), FIRST EPSS (exploitation probability), and CVSS (severity). Multi-source ingest currently includes GitHub Dependabot, GitHub CodeQL, GitHub Secret Scanning, first-party ShipReady SAST, first-party ShipReady DAST, GitLab, Azure DevOps, and cloud CSPM connectors (AWS Security Hub, Google Cloud SCC, Azure Defender, Oracle Cloud Guard) when those sources are connected. Cross-source dedup collapses the same weakness seen by more than one scanner so a distinct CVE is not counted once per repo or once per tool.
That findings surface is a continuous operating layer over connected sources. It is not a complete vulnerability-management program. It does not inventory every enterprise asset. It does not apply patches to YOUR estate. It does not file with CISA, ENISA, or a market-surveillance authority. It does not determine that BOD 26-04, ISO/IEC 27001:2022 A.8.8, CIS Control 7, or NIST SP 800-53 RA-5 applies. Default severity-based due dates in the product are an internal policy default, not a legal SLA. A named human still owns SLAs, exceptions, and risk acceptance. Signed-in app → Security → Risk register records accepted risk when a named human records it.
A dedicated how-ShipReadyMetrics-prioritizes-risk guide is not on this site yet. Naming it is not a link. This page does not document a public demo URL. This product does not issue certifications and does not start a clock.
How this cluster differs from the CRA vulnerability pages
The CRA docs hub on this site is Regulation (EU) 2024/2847. The coordinated-vulnerability-disclosure guide on this site is the CRA Annex I Part II CVD page. Coordinated disclosure is how reporters tell a manufacturer about a vulnerability. Vulnerability management is how an organization finds, ranks, treats, and verifies weaknesses in the systems it runs. They are related and not the same.
A dedicated CRA-cluster vulnerability-management guide is not on this site yet. Naming it is not a link. Last verified 9 September 2026. Not legal advice.
Primary sources (last verified 9 September 2026)
Every guidance or control claim on this page is taken from one of these. If a later revision of a source changes the rule, the date above is how you can see we have not re-checked yet.
NIST SP 800-40 Revision 4, Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology (April 2022), is NIST guidance on identifying, prioritizing, acquiring, installing, and verifying patches, updates, and upgrades. NIST SP 800-53 Revision 5 (updated) control RA-5 is vulnerability monitoring and scanning — a control, and a legal requirement only if it applies. CIS Control 7, Continuous Vulnerability Management, is best practice. ISO/IEC 27001:2022 Annex A control A.8.8 is management of technical vulnerabilities — a requirement only if that ISMS control applies. CISA's vulnerability-management page, Known Exploited Vulnerabilities catalog, BOD 26-04 (10 June 2026), and federal vulnerability-response playbook are CISA materials: BOD 26-04 is a legal requirement for FCEB agencies and carries forward the KEV catalog criteria from BOD 22-01, which was revoked on 10 June 2026; the rest is guidance unless a cited directive applies. These are not a complete world list. Not legal advice.
The vulnerability-management glossary entry on this site is the education page under glossary. The KEV, EPSS, and CVSS glossary entries on this site are live. The KEV and EPSS learn guide on this site is live. The CRA coordinated-vulnerability-disclosure guide on this site is live. A dedicated program-checklist, how-to-prioritize-vulnerabilities, remediation-SLAs, and how-ShipReadyMetrics-prioritizes-risk guide is not on this site yet. A dedicated CRA-cluster vulnerability-management guide is not on this site yet. Naming them is not a link.