Author: Josh Bressers

If you look at the trajectory of the software supply chain over the last few years, one thing becomes painfully clear: the old playbook is broken. For a decade, our industry has operated under the assumption that if we just hired enough people, bought enough scanners, and worked hard enough, we could reach a state of “perfect” security. We chased a clean dashboard with zero CVEs and a fortress-like perimeter.

But as we look toward 2026, that goal isn’t just difficult; it is mathematically impossible. We are facing a convergence of pressures that no amount of manual effort can withstand. The winners of the next era won’t be the ones with the cleanest reports. They will be the ones who have automated their compliance and built the engines to upgrade faster than the bad actors can attack.

To be honest, we don’t have a crystal ball. Nobody does. But we are trying our best to skate to where the puck is going. We want to share what we’re seeing so we can all navigate this shift together.

Reachability is not a silver bullet

For a long time, we pinned our hopes on “reachability.” The idea was simple: if a vulnerability isn’t reachable in the code, we don’t need to fix it. It was a triage strategy born of necessity.

However, the sheer volume of CVEs is growing out of control. Reachability is becoming a noisy, diminishing metric. It struggles to keep up with the flood. Reachability struggles with weakly typed languages like Python and Nodejs, which also happen to be two insanely popular languages. There’s also the problem of while you might not be using the code in question, can an attacker? The infosec world likes to call this “living off the land”. And there’s always the problem where someone starts using code that wasn’t used in the past, now you have a vulnerability that jumps out of nowhere unexpectedly.

We are moving toward a new metric: high velocity hygiene.

The question is shifting from “Is this vulnerable?” to “How fast can we upgrade?” We need to upgrade everything faster, not just the things with red flags attached to them. The goal is general hygiene across all of our code and dependencies. Technology that didn’t exist even a few years ago has come a long way to help us solve this problem. Hardened container images, vendored libraries, and automatic updates can make a gigantic difference. And of course vulnerability scanners that are fast and cover more ecosystems than ever before double check our work.

Supply chain attacks on steroids

Attacks will continue to rise because the fundamental incentives haven’t changed. Attackers still see many package repositories as prime targets, and every package repository is still struggling with resources. The rate of growth is not matching the rate of attacks. In fact, the attackers are about to get an upgrade.

We expect a significant increase in scale and sophistication as attackers leverage Large Language Models (LLMs). There is a distinct asymmetry at play here. Attackers have “zero red tape.” They can adopt new AI tools for exploitation immediately. We saw the start of this behavior with the Shai-Hulud attack in 2025.

Defenders, conversely, are slowed by procurement, legal reviews, and legacy infrastructure integration. This speed gap favors the adversary. While prevention is ideal, rapid response is the only viable reality for 2026.

EU CRA wake-up call

The industry is largely caught off guard regarding the EU Cyber Resilience Act (CRA). Later this year, (specifically; September 11) both vulnerability management and incident response will become law. As most deadlines work, the vast majority of organizations will start working on this around September 10.

This introduces strict reporting obligations (Article 14). Organizations must report actively exploited vulnerabilities and severe incidents to national authorities (CSIRTs) and ENISA within strict timelines.

Beyond reporting, SBOM requirements will be a critical part of this compliance landscape. You cannot report on what you do not know you have. Organizations will be forced to finally understand their software composition in depth, not as a “nice to have,” but to stay legal.

The inevitability of CompOps

“CompOps” (Compliance Operations) sounds like a buzzword nobody wants. Nobody likes compliance work. Also, it’s boring. But that is exactly why it will succeed.

As requirements mount, the only practical way to meet them is by applying DevOps principles to compliance. CompOps emerges as a survival mechanism. It is compliance that “just happens” through automation rather than a manual checklist. Most teams will start doing this by accident as compliance requirements get baked into the existing DevOps process.

We need to stop treating compliance as an annual audit event. It must be a continuous stream of evidence generated by the pipeline itself.

The state of open source in 2026

There will be more open source code than ever before. The graphs are still trending up exponentially.

We need to watch how major foundations like the Python Software Foundation (PSF), Apache, and Eclipse handle this pressure. They are facing the dual challenge of massive growth and new compliance requirements like the CRA demands on open source stewards.

The human element remains a serious risk. Developer burnout and funding are critical issues. We don’t yet know how far automation can take us in mitigating this, but the limit is being tested. We will be keeping an eye on the Sovereign Tech Agency in 2026.

Building the right boat

For too long, software supply chain security has relied on heroics. We relied on security engineers working late nights to triage thousands of CVEs. We relied on release managers scrambling to generate spreadsheets for auditors.

By 2026, that era must close. The sheer scale of the ecosystem means human heroism is no longer a scalable defense strategy.

We must build a system resilient by design. We need to treat the SBOM as a dynamic layer of observability. This allows teams to instantly query their entire software fleet to answer “where is X installed?”

Anchore helps organizations make this shift. We maintain open source tools like Syft (SBOM generation) and Grype (vulnerability scanning) to provide the data layer. For enterprises, the Anchore platform acts as the CompOps engine. It embeds “Policy-as-Code” directly into the CI/CD pipeline, enforcing rules automatically on every commit. This ensures you have the immediate, granular visibility needed to meet strict 24-hour incident reporting timelines without slowing down developers.

The outlook for 2026 isn’t about panic. It’s a “keep calm and carry on” moment. The flood waters are rising, but we are finally building the right boat.

Learn the 5 best practices for container security and how SBOMs play a pivotal role in securing your software supply chain.

Download Now

There’s a saying I use often, usually as a joke, but it’s often painfully true. Past me hates future me. What I mean by that is it seems the person I used to be keeps making choices that annoy the person I am now. The best example is booking that 5am flight, what was I thinking? But while I mean this mostly as a joke, we often don’t do things today that could benefit us in the future. What if we can do things that benefit us now, and in the future. Let’s talk about supply chain security in this context.

The world of supply chain security is more complicated and hard to understand than it’s ever been. There used to be a major supply chain attack or bug every couple of years. Now it seems like we see them every couple of weeks. In the past it was easy for us to mostly ignore long term supply chain problems because it was a problem for our future selves. We can’t really do that anymore, supply chain problems are something that affect present us, and future us. Also past us, but nobody likes them!

There are countless opinions on how to fix our supply chain problems. Everything from “it’s fine” to “ban all open source”. But there is one common thread every possible option has, and that’s understanding what software is in your supply chain. And when we say “software in your supply chain” we really mean all the open source you’re using. So how do we track all the open source we’re using? There are many opinions around this question, but the honest reality at this point is SBOMs (Software Bills of Material) won. So what does this have to do with us in the future?

Let’s tie all the pieces together now. We have a ton of open source. We have all these SBOMs, and we have a supply chain attack that’s going to affect future us. But not the distant future us, it’s the future us in a few weeks. It’s also possible we’re still in the middle of dealing with the last attack.

How does an inventory of our software help with future supply chain attacks?

