Building Your Vulnerability Monitoring Program

A vulnerability monitoring program starts with an accurate SBOM, watches a defined set of sources (NVD, the CISA KEV catalog, vendor advisories) on a schedule tiered to component risk, and routes anything new into a documented assessment process. Critical components get daily checks, and automation does the heavy lifting wherever possible.

5.3.1 Information Sources

You can't fix what you don't know about. Effective monitoring requires multiple information sources:

Primary Sources

National Vulnerability Database (NVD)

• Comprehensive CVE listings
• CVSS scores
• Reference links
• Updated continuously

CISA Known Exploited Vulnerabilities (KEV) Catalog

• Vulnerabilities actively exploited
• Required monitoring per FDA
• Priority patching targets

Vendor Security Advisories

• Component supplier notices
• OS vendor bulletins
• Library updates
• SDK patches

Security Research

• Conference presentations
• Academic papers
• Blog posts
• Proof-of-concepts

For how monitoring fits into the six discovery sources and the 30/60-day response expectations, see A guide to post-market cybersecurity management.

Setting Up Monitoring

flowchart TD
    A[Component Inventory/SBOM] --> B[Identify Sources]
    B --> C[Configure Alerts]
    C --> D[Daily Monitoring]
    D --> E{New Vulnerability?}
    E -->|Yes| F[Impact Assessment]
    E -->|No| D
    F --> G[Response Process]

5.3.2 Monitoring Frequency and Methods

Based on the JSP and FDA guidance:

Critical Components (Direct patient safety impact):

• Monitor: Continuously/Daily
• Method: Automated alerts + manual review
• Sources: NVD, CISA KEV, vendor sites

High-Risk Components (Network-facing, privileged):

• Monitor: Daily
• Method: Automated scanning
• Sources: Multiple vulnerability databases

Standard Components (Limited exposure):

• Monitor: Weekly
• Method: Automated tools
• Sources: Standard databases

Low-Risk Components (Isolated, non-critical):

• Monitor: Monthly
• Method: Batch scanning
• Sources: Primary databases

5.3.3 Automation Tools and Processes

Manual monitoring doesn't scale. Automate where possible:

Commercial Tools

• Black Duck: Comprehensive scanning
• Snyk: Developer-friendly alerts
• WhiteSource: Policy automation
• Sonatype: Repository integration

Open Source Options

• OWASP Dependency Check: Free scanning
• CVE Search: API access
• GitHub Security Alerts: Repository monitoring
• OSV: Open source vulnerabilities

Building Your Monitoring Pipeline

# Example monitoring script structure
def daily_vulnerability_check():
    # Load your SBOM
    components = load_sbom()
    
    # Check each component
    for component in components:
        # Query vulnerability databases
        vulns = check_nvd(component)
        vulns += check_cisa_kev(component)
        vulns += check_vendor(component)
        
        # Assess impact
        for vuln in vulns:
            if is_exploitable(vuln, component):
                severity = calculate_severity(vuln)
                create_ticket(vuln, severity)
                notify_team(vuln, severity)

5.3.4 SBOM Maintenance

Your SBOM is a living document that requires continuous updates:

Regular Updates:

• New components added
• Versions changed
• Components removed
• Dependencies updated

Update Triggers:

• Software releases
• Patch deployments
• Component upgrades
• Security updates

SBOM Version Control:

SBOM_v1.0_2024-01-01.json (Initial release)
SBOM_v1.1_2024-02-15.json (Security patch)
SBOM_v1.2_2024-03-30.json (Feature update)
SBOM_v2.0_2024-06-01.json (Major upgrade)