If you develop or use software, which in 2025 is everyone, it feels like everything is starting to change. Software used to exist in a space where we could do almost anything they wanted and it didn’t seem like anyone was really paying attention. We all heard stories about mission critical Windows 95, still running today. Or running a version of Log4j older than the interns have been alive. Some will view it as some sort of golden age of software, to others it was the darkest of ages with no accountability. No matter what you think about how things used to work, we are on the precipice of change in the world of software development.
If you try to ask why things are starting to change, you’re going to get a multitude of answers. The why doesn’t really matter though, we need to understand the how. What is going to change? What should we be paying attention to? Anyone working on software will need to know what they have to pay attention to now. The what in this instance is compliance, a lot of new compliance standards.
So what are these standards we all need to start paying attention to? There’s not enough time to hit them all here, but a few names you’re going to start hearing more about are the EU Cyber Resilience Act (CRA), the Product Liability Directive (PLD). Secure Software Development Framework (SSDF), Cybersecurity in Medical Devices (everyone seems to be calling this “FDA”). And there are even more industry specific standards starting to emerge like PCI. We will cover all these and more over the course of this blog series.
What we’re seeing now is that the sort of compliance in healthcare doesn’t look like the compliance in automotive or financial. And then there are even broader things like the EU CRA that will cover everyone and everything. One of our challenges moving forward is figuring out which standards apply where and what needs to change. This can include the markets we sell into, the type of product we’re selling, the service(s) we’re providing. There won’t be any easy answers and we will all have to figure this out.
There’s a term I really like I heard someone use the other day: CompOps to build on the SecDevSecOpsSec sort of naming. Compliance Operations. A few years ago this could be dismissed as a weird and boring term, but as we see compliance everywhere we look, it’s going to be more important than ever to incorporate compliance into how we build and distribute software. Thinking about this with a DevOps mindset might be the only reasonable way forward.
We should take a moment to note the software industry is not special with all these new compliance standards. Virtually every existing industry has standards they must adhere to. Issues like food safety, human safety, auto safety, too many topics to list. Compliance is nothing new, we are not special. We’re finally catching up to everyone else.
While every one of these standards has different requirements. And we will of course cover many of those differences, there are certain things they all seem to have in common. The two that are probably easiest to understand and unpack are Software Bill of Materials (SBOMs) and vulnerabilities. At Anchore this is something we’ve been thinking about and working on for a very long time. Our SBOM and vulnerability projects Syft and Grype were created in 2020, and we had a tool called Anchore Engine before that.
Let’s start with SBOMs. Just because a compliance standard says you need an SBOM, that’s not necessarily helpful. What format does it need to be in? How are you supposed to store the SBOM? How long are you supposed to keep an SBOM around? Do you need to publish it on your website? Give it to customers, or regulators, or some other group? It’s one of those things that can seem really easy, but the devil is always in the details. We can answer some of these questions today, but some of them are going to evolve over time as the intention of regulators becomes more clear.
Vulnerabilities aren’t any easier, but might be a more tractable problem. You just need to release software that doesn’t have any vulnerabilities! That’s probably not easier than SBOMs. But recently we’ve seen very small hardened containers images show up that can make a huge difference with vulnerability wrangling. This doesn’t solve the problem of vulnerabilities in your dependencies and own code. But it will certainly free up your time to focus on your product rather than the things in your container base image.
Before we get to our exciting conclusion, it’s important to understand that all these compliance standards are going to have unintended consequences. There will be second and third order effects that create new problems while trying to solve the original problem. That’s how new standards work. It will be important for all of us to give feedback to the governing bodies of all these standards. They do listen and generally try to do the right things.
So what happens now? If you’ve never been involved in compliance standards before, this can all feel extremely overwhelming. It’s OK to panic for a little while, this sort of change is a big deal. There are a lot of resources available to help us all out. There are companies that can help us out. Plenty of people have made a career out of making compliance easy (or at least less hard).
This post is the start of a series where Anchore is going to help break down and explain many of the SBOM and software supply chain requirements in these standards. Helping out with SBOM requirements is something we’ve been working on for years. We knew SBOMs were going to end up in compliance standards, we just didn’t think it would happen so suddenly!
If this is your new reality, stay with us. We’ll be diving deep into each major standard, providing practical implementation guidance, and sharing what we’ve learned from organizations that are already ahead of the curve. Subscribe to our newsletter or follow us on LinkedIn to get these insights delivered directly to your inbox, because staying informed isn’t just a nice-to-have anymore: it’s a must-have.
Josh Bressers is Vice President of Security at Anchore where he guides security feature development for the company’s commercial and open source solutions. He serves on the Open Source Security Foundation technical advisory council and is a co-founder of the Global Security Database project, which is a Cloud Security Alliance working group that is defining the future of security vulnerability identifiers.
Learn about the role that SBOMs for the security of your organization in this white paper.