When any sort of widespread incident happens in the world of security, the first question to ask is “am I affected” I have a blog post I wrote after one of the recent NPM incidents. A Zero-day Incident Response Story from the Watchers on the Wall. I can’t even remember where exactly it falls in the timeline of recent NPM attacks, there have been so many of these things. Most modern infrastructure is pretty complex. Asking the question “am I affected” isn’t as simple as it sounds.

If you have a container image, or a zip file, or a virtual machine that’s running your infrastructure, how do you even start to understand what’s inside? You might dig around and look for a specific filename, maybe something like “log4j.jar”. Sometimes looking for a certain file will work, sometimes it won’t. Did you know JAR files can be inside other JAR files? Now the problem is a lot harder.

It’s also worth noting that if you’re in the middle of a supply chain event, finding all your software and decompressing it isn’t a great use of time. It’s slow and a very error prone task. If you have thousands of artifacts to get through, that’s not going to happen quickly. When we’re in the middle of a security incident, we need the ability to move quickly and answer questions that come up as we learn more details.

Was I ever affected?

Let’s assume you figured out if you are, or aren’t, affected by a supply chain attack, the next question might be “was I ever affected?” Some supply chain problems don’t need a look back in time, but some do. If the problem was a single version of a malicious package that’s 6 hours old, you might not need an inventory of every version of every artifact ever deployed. But one of the challenges we have with these supply chain problems is we don’t know what’s going to happen next. If we need to know every version of every artifact that was deployed for the last two years, can most of us even answer that question?

It’s likely you’re not keeping artifacts laying around. They’re pretty big, but even if you don’t care about space, it can be really hard to keep track of everything. If you deploy once a day, and you have 20 services, that’s a lot of container images. Rather than keep the actual artifacts around taking up space, we can store just the metadata from those artifacts.

How can SBOMs help with this? SBOMs are just documents. One document per artifact. There are SBOM management systems that can help wrangle all these documents. While we’ve not yet solved the problem of storing a large number of software artifacts easily and efficiently. We have solved the problem of storing a large number of structured documents and making the data searchable.

The searchable angle is a pretty big deal. Even if you do have millions of stored container images, good luck searching through those. If you have a store of all your SBOMs, which would represent all the software you currently and have ever cared about, searching through that data is extremely fast and easy. We know how to search through structured data.

Next steps

Keep in mind that generating and collecting SBOMs is just the first step in a supply chain journey. But no journey can start without the first step. It’s also never been easier to start creating and storing SBOMs. We can benefit from the data right now. There’s a paper from the OpenSSF titled Improving Risk Management Decisions with SBOM Data that captures many of these use cases.

Fundamentally it’s an investment for our future selves who will need to know what all the software components are. It’s common for most solutions to either help present us or future us, but not both. When we start using an SBOM, why not both?

Explore SBOM use-cases for almost any department of the enterprise and learn how to unlock enterprise value to make the most of your software supply chain.

Download Now

If you’ve been in the security universe for the last few decades, you’ve heard of the OWASP Top Ten. It’s a list of 10 security problems that we move around every year and never really solve. Oh sure, there are a few things we’ve made less bad, but fundamentally the list shows how our use of technology changes rather than a measure of solving problems.

I was talking with a friend long ago and I made a comment along the lines of “I don’t understand why OWASP doesn’t create an effort to eradicate whatever is number one on the list”. Their response was “OWASP is mostly consultants, they don’t want to solve these problems”. I am aware of the cynical nature of that answer, but it stopped me in my tracks for a moment. The Top Ten list gets a ton of attention, and if you look at the attention the current list is receiving, it’s less about solutions and more talking about how exciting a newly shuffled list is. A new Top Ten list is exciting, and it’s especially exciting when there’s a new entry on the list.

For the rest of this post, I’m going to focus on the new supply chain entry on the list. It’s number 3.

It’s worth starting out with the premise that there is no “Software Supply Chain”. Well there is, but I mean it’s not a term or concept you can just define. I could try to define it here, and every single reader will disagree because their definition is 1) Different, and 2) Better. A clever reader might be thinking right now we should probably define what this means. We probably should. The current definition is probably “supply chain is whatever I’m trying to sell”. Oh wait, I said I wasn’t going to define it. Too late.

So anyway, the point of this blog post is to set expectations on what happens after something lands on the OWASP Top Ten list. There will be a lot of people who proclaim all the exposure the Top Ten list generates is the solution. As we all know exposure is the most valuable currency, so I’m sure the list will drive plenty of exposure. But it should come as no surprise that just being on this list isn’t a solution.

The things on the OWASP Top Ten are systemic problems in our industry. We don’t solve systemic problems by buying a security tool. You can solve part of the problem sometimes, but the actual problem isn’t something any one company solves. Let’s pick apart the Software Supply Chain as a systemic issue in the industry.

What most people mean when they say Software Supply Chain is open source. They mean they are struggling with all the open source that runs all the software now. There are countless surveys and reports that declare all software is somewhere between 80% and 99% open source. What we’re really worried about is the Open Source Software Supply Chain.

Part of what makes this so hard is there isn’t a singular Open Source Software Supply Chain; open source is a collection of millions of projects and tens of millions of people. Nobody is in charge. There can be pockets of coordination where groups work together but even then there are at most thousands of those groups and still millions of things lacking coordination. This is a number larger than anyone can possibly comprehend, much less understand. You’d be wise to avoid anyone claiming to understand open source, they are basically a bigfoot expert who has never seen bigfoot.

So let’s rewrite the new OWASP item. It’s not “Software Supply Chain Failures”. It’s more accurate to say “Collection of random software I found in the couch cushions that I don’t understand and we don’t know where most of it comes from”. But didn’t I just say you can’t understand your open source software? I said, you can’t understand the nebulous cloud known as Open Source; but there are things they have in common. You can understand the specific open source software that you use…if you want to. And you should.

This is like claiming instead of building a structure that can withstand a hurricane if you buy my anti-hurricane product. That’s a silly premise. What we really need are buildings that are designed to withstand the weather in the place they are built. A hurricane isn’t a concern if you’re in Chicago, but it is a concern if you’re in Miami. Using open source software is a similar problem.

The problems you will see in the NPM ecosystem are not the same as the problems you will see in the PyPI ecosystem. There are some similarities, but there are also many differences. For example, NPM has a lot of very small packages designed to do one thing, so you end up with a huge explosion of dependencies. PyPI has less dependency explosion, but they often ship pre-built binary components. Two very different sets of challenges.

So what should a proper response to Software Supply Chain Failures look like? There isn’t a single answer, but there are ideas and groups that are on the right path. The Cyber Resilience Act in the EU seems to be a good start. There are supply chain efforts in foundations like the Linux Foundation and the Eclipse Foundation. But those efforts are less about technology and more about the people. The TL;DR of many efforts is really “know what you’re shipping”. It’s the first place to start.

It’s easy to be a cynic about anything happening in the security space. There is a lot of good happening, but we need to roll up our sleeves and do the work. Open source is a team sport. Ask your vendors how they are helping. Ask your developers which projects they are helping out. Ask all the people on LinkedIn posting about the supply chain how they are helping (posting opinions on LinkedIn doesn’t count as helping).

