Multiple agencies across the U.S. government are paying closer attention to the software they are buying. More specifically, they want to know what open-source and third-party components were used to build the software applications. For example:
- U.S. Food and Drug Administration (FDA) wants to know what open-source components are being used in medical devices.
- U.S. Department of Defense (DOD) is introducing new procurement language for software purchases to ensure it is free of vulnerabilities, either intentionally or unintentionally designed or inserted as part of the software.
- U.S. Federal Trade Commission (FTC) is filing complaints against businesses offering software with known vulnerabilities.
Similar moves by the National Institute of Standards and Technology (NIST), Underwriters Laboratories (UL) and the U.S. General Services Administration’s (GSA) 18F Group have also been noted over the past year. The common thread among these initiatives is a need for a Software Bill of Materials.
According to wikipedia, a “Software Bill of Materials (software BOM) is a list of components in a piece of software. Software vendors often create products by assembling open source and commercial software components. The software BOM describes the components in a product. It is analogous to a list of ingredients on food packaging.”
What’s in Your Software?
Nowadays, that question is not difficult to answer. Where software applications of the past were coded from scratch—each one being like a unique snowflake, today’s applications are assembled with reusable open-source and third-party components. With 80 percent to 90 percent of an application now built from open-source and third-party components, it is easy for organizations to quickly produce a Software Bill of Materials.
The Same Rules Apply to Software
You don’t want to purchase spoiled food, buy a car with defective airbags or have a relative receive a defective pacemaker. Modern society would not accept products built this way. The same rules apply to software.
Recent analysis of 25,000 applications that revealed 6.8 percent (about 1 in 16) of components used by development teams included a known security defect. The defects are known security vulnerabilities in open-source and third-party components used to build the applications. With known defect rates in software manufacturing so high compared to other manufacturing industries, it’s no wonder government agencies are paying more attention.
The Same Guidelines Apply Outside of the Government
Industry organizations including the American Bankers Association (ABA) and the Energy Sector Control Systems Working Group (ESCSWG), along with private sector organizations that include Exxon and The Mayo Clinic, are also mandating use of a Software Bill of Materials. Producing a Software Bill of Materials will soon be a common practice across development organizations, just as it is across other manufacturing industries.
A bill of materials provides a useful ingredient list. For some organizations, that ingredient list serves to inform businesses and government organizations that they are not buying products with known defective parts. Other organizations will rely on the bill of materials as a point of record for what parts were used within a released software application—again, another common practice in manufacturing.
Just yesterday, I received a recall notice from Toyota informing me that my car had a known defective Takata airbag. Toyota knows exactly what part was used in the car it sold me 10 years ago and tracked me down. The company informed me that it is working on a remedy to fix or replace that defective part in my car.
Imagine if application developers, using a Software Bill of Materials, could do the same thing as Toyota. Imagine the next OpenSSL heartbleed-like vulnerability is announced tomorrow. How many software practices could immediately identify if they used the specific version of that flawed component in their application. How many of those organizations could track that component down in seconds? How many of them would offer to remediate that critical defect in a timely manner?
It’s Not Just Rules—It’s Software Supply Chain Optimization
One of my favorite quotes from “The Phoenix Project” (a must-read novel about DevOps) goes like this: “You win when you protect the organization without putting meaningless work into the IT system. And you win even more when you can take meaningless work out of the system.”
An average application includes 106 open-source and third-party components. If you select the best components, you can build the best software. Use known defective components and you are introducing waste, rework and technical debt into the system—a.k.a., meaningless work.
Producing a Software Bill of Materials can help organizations quickly identify what parts have been used in an application—good or bad. In a recent discussion with VMTurbo’s Chief Architect, Sylvia Isler, she noted: “Zero tolerance for risk is also why some customers require us to provide proof that our applications do not contain hidden security or licensing vulnerabilities.” Not only does their zero-tolerance policy improve customer satisfaction, it also helps them by removing meaningless work from their system. Customers are happy and so are their development teams.
A Free Software Bill of Materials in 15 Seconds
There are companies that provide services to help users create a Software Bill of Materials. Sonatype, for example, offers the service for free service. Analyzing a typical application might take 20 seconds, and produces a list of all open-source components identified by their name, version and license type, and listing known security vulnerabilities, adoption rates, age and other attributes.
If governments and customers are paying closer attention to what’s in the software they are buying, it might just be time to figure out what’s in the software you are building.
