To prevent cyberattacks, the government should limit the scope of a software nomenclature – TechCrunch

The May 2021 White House Executive Order on Improving Cybersecurity in the United States includes provision for a Software Bill of Materials (SBOM), a formal record containing supply chain details and relationships of various components used in the construction of a software product.

An SBOM is the complete list of all the elements 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, those who select or purchase software, and those who operate the software.

As the executive order 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 exploit 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 offers greater benefits through automation and tool integration,” the executive order says. “SBOMs gain value when 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 scan for 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 foundation for its functionality. Each 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 executive order 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.

Obviously, the intent of an SBOM is good. If software vendors aren’t upgrading dependencies to eliminate security vulnerabilities, we need to be able to ask vendors to share their dependency lists. In this way, fear of ridicule from customers 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’s 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 grow into hundreds. And if a modern application consists of a few hundred microservices, which is not uncommon, the list of dependencies can grow into the thousands.

If a software vendor were to publish 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 are vulnerable, and let’s say that list numbers in the hundreds. Now what?

Obviously, having to upgrade hundreds of vulnerable dependencies is no trivial task. A software vendor would be constantly choosing between adding new features that generate revenue and keep the business ahead of competitors or upgrading dependencies that don’t either. more.

If the government formalizes an SBOM mandate and begins to financially penalize vendors who have vulnerable dependencies, it’s clear that given the complexity associated with upgrading dependencies, software vendors might choose to pay fines rather than risk losing revenue or a competitive advantage in the marketplace.

Revenue 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 vendors generally do not want to publish lists of all of their dependencies, as this provides a lot of information to 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 discover weaknesses.

Customers and users of the software, on the other hand, do not want to know all the dependencies. What would they gain by studying a list of hundreds of dependencies? Instead, software vendors and their customers want to know what dependencies, if any, make the application vulnerable. This is really the key question.

Software Composition Analysis (SCA) prioritization 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 publishing a list of 1,000 dependencies, or 100 that are vulnerable, organizations can publish 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, it can make changes to the code, which is not always possible if one simply searches the list of vulnerable dependencies.

There’s no reason to dismiss the concept of SBOM altogether. By all means, let’s make software vendors responsible for being transparent about what’s going on in their software products. Many organizations have paid a heavy price due to preventable software vulnerabilities in the form of data breaches and other cybersecurity attacks.

Indeed, it is heartening to see the federal government taking cybersecurity so seriously and coming up with 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 directly reducing sources of vulnerabilities that can cause harm. In this way, we can solve ongoing problems without creating unnecessary burdens.