The DevOps, IT security and IT governance communities will remember 2021 as the year when the Software Nomenclature, or SBOM, has gone from being a ‘nice to have’ to a ‘must have’.
For years, SBOM has become an essential part of DevSecOps, which everyone should understand and integrate into their SDLC (Software Development Lifecycle). In summary, SBOMs provide visibility into the components that make up software and how it has been assembled, so it’s easy to determine if it contains security and compliance issues.
In this blog post, you will learn what an SBOM is, its benefits, the misconceptions surrounding it, and why it should be a key part of your SDLC security and compliance.
We also invite you to register for theWebinar “Trusted SBOMs Comes with the JFrog Platform and AWS” on Thursday, September 9 at 3 p.m. ET. AWS Senior Partner Solutions Architect Shashiraj Jeripotula and I will dig deeper into SBOMs and share ideas and best practices on creating and using SBOM.
How SBOM went from behind the scenes to center stage
The SBOM standard was proposed in 2018 by the United States Food and Drug Administration (FDA) to ensure that medical device software has the same level of responsibility as food products because it directly affects the health of individuals. But the rise of SBOM can be directly linked to two recent events: the devastating crisis SolarWinds hack at the end of 2020, and the White House decree on cybersecurity of May 2021.
SolarWinds breach highlighted supply chain attacks, in which malware is hidden within legitimate software which is then distributed through authorized channels to unsuspecting end users. In the case of SolarWinds – a computer monitoring vendor – hackers injected malware into its Orion platform’s software creation process in the form of indirect transitive dependencies.
For months, SolarWinds inadvertently shipped updates to products with the vulnerability, designed to help hackers compromise customers’ Orion servers using a backdoor. About 18,000 clients received compromised updates, and several dozen were breached, including leading multinationalsand US Federal Government Agencies.
At the time, it was the last of a supply chain hacking chain, but its breadth and consequences set it apart, prompting scrutiny and increased attention to software development security and DevSecOps. With its disastrous fallout is still felt, it was cited by the White Houseas a driver for US President Joe Biden Executive decree on improving the nation’s cybersecurity.
The command highlights the The importance of SBOMas “a formal record containing the details and supply chain relationships of the various components used in software creation.” Comparing SBOMs to a list of food ingredients, the White House declares them useful for software makers, software buyers, and software operators.
The transparency that an SBOM provides into all of the dependencies between the software components of an application can help prevent, or mitigate more quickly, supply chain breaches. “Understanding the software supply chain, obtaining an SBOM, and using it to analyze known vulnerabilities are key to managing risk,” the order reads.
Although the US government will provide more specific security requirements to software makers, it has already indicated in the order that it will require every software it purchases to be accompanied by a detailed SBOM.
SBOM: Visibility and transparency
The security of open source software cannot be overlooked, and knowing what’s in the software that you are selling to customers, buying from vendors, or downloading for free from the internet is essential.
Study after study has shown that open source software makes up the bulk of an average application’s code base, often over 90%, including risky components that have critical vulnerabilities or have not been released. updated for years by their creators.
In other words, uninspected software is inherently insecure or faulty.
So it’s no surprise that having SBOMs for the software you develop has become a core best practice for DevSecOps, as well as an increasingly common regulatory requirement – especially in highly regulated industries. , like finance and health – and a condition for doing business with a number of public and private clients.
By providing transparency and visibility into the components of the software you market and use, SBOMs help your organization protect its employees, customers, and reputation, as well as reduce remediation costs and legal liability and liability risks. government fines.
While SBOM information is needed to sell software to the U.S. government, regulated industries, as well as government organizations around the world, will likely require this information as well. Thus, documenting and reporting the SBOM of the software you create should become a required universal practice.
What’s in an SBOM?
An SBOM contains a list of the “ingredients” that make up software, including libraries and modules – whether open source or proprietary, free or paid – as well as information about development tools and CI (continuous integration). environment variables used during the build process.
SBOM can also indicate when software was built, what SDLC stages it went through – development, quality control, staging, production – and what security and compliance issues were detected and resolved.
This information reinforces DevSecOps efforts and helps maintain security and compliance in a variety of use cases, including:
- For software vendors: An SBOM helps them build and maintain their applications by detailing all upstream components used and tracking changes between different versions of the application. When a vulnerability that affects their application is disclosed, software vendors can immediately detect which versions are impacted and how, quickly resolve the issue, and notify their customers.
- For software buyers; SBOM helps them have visibility into the makeup of the product they are purchasing to ensure that it meets their safety and compliance standards and requirements, especially if they are in a highly regulated industry. It also helps them anticipate and quantify the risks inherent in a particular software package.
- For software operators: SBOM helps inform their processes for managing vulnerabilities and assets, verifying license compliance, and identifying risky software components. SBOM can also help them optimize software performance and reliability, reducing the risk of outages and malfunctions.
The more complex an application, the more valuable an SBOM is, as it provides clarity on all interdependencies within components and among the multiple container layers of software, including the application layer, execution layer, and software layer. base of the operating system. .
For example, like a fancy big cake, a complex web service has many layers with many ingredients. In the case of the web service, the layers are often Docker images, and each must have its own SBOM. There should also be a main and umbrella SBOM that encompasses all individuals.
This way, you can track all dependencies and sub-dependencies and isolate individual web service components to identify those affected by a security or compliance issue, such as a critical vulnerability or misconfiguration. With this information, you can detect and resolve issues early and quickly, reducing the risk of breaches. For example, it is estimated that almost 75% of applications with vulnerable libraries can be fixed by upgrading to a new version with updated libraries.
Misconceptions of SBOM
Over the years, unfounded objections to SBOMs have arisen, including:
- Won’t an SBOM provide a roadmap for hackers? No, the information in an SBOM won’t give attackers the clues they need to hack your software, and they won’t even bother to look at SBOMs. They have much more powerful and sophisticated tools to carry out their nefarious deeds.
- Won’t you have to disclose your source code in an SBOM? No, you don’t. An SBOM contains information about the content of your software and the environment in which it was created, but not your source code.
- Won’t an SBOM expose my confidential intellectual property? No, SBOMs do not contain proprietary IP data.
It is important to understand that SBOM is simply metadata about the software and not the software itself. It contains data on what was used to create the software, but not on the process with which it was put together.
How JFrog and AWS Can Help You
With the JFrog DevOps Platform– and in particular with JFrog Artifactory, JFrog Xray and JFrog Distribution – hosted on AWS, you can easily get all the granular data you need for an SBOM, including:
- All the transitive dependencies of your software
- Detailed information on the CI environment
- Security and compliance data, including the “blast radius” of vulnerabilities and non-compliant licenses in all versions of your applications
- Distribution data, such as how, when and where your software was deployed, which customers received it, etc.
This treasure trove of information about your software is available both through the JFrog user interface and through the JFrog REST API, so you can export it to the third-party tools of your choice.
(For practical technical details on how the JFrog DevOps Platform can help you determine if you are affected by the SolarWinds violation, where you are affected, and how you can remedy the affected libraries, read our recent blog post. “Automatically Evaluate and Fix SolarWinds Hack.”)
In summary, now is the time to pay more attention to SBOM and move it up your DevSecOps priority list, for all of the reasons discussed above.
Do not hesitate to contact us if you wish to explore this subject further. And don’t forget to register for our next webinar with AWS!
JFrog Ltd. published this content on August 24, 2021 and is solely responsible for the information it contains. Distributed by Public, unedited and unmodified, on 25 Aug 2021 06:53:06 AM UTC.