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

Most modern apps are built on code developers didn’t write—and barely look at. Instead of copying snippets from StackOverflow or manually downloading libraries, today’s teams pull entire frameworks, utilities, and APIs from open-source package managers like npm, PyPI, NuGet, and Maven Central. It’s fast, easy, and automated. You just declare dependencies, and your CI/CD pipeline does the rest. 

But while this convenience drives productivity, it also creates a blind spot: most teams aren’t actively tracking, updating, or securing the packages they rely on. Instead, they typically just: 

• Declare dependencies in a file like package.json, requirements.txt, or .csproj—but rarely check if they’re still safe or up to date  
• Pull packages straight from registries like npm, PyPI, NuGet, or Maven Central—without knowing who published them or what’s inside  
• Let builds or CI/CD pipelines fetch everything automatically—making it easy to install a vulnerability at scale without noticing 

Open source now powers over 90% of modern applications, yet few teams have visibility into what’s being pulled in, or a strategy to manage it. OSS package managers simply store and distribute packages in a consistent format; they don’t vet code or enforce trust. And most orgs lack consistent policies, workflows, or ownership around open-source use. For something so critical, that’s a major blind spot. Just like CI/CD transformed how we ship code, we need a smarter way to manage what we’re shipping. 

This article introduces that approach. You’ll learn why unmanaged package usage creates real risk, how public registries and ad hoc tooling fall short, and what it takes to gain control. Then we’ll introduce a new approach for getting everything under control: Centrally Managing Package Repositories (CMPR). You’ll learn the five core pillars of good package governance, and how to start leveling up your organization’s maturity.  

The Problem of Packages Without Governance 

Even though modern tools like NuGet.org, npm, and PyPI make it easy to install and update packages, most teams lack structured processes for tracking, reviewing, or approving what gets pulled in. While some orgs have added stopgaps like a private file share or GitLab Packages, they’re hard to scale and full of blind spots. It’s like building a house with prefabricated parts delivered overnight — you don’t always know who made them, what they’re made of, or if they fit together. There’s often no formal oversight, no ownership, and little visibility. Any reviews that are conducted are likely not consistent or easily auditable. 

Developers pull packages straight from live public registries, often with zero review. If it installs and the docs look okay, it’s in. Even when there’s a registry mirror or an internal repo, teams still struggle with fragmented processes for security reviews, license checks, and version tracking. Some are on GitHub, some are buried in Slack threads from last year, and a few are sitting in a random S3 bucket with no docs. No one really owns anything. There’s no system for tracking what got approved, what version is in use, or whether something is completely outdated. If an audit were required tomorrow, most teams would struggle.  

This isn’t just a problem for teams new to using OSS packages in their code. Even with shared registries and basic reviews, dependencies pile up, visibility fades, and risks grow. Teams waste time troubleshooting while leadership remains unsure of what’s running in production. Unmanaged packages may seem minor now, but their impact quietly spreads across several areas where things can quickly fall apart.

Why This Is Actually a Big Deal 

Unmanaged packages might not feel like a problem… until they really are. The impact shows up in various risky or costly ways across your organization. The following are five areas where things can quietly fall apart: 

⚠ Developer Enablement 

• Reinventing the Wheel: Developers end up rebuilding tools or utilities that already exist, because nobody knows they’re already floating around somewhere in the org. This leads to duplicated work, wasted time, and slower delivery. 
• Poor Discoverability: Internal packages are scattered across GitHub, email threads, Notion docs, maybe someone’s desktop. There’s no central place to look, so people just give up and build from scratch. Tribal knowledge wins, reusability loses. 
• Inconsistent Environments: One team’s on v1.2.3, another is on beta-rc5, and someone’s using a fork from two years ago. That’s how “it works on my machine” becomes a failed build or a production issue—costing time to track down and fix. 
• Slow Onboarding: New engineers spend their first few weeks just figuring out what packages they’re supposed to use, instead of shipping releases. Even more time wasted. 

⚠ Security Risks 

• Malicious Packages: Typosquatting and supply chain attacks are real. Pulling code that ends up running in your production environment, directly from public registries with no checks? It’s like leaving your front door wide open. 
• Outdated Dependencies: Old packages with known vulnerabilities stick around because no one’s flagging them. Out of sight, out of mind until something breaks. 
• Unscanned Components: If packages bypass your scanners and controls, they could go straight into prod with who-knows-what inside. 
• Slow Zero-Day Response: When a major vuln drops, you’re scrambling to figure out: Do we use this? Where? What version?  

⚠ Governance Gaps 

• No Ownership: Nobody owns the package process. No reviews, no approvals, no one to say “yes” or “no”. Even DevOps and platform teams often overlook this as a distinct discipline, leaving a critical gap in responsibility. 
• Uncontrolled Use: Anyone can add any package to any project, at any time, from anywhere, creating chaos that no single team is set up to manage. 
• Policy Drift: Even if someone does set up rules, they’re often ignored or enforced inconsistently across teams. 

⚠ Auditability & Compliance 

• No Traceability: You don’t know where a package came from, who approved it, or how it ended up in the build. 
• License Uncertainty: Open-source licenses have obligations. If you’re not tracking them, you could be exposed to legal risks and not even know it. 
• Incomplete SBOMs: Without a central source of truth, generating a complete Software Bill of Materials is like assembling furniture with missing pieces. 

⚠ Scalability Bottlenecks 

