user

Why Curation Matters Now More Than Ever In the Software Supply Chain

Introduction

The Inedo Team

The Inedo Team


LATEST POSTS

Webinar: Turn Complexity into Predictable Delivery with Lean Platforms 02nd December, 2025

Recently Published, Aged Packages, and Upcoming ProGet 2026 Changes 20th November, 2025

Package Management

Why Curation Matters Now More Than Ever In the Software Supply Chain

Posted on .

This article is part of our series on Package Management at Scale, also available as a chapter in our free, downloadable eBook

Many teams overlook software supply chain curation until a crisis hits. Vulnerabilities, dependency issues, and malicious packages can slip in unnoticed, surfacing only when it’s too late. Relying on thousands of open-source components introduces risks such as supply chain attacks, license violations, and unpatched flaws. Traditional practices, built for in-house code and controlled environments, couldn’t account for the external risks of large-scale open-source adoption. Even modern DevOps processes struggle to keep pace, leaving organizations exposed and scrambling to respond.

Risk isn’t the only motivator. Teams increasingly turn to curation to simplify visibility, storing packages in a single place to avoid chasing dependencies across multiple tools. Curation also helps enforce consistency by defining and promoting approved versions of dependencies, reducing the overhead of evaluating every package from scratch. 

The solution is shifting from reactive firefighting to proactive governance. Organizations adopting Centrally Managed Package Repositories (CMPR) and policy-driven controls can regain visibility and control over their dependencies. This improves risk management, enforces compliance automatically, and reduces manual overhead that drains teams and slows development. 

In this article, we’ll dive into why conventional methods fall short, examine the operational challenges posed by modern open-source software. We’ll also explain how effective package curation empowers your teams to take back control. This keeps your software supply chain safe and reliable before issues ever reach production. 

Problems in the Software Supply Chain 

Software development has undergone a dramatic shift over the past two decades, bringing with it a set of new challenges. Open-source software use has surged from near zero to nearly 99% in modern applications. This shift has accelerated innovation and lowered costs, but also introduced complexity and risk: 

  • Fragmentation of technology stacks: With so many OSS components integrated into a single product, dependency bloat has become a problem, especially in ecosystems like npm, where a single package can pull in dozens or even hundreds of transitive dependencies. This complexity increases the attack surface and creates management headaches. 
  • Malicious packages: These have become pandemic, with thousands of reports of attackers injecting harmful code into package repositories. Studies show that malicious packages in npm and PyPI repositories have grown exponentially in recent years, with a 188% increase in detected malware packages during the first half of 2025. 
  • OSS package vulnerabilities: While not intentionally malicious, these can still be exploited by attackers to compromise entire software supply chains. Cases like SolarWinds and Log4J demonstrate how a single vulnerable package can cause massive disruptions. 

Problems and Challenges Due to Lack of Curation 

When organizations lack a proper curation process, which includes the use of CMPR, these risks and challenges multiply:  

Exploitation of Vulnerabilities: While this is inevitable due to malicious actors, the real risk comes from a lack of centralized oversight and policy enforcement. The SolarWinds breach and Log4J vulnerability revealed how devastating the fallout can be when organizations have no way to block the use of known-vulnerable packages at the time of adoption or identify them quickly through SBOMs. In many cases, it can take hours or even days to track down which projects are affected, something preventable with proper curation and centrally managed policies. 

License litigation: When teams source OSS packages in silos without unified governance, the risk of unknowingly violating license terms increases dramatically. This can lead to costly legal battles and damage to a company’s reputation. Furthermore, development slows down because teams spend excessive time vetting OSS packages or waiting for others to do so.  

Duplicative Vetting Process: Multiple teams unknowingly perform the same security and compliance checks on identical packages. This is caused by packages being stored in isolated repositories without visibility. This redundancy wastes valuable time and resources. 

Ineffectively vetting packages without a centralized, coordinated process costs time and resources upfront, but skipping this step only defers the cost to the future, in the form of security incidents, legal penalties, or firefighting production failures. However, with the right approach to software supply chain management, organizations can balance speed and safety. Before we explore this, we need to be aware of the common pitfalls and ineffective strategies companies use to address these challenges.