If your first reaction to this is “that sounds hard” and your second reaction is “I don’t know where to start”, that’s OK. It is hard and it’s not always obvious where to start. The first step is knowing what you have. I’m partial to using SBOMs to figure this out, but it’s not the only way. If the open source you’re using is 99% Python, that’s where you can start. The Python Software Foundation has a bunch of working groups. If you don’t see anything you like there, go check out the OpenSSF, or OWASP, or one of the countless Linux Foundation vertical groups.

You could reach out and see if some of the python packages you are using could use help. Maybe it’s money, maybe it’s patches, maybe it’s just hanging out with them and chatting about what’s happening. You can even ask me (or someone else you know in this universe), I love talking about this stuff and I’ll point you at someone smarter than me who can help you out. There’s no one right way to get involved.

The most important takeaway from all this is just because OWASP added software supply chain (open source) to the list, doesn’t mean it will magically solve itself. Supply chain security making the OWASP list changes nothing unless we make the change happen. The things that have fallen off the OWASP list did so because groups of dedicated people did a lot of work to improve the situation. We are the dedicated people, we have to fix this. The cavalry isn’t coming to save us, we are the cavalry.

It’s starting to feel like 2025 is going to be the year of IT compliance. We hear about new regulations like the CRA, PLD, DORA, SSDF; as well as, updates to standards like FDA, PCI-DSS, and SSDF. If you’re a compliance nerd this has been an absolutely wild year. It seems like there’s a new compliance standard or update happening every other week. Why this is happening right now is a hotly contested topic. There’s no single reason we’re seeing compliance becoming more important than it’s ever been in the world of IT. But no matter the reason, and no matter if you think this is good or bad, it’s the new normal.

It should also be noted that IT isn’t special. It’s easy to claim IT isn’t comparable to other industries for many reasons; we move very fast and we don’t usually deal with physical goods. Many other industries have had regulations for tens or even hundreds of years. We can think of food safety or automobile safety as easy examples where regulations and compliance are a major driving force. If anything this shows us that IT is becoming a mature industry, just like all those other regulated spaces.

There’s a new term being used I find delightful. CompOps. Think DevOps, but with compliance—basically Compliance Operations. If you wanted to get silly we could make up something like DevCompSecOps. We like to put words in front of Ops to claim it’s a new way of doing something. In this particular instance, CompOps, there might actually be a new way of doing things. Having to conform to compliance standards is something the world of IT hasn’t really had to do at scale before. There’s no way we can comply with these standards without making some changes, so the term CompOps helps show that something is different.

When we think of how compliance in IT used to work, the first thing that comes to mind would be the annual audit. Once a year an auditor would come around and ask for a bunch of evidence. Everyone would make sure all the patches were installed, and user accounts cleaned up. Make sure the logging server was working and all that awareness training was finished. The auditor would collect their evidence, and assuming everything checked out, you were off the hook for another year!

Compliance isn’t a once a year effort anymore. Many of the new standards are demanding certain evidence be collected regularly and saved for a period of time. For example the CRA demands SBOM be generated for every software release and stored for 10 years. PCI-DSS 4 requires vulnerability scans to be run at least every three months! 

And it’s not just about scanning, it also has to be shown that findings were resolved. This new way of adhering to a compliance standard on a constant basis will need a new process. The ideas behind CompOps is a new process. Rather than keeping your compliance staff hidden away in a dark basement until the once a year you need them, they are going to be present for everything now. We will all need guidance to ensure things are done right at the start, but also things are kept right all the time.

So how do we do this CompOps thing?

Let’s start with the difficult reality that your security budget is likely already fueled by compliance requirements. Security teams have always struggled to show business value, this has been a problem since the beginning of security. How do you prove you’re the reason something didn’t happen? When security teams do their jobs, the result is nothing. “Nothing” can’t be measured. It’s pretty easy to measure when things go wrong, but very hard to measure when things go right. 

However, we can measure compliance requirements. If we can’t do business in a certain jurisdiction, or can’t take credit cards, or can’t process customer data, that’s easy to explain. If we meet these requirements, the rest of the business can do their thing. If we don’t meet those requirements everything grinds to a halt. That’s an easy story to tell. So make sure you tell it.

Security teams love to be in charge. There’s nothing more exciting than showing up and declaring everything is going to be fine because security is here! If you do this when trying to build out a compliance program you just lost before you started. It’s likely your existing development and operations teams are doing a subset of the things you’re going to need in this new compliance focused world. The only real difference might be you have to continuously collect evidence now.

Speaking of continuously collecting evidence. When you have a process you do once a year, you can sort of just wing it and deal with whatever bumps in the road show up along the way. Once a year isn’t all that often so it’s easy to justify manual effort. When you have to do something every month, or every week, or every day, the rules all change. Now we go from justifying a few extra hours of manual effort to an unacceptable amount of effort needed every single day. 

The world of CompOps means we have to architect how we are going to meet our compliance requirements. It’s a lot like building software, or deploying infrastructure, except in this case it’s meeting your compliance requirements. The DevOps crowd has a lot they can teach here. DevOps is all about making systems resilient and repeatable. The exact sort of thing we’re going to need!

It’s probably better to think of all this like a product manager more than a security or compliance team. Your DevOps folks know how to architect solutions based on a set of requirements. If we think of a compliance standard as a set of detailed requirements, we can translate those requirements into something the DevOps team already knows how to handle. This whole CompOps world is going to be all about communication and cooperation.

The road ahead

For many of us, all these new compliance standards are a welcome change, but it’s also a future filled with hard work and difficult problems. Change is always hard, and this will be no exception. While many of us are familiar with meeting compliance standards, the future of compliance won’t look like the past. It’s time to implement compliance programs that are not only continuous, but are part of our development and operations processes. For an experienced DevOps team these will all be very solvable problems, assuming we communicate clearly and work with them as a trusted partner.

In a few years we won’t be talking about CompOps anymore because it will just be part of the existing DevOps process. Our job for the next year or two will be figuring out how to normalize all these new requirements. If we don’t listen to our DevOps experts, none of this is going to be smooth and painless. They can teach us a lot, make sure you listen to them. Because if we do our job right, nothing will happen.

When I woke up the morning of September 8, I didn’t have the foggiest idea what the day had prepared for me. The most terrifying part of being a security person is the first few minutes of your day when you check the dashboards.

By mid-morning the now infamous blog post from Aikido Security about compromised NPM packages had found its way into Anchore’s Slack. My immediate response? Immediate panic, followed by relief when the scan of Anchore systems came back with the answer that we weren’t impacted.

We wanted to write this blog post to give the broader community a peek behind the curtains at what a zero-day vulnerability disclosure looks like from the perspective of the vendors who help customers protect their users from supply chain attacks. Spoiler: we’re just normal people making reasonable decisions while under pressure. 

Let’s walk through what actually happened behind the scenes at Anchore.

The first ten minutes: actions > root cause

When I first read the Aikido post, I didn’t care about the technical details of how the attack happened or the fascinating social engineering tactics. I wanted one thing: the list of affected packages. Something actionable.

