In a world of increased vulnerability exposure and information complexity, transparency and simplicity are key to enabling security professionals to efficiently track, update, and remediate threats in a timely manner. The ideal end state with any information problem is a system with maximum simplicity, maximum transparency to stakeholders and maximum automation. In order to achieve this, an efficient means of tracking the development, deployment, and maintenance of software components is necessary.
Software Bill Of Materials (SBOM) contains a list of software identifiers and information and can be nested with other SBOMs as shown below:
SBOM is a nested inventory of software components used to track the deployment of software across organizations. This makes it highly relevant to both software developers and cybersecurity professionals as it can enable real time visibility into the vulnerability status of distributed software systems and shorten the information gathering and remediation steps for software vulnerabilities.
The three classes of SBOM interactions and transformations are shown below:
In Sun Tzu’s “Art of War” the first foundational requirement to success is “know thyself.” The Department of Defense (DoD) often struggles to respond quickly to cybersecurity vulnerabilities in software due to the nature and complexity of software distributed across the DoD. This lack of self-knowledge leads the DoD to be plagued with manual processes for discovering affected systems which often take weeks or months to complete. Once completed, these vulnerability data calls yield incomplete lists of affected systems. Proper implementation and utilization of SBOMs could solve both problems by making software vulnerabilities trackable in real-time and simplifying remediation so that software patching would not take additional steps, thus ensuring comprehensive implementation.
SBOMs are limited in effectiveness by how widespread their use is and how granular the breakdown of software components is. This means that if a vulnerability is discovered in a particular piece of software, SBOMs can only be useful in remediation if all affected software is already documented comprehensively with SBOMs. Also, the depth of information within a SBOM can lead to varying usefulness.
Because software today is increasingly complex and exposed, it is no longer enough to treat software security reactively. The lack of automation and visibility into the composition of software systems contributes to prolonged vulnerability and increased cost. We have a duty to build a system of software supply chain transparency to reduce cybersecurity risk to ourselves, customers and partners.
As of May 2021, Executive Order on Improving the Nation’s Cybersecurity was published outlining several key requirements for federal agencies and organizations to implement in regard to SBOMs. This further details hardening the Software Supply chain by adding the requirement of… “providing a purchaser a SBOM for each product.” This has since been followed by publications from NTIA, CISA, and later more detailed standards from NIST.
For more information reach out to our Center of Excellence: COETeam@swishdata.com
Executive Order on Improving the Nation’s Cybersecurity (See Section 4)
OMB Memo (See Section 1: Self-Attestation Requirement)