Anti-Patterns: What Not to Do 

When organizations fall into common pitfalls when trying to manage packages without purpose-built tools or governance models. These anti-patterns introduce complexity and risk that undermine the benefits of package management. 

❌ Cloud Storage (e.g., Azure Blob, S3, File Shares): These solutions are excellent for scalable file storage but are ill-suited as package management systems. They lack key features such as package awareness, meaning they do not understand or enforce package metadata, semantic versioning (SemVer), or dependency relationships. This absence leads to a chaotic environment where developers can upload any file, anywhere, without structure or control. The result is duplicated packages, inconsistent versions, and blind spots in compliance and security. Without version enforcement or metadata, it becomes nearly impossible to track what is being used, where, and by whom, greatly increasing operational risk. 

❌ CI/CD Tools (e.g., GitHub Actions, Azure Pipelines, Jenkins): These excel at automation but lack native support for package management or governance. They typically pull dependencies dynamically at build time without maintaining a curated inventory or review process. This makes reproducibility and auditing difficult as CI/CD systems can’t track package provenance or vulnerabilities without integrating an external package repository.  

Additionally, artifacts generated by CI/CD are often stored in ephemeral or loosely controlled locations, such as temporary pipeline storage or untracked cloud buckets. This leads to unclear ownership and unmanaged storage growth. Relying solely on CI/CD for package management creates an opaque ecosystem where governance policies, such as approval workflows or compliance checks, are not natively supported and can be easily bypassed, increasing the risk of vulnerabilities and compliance violations. 

❌ Tech-Specific Tools (e.g., NuGet.Server, Verdaccio): Lightweight, ecosystem-specific tools provide a minimal proxy or local registry for packages. While useful for small teams or projects, they fall short in larger enterprises. They usually support only a single technology stack, limiting cross-team visibility and control in diverse environments. If a team uses Verdaccio for npm packages and NuGet.Server for .NET packages, they’ll have to manage two separate registries, each with its own interface and login credentials. This prevents a unified view of all packages across technologies. 

Furthermore, they often lack essential governance features like approval workflows, role-based access control, and automated policy enforcement. This means users must log in to Verdaccio and NuGet.Server separately, with no single dashboard to monitor both npm and NuGet packages simultaneously. This complicates oversight and increases the risk of errors.  

Finally, because they are frequently deployed and managed separately by different teams, they can lead to fragmented package repositories and inconsistent standards. This decentralization without coordination undermines governance efforts, making it difficult to maintain security, compliance, and operational efficiency at scale. 

Best Practices: Curating Packages in a Software Supply Chain 

Proper curation of packages within your software supply chain is critical for maintaining control, security, and consistency while enabling teams to move quickly. By adopting these best practices, organizations can reduce risk, increase visibility, and improve collaboration across teams. 

Connect to External Sources via Upstream Connectors 

Rather than letting developers pull packages directly from public registries (such as npm or PyPI), centrally curate all internal and external packages in one place by funneling all external package requests through a centralized package manager like ProGet. This centralized gateway intercepts and logs every external package request, providing visibility into which packages are being requested and used. It lets organizations enforce policies on what external packages can be fetched, preventing unreviewed or risky packages from entering your ecosystem. 

This also reduces duplicated work, as teams avoid unknowingly sourcing or developing packages/components that others have already created. Upstream connectors can cache and proxy external sources, reducing build times and bandwidth usage. 

Why it matters: This protects your development environment from direct exposure to the vast and sometimes risky open-source ecosystem. It provides a control point to enforce security, compliance, and organizational policies, preventing unknown or malicious code from entering unchecked. 

Cache and Store Packages Locally 

Downloaded packages should be stored within internal repositories instead of relying on real-time external fetches. This includes: 

  • Snapshot Feeds: Maintain feeds that contain development or pre-release versions, allowing teams to experiment safely without affecting production stability. 

