Blog
Insights on securing open source from the team that builds it.
Featured posts
.png)
Achieving SLSA Level 3: Why a Curated Catalog Helps Enterprise Teams Operationalize Trust
Key takeaways
- SLSA Level 3 components help organizations prove software integrity by providing software provenance and building trust.
- Traditional tools like SBOMs and vulnerability scanners can’t verify how open source components were built or where they originated.
- A Curated catalog shifts software supply chain security upstream, establishing trust before dependencies enter development.
- The ActiveState Curated Catalog helps organizations operationalize SLSA Level 3 while reducing remediation effort, preserving developer productivity.
Every piece of software has a story. The question is whether you can trust where it came from. According to Stack Overflow’s 2025 Developer Survey, 47% of developers now use AI coding assistants daily, accelerating the rate at which open source dependencies enter modern applications.
Meanwhile, organizations are seeing more examples of why software provenance matters. For instance, the recent compromise of the widely used TanStack npm packages demonstrated how quickly trusted open source dependencies can become software supply chain risks.
While many organizations can implement Supply-chain Levels for Software Artifacts (SLSA) controls within their own build pipelines, achieving SLSA Level 3 across hundreds (or even thousands) of open source dependencies is a far, far greater challenge.
In this article, we explore why curated open source catalogs are becoming an increasingly important part of helping enterprise teams meet the SLSA standard while building a more trustworthy software supply chain.
Why does SLSA level 3 matter now more than ever?
Sixty percent of those working for the largest enterprises spend 50% or more of their time on maintenance and bug fixes instead of new feature development. While most organizations spend this sort of time securing the software they build, the reality is that internally developed code represents only a small fraction of the applications your teams ultimately ship.
The rest of the code comes from the open source ecosystem, and every third-party component your engineers introduce arrives with its own build process, maintainers, release cadence and dependency tree.
These components may power innovation and shorten your go-to-market lifecycle, sure. But they also extend your software supply chain far beyond your organization’s direct control, opening you up to unnecessary vulnerabilities.
This is precisely why SLSA Level 3 has become so important, and organizations increasingly need an intelligent way to verify the integrity of the software you inherit, proving where it came from, how it was built and whether it can be trusted before it becomes part of your own applications.
Here’s why traditional software supply chain controls fall short
You probably already rely on things like SBOMs to tell you what software you’re running and vulnerability scanners to tell you what’s wrong with them.
While this process remains important today, it wasn’t designed to answer a different (and increasingly important) question: Can this software be trusted in the first place?
Neither an SBOM or vulnerability scanner can prove how a component was built, whether it originated from a trusted source or whether its provenance remained intact throughout the build process. And that’s why software provenance has become such a critical part of modern software supply chain security.
Trust in your codebase can’t be reconstructed after a dependency enters production, and it’s up to you and your teams to establish that trust before software ever reaches your development environment.
How ActiveState helps organizations operationalize SLSA Level 3
The real challenge isn’t achieving SLSA Level 3 within your own development environment, but extending that same level of assurance to the open source software your applications rely on every day.
The ActiveState Curated Catalog was built to make that possible. It gives organizations like yours a practical way to govern open source dependencies before they enter the software supply chain.
Rather than pulling packages directly from public registries, developers can consume open source components that have already been built from source within a SLSA Level 3-compliant build environment. Every component is accompanied by signed attestations and a complete SBOM, providing the provenance needed to demonstrate to auditors how it was built and where it came from.
Here’s why that matters for your organization:
- You can establish trust before software enters a production environment. The ActiveState Curated Catalog verifies components before developers ever consume them. So, instead of investigating where a package came from only after one of your engineers has already plugged it into your application, your teams can begin with software that already meets a defined standard of trust.
- You can retain compliance and ensure the safety of your critical data. Meeting SLSA Level 3 is ultimately about demonstrating software integrity. Because every component in the ActiveState Curated Catalog is built from verified source code and includes signed provenance, much of that evidence already exists before an audit, customer review or regulatory assessment begins. No longer do your teams need to piece together documentation from multiple tools to prove provenance. Instead, your security leaders can demonstrate where software came from and that it meets the controls expected by modern software supply chain frameworks before ever introducing it into your software environment.
- Open source security becomes proactive instead of reactive. When trust is established at the point of intake and your audit trail becomes easier to defend, vulnerability management becomes much more proactive. That means fewer downstream surprises, less unplanned remediation work and more engineering capacity dedicated to innovation.
This is important, especially for your security leaders who can now govern what enters the software supply chain from the outset. Consequently, your teams gain greater confidence in the integrity of every component entering their environments, while simultaneously creating a defensible provenance chain that stands up to auditors and regulators alike.
Operationalize trust across your software supply chain
In today’s open source security landscape, AI coding assistants are accelerating open source velocity while software supply chain attacks are becoming increasingly sophisticated. The recent compromise of dozens of TanStack npm packages demonstrated that attackers are now targeting trusted release processes rather than just individual developers.
At the same time, companies like OpenAI, Anthropic and Meta have begun collaborating on standardized software supply chain security questionnaires, signaling that software provenance is becoming a core expectation for enterprise software vendors.
So, what is this signalling to everyone else? Well, organizations need stronger controls over the software entering their environments, and not just better tools for detecting problems later.
The ActiveState Curated Catalog makes that possible by shifting governance upstream. Security and engineering teams can define the guardrails once, while developers and AI coding assistants continue consuming packages through the package managers they already use.
The difference, however, is that instead of pulling directly from public registries, your teams can consume components that have already been built from verified source code in a SLSA Level 3-compliant build environment, complete with signed attestations, SBOMs and verifiable provenance.
To learn more about how your teams can establish trust before software ever enters your development pipeline, explore the ActiveState Curated Catalog.
Read the article
.png)
.png)
.png)
.png)
.png)
.webp)
.webp)
.webp)
.webp)

