Are Software composition analysis (SCA) scans and container scans the same thing? The short answer is yes… and no. A comprehensive container image scan applies SCA specifically to containers in combination with other analyses particular to containers, such as how they’re configured to deploy and the presence of secrets. Read on to learn the key differences.

Containers offer many benefits, including lightweight portability from one environment to another, but they add a layer of complexity to application security that can introduce additional risks. There are many ways a container can become vulnerable to attack: through its source code, how the container is built, how the container is configured, how it secures secrets, and how it interacts with the host and other containers. Each of these avenues has its own security solutions and best practices.

As the name might imply, it’s important to keep secrets secret. Access to even the smallest of secrets can open a window for attackers who can then escalate their access to other parts of the system, allowing them to find more important secrets along the way. Poor practices can leave many secrets lying around unprotected and just one seemingly unimportant secret can lead to a broad security breach.

The CVSS (Common Vulnerability Scoring System) is a widely used standard that produces a score between 0 and 10 to indicate the level of severity of a vulnerability. The most popular spot to find CVSS scores is on the National Vulnerability Database (NVD) website, where you’ll see CVSS scores for all CVE (Common Vulnerabilities and Exposures) IDs.

Static Application Security Testing (SAST) has a bit of a bad reputation. SAST tools can produce an overwhelming number of alerts and security teams, having often come from networking backgrounds, don’t always fully understand the alerts that they are passing on to developers for fixes. This can cause the relationships between the teams to sour, as developers often perceive this work as pointless and holding them back from working on their primary responsibilities like new features.

In my previous blog post, we saw how the growth of generative AI and Large Language Models has created a new set of challenges and threats to cybersecurity. However, it’s not just new issues that we need to be concerned about. The scope and capabilities of this technology and the volume of the components that it handles can exacerbate existing cybersecurity challenges. That’s because LLMs are deployed globally, and their impact is widespread.

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.