INF-007 Vulnerability Management
Description
A vulnerability management programme covers authenticated vulnerability scanning of production systems and applications at a defined frequency of at least monthly, risk-based prioritisation of findings using an industry-standard scoring method and tracked remediation within defined SLAs by severity. Scanning covers every production system and application, including all internet-exposed systems. Information about the service that is discoverable from outside, including exposed hosts and services, leaked credentials and published code, is established at a defined frequency and each finding carries a recorded action. Critical and high findings carry documented remediation deadlines. Vulnerability metrics, including time to remediate by severity and SLA adherence, are tracked and reported to accountable owners at defined intervals. The scanned population includes model artefacts and the files a model produces that are later executed or loaded. A serialised model file is scanned before it is loaded for calls that would execute code, start a process or open a network connection, and a file the scanner cannot fully de-serialise carries a recorded result rather than being skipped.
Rationale
Unpatched vulnerabilities are the most commonly exploited attack vector, and an SLA-bound programme keeps exposure actively managed rather than merely measured. Scanning covers the systems the organisation knows about; external discovery covers the ones it does not, which is where a forgotten subdomain, a stale cloud account or a credential in a public repository sits. The two run on different inputs and find different things, so one does not substitute for the other. A model artefact is an executable file wearing a data extension: a serialised model can carry a call that runs the moment the file is loaded, which no application scanner reads and no dependency manifest lists. APP-007 holds the build-time bill of materials for third-party components and AIG-010 the registry the artefact is versioned in; the scan of the artefact itself is here.
Applicability (9 profiles)
Framework Mappings (26)
| MDS-02 | Model Artifact Scanning | full |
| MDS-13 | Secure Model Format | partial |
| TVM-01 | Threat and Vulnerability Management Policy and Procedures | full |
| TVM-03 | Vulnerability Identification | full |
| TVM-08 | Vulnerability Remediation Schedule | full |
| TVM-09 | Vulnerability Prioritization | full |
| TVM-11 | Vulnerability Management Reporting | partial |
| TVM-12 | Vulnerability Management Metrics | full |
| TVM-01 | Threat and Vulnerability Management Policy and Procedures | full |
| TVM-03 | Vulnerability Identification | full |
| TVM-08 | Vulnerability Remediation Schedule | full |
| TVM-09 | Vulnerability Prioritization | full |
| TVM-11 | Vulnerability Management Reporting | partial |
| TVM-12 | Vulnerability Management Metrics | full |
| HIPAA-164.308.a.8 | Evaluation | informative |
| 8.8 | Management of technical vulnerabilities | full |
| AML.M0016 | Vulnerability Scanning | full |
| NIS2-Art.21.2.e | Security in Acquisition, Development and Maintenance | informative |
| NIS2-CIR-6.10 | Vulnerability Handling and Disclosure | partial |
| RA-5 | Vulnerability Monitoring and Scanning | full |
| RA-5(2) | Vulnerability Monitoring and Scanning | Update Vulnerabilities to Be Scanned | partial |
| RA-5(3) | Vulnerability Monitoring and Scanning | Breadth and Depth of Coverage | full |
| RA-5(4) | Vulnerability Monitoring and Scanning | Discoverable Information | full |
| RA-5(5) | Vulnerability Monitoring and Scanning | Privileged Access | full |
| SI-2 | Flaw Remediation | full |
| SI-2(3) | Flaw Remediation | Time to Remediate Flaws and Benchmarks for Corrective Actions | full |
Evidence (4)
Vulnerability management metrics report showing SLA adherence, mean time to remediate by severity, and trend of open findings over time.
Example: Monthly or quarterly vulnerability management report (dashboard export or PDF) from Tenable, Qualys, Drata, or an internal tracking tool, showing MTTR by severity, open finding counts by age, and SLA breach rate for the last reporting period.
Test: Request the most recent vulnerability management metrics report. Verify: (1) the report covers the last full reporting period, (2) MTTR for critical findings is within the policy-defined SLA, (3) the trend in open critical/high findings is flat or declining, (4) any SLA breaches are documented with a remediation plan or risk acceptance.
Authenticated vulnerability scan results for production systems and applications covering the most recent scan cycle, with findings risk-rated by CVSS score. Model artefacts held for production use are scanned on the same cycle.
Example: Qualys, Tenable Nessus, or Rapid7 InsightVM scan report for production environment, exported within the last 30 days, showing CVSS scores and open/closed status per finding
Test: Request the most recent vulnerability scan report and the remediation tracking register. Verify: (1) scans are authenticated and cover all in-scope production systems; (2) findings are rated using CVSS or an equivalent severity framework; (3) critical findings (CVSS 9.0+) show a remediation due date within the documented SLA; (4) overdue findings have a documented exception or compensating control. (5) model artefacts and the files models produce for later execution or loading appear in the scanned inventory; (6) a serialised model file carrying a deliberately unsafe call is reported by the scanner, and a file the scanner cannot fully de-serialise carries a recorded result rather than no result.
Vulnerability remediation tracking register showing open findings, assigned owners, due dates, and completion records for the last full scan cycle.
Example: Jira vulnerability backlog, Qualys remediation dashboard export, or equivalent tracking record showing finding age, assignee, severity, and status for the last 90-day window
Test: Request the remediation tracking register. Verify: (1) all open critical and high findings have an assigned owner and SLA-compliant due date; (2) closed findings include a completion date and evidence of fix (patch applied, config changed, or compensating control documented); (3) the percentage of overdue critical/high findings is within the defined acceptable threshold.
External discovery output listing the hosts, services, credentials and code fragments attributable to the organisation that are reachable or findable from outside, with the action recorded against each.
Example: external-attack-surface-2026-08-30.json
Test: Request the external discovery output for the period. Verify: (1) discovery runs at or more often than the defined frequency and covers registered domains, cloud address ranges, public code repositories and credential leak sources, (2) each finding carries an action and a named owner, (3) findings that resolve to an asset absent from the component inventory were fed back into it, (4) an asset stood up in a controlled test is discovered within the defined interval, (5) findings closed as accepted carry an approver rather than being closed silently.
Questions (3)
Is authenticated vulnerability scanning of production systems and applications performed at a defined frequency of at least monthly?
The programme should cover both infrastructure and application layers. Scan credentials should be verified. Unauthenticated scans miss a significant portion of findings.
What is the defined SLA for remediating critical severity vulnerabilities (CVSS 9.0 and above) in production systems?
Industry expectation for critical vulnerabilities is 7–14 days. 30 days is the acceptable outer limit only when compensating controls are documented for the gap period.
Which of the following does your vulnerability management programme cover?
Options run from the most commonly covered to the least. Scanning covers the systems you know about; external discovery covers the ones you do not, which is where a forgotten subdomain, a stale cloud account or a credential in a public repository sits. A model artefact is scanned by neither unless it is named: a serialised model is an executable file that most tooling reads as data.