Curate packages by projects, products, or developer teams to avoid overwhelming or confusing developers with access to all packages in centralized repositories.

Why it matters: It ensures builds are reproducible and stable by always using the same, verified package versions. It protects against external issues like deleted packages or malicious updates, improving reliability and auditability over time. 

Set Up Approval Workflows before using packages for development (Or before giving them to developers) 

Before any package becomes available for use within your organization, it should pass through a structured approval process: 

  • Manual or Automated Approval Gates: Define workflows that require either human review or automated policy checks to approve new or updated packages. 
  • Multi-Stakeholder Reviews: Include security teams, legal/compliance experts, and lead developers in the approval process to evaluate packages from multiple perspectives. 
  • Risk Classification: Categorize packages based on their risk profile (e.g., low-risk utilities vs. high-risk security-sensitive libraries) and apply different approval rigor accordingly. 

Why it matters: These workflows serve as a quality gate that prevents unsafe, unlicensed, or inappropriate code from entering your supply chain. Approval workflows balance speed with safety by embedding governance early in the package lifecycle. 

Scan for Vulnerabilities and Licenses 

Continuous security and compliance scanning is a must: 

  • Ongoing Re-Scanning: Vulnerabilities and license issues evolve over time; continuous scanning ensures newly discovered risks are promptly addressed. 

Why it matters: Security and legal compliance are not one-time checks but ongoing responsibilities. Regular scanning protects your supply chain from emerging threats and ensures adherence to licensing requirements, reducing operational and legal risk. 

Block Non-Compliant Packages

Simply identifying issues is not enough; organizations must enforce policies automatically: 

  • Visibility and Alerts: Ensure teams receive timely notifications about blocked packages and understand the reasons to support remediation. 

Why it matters: Governance without enforcement is ineffective and leaves the door open for risky packages to slip into production. Automated blocking turns policy into action, ensuring that safety is not optional but mandatory. 

Enforce Package Compliance Policies 

Consistency and standardization are key for large-scale package governance: 

  • Signed or Internally Built Packages: Mandate cryptographic signing or internal builds for packages deployed in production environments to verify authenticity and prevent tampering. 
  • Immutability: Once a package is approved and published, it should be immutable, preventing any subsequent changes to ensure auditability and trustworthiness. 

Why it matters: These compliance policies provide guardrails that reduce human error and enforce standards systematically. They make package behavior more predictable and strengthen supply chain integrity. 

Use Universal Feeds and Feed Groups 

In organizations that support multiple languages and ecosystems, managing feeds effectively is crucial: 

  • External Sharing: Provide read-only feeds to trusted external partners or vendors as needed, facilitating collaboration without compromising control. 

Use access control to limit feed access and avoid overwhelming developers with unnecessary packages. 

Why it matters: A unified feed strategy reduces fragmentation, duplication, and complexity. It provides a single source of truth for packages, making governance, discovery, and auditing easier while supporting multi-ecosystem development seamlessly. 

The Risks of an Unmanaged Software Supply Chain 

Most organizations don’t realize they’ve lost control of their software supply chain until a crisis exposes the risks—whether it’s a hidden vulnerability, a license violation, or a malicious package. Assembling software from thousands of open-source components has introduced complexity that traditional DevOps wasn’t built to handle, leaving teams with limited visibility and struggling to respond when issues arise. 

The solution is proactive governance through centralized package curation. By using Centrally Managed Package Repositories, automated approval workflows, and continuous scanning, organizations can enforce security and compliance without slowing development. This approach restores control, reduces risk, and ensures a safer, more predictable software supply chain from the start.

Be sure to bookmark this page so you can easily revisit it. Even better, get your hands on our complete CMPR guide, “Package Management at Scale”. It expands on everything covered here and goes further, covering governance, package distribution, and a maturity metric to help you assess and strengthen package management in your organization. Download your free copy today!

Not sure where to start? Our experts can help. Book a free 15-minute guided assessment to get personalized insight into your package management practices, and clear next steps for reducing risk.

Navigation