SBOMs are critical to software supply chain security — but only the first step in your journey – Security Boulevard

The Home of the Security Bloggers Network
Home » Security Bloggers Network » SBOMs are critical to software supply chain security — but only the first step in your journey
sbom-first-step
SBOMs are key to software supply chain security. But they are also only the first step on your software supply chain journey. Here’s what you need to focus on for a comprehensive approach to security across the entire software development pipeline.
Increased use of third-party code and the risks it poses to software supply chains has fueled interest in software bills of materials (SBOM). In addition, the federal government has made software supply chain security a priority following the SolarWinds attack.
An SBOM can inform a user about the third-party components in the software they’re using and make it easier to find and mitigate vulnerabilities after they’re discovered. However, organizations need to recognize that SBOMs alone cannot adequately protect their software supply chains.
Henry Young, policy director for the BSA, an international software advocacy group, maintained in a posting at the organization’s website that an SBOM will not address most of the daily cyber risks confronting an organization. For example, he pointed out an SBOM will have limited value in making procurement decisions for a number of reasons. Chief among them is that vendors will be updating SBOMs so frequently, that the user’s SBOM will likely be out of date by the time a procurement decision is made.
However, Young said that an SBOM will significantly improve an organization’s response to and recovery from a cyber incident by expediting an organization’s determination about whether it is using software with a known vulnerability, and if that vulnerability is exploitable.
Gartner Analyst Mark Driver recently wrote in an Emerging Tech report on SBOMs:
“SBOMs are not a panacea. They are only as useful as the processes and tools implemented to process, analyze, and leverage the information they contain.” 
Mark Driver