The list was originally buried at the bottom of their blog post, which meant those first few minutes involved a lot of scrolling and muttering. But once we had it, everything clicked into place. This is lesson number one when a zero-day disclosure hits: get to the actionable information as fast as possible. Skip the drama, find the indicators, and start checking.

Step one: are we affected?

At Anchore, we dogfood our own products constantly (the Anchore Enterprise instance is literally named “dogfood”). On any given day, it’s somewhere between number two and three on my daily TODO list. On this day, I pulled up the latest build of Anchore Enterprise, and got to work.

First check: our latest releases. Our latest release was from the Friday before this all happened, so the timing meant the malicious packages couldn’t have made it into our most recent release. That’s good news, but it’s just the start.

Next check: the development versions of Anchore Enterprise. We pulled up our SBOMs and started looking. No malicious packages as direct dependencies—that’s a relief. But we did have some of the targeted packages as transitive dependencies! Luckily the packages we had inherited were not the malicious versions. Our dependency management had kept us safe, but we needed to verify this everywhere.

Then we checked with the UI team. Did anyone have these packages installed in their development environments? Did anything make it into CI? Nope, everything checked out.

GitHub Actions workflows were next. Sometimes we have opportunistic dependencies that get pulled during builds. Some of the packages were there, but not the vulnerable versions.

This whole process took maybe twenty minutes. Twenty minutes to check our current state across multiple products and teams. That’s only possible because we generate and store SBOMs for every build and create the tools to search through the growing inventory efficiently. We have stored SBOMs for every nightly and release of Anchore Enterprise. I can search them all very quickly.

Step two: the historical question

Now that we have confirmed that our infrastructure isn’t breached, the next question to answer is “has Anchore ever had any of these malicious packages?” Not just today, but at any point in our history. Granted the history was really just a few days in this instance, but you can imagine a situation like Log4Shell where there were years of history to wade through.

We have 1,571 containers in our build history. If we had to manually check each one, we’d still be working on it. But because we maintain a historical inventory of SBOMs in our database for all of our container builds, this became a simple query. A few seconds later: nothing found across our entire history.

These are the kinds of questions that keep me up at night during incidents: “Are we affected now?” is important, but “were we ever affected?” can be just as critical. Imagine discovering three months later that you shipped a compromised package to customers. The blast radius of that is enormous.

Having historical tracking isn’t fancy or sexy. It’s just good operational hygiene. And in moments like this, it means the difference between answering “I don’t know” and “we’re good.”

Step three: can we protect our customers?

Okay, so Anchore is clean. Great. But we sell the security tools that automate this kind of incident response—our customers are depending on us to help them figure out if they’re affected and detect these malicious packages.

Early in the incident, the GitHub Advisory Database made an understandable but problematic decision: they set the affected versions of these packages to 0, which meant all versions would be flagged as vulnerable. This potentially created mass confusion for users who rely on the GHSA DB for vulnerability results. If anyone ran a vulnerability scan with this version of the GHSA DB their scanners would have lit up like Christmas trees, flagging packages that were known to be good.

In order to protect our customers from this panic inducing possibility we made the call: stop our vulnerability database build. We’d never tried to kill a build mid-process before, but this was one of those “figure it out as we go” moments. We stopped the build, then went to make pull requests to the GitHub Advisory Database to fix the version ranges.

By the time we got there, the GitHub team had already found the issue and a fix was in-flight. This is how the open source community works when everything is going right—multiple teams identifying the same problem and coordinating to fix it.

As soon as GitHub pushed their fix, we rebuilt our vulnerability database and messaged our customers. The goal was simple: make sure our customers had accurate information and could trust their scans. From detection to customer notification happened in hours, not days.

Why is GitHub in this story?

I want to make an important point about why the GitHub Vulnerability Database is an important part of this story. At Anchore, we have an open source vulnerability scanner called Grype. In order for Grype to work, we need vulnerability data that’s available to the public. Most vulnerability data companies don’t let you publish their data to the public, for free, for some reason.

GitHub is an important source of vulnerability data for both Anchore Enterprise and Grype. We have a number of vulnerability data sources and we do quite a lot of work on our own to polish up data without a robust source. Rather than pull in GitHub’s data and treat it like our own, we take the open source approach of working with our upstream. Anytime there are corrections needed in any of our upstream data, we go to the source with the fixes. This helps the entire community with accuracy of data. Open source only works when you get involved. So we are involved.

What actually matters during a zero-day

Looking back at this incident, a few lessons stand out about what actually matters when something like this hits:

Get to actionable information fast. The technical details are interesting for a blog post later, but when you’re responding, you need indicators. Package names. Version numbers. Hashes. Don’t get distracted by the story until you’ve handled the response.

Check yourself first, but don’t stop there. We needed to know if Anchore was affected, but we couldn’t stop at “we’re fine.” Our customers depend on us to help them figure out their exposure.

Historical tracking matters. Being able to answer “were we ever affected?” is just as important as “are we affected now?” If you don’t have historical SBOMs, you can’t answer that question with confidence.

Speed matters, but accuracy matters more. When the GitHub Advisory Database incorrectly flagged all versions, it could have created chaos. We could have pushed that bad data to customers quickly, but we stopped, verified, and waited for the fix. A fast response is important, but an accurate response is what actually helps.

Automation is your friend. Twenty minutes to check 1,571 historical containers? That only happens with automation. Manual verification would have taken days or weeks.

The NPM community’s response was impressive

Here’s something that deserves more attention: NPM pulled the malicious packages in approximately six hours. Six hours from compromise to resolution. We only have to think back to 2021 when Log4j was disclosed and the industry was still responding to the incident weeks and even months later.

This wasn’t one company with a massive security team solving the problem. This was the open source community working together. Information was shared. Multiple organizations contributed. The response was faster than any single company could have managed, no matter how large their security team.

The attackers successfully phished more than one maintainer and bypassed 2FA (clearly not phishing-resistant 2FA, but that’s a conversation for another post). This was a sophisticated attack. And the community still went from compromised to clean in six hours.

That’s remarkable, and it’s only possible because the supply chain security ecosystem has matured significantly over the last few years.

How this compares to Log4Shell

This whole process reminded me of our response to Log4Shell in December 2021. We followed essentially the same playbook: check if we’re affected, verify our detection works, inform customers, help them respond.

During Log4Shell, we discovered Anchore had some instances of Log4j, but they weren’t exploitable. We created a test Java jar container (we called it “jarjar“) to verify our scanning could detect it. We helped customers scan their historical SBOMs to determine if and when Log4j appeared in their infrastructure, this provided their threat response teams with the information to bound their investigation and clearly define their risk.

But here’s the critical difference: Log4Shell response was measured in days and weeks. This NPM incident was measured in hours. The attack surface was arguably larger—these are extremely popular NPM packages with millions of weekly downloads. But the response time was dramatically faster.

That improvement represents years of investment in better tools, better processes, and better collaboration across the industry. It’s why Anchore has been building exactly these capabilities—historical SBOM tracking, rapid vulnerability detection, automated response workflows. Not for hypothetical scenarios, but for moments exactly like this.

What this means for you

