How to Spell Security B-O-M

Before you can talk about application security you first need to know:

  1. Which applications are deployed where? i.e., an application inventory
  2. What components comprise the applications? i.e. a Bill Of Materials (BOM)

Unfortunately, as BSIMM9 points out, these two fundamentals are not widespread in today’s enterprises.

The “Building Security in Maturity Model” (BSIMM) is a measuring stick for software security. The latest version (BSIMM9), examines how 12 security models have been adopted by some 120 firms (from Adobe to Zephyr Health) spanning financial services, ISVs, tech, healthcare, cloud, IoT, insurance, and retail.

When it comes to application inventories and BOMs, BSIMM9 has this to say:

Recommendation: develop an operations inventory of applications

  • Implementation: only 47.5% of participating companies have an application inventory.

Recommendation: enhance application inventory with operations bill of materials

  • Implementation: 0% of participating companies have application BOMs

How can this be? More than half of enterprises don’t know which applications they have deployed, and none of them know what’s in those applications? Let’s take a closer look.

 

Improvising an Inventory

BSIMM9 defines an application inventory as “a map of software deployments.” But it also adds, “Common components shared between multiple projects are noted so that, when an error occurs in one application, other applications that share the same components can be fixed as well.”

Sounds like a laudable goal. And in fact, at one large corporation I used to work at, it’s something we tried to accomplish. The InfoSec group required all Dev Managers to perform the onerous task of updating a database with all the components in their SaaS application each time that application was changed. Teasing out all the components and their current version across multiple languages (our front end was JavaScript; backend Java) per major/minor release was tough enough. But keeping track across multiple production pushes per week was backbreaking.

While we would have fallen into the 47.5% of enterprises that could put a checkmark against this requirement, given the workload it’s understandable why >50% of enterprises can’t. A BOM of what’s currently deployed would have simplified this task enormously.

 

BOM’ing Out

BSIMM9 recommends creating a BOM for all production-deployed applications, which includes “components, dependencies, configurations, external services, and so on… [in order to allow] for timely response when unfortunate events occur.”

Sounds reasonable. However, the reality within most enterprises is that once an application is deployed, it’s forgotten about by everyone except Ops. But Ops typically doesn’t have the bandwidth to be proactively looking for things that might go wrong – they’re too busy wrestling with existing issues.

The closest thing enterprises have to a BOM for their production-deployed applications would be in their binary repository and build system. After all, in any mature software organization applications are never modified directly in production, so what’s being pulled from your repo and successfully built by your CI system should mirror what’s in production, right?

Unfortunately, according to Gartner:

“At the production stage, vulnerabilities may have been reintroduced due to application and configuration changes, and because the production environment may differ from the test environment. In addition, new issues that could not previously be identified may now be … or this could be the first time the application is being tested, as is often the case with legacy applications.”

 

How you can Stop Worrying and Learn to Love the BOM

The ActiveState Platform recognizes this BOM problem and provides a solution. When users incorporate our instrumented Python interpreter within their runtime environment, it generates a comprehensive BOM view of their application. Whenever and wherever the code is run – from unit tests in the IDE to integration testing in the CI/CD chain to live code in production – the interpreter collects Python package information and sends it to the ActiveState Platform.

Every stakeholder in the enterprise can then log into the ActiveState Platform and view:

  • Which applications are deployed in production; which are still in development, and which are in the CI/CD chain, effectively providing an inventory map by environment.
  • Details about the packages that comprise each application, including their version number (and whether that version has been superseded), open source license, and whether the package has any vulnerabilities.

This BOM view has many benefits, such as:

  • Facilitates open source license audits by providing auditors with a comprehensive view of all licenses by component within the application so they can readily spot those that violate corporate policy.
  • By recording all components within the application and scanning them for vulnerabilities throughout the dev/test cycle, the result is far fewer false positives than a single scan in your CI/CD chain.

Want to see how it works? Schedule a demo of the Security & Compliance functionality.

Schedule Demo

 

You can also sign up for a free account on the ActiveState Platform to try out some of the other features.

Dana Crane

Dana Crane

Experienced Product Marketer and Product Manager with a demonstrated history of success in the computer software industry. Strong skills in Product Lifecycle Management, Pragmatic Marketing methods, Enterprise Software, Software as a Service (SaaS), Agile Methodologies, Customer Relationship Management (CRM), and Go-to-market Strategy.