In the report, which noted that demand for SBOMs would increase from 5% today to 60% in 2025, Drive wrote that additional tools and techniques, such as software composition analysis and code signing, were also “necessary elements of a complete software supply chain management effort.”
Here’s what you need to know about SBOMs—and the required next steps for your software supply chain journey.
Get a free SBOM and full supply chain risk analysis report ]
While the inventory of software components an SBOM can provide an organization is an essential part of software supply chain security, more will need to be done to validate those components.
Richard Hill, director of IAM Research at the analyst firm KuppingerCole, recommends ensuring source code integrity by putting security into place on the source control management system and on associated software repositories.
Software code and other artifacts need to be scanned for vulnerabilities, he continued. To guard against tampering, build integrity processes need to verify the provenance of build artifacts and check code to see if it has been signed and validated. Container artifacts, such as Docker images, also need to be scrutinized for vulnerabilities and compliance issues. Other types of scans, such as API scans, should occur in the CI/CD pipeline, he added.
In addition to obtaining SBOMs for software that they use, the Enduring Security Framework working group provided recent comprehensive guidance to software teams, recommending that organizations perform binary and software composition analysis (SCA) scans. Third-party software, sometimes delivered in binary format, is like a black box for the engineer or the organization who is integrating it, the panel explained. The software may not be actively maintained and may have security weaknesses or vulnerabilities.
Binary scanning and software composition analysis (SCA) tools can often detect unknown files and the open source components contained in binary packages, identifying the security weaknesses associated with these components without the need for source code, the panel explained.
Those activities are highly recommended to verify the integrity of the third-party software, it added. What’s more, it continued, the output can be compared with the SBOM, or the source codes provided by the third party, to verify the vendor’s SBOM.
An SBOM can give an organization an understanding of the composition of a product, but for a deeper understanding of the risks posed by it, other technologies are needed, such as context-based analysis and Vulnerability Exploitability eXchange (VEX) reports. Those technologies allow an organization to assess the exploitability of a vulnerability.
Context-based analysis identifies and prioritizes vulnerabilities in digital systems. It goes far beyond analyzing just software components, accounting for hardware architecture, OS configurations, encryption mechanisms, keys, hardening mechanisms, control flow, and APIs in its assessment of a vulnerability’s impact on a system.
SBOMs inform an organization about the ingredients in a software package, while context analysis adds meaning to the process. It allows an organization to get a more accurate picture of the risk it faces so it doesn’t waste time tackling non-issues and so it can spend more time on issues that matter.
VEX reports can complement an SBOM. They allow a software supplier or other preparers to present their assessment of vulnerabilities they’ve found in a product. It, too, seeks to separate non-threatening flaws from those that need priority attention.
A VEX report doesn’t provide the kind of in-depth information produced by context-based analysis, but when used in conjunction with an SBOM, it can give an organization a better view of the true exploitability of the vulnerabilities it finds and help streamline the remediation process. 
Software these days not only leans on third-party dependencies, but it also depends on the cloud. That’s why organizations may also want to look beyond SBOMs to “SaaSBOMs”.
Walter H. Haydock, a non-resident fellow at the Center for Security and Emerging Technology and an author Deploy Securely, and Chris Hughes, co-founder and CISO at Aquia, wrote in an article on CSO Online that with near ubiquitous moved to Software as a Service (SaaS), the ambiguity with what’s in an SBOM at one point in time to the next “presents a hurdle toward the effective use of SBOMs as a risk management tool.”
“In addition to a lack of answers as to what consumers will do with SBOMs once they receive them, it is even less clear as to how to develop them for vendor-managed deployment models such as software as a service (SaaS).” 
Walter H. Haydock and Chris Hughes
Such an expansion of the SBOM concept will include information on a cloud service provider’s infrastructure-as-a-service or platform-as-a-service on which an organization’s software runs. Building a SaaSBOM also requires taking an inventory of APIs. That can give an organization a leg up on future SBOMs, since such an inventory may eventually be added to the minimum requirements for a standard SBOM.
While an SBOM is valuable for giving an organization a view into the third-party dependencies used by its software, it can gain even more visibility by participating in the open source projects maintaining those dependencies. “You should actively contribute to the projects that are key to the success of your applications and business. You’ll know exactly what is used and what isn’t, down to the level of single functions deep down in the pile of open-source projects you depend on,” advised Henrik Plate, a security researcher at Endor Labs, a dependency management company.
Ed Moyle, a member of the ISACA Emerging Trends Working Group and systems and software security director at Drake Software, said it was important to understand what open source projects you’re dependent on, and the relative health of those projects. “In cases where the health of a project is slipping, consider helping out. A lot of open source projects are starved for resources—if you’re a commercial entity and you are dependent on a given project, consider ways to support the community and keep it healthy.”
“People sometimes think of open source as a one-way value diode where they suck value out and don’t contribute back. But really, it’s a community. Be part of that community and you can actively help keep those projects healthy. The stronger and healthier the community is, the more likely they are to be able to respond quickly, to apply resources to code audits and vetting.”
Ed Moyle

Hill emphasizes in his report that the modern software development pipeline demands an end-to-end security approach. 
“[When] securing the software supply chain, the journey starts at the security and privacy by design phase when creating the software system architecture and coding of the design begins and continues throughout software deployment and lifecycle.”
Richard Hill

*** This is a Security Bloggers Network syndicated blog from ReversingLabs Blog authored by John P. Mello Jr.. Read the original post at: https://blog.reversinglabs.com/blog/sbom-critical-but-first-step-software-supply-chain-security
More Webinars
Security Boulevard Logo White
DMCA

source

Note that any programming tips and code writing requires some knowledge of computer programming. Please, be careful if you do not know what you are doing…

Post expires at 10:25pm on Thursday April 27th, 2023

Leave a Reply

Next Post

Hastings woman out $83K in cryptocurrency scam - KSNB

Thu Oct 27 , 2022
HASTINGS, Neb. (KSNB) – Hastings Police are investigating after a woman was scammed out of thousands of dollars.HPD Corporal Nathan Hanson said the 58-year-old woman from Hastings transferred $83,000 through the Coinme app.The application touts itself as the easiest way to buy or sell crypto using cash or debit.Cpl. Hanson […]
%d bloggers like this: