As a software engineer and standards developer, I find it very frustrating trying to advocate for cybersecurity policies that are effective at addressing today’s cybersecurity problems across critical infrastructure. There are too many “Chiefs” with their own biases trying to manipulate and control public opinion and squelch the innovative achievements of technical people looking to solve these problems. There is an ample supply of technical people that are willing to collaborate and focus on finding solutions to cybersecurity problems, but they run into a wall of people in powerful positions that are more interested in playing politics and stroking their own ego’s than in solving the cybersecurity problems at hand. The hackers are free to operate at will, bringing pain into people's lives, because of this dysfunctional situation.
Software Bill of Materials (SBOM) is the poster child that proves my point.
SBOM is a great idea and we have Josh Corman, the Father of SBOM, to thank for this idea. SBOM’s are a no-brainer, IMO. SBOM’s provide a detailed listing of the ingredients found in a software product, along with other identifying information, i.e., Name of the Software Supplier for each SBOM component, that is needed to identify software risks. SBOM’s are an enabler for many useful activities designed to identify risks in software, such as vulnerability monitoring, supplier verification, software integrity verification and other useful risk management functions.
On May 5, 2022 NIST made the most significant contribution to advance SBOM adoption since Josh Corman introduced the concept, by providing clear, actionable implementation guidelines that explain how an SBOM should be used for software risk management to satisfy Executive Order 14028 requirements. The Software Transparency initiative within the NTIA, a sister organization to NIST in the Department of Commerce (DoC), was instrumental in raising awareness of SBOM and providing a high-level understanding of SBOM concepts, which resulted in the publication of some useful SBOM documents on framing and formats. But it’s important to note that Executive Order (EO) 14028 assigned NIST the responsibility of deciding on the best technical path to implement SBOM as part of risk management activities, required by EO 14028. I wasn’t surprised when NIST was assigned this important task; NIST has some of the very best cybersecurity scientists, engineers and technical minds on the planet and I cannot think of a better choice than NIST to provide this important technical guidance on SBOM and Vulnerability Disclosure Reporting (VDR) for EO 14028.
With all this great news coming from NIST on how to apply SBOM’s and Vulnerability Disclosure Reporting (VDR) you would think the “SBOM illuminati” that promote themselves as “SBOM Champions” and “SBOM experts” would be all over this good news, but that’s not happening. Why not?
This is the wall I referred to earlier. Technical people do their work with a focus on solving a problem, but they run into this wall of people with their own political and personal agendas that seek to control messaging and preserve public opinion that “they alone are the SBOM Champions”. These “SBOM Champions”, i.e., “SBOM illuminati”, have said nothing about the objective and unbiased SBOM technical implementation guidance provided by NIST on 5/5, that is intended solve some very challenging cybersecurity problems in the software supply chain for critical infrastructure operators.
To borrow a line from President Reagan; Madam Director [please] take down this wall and help promote NIST’s technical guidance to effectively apply SBOM and Vulnerability Disclosure Reports (VDR) to help solve our cybersecurity problems across critical infrastructure, following NIST's EO 14028 recommendations. Eliminating this wall will remove the resistance that is slowing progress on SBOM and VDR adoption and allow SBOM and VDR to flow freely to the critical infrastructure operators and other people that need it most.