By celeburma_zirmxt
Humans naturally oppose regulation; even when we are aware that a given measure is beneficial, we nevertheless find it unpleasant to be imposed upon.
Software Bills of Material (SBOMs) and the creation of software “recipes” were subject to regulations enforced by the US government. In essence, the foundation for developing a more intelligent technique to recognize possible security threats. It is hardly surprising that there are opposing views and reactions to this regulation.
A who’s who of tech industry heavyweights, the ITI Council, responded by calling SBOMs “not ready” and stating that the discussion as a whole needs to “mature” before the IT industry can consider taking on the additional burden of creating and maintaining these records—especially since the regulations don’t specify the standards to be followed.
It is a rather dubious strategy. Instead of fighting this rule, the IT industry should support it, spearhead its implementation, and foster an informed conversation about it rather than passively waiting for it to happen.
Support for SBOMs
The concept of bills of materials is not new. Often referred to as component lists or product recipes, these organized, standardized lists contain all the ingredients required to produce a product and are widely used in manufacturing.
They are essential in manufacturing for purchase planning and serve as the first port of call in the event of a defect or other problem. It is simple to identify any product that used a problematic component and initiate a recall or other appropriate action if one is determined to exist.
In addition to being a list of every open-source and third-party component found in a software package, an SBOM also includes information on each component’s version number, license, and patch status. Similar to manufacturing, in the event of an issue, this serves as an essential source of reference. When something goes wrong, an organization using open-source software can quickly identify potential vulnerabilities.
This is crucial because open-source is based on a community and hobbyist foundation that should never be forgotten, no matter how professionalized it gets. Therefore, the largest names in technology are creating tools based on code that may have been created as a side project and is not as actively maintained as other code, even while they are putting it on open-source platforms and creating products with open-source ideals.
An excellent illustration is the Log4Shell vulnerability. As its name implies, Log4j was used to record faults and occurrences and notify administrators of them. A 404 error is usually recorded by Log4j when a user accesses a website; if this occurs frequently, there may be an issue. Because of its widespread use and practicality, it was paradoxically somewhat obscure—a standard piece of software that was used everywhere without much consideration. Millions of servers might be attacked and taken over when it was discovered that Log4j could be used to insert code. Log4Shell has received the highest possible CVSS (Common Vulnerability Scoring System) rating of 10 from the NIST vulnerability database.
Contrarily, because Log4j was so widely used, it was simple to determine whether a patch or upgrade was required for practically every server. Even if they might not be as numerous in the future, vulnerabilities will still exist, which makes SBOMs very important.
Leading instead than resisting is necessary
The majority of the opposition to SBOM legislation has come from a pragmatic standpoint rather than an ethical one. “Currently available industry tools create SBOMs of varying degrees of complexity, quality, and completeness,” the ITI Council responded. The existence of several, occasionally erratic, or even contradicting attempts points to an immaturity in SBOMs.”
It is true that there are several approaches to creating an SBOM, meaning that there isn’t yet a single standard that every company or organization can follow. However, rather than tossing the can down the road, the tech behemoths ought to be taking the lead here. It should determine what the best standard is, embrace it, and, if necessary, look for ways to bridge the gap between these disparate standards rather than just shrugging and saying that this is impossible.
In the worst-case scenario, should this lobbying fail, SBOMs would be required without a standard, which would mean that anyone required to generate them would have to choose a method and apply it to satisfy the requirements of the rule. As is always the case, standardization will eventually occur when one instrument gains traction in the business by being the most widely used. However, for the firms who need to update their system, this will be expensive and take years to do.
We might observe another Log4Shell vulnerability while this is happening. Should that occur, the United States Government will be able to use its rule as evidence that it has required this industry-wide change. The industry will be caught off guard by something that is more or less unavoidable if the SBOM protocols that have been put in place are inadequate for the job at hand and do not support the appropriate response.
In the battle to lessen the impact of lesser flaws, SBOMs will be crucial in addressing the next major vulnerability. Instead of opposing any attempts at legislation, the IT industry should set a timeline and collaborate to find solutions to the problems associated with the adoption of SBOMs now. Efforts to lobby should be directed toward how this operates rather than whether it occurs at all.