Third-Party Component Management

Third-party component management means knowing every piece of software in your device that you didn't write, tracking it in a Software Bill of Materials, and watching it for new vulnerabilities for as long as the device is in use. Since most of your codebase comes from someone else, this is where much of your security risk actually lives.

4.4.1 The Reality of Modern Development

According to the JSP, modern medical devices typically contain:

• 80% or more third-party code
• Hundreds of components
• Multiple layers of dependencies

You're not just managing your code - you're managing an entire ecosystem.

Industry-wide audits back this up. Black Duck's annual Open Source Security and Risk Analysis has found open source in 96% of the commercial codebases it audits, and known open-source vulnerabilities in 84% of them.

4.4.2 Component Selection: Choosing Wisely

Before adding a component, evaluate:

Security History

• Check CVE database for past vulnerabilities
• Review security advisories
• Assess vendor response times
• Look for security contact info

Support Status

• Is it actively maintained?
• When was the last update?
• Is commercial support available?
• What's the end-of-life plan?

License Compatibility

• Does it allow medical device use?
• Are there disclosure requirements?
• Can you modify if needed?
• What about liability?

Security Features

• Does it support needed cryptography?
• Are security controls built in?
• Can it integrate with your authentication?
• Does it provide audit capabilities?

4.4.3 Creating Your Software Bill of Materials (SBOM)

The FDA requires an SBOM for cyber devices under Section 524B of the FD&C Act. But what makes a good SBOM?

FDA points manufacturers to the NTIA minimum elements as the baseline: supplier name, component name, version, unique identifiers, dependency relationships, the SBOM author, and a timestamp. CISA now maintains that work and publishes ongoing SBOM guidance.

SBOM Essential Elements

According to FDA's 2023 guidance, your SBOM must include:

Component Identification

• Name and version
• Supplier/author
• Unique identifier (CPE, PURL, SWID)

Component Relationships

• Dependencies
• Hierarchy
• Integration points

Security Information

• Known vulnerabilities (CVEs)
• Security updates available
• End-of-life status

SBOM Formats

FDA accepts several standard formats:

SPDX (Software Package Data Exchange)

{
  "name": "InsulinPumpSoftware",
  "SPDXID": "SPDXRef-Package",
  "packages": [{
    "name": "OpenSSL",
    "version": "1.1.1k",
    "supplier": "OpenSSL Software Foundation",
    "vulnerabilities": ["CVE-2021-3711", "CVE-2021-3712"]
  }]
}

CycloneDX

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "components": [
    {
      "type": "library",
      "name": "OpenSSL",
      "version": "1.1.1k",
      "supplier": {
        "name": "OpenSSL Software Foundation"
      },
      "cpe": "cpe:2.3:a:openssl:openssl:1.1.1k:*:*:*:*:*:*:*"
    },
    {
      "type": "library",
      "name": "SQLite",
      "version": "3.42.0",
      "supplier": {
        "name": "SQLite Consortium"
      },
      "cpe": "cpe:2.3:a:sqlite:sqlite:3.42.0:*:*:*:*:*:*:*"
    },
    {
      "type": "library",
      "name": "zlib",
      "version": "1.2.13",
      "supplier": {
        "name": "zlib authors"
      },
      "cpe": "cpe:2.3:a:zlib:zlib:1.2.13:*:*:*:*:*:*:*"
    },
    {
      "type": "library",
      "name": "boost",
      "version": "1.82.0",
      "supplier": {
        "name": "Boost.org"
      },
      "licenses": [
        {
          "license": {
            "id": "BSL-1.0"
          }
        }
      ]
    }
  ],
  "vulnerabilities": [
    {
      "id": "CVE-2021-3712",
      "source": {
        "name": "NVD"
      },
      "ratings": [
        {
          "score": 7.4,
          "severity": "high",
          "method": "CVSSv3"
        }
      ],
      "affects": [
        {
          "ref": "OpenSSL"
        }
      ]
    }
  ]
}

SWID (Software Identification Tags)

• ISO/IEC 19770-2 standard
• XML-based format
• Good for complex products

For tooling commands to generate these files automatically for your stack, see SBOM generation for medical device software.

4.4.4 Vulnerability Monitoring

Having an SBOM is just the start. You need to monitor it continuously.

Automated Monitoring Tools

Commercial Solutions:

• Black Duck
• WhiteSource
• Snyk
• Sonatype Nexus

Open Source Tools:

• OWASP Dependency Check
• Retire.js (for JavaScript)
• Safety (for Python)
• npm audit (for Node.js)

Monitoring Process

The JSP recommends:

1. Daily Scans for critical components
2. Weekly Scans for all components
3. Monthly Reviews of component status
4. Quarterly Updates of SBOM

4.4.5 Managing Vulnerable Components

When vulnerabilities are found:

Assess Impact

Document Decisions For each vulnerable component, document:

• Why it can't be updated (if applicable)
• Compensating controls implemented
• Risk assessment results
• Monitoring procedures