Software Inventory

Software inventory is a precondition to most of the activities involved in OSMM level 2. The first step to licence compliance or supply chain security is to understand what software is in your estate.

Conceptual Model: Pipeline

Before we do this, let's first lay out a simple conceptual model for how software gets to production which will allow us to identify the venues for performing a software inventory.

The above diagram shows an idealized pipeline of how software can get to production. Circles represent processes whilst squares represent destinations where software can rest or be held in some form before being pushed right to the next stage.

Shift Left vs Shift Right

Potentially, a software inventory could be performed at any stage on this pipeline, however:

• The most important inventory to get correct is at the right hand side since this is the software you are actually using.
• By shifting left with inventory you can discover problems sooner and potentially reduce costs.

It's not necessarily the case that you should pick a single place for inventory management. This is an idealized pipeline and there are plenty of ways the theory gets broken:

1. For projects being actively developed, the code on the left of the pipeline will be in an advanced version to the code on the right.
2. Builds often fail (or in new projects, won't have been set up), meaning the code in the source control will be a later version to that in the artifact repository.
3. Legacy builds might not place code into the Artifact Repository - they might deploy straight into testing/production environments.
4. 3rd party proprietary code might not have source available, or might not be in the Artifact Repository at all.
5. The deploy processes that move code between different environments might introduce differences in the code in UAT vs Production.
6. Sometimes servers are Monkey Patched with new code in emergencies, skipping all the intermediate steps on the pipeline to put software into production.
7. Compiled vs Source code licenses could be different. For example, Microsoft's VSCode licenses for source and binaries are different.

An advanced approach to software inventory would be "joined up" across multiple points in the pipeline.

Hierarchy of Dependencies

It is important to understand that modern software is composed of smaller units (which themselves can be composed of other units and so on). This means that the inventory of a single project or executable could potentially be a list of hundreds of dependencies. Recently, this "hierarchy of dependencies" has become known as a "Software Bill of Materials", or SBOM

Tools

Let's work from left to right in the pipeline and examine what tools are available to help with each stage.

Source Control

Dependabot

GitHub's OSPO uses Dependabot to review code in the many organisations and repos within their estate. It has sufficient understanding of the different build tools for each programming language to analyse the source code and build the Software Bill of Materials in order that it can then perform Software Composition Analysis.

FINOS Security Scanning

FINOS Security Scanning contains GitHub actions and recipes for best practices around performing CI-based scanning of projects for vulnerabilities and license violations. It recommends best-of-breed tools such as AuditJS for NodeJS, Safety for Python and OWASP Dependency Checking

Artifact Repository

Here are some tools popular with teams involved in the body of knowledge for inventorying activities:

Tool	Key Features
JFrog Artifactory	Binary repository management, build integration, Xray integration, replication support, access control
Sonatype Nexus	Binary repository management, component intelligence, build integration, role-based access control
JFrog Xray	Security vulnerability detection, license compliance, continuous monitoring, integration with Artifactory
Nexus Lifecycle	Security vulnerability detection, policy enforcement, continuous monitoring, integration with Nexus Repository
Synopsis' BlackDuck	Open source risk management, security vulnerability detection, license compliance, operational risk insights
Mend (formerly WhiteSource)	Open source security and license compliance, continuous monitoring, inventory reports, policy enforcement

Runtime Environments

tbd.