This NPM incident is hopefully over for all of us (good luck if you’re still working on it). It’s probably worth thinking about what you can do for the next one. My advice would be to start keeping an inventory of your software if you’re not already. I’m partial to SBOMs of course. There will be more supply chain attacks in the future, they will need a quick response. The gap between “we checked everything in twenty minutes” and “we’re still trying to figure out what we have” represents real business risk. That gap is also entirely preventable.

Supply chain attacks aren’t theoretical. They’re happening regularly, they’re getting more sophisticated, and they will keep happening. The only question is whether you’re prepared to respond fast.

The tools exist

At Anchore, we built Syft and Grype specifically for these scenarios. Syft generates SBOMs that give you a complete inventory of your software. Grype scans for vulnerabilities. These are free, open source tools that anyone can use.

For organizations that need historical SBOM tracking, policy enforcement, and compliance reporting, Anchore Enterprise provides those capabilities. This isn’t a sales pitch—these are the actual tools we used during this incident to verify our own exposure and help our customers.

None of this is magic. It’s just normal people making normal decisions about how to prepare for predictable problems. Supply chain attacks are predictable. The question is whether you’ll be ready when the next one hits.

What’s next

Here’s what I expect: more supply chain attacks, more sophisticated techniques, and continued pressure on open source maintainers. But I also expect continued improvement in response times as the ecosystem matures.

Six hours from compromise to resolution is impressive, but I bet we can do better. As more organizations adopt SBOMs, vulnerability scanning, and historical tracking, the collective response will get even faster.

The question for your organization is simple: when the next incident happens—and it will—will you spend twenty minutes verifying you’re clean, or will you spend weeks trying to figure out what you have?

The best time to prepare for a supply chain attack was 10 years ago. The second best time is now.If you want to talk about how to actually implement this stuff—not in theory, but in practice—reach out to our team. Or join the conversation on our community Discourse where we talk about exactly these kinds of incidents and how to prepare for them.

October is Cybersecurity Awareness Month, an idea that’s more than 20 years old now. It’s an idea that had its day, it’s time to re-think the intended purpose. Cybersecurity is ever present now; Cybersecurity Awareness Month shouldn’t exist anymore. The modern purpose of Cybersecurity Awareness Month seems to be mostly for security people to make fun of Cybersecurity Awareness Month.

Let’s start with some history

Cybersecurity awareness month started in 2004. Back in 2004 things were VERY different. 2004 saw a bit more than 2,000 CVE IDs (we’re going to see more than 45,000 by the time 2025 ends). Windows XP SP2 was released in 2004. Many of the news stories I dug up were wondering how close we were to ending spam—how quaint. That’s not a world any of us can recognize anymore. Back in 2004 we would have contests to see who could keep a computer running the longest without rebooting (or applying security updates … or any updates). I could go on, but you get the point. It may have been 20 calendar years, but in tech that feels like 200 years. If any of us traveled back to 2004 we wouldn’t know how anything works, and if someone from 2004 showed up today, they wouldn’t be able to make anything work either.

Cybersecurity awareness month probably made sense back in 2004. It was a brand new problem. This whole internet thing was catching on. We were suddenly using computers to mail DVDs to our homes, check our account balances (instead of an ATM) and to frustrate our family doctors after consulting WebMD. 

It’s no surprise that as humanity began its online journey there would be a whole new group of criminals looking for opportunity. Nobody understood that using the same password everywhere was a bad idea, or that you should install those security updates quickly, or that the email you got about winning the lottery wasn’t real. Having a month where everyone was trying to draw attention to what’s happening probably made sense. It’s hard to spread new ideas, using a gimmick is a great way to get attention.

If we fast forward to 2025, a dedicated month for cybersecurity awareness doesn’t make sense anymore. It would also be a mistake to say “every month is cybersecurity awareness month”. Security awareness also isn’t everyone’s problem. Awareness is part of every security team, it has to be. Things change faster than anyone can possibly keep up with.

Keeping people informed about security is something that happens all the time as needs arise. We can probably use compliance as a good example here. Remember when we only worried about compliance once a year when the auditor was coming to town? That’s not how it works anymore, many of the compliance standards have requirements to collect evidence all year long, not once the night before it’s due. If there’s a new SMS spam attack happening against your company, you’re not going to take a note to cover it next October, you’re going to reach out to everyone right now!

Cybersecurity awareness isn’t a point in time or a single event. It’s honestly not really even about only awareness. It’s all about building trust with whoever the people are you are there to help out. It has to be woven into constant communications about whatever matters right now. You can’t build trust once a year, trust happens through consistent communication and also positive behavior. It’s critical that the people security teams are meant to be protecting aren’t afraid to ask questions or report suspicious activities. Even if those suspicious activities were caused by something they did.

Security teams used to be all about blame. Who is to blame? Anything bad that happened was the fault of someone. We also complained constantly about how little all the other teams cared about security, or how they didn’t seem to like us very much. There are still plenty of security teams that try to assign blame, but it’s not the default anymore, at least not the good teams. Good security teams are now all about being a trusted partner. You aren’t automatically a trusted partner, you have to earn it every day. We don’t need a special month, if anything a special month might detract from a program that’s trying to build trust.

When October rolls around the only thing that you should change is maybe some extra memes making fun of awareness month.

If you’re a security team, planning security focused communications can and should happen all year long. Make sure you understand who you’re working with and why. If you’re not sure your partners trust you, they probably don’t.

October is also National Pizza Month, you can start building trust by buying everyone some pizza. Security will probably never be as loved as pizza, but we can at least try!

Explore SBOM use-cases for almost any department of the enterprise and learn how to unlock enterprise value to make the most of your software supply chain.

Download Now

If you pay attention to the world of AI, you’ll have noticed that Model Context Protocol (MCP) is a very popular topic right now. The Model Context Protocol is an open standard that enables developers to build secure, two-way connections between their data sources and AI-powered tools. The architecture is straightforward: developers can either expose their data through MCP servers or build AI applications (MCP clients) that connect to these servers.

Because MCP is so popular it seemed like a great topic to do some security research with. I decided to review the top 161 MCP servers currently listed on the Docker hub, generate SBOMs for each container then run a vulnerability scan to see what the current state of that software is.

The list of the MCP server I used can be found on Docker Hub at  https://hub.docker.com/mcp. The tools I am using are explained further down. 

Explore SBOM use-cases for almost any department of the enterprise and learn how to unlock enterprise value to make the most of your software supply chain.

Download Now

Step by step vulnerability analysis of 161 MCP servers 

As a first step I pulled all the container images then I used our OSS Syft scanner to generate SBOMs for each image. When Syft scans a container it catalogs all the packages and files contained in a container image. Those SBOMs were then scanned with our OSS vulnerability scanner Grype . All scan results, SBOMs and vulnerabilities were put into Elasticsearch. I enjoy using Elasticsearch as it makes it very easy to make graphs of the data and understand what’s happening.

Keep in mind, these results are the output of Syft and Grype; if there is a bug in one of them, or they cannot detect a certain package type, that will cause a hole in the data. These results shouldn’t be treated as 100% accurate, but we can derive observations, trends, and patterns based on this data set.

How bad is it? TL;DR: It’s pretty bad.

