New cybersecurity guidance from the White House: A step in the right direction, but there’s more to be done
As most have heard by now, the Office of Management and Budget recently issued new cybersecurity guidance as a follow-up to the Biden administration’s executive...
As most have heard by now, the Office of Management and Budget recently issued new cybersecurity guidance as a follow-up to the Biden administration’s executive order from May of last year. The memorandum requires federal agencies to abide by guidance from the National Institute of Standards and Technology when using third-party software in order to safeguard software development and supply chain security.
At the minimum, agencies must obtain self-attestation forms from vendors whose software they use. Agencies can (but are not required to) also request a software bill of materials (SBOM) to verify vendors’ compliance. Optimizing security practices is a top priority for all organizations, and the SBOM plays a vital role in realizing this goal. OMB’s memo is certainly a step in the right direction but, in the future, more will need to be done to protect not only federal agencies but also private companies from security threats.
What’s in an SBOM
Think of an SBOM like a nutrition label. Before we consume a packaged food, we read through the ingredients to understand what it contains: what’s good for us (protein), what’s not-so-good (added sugars), and what’s potentially harmful (gluten, if you’re allergic).
Similarly, an SBOM will let agencies parse through the “ingredients” that make up software before they “consume” it. SBOMs provide a clear view of components (including code written in-house, third-party or open-source code, etc.) and dependencies, technical information about said components, license information, and any hierarchical relationships between code. With this information, agencies can calculate their risk to make an informed decision before using any software.
Why SBOMs are critical in today’s world
The sheer amount of open source code living in software products today poses a significant risk and necessitates guidance like that in OMB’s memo. According to McKinsey, “during the past five years, open source software (OSS) development rose from approximately 35% to about 75% of organizations’ audited codebase.” While this is an average estimate, some codebases may contain a much higher percentage of open source code, up to 90%.
With open source code making up the vast majority of software vendors’ code, by probability alone we can extrapolate that many security risks are lurking within. The visibility provided by an SBOM will be critical in helping agencies mitigate known vulnerabilities and make quick judgements regarding security mechanisms and the status of dependencies in code.
A look at the benefits
When it comes to good security, speed is the name of the game. Organizations need to be agile and have the ability to identify and respond to threats as soon as possible. So while there are many benefits to having a document that tracks the supply chain in software development, faster incident response, penetration testing, vulnerability remediation, and license tracking and verification are notable benefits of an SBOM.
Remember the Log4j vulnerability incident that had IT teams everywhere scrambling last year? The incident received a 10/10 severity rating on the Common Vulnerability Scoring System, and applications and services affected included giants like Apple (iCloud) and Microsoft (Minecraft). Once all companies have access to SBOMs, it’ll be markedly easier to identify and respond to incidents like this; it might take as little as hours or days versus weeks.
What needs to happen next
OMB’s new security guidance is laying critical groundwork for better cybersecurity practices for federal agencies. But all organizations — federal, private or otherwise — would benefit from legislation focused on threat prevention. We can only hope to see the SBOM and similar guidance adopted across all sectors in the future — all enterprises should have access to this vital information.
Regarding this recent guidance for federal agencies, there are still some topics we’ll need to see more specificity around, like how to deliver data on vulnerabilities. The OMB noted that software producers and agencies should provide vulnerability data, but they weren’t explicit about the mechanics of how, or what kind of service-level agreement this would involve. To communicate this information effectively, there will need to be a standardized format to do so, such as a Vulnerability Exploitability eXchange form.
In the coming months and years, we’ll also need a standardized framework that outlines what secure code practices should look like for both agencies and enterprises. As more and more open source code proliferates third-party software, there will need to be mandates that agencies and enterprises stick to guidelines like NIST’s Secure Software Development Framework.
Lastly, the information in SBOMs can be extremely valuable for adversaries as well, so we’ll need to ensure that it’s not getting into the wrong hands. There is some discussion about how we can protect these types of data, but official regulation will be necessary in the future.
Stronger security will take time, but we’re on the right track
Good security is a marathon, not a sprint. It will take time to produce great standards and frameworks for federal agencies as well as private enterprises. So while OMB’s guidance may not yet be “perfect,” it does have people talking, and it has shined a spotlight on the importance of robust security practices. Now, it’s up to software vendors, the government, and the security community at large to come together to create additional legislation, tools, and standards that further the mission.
New cybersecurity guidance from the White House: A step in the right direction, but there’s more to be done
As most have heard by now, the Office of Management and Budget recently issued new cybersecurity guidance as a follow-up to the Biden administration’s executive...
As most have heard by now, the Office of Management and Budget recently issued new cybersecurity guidance as a follow-up to the Biden administration’s executive order from May of last year. The memorandum requires federal agencies to abide by guidance from the National Institute of Standards and Technology when using third-party software in order to safeguard software development and supply chain security.
At the minimum, agencies must obtain self-attestation forms from vendors whose software they use. Agencies can (but are not required to) also request a software bill of materials (SBOM) to verify vendors’ compliance. Optimizing security practices is a top priority for all organizations, and the SBOM plays a vital role in realizing this goal. OMB’s memo is certainly a step in the right direction but, in the future, more will need to be done to protect not only federal agencies but also private companies from security threats.
What’s in an SBOM
Think of an SBOM like a nutrition label. Before we consume a packaged food, we read through the ingredients to understand what it contains: what’s good for us (protein), what’s not-so-good (added sugars), and what’s potentially harmful (gluten, if you’re allergic).
Similarly, an SBOM will let agencies parse through the “ingredients” that make up software before they “consume” it. SBOMs provide a clear view of components (including code written in-house, third-party or open-source code, etc.) and dependencies, technical information about said components, license information, and any hierarchical relationships between code. With this information, agencies can calculate their risk to make an informed decision before using any software.
Why SBOMs are critical in today’s world
The sheer amount of open source code living in software products today poses a significant risk and necessitates guidance like that in OMB’s memo. According to McKinsey, “during the past five years, open source software (OSS) development rose from approximately 35% to about 75% of organizations’ audited codebase.” While this is an average estimate, some codebases may contain a much higher percentage of open source code, up to 90%.
With open source code making up the vast majority of software vendors’ code, by probability alone we can extrapolate that many security risks are lurking within. The visibility provided by an SBOM will be critical in helping agencies mitigate known vulnerabilities and make quick judgements regarding security mechanisms and the status of dependencies in code.
A look at the benefits
When it comes to good security, speed is the name of the game. Organizations need to be agile and have the ability to identify and respond to threats as soon as possible. So while there are many benefits to having a document that tracks the supply chain in software development, faster incident response, penetration testing, vulnerability remediation, and license tracking and verification are notable benefits of an SBOM.
Remember the Log4j vulnerability incident that had IT teams everywhere scrambling last year? The incident received a 10/10 severity rating on the Common Vulnerability Scoring System, and applications and services affected included giants like Apple (iCloud) and Microsoft (Minecraft). Once all companies have access to SBOMs, it’ll be markedly easier to identify and respond to incidents like this; it might take as little as hours or days versus weeks.
What needs to happen next
OMB’s new security guidance is laying critical groundwork for better cybersecurity practices for federal agencies. But all organizations — federal, private or otherwise — would benefit from legislation focused on threat prevention. We can only hope to see the SBOM and similar guidance adopted across all sectors in the future — all enterprises should have access to this vital information.
Regarding this recent guidance for federal agencies, there are still some topics we’ll need to see more specificity around, like how to deliver data on vulnerabilities. The OMB noted that software producers and agencies should provide vulnerability data, but they weren’t explicit about the mechanics of how, or what kind of service-level agreement this would involve. To communicate this information effectively, there will need to be a standardized format to do so, such as a Vulnerability Exploitability eXchange form.
In the coming months and years, we’ll also need a standardized framework that outlines what secure code practices should look like for both agencies and enterprises. As more and more open source code proliferates third-party software, there will need to be mandates that agencies and enterprises stick to guidelines like NIST’s Secure Software Development Framework.
Lastly, the information in SBOMs can be extremely valuable for adversaries as well, so we’ll need to ensure that it’s not getting into the wrong hands. There is some discussion about how we can protect these types of data, but official regulation will be necessary in the future.
Stronger security will take time, but we’re on the right track
Good security is a marathon, not a sprint. It will take time to produce great standards and frameworks for federal agencies as well as private enterprises. So while OMB’s guidance may not yet be “perfect,” it does have people talking, and it has shined a spotlight on the importance of robust security practices. Now, it’s up to software vendors, the government, and the security community at large to come together to create additional legislation, tools, and standards that further the mission.
Read more: Commentary
Moshe Zioni is vice president of security research at Apiiro.
Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.
Related Stories
NSA backs SBOM requirements in latest secure software advisory
Army diving ‘headfirst’ into SBOMs to secure software supply chain
State Dept working toward SBOM adoption to improve supply chain risk management