Why your organization needs a software nomenclature

The recent Log4j vulnerability exposed systemic issues in the way businesses, and the community at large, audit their software.

Early indications show that the Log4j vulnerability was militarized and exploited days before the announcement of its existence. Organizations needed to take immediate action to find all instances of the vulnerability in linked libraries, but most did not have a clear overview of where these instances existed in their systems. from google own research showed that over 8% of all packages on Maven Central have a vulnerable version of Log4j in their dependencies, but of this group only a fifth reported it directly. This means that approximately 28,000 packages on Maven Central are affected by these bugs without ever declaring or using Log4j directly.

Finding all the vulnerable dependency instances and confirming patch levels can be a daunting task, even for software that you control and develop entirely in-house. Identifying it with your suppliers can be even more difficult. Often these providers have an equally obscure idea of ​​their own dependencies.

Like all other IT assets such as servers, laptops or installed applications, having an accurate inventory of your software and dependencies (both direct and transitive) is an essential security control, and arguably the most important. fundamental, that you can apply. Businesses can’t secure what they aren’t aware of. How are businesses starting to take control of the growing complexity of addictions? By auditing and automating dependency graphs, starting with direct dependencies and working through transitive dependencies, often referred to as software nomenclature (SBOM).

While there are nuances in the discussion of what an SBOM should be and contain, for the purposes of this article we will simply refer informally to an SBOM as a manifesto of all the components and libraries provided. with an application, as well as their licenses. This includes tools and related libraries. If you provide a Docker image, it should also include a list of all installed packages.

Take your software supply chain seriously

Unfortunately, the ecosystem for generating these dependency maps often suffers from a lack of sufficient tools. While the tools available to analyze vulnerability dependencies evolve and improve rapidly, the field is still in its infancy. Snyk, Anchore, and other tools provide incredible visibility into your application’s dependencies, but few languages ​​provide native tools for generating full visual maps. As an example, let’s take a look at an older language (Java) and a newer language (Go) that were given the time and experience to develop a modern package ecosystem.

In Java, developers can use tools such as jdeps (introduced in JDK 8) or Maven Dependency Analyzer, while the Golang, despite its modernity, endeavored early on to develop its own history of addiction management and instead authorized tools like Dep (obsolete and archived) to fill in the gaps before finally settling on its own module system. In either case, direct dependencies are generally easy to enumerate, but a full and complete list of direct and transitive dependencies can be difficult to build without additional tools.

For open source maintainers, Google has started a very useful project called Open source information for auditing projects hosted on NPM, PyPI or Github, or similar locations. Much work and research is already applied in this area, but it is clear that much remains to be done.

While it is essential that the applications themselves are audited for dependencies and vulnerabilities, this is only the beginning of the story. Just as an asset inventory or vulnerability report can only tell you what’s out there, an SBOM is just a manifesto of packages and dependencies. These dependencies should be audited for their relative health beyond any vulnerabilities that might be reported. For example, an addiction may not respond to qualifications should be reported to the National Institute of Standards and Technology (NIST) and may not have Common Vulnerability Exposure (CVE) assigned for any reason, whether an issue with abandonware or an entirely in-house product that is relatively little reviewed. Other reasons it may not be reported include ownership or maintenance of the library having been transferred to the wrong actor, bad actors intentionally modifying versions, outdated and vulnerable packages in the Docker container running the application. and / or hosts running old nuclei with known and critical nuclei. CVE.

The organization’s security managers are responsible for studying and thinking deeply about software supply chain issues that could affect their products or business, and it all starts with collecting an accurate inventory of dependencies in the SBOM.

Generating an SBOM

Generating an SBOM can be a technical challenge in itself, but remember that organizations are made up of people and processes. Understanding and evangelizing the need for such work is of crucial importance to gain buy-in. As mentioned above, security managers in organizations should start by taking an inventory of all their software, containers, and packages or applications from third-party vendors. After the first inventory level is complete, the next step is to determine the direct dependencies and finally the transitive dependencies. This process should be very similar to any other discovery process, such as event logging or asset inventory.

When you evangelize an SBOM to your organization, consider the following benefits:

1. A complete, up-to-date, and accurate inventory of your software dependencies dramatically reduces resolution time when vulnerabilities in packages such as Log4j are discovered.

2. A manifest generated during the CI / CD process also provides instant feedback on new dependencies and can prevent the inclusion of new vulnerable components in your software by enforcing policies at build time.

3. It is often said that what gets measured gets better. Keeping an eye on your addictions promotes hygiene by removing unnecessary addictions and removing old ones.

4. It encourages consistency in software release management, which saves engineering and security teams time and money.

5. According to the White House, he will soon become a compliance requirement for many organizations.

As the complexity of our software stacks continues to increase and supply chains become increasingly tempting and viable targets for attackers, techniques and tools such as dependency management and SBOMs must become essential elements of our overall security strategy. And security managers have a responsibility to communicate these benefits of these tools to their organizations.

Bren Briggs is Director of DevOps and Cyber ​​Security at Hypergiant.