In 161 containers, Grype found exactly 9000 vulnerabilities. The number is certainly larger now. Vulnerabilities are a point in time snapshot, it was 9000 when the scan was run in early September 2025. As time moves forward, more vulnerabilities will be uncovered. CVE is adding around 4000 new vulnerabilities per month, some of which will affect a subset of the software in these MCP containers.

Let’s start with the top 10 containers by vulnerability count.

We should dig deeper into the top image as there’s more happening than the raw numbers would suggest. What if we look at the number of vulnerabilities based on the type of package for that image?

This image is based on Debian 12 specifically, which isn’t particularly old. If we take a closer look, we see 429 Debian packages installed, 51 python modules, and 13 unpackaged binaries. 429 packages is quite a lot. The default Debian base container image contains 78 packages, 429 is a lot of new packages being added!

Before publishing, I did contact Clickhouse and they have updated their container image, it’s in way better shape now. I applaud their quick updates!

What’s the make up of a MCP container?

Rather than dwell on this one container, let’s zoom out and look at all the data first. That will allow us to better explain what’s happening with Debian and why we see these results.

Let’s look at the list of all Linux distributions in use in these MCP containers:

The observant will now say that only adds up to 160! The mcp/docker image has no distro. There are also no RPM based container images in the top MCP servers (this might only be interesting to me as I spent many years at RedHat).

Each image has various packages installed, in this instance from the Linux distributions deb and apk. It also includes packages used by the various languages in use such as Python and NPM. What does the number of packages spread across all the images look like?

Anybody watching the world of package ecosystems would probably expect this distribution above; NPM is a widely used language with a lot of packages. Debian is used by many images and doesn’t focus on minimal packages like Alpine, and Go and Python are commonly used languages.

Analysis of vulnerabilities in a debian image

Now if we shift our focus back to vulnerabilities, what does the distribution of vulnerabilities by package look like?

As seen above, the Debian packages account for the vast majority of vulnerabilities in these container images.

On a side note: I want to take a moment to explain something important about the Debian results. We should not be using this data to make a claim Debian is insecure. Debian is a very well maintained distribution with a great security team. They have a huge number of packages they have to keep track of. Debian puts a ton of effort into fixing the security vulnerabilities that truly matter. When a small team of volunteers have limited time, we of course want them working on things that matter, not wasting time on low severity vulnerability noise.

If we look at the distribution of vulnerabilities affecting the Debian packages we are getting a clearer picture: 

The vast majority  are “Negligible” Debian vulnerabilities. These are vulnerabilities the Debian security team after careful analysis has decided are lower than low and will be de-prioritized compared to other vulnerabilities.

I scanned the latest Debian container and these are the results: 0 critical, 0 high, 1 medium, 5 low, 40 negligible. That’s very impressive, and it’s also a great reason to keep your software up to date.  Also keep in mind that many of these MCP Debian images haven’t been updated in a long time. It’s hardly Debian’s fault when the author of a container builds it then never updates the Debian packages.

But how bad is it overall?

On the topic of vulnerability severities, what does that graph look like across all packages in all the containers?

This graph looks a bit like that Debian distribution, but here we are seeing  263 critical vulnerabilities. That’s 263 critical vulnerabilities in 161 container images which seems like a lot. If we break this down into the packages affected by critical vulnerabilities this is what we get.

While we know there are a lot of outdated Debian packages, it’s clear most of the other ecosystems have problems as well. We haven’t done enough research to say if these critical findings could be exploited, but even if not, it’s bad optics. It’s common for an organization to have a policy of no critical vulnerabilities in any software they deploy, it doesn’t matter if it’s exploitable or not.

Deep dive into 36,000 NPM packages

If we recall the table of all package types at the beginning of this post, there were more than 36,000 NPM packages installed in these 161 container images. Since NPM is significantly more than all the other ecosystems combined, we should investigate a bit further. What are the most installed NPM packages?

It is impressive that minipass has almost 700 installs in 161 containers, unless you are an NPM developer, then these packages won’t surprise you. They are widely used across NPM both for MCP and non-MCP software.

As a note to myself, a future research project should be looking for NPM packages that have been removed for having malware, or could be typosquatted or slopsquatted.

When working with these types of data sets, I am always interested to look at the size of files in the images. 

If we look at the graph, there are a huge number of small files but also always outliers that are much larger than one would expect. One datapoint even nears 600 Megabytes. That’s a pretty big file, and my initial thought was that it could be some sort of LLM model or training content. In the clickhouse container there is a shared library in a python package that’s nearly 600 Megabytes in size. It’s a binary library in a file named _chdb.cpython-313-x86_64-linux-gnu.so. chdb is an in-memory database with data needed by the MCP server, so yeah, it’s AI content.

The other outliers around 100 MB are clickhouse and vizro containers with the pyarrow library, about 66 MB. And the aws-terraform container with a 120MB package called playwright.

It’s likely these large files aren’t mistakes but are indeed used by the container images. There’s nothing wrong with large containers. But it’s always interesting to look for outlier data to ensure mistakes haven’t been made somewhere along the way. We want to make sure we don’t accidentally include some sensitive files, or extra packages, or even debug data that nobody needs.

Conclusion…if you want to call them that 

This post has a lot of data for us to think about, it’s probably overwhelming at a first glance. I don’t suggest that this should be treated as some sort of deep security analysis of MCP, it’s meant to be a brief overview of some interesting findings while digging into data. My goal is to start conversations and hopefully see more deeper research into these MCP images. If you think I did something wrong, or want to ask different questions, nothing would make me happier to be proven wrong, or inspire further research.

For now, these are the conclusions I have drawn. All of these images would benefit from some common vulnerability handling best practices:

1. Keeping software updated is a great first step. Regular updates are hard, but also table stakes for anyone building software in the modern age. 
2. Minimizing attack surfaces should also be used when possible. There are small container images to build on top of. Make sure you prune out unused dependencies on a regular basis. Only use the dependencies and libraries that are needed. 
3. And most importantly is to keep an inventory of what you’re shipping, then using that inventory to make informed decisions.

Software doesn’t age like a fine wine, more like milk. It’s important we keep track of what we’re shipping. When you produce software, it’s never a “one and done” sort of situation. It needs constant care and feeding. Understand what our threat model and risk profiles are, and most importantly, keep things updated.

Learn about the role that SBOMs for the security of your organization in this white paper.

Download Now

Lately it seems like a new company building hardened container images is popping up every other day. What’s the deal with this, why the sudden influx of hardened images? 

A previous blog article titled “Navigating the New Compliance Frontier” discussed some of the new trends with compliance. But it’s not as simple as just claiming “because compliance”–that’s the easy answer that doesn’t tell us much. Compliance doesn’t say anything about using hardened container images. But here’s the thing: many compliance standards do have things to say about configuration management, attack surface, and vulnerabilities. We’re not being told to use hardened images, but hardened images solve many of these problems, so they are getting used. It’s one of those situations where the practical solution emerges not because someone mandated it, but because it actually works.

