Organizations should analyze their existing security initiatives through the lens of the challenges outlined here. Considering existing and emerging software quality standards and tooling and how they can benefit or augment current security programs can be particularly helpful. Third-party and open source software components should receive extra attention, as they can provide an easy entry point for bad actors.
Given the scale of third-party and open source software usage, paying the necessary amount of attention to these components requires specialized tooling. Although manual processes, such as requiring developers to disclose which dependencies they’re leveraging, may have sufficed in the past, they leave large gaps today. For example, developers may only be aware of direct dependencies and not the further-removed dependencies.
Likewise, foundational components that have been in place since the architectural stages of application development should be tracked from their introduction. But the difficulty of staying on top of updates and the associated vulnerabilities for these components helps explain why we find foundational components to be the most vulnerable in our most recent OSSRA report. For this reason, automated detection and continuous monitoring of dependencies is necessary for staying on top of patches, and the risks that these patches often remediate.
Another important security best practice that can help mitigate supply chain risks is generating a robust software Bill of Materials (SBOM). D’Amico notes that “creating an SBOM allows organizations to proactively gather a comprehensive inventory of the components used to make up a piece of software, so as new and existing vulnerabilities are identified, organizations are fully equipped to act quickly to remedy those issues.”
Building an SBOM is only part of the process though; it simply provides a list of ingredients. Although it’s a necessary first step in securing the software supply chain, next steps should involve adding SBOM generation into development pipelines, and associating the listed components with areas of operational, security, and license risk.
CISQ wants organizations to think of the next vulnerability as inevitable. “[Organizations should be doing] anything and everything to prepare for the next Log4J,” the report states.