Overview

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 first article of “Package Management at Scale” 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, and 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: What do we do about it? When? Do we even need to do anything about it at all? 

⚠ 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, and 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. 

With CMPR, package management becomes more than just “installing stuff.” It becomes: 

⚙ A centralized, controlled system for pulling and publishing packages 

🔐A trusted layer for enforcing policy and security checks

📈 A scalable platform for sharing internal components and avoiding rework 

⚖ A governance model with real ownership, traceability, and visibility 

CMPR gives you the same confidence in your dependencies that CI/CD gives you in your deployments. And honestly? It’s overdue. 

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. 

What the CMPR Guide is All About 

In this guide, we’ll break it all down for you: 

• Why CMPR matters right now 
• What can (and does) go wrong when package management is ignored 
• The five key pillars of good package governance 
• What maturity looks like, and how your org can start leveling up 

Package management shouldn’t just be an afterthought you figure out when something breaks. It’s a core part of how modern software gets built. And if we want that software to be secure, scalable, and sustainable… it’s time to treat it that way. It’s time to take package management seriously and adopt a more deliberate approach. 

How to Use The Guide 

This guide introduces a new, strategic framework for managing software packages across your entire organization. Whether you’re a platform engineer, DevSecOps lead, architect, or engineering manager, this book is here to help you understand how packages fit into your software supply chain. More importantly, it’ll help take control of them. 

Managing software packages isn’t just a technical task anymore; it’s a critical part of security, governance, and developer productivity. This guide will walk you through how to bring structure and discipline to package management, turning what often feels chaotic and invisible into a manageable, scalable process. 

Part 1: Introducing CMPR and Its Five Pillars 

In the first section, we’ll introduce you to the Centrally Managing Package Repository (CMPR) framework. This is designed to help your organization govern packages as strategically as you do source code, deployments, or infrastructure. You’ll learn the five essential pillars that support effective package management: Centralization, Governance, Curation, Distribution, and Scalability. Each pillar plays a key role in improving consistency, security, and developer enablement across your teams. This section lays the foundation for why package management can no longer be an afterthought. 

Part 2: CMPR Self-Assessment & Maturity Model 

Once you understand the framework, we’ll help you evaluate your organization’s current maturity with a hands-on self-assessment. This structured exercise will highlight your strengths, reveal hidden risks, and give you a clear roadmap to improve your package governance, increase reuse, and boost visibility. It’s designed to be practical and actionable — whether you’re just starting out or looking to refine an existing process. 

How to Get the Most from This Guide 

Use this book as both a strategic overview and a practical playbook. Don’t just read it from start to finish; dive into the sections that are most relevant to your role and current challenges. Experiment with the self-assessment to identify areas where your team can immediately improve. And keep the five pillars top of mind as a framework for ongoing package management maturity. 

By the end of this guide, you’ll have a clear understanding of how to turn package management from a source of risk. Turn redundant work into a core strength that accelerates development and secures your software supply chain. This begins with the first pillar: Centralization, that we will jump to in the next article.