Sonatype has partnered with the Cloud Native Computing Foundation (CNCF) for Security Slam, an event to help improve the security of open source projects. To extend the value of this event, we created a series of blog posts on best practices for open source maintainers.

Here in the second post of our series, we explore how your project can benefit from the use of a software bill of materials (SBOM).

Where to begin with security vulnerabilities

As an open source maintainer, you already work to ensure your project’s code doesn’t contain vulnerabilities such as flaws, glitches, or other weak spots that a bad actor can exploit.

But that’s only half the battle.

Since you rely on other open source components to save you time and deliver new capabilities, you need to manage the risks created by your web of dependencies and root out any security vulnerabilities nested within your dependency tree.

Consider how nearly 96% of all known vulnerable components have a fixed version available— an SBOM will help drive attention and create transparency around these things. You need to know if you’re introducing any open source components that contain known vulnerabilities, or worse, malicious code that bad actors are waiting to exploit.

Fortunately, there are excellent tools available, many free for open source projects, that can identify vulnerable or malicious open source on every pull request. Adding a tool to your project is as easy as going to GitHub Marketplace, selecting one, and enabling it on your repository. As an added bonus, many of these tools also generate SBOMs, yet another critical element to improve open source security.

What an SBOM provides

In the fallout of the disaster that was Log4Shell, as of this writing, 33% of all Log4j package downloads continue to be (Read more...)