Before you can talk about application security you first need to know:
- Which applications are deployed where? i.e., an application inventory
- 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 a Software Component 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.
Production vs Development Bill of Materials
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.”
The ActiveState Platform Bill of Materials
- Python, Perl and Tcl programming language
- Python, Perl and Tcl ecosystem packages and dependencies (as well as dependencies of dependencies)
- Windows and Linux OS-level dependencies
- Configuration/versions
Want to see how it works? Schedule a demo of the Security & Compliance functionality.
