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:
- 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.
- 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.
- Legacy builds might not place code into the Artifact Repository - they might deploy straight into testing/production environments.
- 3rd party proprietary code might not have source available, or might not be in the Artifact Repository at all.
- The deploy processes that move code between different environments might introduce differences in the code in UAT vs Production.
- Sometimes servers are Monkey Patched with new code in emergencies, skipping all the intermediate steps on the pipeline to put software into production.
- 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
Let's work from left to right in the pipeline and examine what tools are available to help with each stage.
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
Here are some tools popular with teams involved in the body of knowledge for inventorying activities:
|Binary repository management, build integration, Xray integration, replication support, access control
|Binary repository management, component intelligence, build integration, role-based access control
|Security vulnerability detection, license compliance, continuous monitoring, integration with Artifactory
|Security vulnerability detection, policy enforcement, continuous monitoring, integration with Nexus Repository
|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
Here are some tools marketed as handling runtime software inventory. We are interested to get feedback on whether these are useful:
|Tanium provides a unified endpoint management and security platform for IT operations and security teams. Key features include real-time data collection and remediation, flexible endpoint management, vulnerability assessment, threat detection, incident response, and compliance support.
|AutoCloud.io is a cloud-based configuration management database tool that provides real-time visibility into your IT landscape. It offers automated discovery of your entire IT environment, relationship mapping, risk assessment, change tracking, and integration with IT service management tools.
|Nexpose is a vulnerability management tool that provides live monitoring of changes in the environment, adapts to new threats with fresh data, and remediates vulnerabilities faster. Key features include live dashboards and reports, remediation workflows, risk scoring, and integrations with incident response and automation tools.
|Qualys Cloud Platform
|The Qualys Cloud Platform is a cloud-based tool for IT, security, and compliance. Key features include asset discovery, network security, threat protection, web application security, security configuration assessment, and end-of-life tracking for all your global IT assets.
|Tenable.io is a vulnerability management tool that provides actionable insight into your security risks. Key features include a unified view of your assets and vulnerabilities, automated network scanning, web application scanning, container security, and integrations with IT operations and DevOps tools.