When you operate in a regulated space (as we all will be soon, thanks to the CRA) you have to justify configuration changes, software changes, and every vulnerability. The idea behind the hardened images is to have only the software you absolutely need and nothing else. That translates into you only having a list of the vulnerabilities that directly affect you.

There’s an additional reason that’s giving small hardened images extra attention. The ability to scan your software for vulnerabilities is better than it’s ever been. Historically trying to scan software for vulnerabilities wasn’t very reliable or even a good use of anyone’s time. Scanners of the past missed a lot of things. It was a lot harder to figure out what all the software installed on bare metal, VMs, or containers. And by harder we really mean it was nearly impossible. It was common to just fall back to spreadsheets with people doing this all manually.

Scanning for vulnerabilities was basically out of the question, nobody had a decent inventory of their software supply chain. The scanners also had incomplete data if they even had data at all. The false positive rate made the results useless and the false negative rate made those useless results dangerous. It was also common to scan a system and just get no results at all. Not because there are no vulnerabilities, but because the scanners couldn’t figure anything out.

That’s not true anymore. If you scan any modern Linux distribution you’re going to get results. Language ecosystems like Python, Java, and Go are well supported. A lot of scanners can even figure out what pre-built binaries are in a container image. Scanners have gotten pretty good at finding the software in a container.

This also means that if we have a reliable list of software, we can also scan that list for vulnerabilities. Something you’ll notice quickly is a hardened minimal image has fewer findings than a more traditional container image. This doesn’t mean a minimal container image is better than a more traditional one. They solve different problems.Here’s an example, let’s look at an Alpine image and a Debian image. We can scan the container image with the Syft SBOM scanner.

➜  ~ syft alpine:latest
 ✔ Parsed image
   sha256:9234e8fb04c47cfe0f49931e4ac7eb76fa904e33b7f8576aec0501c085f02516 
 ✔ Cataloged contents
   eafc1edb577d2e9b458664a15f23ea1c370214193226069eb22921169fc7e43f 
   ├── ✔ Packages                        [16 packages]  
   ├── ✔ File metadata                   [81 locations]  
   ├── ✔ Executables                     [17 executables]  
   └── ✔ File digests                    [81 files] 

➜  ~ syft alpine:latest
 ✔ Parsed image
   sha256:9234e8fb04c47cfe0f49931e4ac7eb76fa904e33b7f8576aec0501c085f02516 
 ✔ Cataloged contents
   eafc1edb577d2e9b458664a15f23ea1c370214193226069eb22921169fc7e43f 
   ├── ✔ Packages                        [16 packages]  
   ├── ✔ File metadata                   [81 locations]  
   ├── ✔ Executables                     [17 executables]  
   └── ✔ File digests                    [81 files] 

➜  ~ syft debian:latest
 ✔ Parsed image
   sha256:999ffdddc1528999603ade1613e0d336874d34448a74db8f981c6fae4db91ad7 
 ✔ Cataloged contents
   56b68c54f22562e5931513fabfc38a23670faf16bbe82f2641d8a2c836ea30fc 
   ├── ✔ Packages                        [78 packages]  
   ├── ✔ Executables                     [655 executables]  
   ├── ✔ File metadata                   [4,148 locations]  
   └── ✔ File digests                    [4,148 files] 

➜  ~ syft debian:latest
 ✔ Parsed image
   sha256:999ffdddc1528999603ade1613e0d336874d34448a74db8f981c6fae4db91ad7 
 ✔ Cataloged contents
   56b68c54f22562e5931513fabfc38a23670faf16bbe82f2641d8a2c836ea30fc 
   ├── ✔ Packages                        [78 packages]  
   ├── ✔ Executables                     [655 executables]  
   ├── ✔ File metadata                   [4,148 locations]  
   └── ✔ File digests                    [4,148 files] 

The Alpine image has 16 packages in it. The Debian image has 78. That’s a pretty big difference. It’s pretty clear that an Alpine image would fall under the umbrella of a minimal hardened image while Debian does not.If we scan these for vulnerabilities the results are similar. The Grype vulnerability scanner does a great job when scanning both Alpine and Debian container images.

➜  ~ grype alpine:latest
 ✔ Vulnerability DB                [updated]  
 ✔ Parsed image
   sha256:9234e8fb04c47cfe0f49931e4ac7eb76fa904e33b7f8576aec0501c085f02516 
 ✔ Cataloged contents
   eafc1edb577d2e9b458664a15f23ea1c370214193226069eb22921169fc7e43f 
   ├── ✔ Packages                        [16 packages]  
   ├── ✔ Executables                     [17 executables]  
   ├── ✔ File metadata                   [81 locations]  
   └── ✔ File digests                    [81 files]  
 ✔ Scanned for vulnerabilities     [6 vulnerability matches]  
   ├── by severity: 0 critical, 0 high, 0 medium, 6 low, 0 negligible

➜  ~ grype alpine:latest
 ✔ Vulnerability DB                [updated]  
 ✔ Parsed image
   sha256:9234e8fb04c47cfe0f49931e4ac7eb76fa904e33b7f8576aec0501c085f02516 
 ✔ Cataloged contents
   eafc1edb577d2e9b458664a15f23ea1c370214193226069eb22921169fc7e43f 
   ├── ✔ Packages                        [16 packages]  
   ├── ✔ Executables                     [17 executables]  
   ├── ✔ File metadata                   [81 locations]  
   └── ✔ File digests                    [81 files]  
 ✔ Scanned for vulnerabilities     [6 vulnerability matches]  
   ├── by severity: 0 critical, 0 high, 0 medium, 6 low, 0 negligible

➜  ~ grype debian:latest
 ✔ Parsed image
   sha256:999ffdddc1528999603ade1613e0d336874d34448a74db8f981c6fae4db91ad7 
 ✔ Cataloged contents
   56b68c54f22562e5931513fabfc38a23670faf16bbe82f2641d8a2c836ea30fc 
   ├── ✔ Packages                        [78 packages]  
   ├── ✔ Executables                     [655 executables]  
   ├── ✔ File metadata                   [4,148 locations]  
   └── ✔ File digests                    [4,148 files]  
 ✔ Scanned for vulnerabilities     [46 vulnerability matches]  
   ├── by severity: 0 critical, 0 high, 1 medium, 5 low, 40 negligible

➜  ~ grype debian:latest
 ✔ Parsed image
   sha256:999ffdddc1528999603ade1613e0d336874d34448a74db8f981c6fae4db91ad7 
 ✔ Cataloged contents
   56b68c54f22562e5931513fabfc38a23670faf16bbe82f2641d8a2c836ea30fc 
   ├── ✔ Packages                        [78 packages]  
   ├── ✔ Executables                     [655 executables]  
   ├── ✔ File metadata                   [4,148 locations]  
   └── ✔ File digests                    [4,148 files]  
 ✔ Scanned for vulnerabilities     [46 vulnerability matches]  
   ├── by severity: 0 critical, 0 high, 1 medium, 5 low, 40 negligible

We see 0 vulnerabilities in the Alpine image and 46 vulnerabilities in the Debian image. Now this doesn’t make Debian worse, they have limited time and fix the most dangerous vulnerabilities first. It’s 1 medium, 5 low, and 40 negligible. It’s pretty clear the Debian security folks are staying on top of all this.

