Effective Software Supply Chain Monitoring

### Overview In this talk, Michael Angelo discusses the persistent challenge of software supply chain security, drawing on a decade of experience building internal tooling. Drawing an analogy to bottled water—which seems pure until foreign additives are introduced—he explains that organizational security models can be weakened not by the overall brand or origin of software (whether commercial, homegrown, or open source), but by the third-party components nested inside it. Because commercial binary analysis tools can be cost-prohibitive, Angelo presents a blueprint and architectural lessons for creating an internal monitoring system to track components and correlate them with known vulnerabilities.

### Key Topics - **Software Component Visibility**: Organizations rarely have full visibility into the software downloads, third-party libraries, and specific versions deployed in their environments. - **Widespread Component Exposure**: A single vulnerable library can have massive reach. For example, Angelo cites statistics showing 324 OpenSSL vulnerabilities across 3,208 products, noting how widespread OpenSSL has been across hundreds of millions of websites and web-facing servers. - **Data Collection and Identification**: Strategies for discovering components include inspecting product headers, copyright statements, license files, generating hashes to look up against the NIST Software Reference Library, or using free tools like the OWASP Dependency Checker. - **Software Bills of Materials (SBOM)**: Requiring internal developers to declare components and asking external vendors for software bills of materials according to emerging standards.

### Technical Details & Tool Architecture Angelo outlines how to design an internal tracking tool and relational database: - **Database Schema & Nested Relationships**: The database must map products to components and subcomponents across multiple nested levels (e.g., Product 1 contains Component 2, which contains Component 3). It must link component IDs and specific version enumerations directly to CVE records. - **Daily CVE Synchronization**: Because 20 to 30 new CVEs typically arrive daily, the system must update its CVE database regularly (allowing users to specify release years, such as catching 2019 updates during 2020) and run checks against both existing inventories and newly discovered products or machine portfolios. - **User Interface and Querying Capabilities**: Helpful tool features include progress bars for network-transferred databases, displayed SQL/Access command strings for debugging, portfolio scanning (e.g., scanning an entire HR machine group), and specialized query views (e.g., listing all CVEs by component, listing components within a product, or finding component/CVE matches on specific machines).

### Takeaways & Triage Strategy - **Triage and Status Tracking**: Finding a vulnerability in a component does not automatically indicate exploitability, as the affected functionality may not be enabled (such as unused modules in Tomcat). Teams must classify findings by relevance (Relevant, Not Relevant, Under Investigation) and mitigation status (Mitigated, Not Mitigated, No mitigation necessary). - **Handling Data Inaccuracies**: The National Vulnerability Database (NVD) occasionally lacks complete information or contains errors; tracking systems must be resilient to missing fields and database errors. - **Continuous Monitoring**: Effective supply chain security requires ongoing vigilance and triage rather than a one-time scan, ensuring newly published vulnerabilities against older software are flagged promptly.