What serious issues besides vulnerabilities and compliance issues will keep you from sharing your SBOM?
You are going to find yourself in a jam. An urgent request for a Software Bill of Materials (SBOM) is going to come across your desk. Thinking that it’s a simple “push a button, get a report” process you’re going to ask an engineer to “push a button and get you a report”.
When you look at that report, your first SBOM, you are going to find a long list of problems that you won’t want to share with your customers or the government or whoever else is demanding a SBOM ASAP!
Let’s talk about what problems you’ll encounter.
In a previous article “Your first SBOM is going to stink. Don’t panic, get started fixing it!” I discussed common mechanical problems in getting to your first complete SBOM. These included Completeness, Depth, Unremediated Vulnerabilities, Open Source License Violations, and Over Delivery.
As part of the process, you will clear out vulnerabilities and open source license violations but along the way you will find other issues that may prevent you from sharing your SBOM.
These include Commercial Components with licensing problems, information you can’t share due to NDAs, architecture issues you don’t want exposed, export control issues, competitor’s technology, perceived over dependence on open source, and dependence on old code or technology.
Commercial Components and Technology
While much of the discussion around SBOMs has revolved around Open Source, there is still a large dependence on Commercial technology in the modern software stack. Most Software Composition Analysis (SCA) tools do not discover or report on Commercial components. If the contract or legislation your SBOM is being generated in order to fulfill requires a list of “all third party software” or explicitly calls out Commercial components as reportable, it will be required to discover and add these components to your SBOM. This is typically a manual process.
These commercial components often require payment or contract terms in order to be used. It is important to confirm that the usage is being tracked and properly paid for under the terms of the agreement. It is not uncommon to find commercial code that should have been removed at the end of a contract term still being used and shipped in a codebase. This may require re-licensing for continued use or rework to remove.
Additionally, you may find yourself with a conflict between the requirement to produce a complete SBOM and a Non-Disclosure Agreement with your technology vendor. It is important to understand any restriction on your ability to tell others about your usage of this commercial technology. It is also important to understand how to resolve any conflicts between a requirement to share everything with an agreement to keep some items confidential.
Competitors’ Technology or Relationship Disclosure
The larger your organization, the more likely that products have had a long lifetime, possibly being brought in through mergers and acquisitions or through technology partnerships. The technology stack that was appropriate a decade ago, may no longer be politically or commercially appropriate now. While reviewing your SBOM you may find indicators of components or technology coming from current competitors. It is very important to understand the licensing framework that this technology requires. Are there restrictions on using this technology? Has the cost become prohibitive? Will this potentially public use cause marketing, business or legal issues for your organization?
Will sharing of this SBOM alert competitors to your technology usage or business relationships?
It is common for business relationships to be confidential or at least kept quiet. Through this sharing of a SBOM, will these relationships become public? For example, does your new release swap out one technology (commercial or open source) with another, will this be a surprise to your own vendors or community? Is your executive management aware of this? Are there additional NDAs or agreements that could be put into place in order to limit sharing of this information? Are you prevented from sharing this relationship information in your SBOM? How can you legally satisfy both sides?
Export Licenses and Review
The shipping of certain technology may require export licenses or compliance review depending on your location and the type of technology being used. By creating a SBOM you may find yourself aware of technology that requires this process and review. It is important to bring in experts who are aware of export restrictions and requirements especially if there has been potentially missing compliance. Additionally, your organization may already be producing this required documentation which can be helpful in producing a complete SBOM. SCA scans often miss the commercial (and sometimes open source) components that may require export review. This is a manual review step when producing your SBOM.
Perceived Overdependence on Open Source Technology or Engines
Even though 90% of a project’s technology stack is typically open source, it can sometimes be a surprise to customers or the public to see the actual contents of the SBOM. If a company has made a big deal about “their secret sauce” or cutting edge technology, but the SBOM shows that it’s based heavily on an Open Source engine, you may find yourself with a marketing problem. If your organization is concerned about a customer asking “Why are we paying so much for this if it’s just rebranded Open Source?” it’s important to get ahead of the question and have a well thought out response to change this impression. This also might also be a time to look at your public and financial support of the open source you depend on. If you are heavily dependent on certain open source technology are you a financial supporter or major code contributor to the project? “Of course we are heavily dependent on it, we’re a major financial and code contributor to the project” can be a great response to this objection!
Dependence on Old code or Technologies
Before SBOMs, many commercial products were Closed Boxes where customers had little insight into how and when they were put together. By sharing a SBOM, it will be clear the years that the majority of the project was built in, the types of source code languages being used, and technology choices that can be second guessed.
If no new components have been added in years, you may have to manage customer expectations about perceived lack of development. If the technology stack is based on a programming language or architecture that is out of the mainstream or has become passe, you also may find yourself with a customer management problem. It is important to get an understanding of what objections customers may have when they read your SBOM for the first time based on age, architecture or design choices. These choices are often set in stone though, and management may need to provide staff with clear and concise responses to prevent customer concern.
Sharing what you Know
The process to getting to a Sharable SBOM requires attention to detail, coordination of multiple teams, and an understanding of how technological decisions can be impacted by legal, commercial and political concerns. It’s important to be aware of how SBOM creation and dissemination is occurring in your organization and to make sure that the business needs of the organization are reflected in the SBOM process. By being aware of these issues, you can prevent legal and commercial issues, as well as preventing ethical breaches when teams find themselves stuck between two contrary requirements. A little early planning goes a long way to showing that you are aware and in control of your technology and will continue to be a good partner going forward.