• Tool Sprawl: Every team does their own thing. Different tools, registries, workflows. It gets messy and wastes valuable time coordinating or troubleshooting inconsistencies. 
• Inconsistent Practices: One team has a process, another doesn’t. Some scan dependencies; some don’t. Standardizing becomes futile, leading to duplicated effort and wasted time fixing preventable problems. 
• Inefficient Distribution: Sharing packages across clouds or teams? It usually involves manual hacks or insecure shortcuts. That doesn’t scale, and the extra manual work drains team productivity and increases risk over time. 

When packages aren’t managed, everything gets harder—collaboration, compliance, security, onboarding, scaling. Packages often come with unknown licenses, dependencies, or provenance, quietly introducing risks that can lead to outages, legal issues, or costly remediation. Something that teams with mature package management don’t have to deal with. 

Furthermore, this problem compounds quickly. As teams pull in more code, each new package adds complexity, more versions to track, and more vulnerabilities to monitor. Without a system in place, complexity scales faster than your team can keep up with. 

The Problem Is Getting Worse 

When there’s no system in place to manage packages, complexity grows fast. What’s more, this problem is only getting worse. Here’s why it continues to grow each day: 

📛 Modularization Is Exploding: Modern apps are like 90% open source or third-party code now. That’s not an exaggeration; it’s the norm. Even a “small” npm package usually pulls in 79 other packages maintained by 39 different people you’ve never met. Java users are juggling a median of 148 dependencies per project and facing over 1,300 dependency changes a year. Your dependencies are changing constantly. Even your “stable” dependencies like React, Lodash, Express drop updates all the time. If you’re not keeping tabs, these changes sneak into production and ripple through your stack without warning. 

📛 Security Risks Are Increasing Rapidly: Supply chain attacks aren’t just a theoretical risk anymore; they’ve jumped 700% since 2020. Once a vulnerability is public, attackers are exploiting it in under three days. Notably, 94% of these risks arise from transitive dependencies. So even if you think your code is clean, your dependencies might be a mess. If you’re not actively managing what gets pulled in and where it comes from, you’re basically hoping nothing breaks or gets breached. 

📛 Developer Productivity Is Taking a Hit: Developers already spend 30–35% of their time on maintenance, a big part of that is chasing down package issues. Around 25% of that is troubleshooting problems with OSS packages. Case in point, the npm registry outage in April 2024. Thousands of teams had broken builds because their dependencies weren’t tracked, mirrored, or managed properly. Dependencies are supposed to save time, not steal it. But without structure, they become a source of risk, friction, and burnout. It’s not just a tooling gap; it’s a growing, organization-wide problem. 

The impact isn’t always a breach or broken build. It could be a delayed release from an outage, a legal issue from a bad license, or wasted dev time chasing package problems. Issues that your better-governed peers and competitors have already eliminated. Clearly, the old approach isn’t sufficient anymore. 

So Why Hasn’t This Been Solved? 

The tools are everywhere. Your teams are smart. You’ve got CI/CD, scanners, observability, maybe even SBOMs. But somehow, package chaos still finds a way in. Maybe you’ve tried to fix it. You’ve got some automation scripts. Maybe one of your engineers or managers wrote governance documentation, and nobody ended up reading it. 

You’re not alone. We’ve seen it across dozens of organizations: the smartest teams with the best intentions still struggle to solve these problems. It’s not a tooling, technical, or automation problem. It’s a visibility, ownership, and scaling problem. And solving it requires more than checklists or tools. It takes a shift in perspective, or a moment of clarity. You realize the chaos isn’t just accidental; it’s structural and solvable. 

A New Discipline: CMPR 

We’re proposing a new approach called Centrally Managing Package Repositories — or CMPR for short. It’s not a tool, It’s a discipline designed to bring clarity, structure, and sanity to the way organizations handle software dependencies. Think of it like this: CI/CD revolutionized how we ship code. CMPR aims to do the same for how we pull it in, governing what gets used, how it’s approved, where it’s shared, and how it scales across teams. 

And if you’re thinking, “we already do this because we use GitHub for CI/CD and it has packages” — you don’t. GitHub Packages isn’t CMPR. Neither is a file share, or slapping an artifact in S3. CMPR is a strategic layer of governance, not just a place to stash binaries. 

CMPR transforms package management from a reactive task into a strategic discipline that governs the entire lifecycle of software dependencies with accountability. It centralizes approved packages while enforcing security, licensing, and versioning policies before code reaches production. This gives developers a safe, reliable way to share and reuse components and provides leadership with full visibility and traceability to respond quickly to vulnerabilities.

The Five Pillars of a Centrally Managed Package Repository

Implementing CMPR is a journey, not a one-time fix. It requires:

• Centralization: Centralizing control to create a single source of truth for approved packages
• Governance: Defining a trusted layer for enforcing policy and security checks
• Curation: Vetting and maintaining package quality to meet organizational standards
• Distribution: Securely delivering approved packages to teams and production environments
• Scalability: Scaling practices across teams to ensure consistency and reusability

Starting small by focusing on high-risk or critical packages, then expanding gradually helps build momentum and prove value.

Taking Control of Your Software Supply Chain

Modern software development demands modern package management. Relying on scattered processes, partial tooling, or hope isn’t enough anymore. Centrally Managing Package Repositories (CMPR) offers a structured, scalable way to bring order to the chaos, reduce risk, and unlock developer productivity.

If your organization hasn’t yet adopted a strategic approach to package governance, now is the time. Because the code you don’t write is just as important as the code you do, and managing it well is critical to your software’s success.

Ready to take control of your software supply chain and eliminate the risks of unmanaged packages? Our full CMPR guide “Package Management at Scale” dives deeper into the five pillars of effective package governance, provides practical steps to assess your current maturity, and lays out a roadmap for building a secure, scalable package management strategy across 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.