Software supply chain security remains a challenge for most enterprises

Log4j, maybe more than any other security issue in recent years, thrust software supply chain security into the limelight, with even the White House weighing in. But even though virtually every technology executive is at least aware of the importance of creating a trustworthy and secure software supply chain, most continue to struggle with how to best implement a strategy around it.

The number of CVEs (Common Vulnerabilities and Exposures) continues to increase at a steady pace and there’s nary a container out there that doesn’t include at least some vulnerabilities. Some of those may be in libraries that aren’t even used when the container is in production, but they are vulnerabilities nevertheless.

Image Credits: Slim.ai

According to Slim.ai‘s latest Container Report, the average organization now deploys well over 50 containers from their vendors every month (and almost 10% deploy more than 250). Yet only 12% of the security leaders who responded to Slim.ai’s survey said they were able to achieve their own vulnerability remediation goals. Everybody else says they are “greatly” struggling or see significant room for improvement. And while those organizations are all pressuring their vendors to improve their security stance and deliver, the vendors and buyers often can’t even agree on which CVE’s actually need patching in a container.

As Ayse Kaya, Slim.ai’s VP for Strategic Insights and Analytics told me, the interaction between buyers and vendors is often still driven by the exchange of spreadsheets and ad hoc meetings between security groups. According to the company’s report, which it created in partnership with research firm Enterprise Strategy Group, that’s still how 75% of organizations exchange information with their vendors, even as virtually all security leaders (84%) would look to see a centralized collaboration platform for managing vulnerabilities. For the time being, though, it seems like emailing spreadsheets back and forth remains to be the state of the art.

Image Credits: Slim.ai

All of this inevitably leads to inefficiencies. The majority of organizations that responded to the survey said they employ six or more specialists who focus on vulnerability remediation (with a quarter of respondents employing more than 10). One of the major problems in the industry is that more than 40% of the alerts these teams get are false positives — often for libraries that may be part of a container but aren’t used in production. Because of this, Kaya for example greatly advocates for creating minimal container images. One could argue that this should be a best practice anyway, since it creates a smaller attack surface and reduces false positives.

It’s not just security teams that have to deal with these vulnerabilities, though, of course. All of these efforts slow down the overall development process, too. Most companies see some disruptions multiple times a week because they detect a vulnerability in a production container, for example. According to Slim.ai’s report, the average container now sees a new release roughly every 11 days and the average container is now affected by 311 CVEs (up from 282 in 2022). All of that means more work, more interruptions and more effort expended in working with vendors to get them fixed.