Keep in mind that Debian has a lot more software than you get in an Alpine image. There are many problems that are easier to solve with Debian than Alpine because it has more software available. There are also problems that are easier to solve with Alpine because it has less software.

In the case of hardened container images, if our primary problem is justifying security findings, you’re going to have less work to do if you have fewer vulnerabilities. Less software means fewer vulnerabilities. This seems like a pretty easy logical conclusion. Even when a security vulnerability is marked as “negligible” as we see in the above Debian report, security and compliance auditors will want a justification. Those justifications come with a cost. We can remove that cost by just not having those vulnerabilities present. One way to get fewer vulnerabilities is to ship less software. This is that case where Alpine solves a problem Debian doesn’t.

Of course we could try to build our own tiny variant of Debian. Is that a problem we want to solve? The care and feeding of container base images has been solved by many other companies and open source projects. If you need a giant image full of stuff, or a small image that only contains what you need. This is one of those classic situations where you can use an existing solution to solve a problem. You don’t generate your own electricity, you pay a utility. Why are you trying to manage the operating system in your container images?

As we see more compliance standards becoming the reality for software producers. We are going to see more hardened container images emerge, these things are here to stay. They solve real problems. The thing to keep an eye on in the future is what other common problems that mandatory compliance creates?

Hardened container images aren’t the end goal of meeting your compliance requirements, they are the first step in a long journey. There are many stages to release software and services. We’re going to see increasing attention to how we build our software, what the dependencies are, what the vulnerabilities in those dependencies are. There won’t be a single simple answer for any of these new requirements. However, now that we have some requirements we can start to figure out the best way to solve these new problems.

This is exactly why Anchore recently announced a strategic partnership with Chainguard, one of the leading companies in the hardened container space. The partnership recognizes something important: starting with secure, hardened container images is just the beginning. You also need continuous scanning, policy enforcement, and compliance monitoring as you build your own code on top of those secure foundations. It’s a “Start Safe, Stay Secure and Compliant” approach that acknowledges hardened images solve the base layer problem, but you still need to manage everything else in your software supply chain.

At Anchore we don’t think we can solve every problem, but we do think the combination of starting with hardened images and applying continuous security practices like SBOMs and policy evaluations throughout your development lifecycle is the most practical way forward in this new compliance world.

Learn how Chainguard’s hardened images and Anchore Enterprise’s SBOM-powered, vulnerability scanning and policy enforcement reduce audit effort and accelerate entry into new markets.

Watch Now

On September 8, 2025 Anchore was made aware of an incident involving a number of popular NPM packages to insert malware. The technical details of the attack can be found in the Aikido blog post: npm debug and chalk packages compromised

After an internal audit, Anchore determined no Anchore products, projects, or development environments ever downloaded or used the malicious versions of these packages.

Anchore Enterprise and Grype both use the GitHub Advisory Database to source the vulnerability data for NPM packages. Since this database also includes malware packages such as this, both Anchore Enterprise and Grype will detect these malware packages if they are present.

The databases used by Anchore Enterprise and Grype will auto update on a regular basis. However, given the severity of this malware, users of Anchore Enterprise and Grype can update their feed database manually to ensure they are able to detect the malicious packages from this incident.

Grype users should run:

$ grype db update

$ grype db update

Which will download the updated vulnerability database.

Anchore Enterprise users can run:

$ anchorectl feed sync

$ anchorectl feed sync

Which will download the latest version of the vulnerability database.

Once the databases are updated, both Grype and Anchore Enterprise identify the malware in question. You can verify the vulnerability ID is found in your vulnerability dataset with the following API call:

$ curl -u ${ANCHORE_USER}:${ANCHORE_PASS} -H 'x-anchore-account: {account_context} -X 'GET' "$ANCHORE_URL/v2/query/vulnerabilities?id=GHSA-5g7q-qh7p-jjvm&page=1" -k

$ curl -u ${ANCHORE_USER}:${ANCHORE_PASS} -H 'x-anchore-account: {account_context} -X 'GET' "$ANCHORE_URL/v2/query/vulnerabilities?id=GHSA-5g7q-qh7p-jjvm&page=1" -k

And then you can locate affected artifacts by using reports:

Timeline

[1830UTC] Anchore Enterprise and Grype start rebuilding the vulnerability databases to properly detect these malicious packages

[1930UTC] Anchore Enterprise vulnerability database is published

[2015UTC] Grype vulnerability database is published

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.

Download Now

For the last 7 years CISA has been one of the major public stewards of SBOMs – publishing many whitepapers, hosting a multitude of meetings, and evangelizing the term so nearly everyone in the industry now recognizes. For those of us who have been working in the SBOM community over the years, one of the best meetings was a Monday morning SBOM community call (morning if you’re in the US, not morning most everywhere else on the planet). The agenda usually started with an informal discussion about news and events and moved to a semi formal presentation about a tool or idea that was being worked on. Occasionally the discussions lasted the entire hour and the topics were always informative and interesting.  

As the world of SBOMs has grown, one of the biggest challenges is just keeping track of everything; There are too many events, tools and talks and it is impossible for one person to be on top of it all. And that’s why the Monday community meeting was so useful to its attendees. Even if you weren’t trying to actively keep track of the SBOM universe, the SBOM universe would come to you! 

Unfortunately the Monday community meeting has recently been discontinued. It’s tough to keep a meeting like this going, especially for many years, so hats off to CISA for all the hard work! That meeting shall be missed, but we can all respect the need to focus the existing resources to better align with the CISA mission.

But given how valuable the CISA meeting has been, a few of us at the OpenSSF have decided we miss the meeting and would like to keep it going. So the OpenSSF SBOM Coffee Club has been started! Same time on Monday as the CISA meeting (11am Eastern). The format is going to be exactly the same: Show up, discuss the latest news and happenings and share interesting SBOM related events. Just like the CISA list of SBOM events, this one will be pretty flexible and only need to be vaguely SBOM related to deserve a mention.

One of the often overlooked aspects of building a community are the little things that bring everyone together. I’ve been part of many communities over the years, I am honored to be part of the SBOM community now. While our community is built on top of SBOMs, that’s not enough to keep everyone connected. We need a place to discuss topics, share experiences, and talk about new things and ideas, and most importantly, let new people find us. That was the Monday SBOM call. It’s important to me and others to keep a place going that can help the existing community thrive and bring in new people in a safe and welcoming way.

Everyone is welcome, it doesn’t matter if you’re not an OpenSSF member. The invite is available on the OpenSSF public calendar (it’s pretty full of events, look for “OpenSSF SBOM Coffee Club” on Monday. You are welcome to check out the notes document. This will be updated before and during the meeting each week. Even if you don’t attend you are welcome to keep track of what’s happening from the meeting notes. We’ve quite literally copied the events list from the last CISA call and we are going to keep it updated.

I hope to see you at a future meeting to learn, to share and evangelize. I promise you will learn something. And if you have an idea to present, or a tool, or anything really, reach out to the group. See you next Monday!