On the “what’s old can be new again” aspect of cybersecurity, here is something that isn’t an attack! A Software Bill of Materials (SBOM) has been an important part of software development for a long while. However, the SBOM has been mostly used internally by development teams to drive build, signing, and delivery/deployment systems. The SBOM includes all the software and components included in the build and deployment. It can have meta-data to make it more useful such as license information (if we didn’t build it, did we buy it or get it from open source?), versions, sub-dependencies, etc.
Given the recent supply chain attacks (a.k.a. Solarigate/Sunburst), there is a push for reviving the SBOM in general and publishing it externally, much like release notes. So, consumers know what they are receiving and deploying, or using in the case of “cloud” services. Everyone can include this in their Configuration Management Database (CMDB) so they have tracking of deployed assets and attack surfaces. It sounds simple, right?
It is a simple concept but there is complexity lurking down a few slippery slopes. First, for a variety of reasons (IP protection, obfuscation, etc.), many software providers don’t want you to know what makes up their solution. Second, the complexity of software and services has exploded! The SBOM is anything but simple when considering software containers and devices (each designed to be somewhat opaque) and hybrid clouds providing capabilities “on-demand” via more than one provider or instance employing heavy virtualization, edge computing, and ephemeral, server-less code (e.g., AWS Lambda and Azure Functions) – whew. So, the runtime software, even between transactions, may not be the same – the devil really is in the details.
Software Bill of Materials (SBOM) references:
https://www.ntia.gov/SBOM // What is it?
https://thehill.com/opinion/cybersecurity/543186-the-us-must-adopt-software-bill-of-materials-to-thwart-cyber-attacks // A rationale for the renewed push, but neither a SBOM nor a common security rating system will “thwart” attacks.
However, that doesn’t mean that an SBOM should be dismissed, just not underestimated in complexity or overestimated in value. Like architecture diagrams or threat models, a SBOM isn’t always kept current. So, it’s better to make them an automatic output of your build and deployment processes which already have most of the details. Even then, you may not know the origins of every component or bit of code as developer’s can typically bring in packaged components and open source, and create service and data source dependencies without much of a vetting process. Oversight by architects and release managers who can manage the SBOM through processes and code reviews are critical. Once code is checked-in and you build, sign, and release or deploy solution, you effectively own it and are accountable (legal arguements withstanding).
In the grand scheme, an SBOM does have value both for both the internal developers and external consumers of a solution in the Identify and Protect phases of NIST’s Cybersecurity Framework. Adding a dynamic aspect to the traditionally static SBOM and keeping pace with the aforementioned complexities will increase the overall SBOM value while adding value in the NIST Detect, Respond, and Recover phases.
コメント