Government: What's in Your Software?

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.  The report notes:

• 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 - 90% 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% (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 like the American Bankers Association (ABA) and the Energy Sector Control Systems Working Group (ESCSWG), along with private sector organizations like 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 they sold me 10 years ago and tracked me down.  The company informed me that they are 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, he shared:

“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.  By partnering with Sonatype, we’re able to provide our customers with a detailed Software Bill of Materials validating that VMTurbo applications consist of only the highest quality open source components.”

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.

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.