Building Your Vulnerability Monitoring Program

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

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)