[ad_1]
The May 2021 White House Executive Order on Improving Cyber Security in the United States includes a provision for a software nomenclature (SBOM), a formal record containing the details and supply chain relationships of the various components. used in the creation of a software product.
An SBOM is the complete list of everything needed to create an application. It lists all parts, including open source software (OSS) dependencies (direct), transitive OSS dependencies (indirect), open source packages, vendor agents, application programming interfaces (APIs) of vendors and vendor software development kits.
Software developers and vendors often create products by assembling existing open-source and commercial software components, the executive order notes. It is useful to those who develop or manufacture software, to those who select or purchase software, and to those who operate the software.
As the decree describes, an SBOM allows software developers to ensure that open source and third-party components are up to date. Buyers can use an SBOM to perform a vulnerability or license scan, both of which can be used to assess a product’s risk. And those who operate software can use SBOMs to quickly determine if they are at potential risk from a newly discovered vulnerability.
“A widely used, machine-readable SBOM format allows greater benefits through automation and tool integration,” the decree says. “SBOMs gain in value when they are collectively stored in a repository that can be easily queried by other applications and systems. Understanding the software supply chain, obtaining an SBOM, and using it to analyze known vulnerabilities are key to managing risk.
An SBOM is inherently hierarchical. The finished product sits at the top, and the hierarchy includes all of its dependencies providing a basis for its functionality. Any of these parts can be exploited in this hierarchical structure, resulting in a ripple effect.
Unsurprisingly, given the potential impact, there has been a lot of talk about the proposed SBOM provision since the decree was announced. This is certainly true within the cybersecurity community. Whenever there are attacks such as those against Equifax or Solarwinds that involve the exploitation of software vulnerabilities, there is renewed interest in this type of concept.
Clearly, the intention of an SBOM is good. If software vendors aren’t upgrading dependencies to eliminate security vulnerabilities, the idea is that we need to be able to ask vendors to share their dependency lists. In this way, fear of ridicule from the customer or the public might encourage software producers to do a better job of upgrading dependencies.
However, this is an old and outdated way of thinking. Modern applications and microservices use many dependencies. It is not uncommon for a small application to use dozens of dependencies, which in turn can use other dependencies. Soon, the list of dependencies used by a single application can reach hundreds. And if a modern application consists of a few hundred microservices, which is not uncommon, the list of dependencies can number in the thousands.
If a software vendor published such a comprehensive list, how would the end users of that software really benefit? Yes, we can also ask the software vendor to publish which of the dependencies is vulnerable, and let’s say that list is in the hundreds. Now what?
Obviously, having to upgrade hundreds of vulnerable dependencies is no trivial task. A software company would constantly decide between adding new features that generate revenue and keep the business ahead of its competition, or upgrading dependencies that also don’t.
If the government formalizes an SBOM mandate and begins to financially penalize vendors who have vulnerable dependencies, it is clear that given the complexity associated with upgrading dependencies, software vendors might choose to pay fines rather than pay fines. risk losing revenue or a competitive advantage in the market.
Income drives market capitalization, which in turn drives executive and employee compensation. Fines, no matter how small, have a negligible impact on the bottom line. In a purely economic sense, the choice is quite obvious.
Additionally, software companies generally do not want to publish lists of all their dependencies, as this provides a lot of information for hackers and other malicious actors as well as competitors. It’s bad enough that cybercriminals are able to find vulnerabilities on their own. Providing lists of dependencies gives them even more possible resources to uncover weaknesses.
Customers and users of the software, on the other hand, do not want to know all the dependencies. What would they gain from studying a list of hundreds of addictions? Rather, software vendors and their customers want to know which dependencies, if any, make the application vulnerable. This is really the key question.
Prioritizing Software Composition Analysis (SCA) ensures that when dependencies are analyzed in the context of an application, the dependencies that make an application vulnerable can be significantly reduced.
Instead of posting a list of 1,000 dependencies, or 100 that are vulnerable, organizations can post a much more manageable single-digit list. This is a problem that organizations can deal with much more easily. Sometimes a software vendor can fix a problem without having to upgrade the dependency. For example, he can make changes to the code, which is not always possible if one is simply looking for the list of vulnerable dependencies.
There is no reason to outright despise the concept of SBOM. By all means, let’s make software vendors accountable for being transparent about what goes into their software products. Many organizations have paid a high price for software vulnerabilities that could have been avoided in the form of data breaches and other cybersecurity attacks.
Indeed, it is heartwarming to see the federal government taking cybersecurity so seriously and proposing ways to improve application and data protection.
However, let’s make SBOM specific to the list of dependencies that actually make the application vulnerable. This serves both the vendor and its customers by cutting directly to the sources of vulnerabilities that can cause damage. This way, we can fix the issues without creating unnecessary burdens.
Source link
