Why ActiveState Uses Curated Catalogs to Reduce Open-Source Risk

The way modern software is built, teams do not pull code from a single place. Repositories, container registries, Git-based installs, operating system packages, and anything else that fits the context can all end up being used to build modern software. And although that gives teams a lot of flexibility, it also creates a problem around where software is being sourced from. 

The result of all this is fragmentation. A company may have security policies, but package sourcing can still vary across product teams, individual developers, or business units. What then happens is that it weakens consistency inside CI/CD pipelines. Risk reviews become slower, builds become harder to reproduce, and remediation becomes more expensive because the same type of problem can show up across different teams and have slightly different causes.

Twain Taylor, editor at Software Plaza, discussed that issue with ActiveState’s Johnny Rivera on the Software Plaza podcast. In order to reduce downstream surprises, organizations must stop treating open source intake as an open door. ActiveState’s answer is a curated catalog model that shifts security toward the source, where package decisions are made, instead of relying on downstream scanning to catch the fallout later. 

Dependency-level risk does not stop with the package a developer chose

Another place where open source governance needs to focus is the nested chain, because that is where a lot of risk sits. What happens is that a developer gets one package, which depends on another package, which might then bring in another package, and so on.

This nested chain may include older libraries. Several levels down, there might be unsupported components still sitting in the dependency graph long after teams stop using them or stop thinking about them. Even public packages can come from fragmented sources with uneven review and uneven maintenance practices, which is why dependency-level risk is such a stubborn problem. 

When teams choose packages from very different sources and do it in isolation, they might think they are only using a simple package without realizing that the decision might affect numerous ecosystems within a company.

Reactive scanning finds problems after the blast radius has grown

So what is the solution? It is not reactive scanning alone, even though reactive scanning does give organizations visibility into what software they are using and where known issues exist. The idea is that scanning tells a team when a risk has already entered the environment. And as noted earlier, even before the alert appears, the dependency may already be spread across the build system and linked to various parts of the application code. 

Which then means that the security team has to investigate, prioritize, and assign work, while hoping that remediation happens before there is a larger operational or security problem. Instead of moving toward a system where the problem does not arise in the first place, the security team ends up defending the cleanup. 

And that creates a loop where teams are only sorting through things that have already affected the system instead of building a pipeline where dependencies and packages are checked before they get through. 

So the point is not that scanning is wrong, but that scanning alone is not enough.

How ActiveState shifts security to the source

Instead of treating every package decision as something that has to be scanned and inspected after intake, ActiveState pushes governance to the source through curated and vetted component catalogs. 

This model narrows the entry points into the software supply chain. Instead of every team sourcing packages from anywhere on the internet, the organization guides teams toward a catalog of approved components. This shifts security closer to the point of intake and package selection, which then reduces the number of issues that are only discovered at the scanning stage. 

This model changes when the decision is made. The company is not saying that this removes the need for scanning, monitoring, or patching security issues. But it does create a system where security and platform teams get a way to define approved components earlier in the process. This lowers the odds that risky or unvetted dependencies spread before either a system or a person can notice.

Standardizing secure open-source consumption across teams

This problem compounds in large organizations and enterprises, where different teams have built up different habits over time. One team may have a well-disciplined way of handling versions and reviews, while another may optimize more for speed. 

That can make it difficult to maintain consistent security policies when actual software intake varies in practice. This is why a standardized consumption model allows teams to have a shared starting point. It takes some stress away from developers, who would otherwise have to interpret whether a particular open source package is trustworthy or not. Platform teams can have more repeatable workflows, and security teams spend less time chasing random intake patterns. That then allows them more time to improve the supply path itself.

Why does this upstream model change the economics of risk

Fixing dependency problems after they enter the pipeline is expensive. Teams must identify affected builds, trace usage, replace packages, rerun tests, and sometimes rebuild trust in the artifact chain itself. That is a lot of labor spent undoing a bad intake decision.

Preventing some of those decisions upfront is cheaper and cleaner.

That is why the ActiveState framing lands on source control in the broad sense of intake control, not only source code management. If organizations can be more deliberate about which open source components are allowed into development in the first place, they reduce the number of security and operational problems that need to be cleaned up later.

The strongest part of this conversation is that it moves the debate upstream. It does not ask how teams should respond once a vulnerable package has already spread. It asks why so many organizations still allow that package to get in unchecked. Readers who want the fuller discussion on curated catalogs, dependency-level risk, governance pressure, and AI-related exposure should check out the full webinar episode.