We’ve talked a lot about why software bills of materials (SBOMs) are important and how they communicate the value of your organization, so we won’t continue those lectures here. We’re all good on the why so today we’ll talk about the how – the best (and free!) tools to help you create SBOMs automatically. Creating an SBOM manually is arduous and error-prone so why not avoid it altogether?

EPSS is a relatively recent addition to the world of freely available security scoring systems. While it’s not without its flaws and limitations, EPSS can be a powerful predictor of exploits to come and a useful tool in your arsenal, as long as you wield it correctly.

So you want to use AI-generated code in your software or maybe your developers already are using it. Is it too risky? Large language model technology is progressing at rapid speeds, and policy makers are ill-equipped to catch up quickly. Anything resembling legal clarity may take years to come about. Some organizations are deciding not to use AI at all for code generation, while others are using it cautiously — but everyone has questions.

In my previous post, I began to list the ways you can strengthen your security posture, with some holistic approaches to application security and the software supply chain. In this second part of the series, let’s look at six more important considerations.

Developing applications and working within the software supply chain requires hard skills such as coding and proficiency in programming languages. However, protecting the software supply chain also requires some softer skills and an openness to strategies and tools that will strengthen your security posture. In this two-part series, we will discuss these considerations and how they support a holistic approach to application security and software supply chain security.

Some things, like choosing tools, are perennial problems. Others, like complete security team turnover, seem to be a more recent development within my circles. But either way, staff turnover has ripple effects that are not always immediately apparent. Let’s take a look.

An open source license is a binding legal contract between author and user that declares the certain conditions in which a piece of software can be used, which is especially relevant in commercial applications. This license is what turns software components into open source components, allowing developers to use that software so long as they keep the specific terms and conditions laid out in the license. There are a lot of open source licenses, over 200 in fact.

Code doesn’t write itself and software doesn’t secure itself, as much as the race is on to make that happen. At the beginning and end of everything in software is people and, importantly, people interacting with each other. Having great tools doesn’t matter if no one uses them, and having great policies doesn’t matter if no one enforces them.