What Are the New Rules for Secure Open Source Consumption?
7 minute read time
Secure open source consumption requires more than an approved package registry or a scan before release. Teams need to control where components come from, evaluate them when they are selected, choose suitable versions, and keep track of them as new risks emerge.
Sonatype's research puts the average application at around 180 dependencies. At that scale, secure consumption needs consistent controls that support developers through each dependency decision.
The goal is to make a trustworthy dependency the easy choice for developers and AI-assisted workflows, while giving teams a practical way to respond when that choice needs to change.
Consider a developer adding a library to support a new feature. That single choice can introduce risks at different points:
-
At selection: The package manager may retrieve the library along with dozens of transitive dependencies.
-
At installation: A malicious package may have an opportunity to run before the application is built.
-
After adoption: A new vulnerability disclosure may leave the team needing to find every affected application and identify a workable update.
That is why rules for secure consumption must cover the full path from selection to remediation.
1. Establish Approved Sources
Approved sources define where developers, build systems, and AI coding assistants can obtain open source components. A public registry is a useful distribution channel, but its availability does not amount to an organization's approval of every package it hosts.
Teams should define approved upstream sources per ecosystem and establish a unified route to access them. Fetching packages through a managed repository versus directly from public registries creates inconsistent visibility and control over incoming code.
An approved path should extend to local development and CI/CD, where dependencies are often resolved automatically. This does not mean freezing developers into a short list of preapproved libraries. It means giving them a reliable route to the packages they need and a clear process when they need something outside the usual sources.
Source approval is only the starting point. A harmful package can be published to a legitimate registry, and a legitimate package can later be compromised. Teams still need to evaluate the component itself.
2. Evaluate Components Before Download
Components should be evaluated when they are requested, before they enter a developer environment or build. This matters particularly for malicious packages as some can execute code during installation, so discovering them after a build may be too late to avoid the initial exposure.
By the end of Q2 2026, Sonatype Research had logged more than 1.8 million malicious packages across ecosystems over the past decade. That scale reinforces the need to evaluate what teams consume, even when packages come through familiar registries and workflows.
Evaluation should distinguish among risks that call for different responses:
-
Malicious or suspicious packages may need to be blocked or quarantined before installation.
-
Known vulnerabilities may call for a safer version or an assessment of how the component will be used.
-
License conflicts may require an alternative component or a review under organizational policy.
These decisions should follow an organization's risk thresholds. When a request is stopped, developers need to know why and what they can do next, whether that means choosing another version, selecting a different component, or requesting an exception.
Scanning remains valuable throughout development, but evaluating components before download adds an earlier decision point for packages that may execute code as they are installed.
3. Choose Trusted Versions, Not Just Trusted Packages
A trusted package choice depends on the specific version a project will use. Versions differ in their vulnerabilities, behavior, maintenance status, dependencies, and compatibility with an application. The newest release is not automatically the best choice, and the version already used by another team may not fit this project.
A trusted version decision should account for:
-
If the version is published by the expected source and shows signs of malicious activity.
-
Known vulnerabilities and the application's exposure to them.
-
License requirements and organizational policy.
-
Compatibility with the application and its existing dependency tree.
-
The project’s maintenance history and a viable path for future updates.
These questions also apply to transitive dependencies. A developer may choose one direct dependency, but the build consumes the versions resolved beneath it. Lockfiles and consistent dependency resolution help teams preserve and understand the result. They do not replace evaluation of what was selected.
The practical outcome should be guidance toward a version that a team can use, rather than a warning with no workable next step. That becomes increasingly important when coding assistants propose dependencies or upgrades as part of routine development.
4. Make the Repository the Consistent Route
Without a centralized managed repository, enforcing component checks, standardizing version governance, and securing approved sources across pipelines and developer environments becomes highly fragmented. A managed repository creates a secure, single path for retrieving open source components while keeping an audit log of all incoming artifacts.
Centralizing access helps teams configure approved upstream sources, trace the components they consume, and apply consistent controls across local development and automated builds. It also reduces the need for each project to manage its own registry connections and download rules.
The repository should be treated as part of the delivery workflow, not merely a place to store files. Teams need to know which projects and pipelines use it, where direct downloads still occur, and whether developers can retrieve approved packages without delays. The trusted route has to be dependable enough for teams to use every day.
5. Keep Watching After Approval
An approved component needs continued monitoring because its risk can change after download. Researchers may disclose a new vulnerability, investigators may identify previously unknown malware, or a project may stop maintaining a version on which an application depends. Secure consumption therefore continues after the initial download.
Teams need a current view of the components and versions in their applications, including transitive dependencies. When new intelligence arrives, they should be able to identify affected projects and distinguish components in active use from packages that were merely downloaded or stored. That context makes it possible to focus response work where it matters.
This is where ongoing dependency analysis complements controls at download. Early evaluation limits what enters development. Continued monitoring catches changes in risk after a component has been accepted. Neither decision can be made once and assumed to remain valid indefinitely.
6. Give Every Finding a Remediation Path
Every finding needs a clear path from identification to action. A response process should connect a newly identified risk to the affected applications, the people who own them, and an appropriate next step:
-
For a malicious package: Stop further consumption and investigate whether it executed or exposed credentials.
-
For a vulnerable component: Identify affected applications, select a safer version, and test the change for compatibility.
-
When an immediate fix is unavailable: Document the exception, assign an owner, and set a date to revisit it.
Prioritization should reflect the threat and how the component is used, rather than relying on a severity score alone. Teams also need room to test changes. An upgrade that breaks a critical application is not a complete remediation plan.
Tracking how quickly teams identify affected applications and complete viable upgrades can show whether the consumption process is working. While prioritization and remediation address risks already found in your software, a more secure approach shifts protection left. Organizations should put malware protection in place to block anything malicious before it reaches your repository or builds.
Make the Trusted Choice the Easy Choice
The new rules create a continuous path: choose approved sources, evaluate components early, select suitable versions, use a managed repository, monitor ongoing risk, and establish clear remediation steps.
That path supports faster delivery as well as stronger security. Developers spend less time sorting through ambiguous warnings or unwinding a bad dependency after it has spread. Engineering leaders gain a clearer view of what their teams consume and a more reliable way to respond when a component's risk changes.
Begin by auditing the pathways dependencies currently follow across your organization. Identifying unmanaged downloads and making a secure repository the dependable path gives the other rules a place to work. Explore Sonatype Nexus Repository to learn how centralized artifact management can support that foundation.
Aaron is a technical writer at Sonatype. He works at a crossroads of technical writing, developer advocacy, and information design. He aims to get developers and non-technical collaborators to work better together in solving problems and building software.
Explore All Posts by Aaron LinskensTags
Try Nexus Repository Free Today
Sonatype Nexus Repository is the world’s most trusted artifact repository manager. Experience the difference and download Community Edition for free.