Level 3: Repo-Centric Silos 

Level 3 organizations are technically mature and provide strong developer enablement with modern CI/CD, automated security checks, and repo-centric package publishing with modern CI/CD tools such as GitHub or Gitlab. But this enablement stops at the repository boundary — there’s no centralized way to govern, share, or reuse packages across projects, leaving code fragmented and underutilized. 

Despite technical competence, organizations often fail to realize the full potential of package technologies. Packages are meant to be reusable across multiple projects, not locked inside a single one. Yet the design of many popular platforms gets in the way. For example, GitHub’s Packages and GitLab’s package registry tie repositories to individual projects, making it unnecessarily difficult to share and reuse internal code or approved external packages across teams. 

Workarounds exist, but they require extra configuration for each project and still don’t address the bigger issue: GitHub lacks the centralized management capabilities that purpose-built package managers provide. There is no unified place to organize packages, categorize them, apply consistent vulnerability scanning, or distribute them reliably across projects. The result is predictable: valuable code sits underutilized, duplicated, or fragmented — and governance becomes an afterthought. 

This gap undermines developer enablement by forcing teams to reinvent solutions instead of reusing trusted packages. It weakens security and auditability, since vulnerabilities and usage can’t be tracked consistently across projects. And it limits scalability and governance, as every new project compounds the complexity of managing packages in isolated silos rather than through a unified, organization-wide strategy. 

In this chapter, we’ll explore the challenges Level 3 organizations face when packages are “shared (sarcastic double quote)” across projects, but package management remains decentralized — highlighting the technical limitations, security blind spots, and governance gaps that emerge from a repo-centric approach: 

AREA	DETAILS
Centralization	Fragmented package registries make it difficult for developers to discover and reuse packages across teams, slowing development and making onboarding to a new project or team harder, even for developers already inside the company.
Governance	Security is inconsistent and reactive, with vulnerabilities often caught only after packages have already been downloaded by developers, integrated into builds, or, in the worst case, deployed to production, with no unified pre-download scanning across sources.
Curation	Team-level governance exists, but without centralized standards, policies vary widely and are easily bypassed.
Distribution	Package usage and provenance data are scattered, making audits and incident response time-consuming and error-prone.
Scalability	While automation exists within teams, siloed tools and inconsistent practices create inefficiencies that don’t scale.

From Code-Centric to Package-Centric Development 

Modern package-centric development is a fundamental shift from traditional code-centric approaches, changing not just how code is managed, but how organizations structure, share, and govern software. Unlike code-centric development, which treats projects and repositories as primary units of work, package-centric development treats reusable components as first-class organizational assets, enabling broader discovery, reuse, and governance. 

Major shifts in software development tend to happen roughly once per decade: Waterfall in the 1980s, Agile in the 2000s, DevOps in the 2010s, and Cloud-first approaches in the 2020s.  These changes usually respond to broader industry trends, not internal decisions to “work better.” The next shift is already here: the rise of package technology and open-source software (OSS). Key milestones include: 

• 2001: Maven Central launches (Java) 
• 2008: npm debuts (JavaScript) 
• 2010: NuGet released (.NET) 
• 2011–2014: Ecosystems adopt modern package managers; transitive dependencies become common, and OSS adoption moves from niche to mainstream 
• 2015–2017: OSS adoption exceeds 50% of enterprise codebases; package managers become standard 
• 2018: First large-scale malicious package incidents (event-stream npm) 
• 2020–2024: OSS now accounts for 70–90% of application code; dependencies and security incidents surge 

This transformation is as profound as previous shifts to Agile, DevOps, or Cloud. Like these, organizations must adapt or be left behind. Yet few fully understand what package-centric development entails, and many modern tools are still built around code-centric workflows, making them ill-suited for the package-driven landscape. 

From Forks to Feeds: How OSS Management Has Changed 

Not long ago, managing open-source software (OSS) was simple: teams forked libraries or copied them into /lib or /vendor. This approach worked because OSS adoption was low, dependencies were few, and updates were infrequent. The risk of inconsistencies across projects was minimal. 

Today, the landscape is vastly different. Modern applications rely on hundreds (sometimes thousands) of direct and transitive dependencies: 

• 70–90% of application code is OSS. 
• The average app contains 900+ OSS components, with transitive dependencies accounting for 77% of OSS vulnerabilities. 
• Malicious package uploads rose 188% in 2023, with 96% of organizations reporting at least one OSS-related security incident. 
• Manual vendoring or forking is no longer feasible; tracking, updating, and securing thousands of components is unmanageable. 

Modern Package-Centric Practices 

Package technologies now allow organizations to shift security left: scanning for vulnerabilities, license compliance, and policy violations before code or CI/CD runs. Mature package-centric practices also enable: 

• Promotion of vetted packages from staging to production 

• Instant availability of packages across all projects 

• A single, curated organization-wide repository 

Many organizations still rely on post-download scanning via GitHub Actions, Dependabot, or GitHub Advanced Security, but this approach has significant drawbacks: 

⚠ Risky packages are flagged after they’re already pulled: Vulnerabilities may enter the codebase, increasing the likelihood of breaches, failed deployments, or compliance violations. 

⚠ GitHub’s project = repo structure creates isolated dependency “islands”: Teams lack visibility into which packages are used across projects, leading to duplicated work, inconsistent updates, and delayed security responses. 

⚠ Internal packages are approved per project: Results in siloed storage, repeated vetting efforts, inconsistent governance, slower vulnerability remediation, and a larger organizational attack surface. 

Even with GitHub Packages supporting organization-wide storage (as of August 2025), critical limitations persist: 

❌ No upstream proxying → Public feeds like npmjs.org cannot be cached centrally, exposing projects to downtime, version inconsistencies, and unvetted packages. 

❌ No promotion workflows → Packages cannot move efficiently from dev → staging → prod, increasing the risk of untested or unsafe code reaching production. 

❌ Limited central curation and distribution → Teams cannot uniformly enforce security, licensing, or compliance policies, leaving gaps in governance and traceability. 

Despite the benefits of modern package-centric practices—centralized curation, preemptive security, and easier distribution—many organizations still treat each repository in isolation, resulting in siloed dependencies, inconsistent governance, and duplicated effort. 

Anti-Patterns of Level 3 Organizations 

Many organizations still rely on fragmented, repo-by-repo workflows for package management. This decentralization creates inefficiencies, complicates governance, and scales poorly, introducing security, compliance, and operational risk. The following anti-patterns highlight how these challenges manifest: 

⛔ Centralization – Not achieved: Packages are stored per project in GitHub Packages rather than in a single organization-wide feed. Each project sources OSS independently, often pulling directly from public registries. 

• Reinventing the wheel – Developers manually search public registries, often duplicating vetting already done by others. This wastes engineering time, slows feature delivery, and increases the risk of inconsistent quality checks. 
• Limited discovery – GitHub Packages lacks strong search and metadata, making it hard to find and reuse internal packages. Developers frequently rebuild or re-import solutions that already exist, leading to duplicated effort and slower collaboration. 
• Inconsistent versions – Different repos pull different versions of the same dependency, creating fragmentation. This causes compatibility issues between projects, unexpected build failures, and unpredictable security coverage. 
• Fragmented visibility – Without a central feed, leaders lack a clear view of what OSS is being used across projects. Security, licensing, and operational risks go unmonitored at the organizational level, making coordinated response to incidents nearly impossible. 

Why it matters: Teams face duplicated effort, inconsistent dependency versions, and fragmented visibility into the software supply chain, which slows delivery and increases the risk of integration failures and security blind spots. 

⛔ Governance – Repo-scoped only: License compliance and vulnerability policies are enforced at the repository level using tools like Dependabot or GitHub Advanced Security. There is no central enforcement point to block unsafe packages before they enter the development environment. 

• Repo-by-repo autonomy – Each repo manages governance independently, preventing coordinated oversight. Policies drift over time, making it impossible to guarantee consistent security or compliance standards across the organization. 
• Inconsistent enforcement – Some repos enforce strict rules, others none at all. Risky or non-compliant packages can slip through weaker repos, creating uneven security postures and hidden compliance liabilities. 
• No organization-wide visibility – No central dashboard for dependencies, vulnerabilities, or licenses. Leaders lack the ability to prioritize remediation, allocate resources effectively, or assess risk exposure at scale. 
• Undocumented policy exceptions – Overrides happen ad hoc, leaving no audit trail. Audits become unreliable, repeated risky decisions go unnoticed, and accountability is weakened. 
• Slow zero-day response – Vulnerabilities like Log4Shell require repo-by-repo hunts, delaying patching and increasing exposure. Production systems stay vulnerable longer, raising the likelihood of exploitation and costly incident response. 

Why it matters: Unsafe or non-compliant packages can bypass inconsistent repo-level controls, creating governance blind spots, slowing audits, and raising the likelihood of breaches, compliance failures, and operational disruptions. 

⛔ Curation – Manual and repetitive: Each team independently decides which OSS packages to use, often re-vetting the same components multiple times. Even when client-side tools (npm, NuGet, etc.) flag vulnerabilities, results are uncurated and untracked, forcing teams to reassess risks whenever a package is added or updated. 

• More work for developers – Vetting package safety and compliance becomes developer-owned. Engineering time is diverted from building features to repetitive safety checks, slowing development cycles. 
• Blocked by CI/CD – Vulnerabilities are often flagged only after code is pushed. Developers must redo work, refactor code, and rerun tests, creating delays and frustration. 
• Redundant reviews – The same OSS components are vetted repeatedly across teams. Repeated effort increases operational overhead and wastes organizational resources. 
• Uncurated vulnerability checks – Built-in tools flag issues without context or organization-wide tracking. Teams may overreact or underreact to flagged vulnerabilities, causing inconsistent security practices and potential blind spots. 
• No “approve once, use everywhere” – Safe packages are not reusable across the organization without repeating approvals. Knowledge is siloed, and safe, vetted packages are underutilized, slowing project delivery and increasing the risk of errors. 

Why it matters: Teams waste time on redundant reviews, slow down development, and risk inconsistencies in dependency quality. Without central curation, every new package introduces repeated overhead, fragmented security practices, and slower delivery across the organization. 

⛔ Distribution – Siloed: Internal libraries are published to a project’s GitHub Packages feed instead of a shared organizational feed. 

• Limited internal discovery – Developers cannot easily find internal libraries. Teams spend extra time searching or recreating functionality, slowing development and reducing efficiency. 
• Duplicated libraries – Without a central hub, teams re-implement functionality that already exists. Redundant work increases maintenance overhead, creates inconsistent implementations, and complicates future integrations. 
• Slower collaboration – Fragmented distribution forces teams to track provenance manually. Integrating internal libraries becomes error-prone and time-consuming, delaying project timelines. 
• Weakened reliability – Internal components feel “local” to projects rather than reusable across the organization. Confidence in internal packages decreases, discouraging reuse and forcing teams to rebuild or vet components independently. 

Why it matters: Teams struggle to discover, consume, or reuse internal packages efficiently, leading to duplicated work, inconsistent implementations, and slower project delivery across the organization. 

⛔ Linear effort per project: Every security scan, license review, and package update must be repeated per repository. 

• Massive administrative overhead – Thousands of packages across hundreds of repositories each require manual vetting. Security and engineering teams are consumed by repetitive tasks, reducing focus on strategic initiatives and slowing delivery. 
• Inconsistent practices – Different repos use different tools or SBOM formats (e.g., SPDX vs. CycloneDX). Aggregating and comparing data becomes difficult, increasing the risk of overlooked vulnerabilities or compliance gaps. 
• Fragmented data – Access, vulnerabilities, and licenses are tracked per repo. Leadership and security teams cannot get an accurate, organization-wide view, delaying risk assessments and remediation. 
• No organization-wide SBOM – GitHub generates SBOMs per repo, but not across the organization. Manual aggregation is time-consuming and error-prone, creating gaps in dependency and vulnerability tracking. 
• High audit overhead – Compliance reports require piecing together data repo by repo. Reporting is slow, costly, and prone to mistakes, increasing regulatory and operational risk. 
• Duplication of effort – Teams repeatedly vet the same public packages independently. Resources are wasted, development cycles are slowed, and organizational knowledge is not leveraged efficiently. 

Why it matters: As projects multiply, decentralized package management becomes unmanageable. The workload scales linearly, audits are costly and error-prone, and inconsistent practices make it difficult to maintain a coherent security posture, increasing exposure and delaying delivery. 

For quick reference, see the Appendix for summaries and essential takeaways from this section. 

Moving Forward: Breaking Free from Repo-Centric Silos with a Package-Centric Approach 

At Level 3, organizations often have the appearance of maturity: well-oiled CI/CD pipelines, automated testing, and robust security checks. But beneath the surface, repo-by-repo workflows still dominate. Packages are tied to individual projects, governance is inconsistent, and valuable code remains siloed, duplicated, or underutilized. The result is hidden inefficiency, fragmented security, and slower delivery—challenges that only worsen as the organization grows. 

The next leap forward isn’t about more automation in each repo—it’s about rethinking the unit of development. Moving from code-centric to package-centric practices transforms reusable components into first-class assets, enabling consistent governance, faster delivery, and true scalability. 

✅ Centralization: One Registry to Serve the Entire Organization 

Packages are often scattered across individual GitHub Packages feeds or local registries, making discovery and reuse slow and unreliable. To address this, unify all internal and third-party packages in a single, purpose-built manager like ProGet that proxies approved public sources and stores curated code in organized feeds or feed groups. Implement role-based access control so only authorized users and CI/CD pipelines can publish or consume packages. This centralization consolidates governance, security, and tracing, eliminates siloed blind spots, ensures every package is vetted and traceable, and provides complete visibility for faster incident response and consistent compliance. 

Why this helps: Developers get a single, trusted source for all packages, reducing duplication, speeding onboarding to new projects or teams, and enabling cross-team reuse. Centralization also sets the stage for consistent governance and visibility across the software supply chain. 

✅ Governance: Enforce Once, Apply Everywhere 

Policies for vulnerabilities, licenses, and approvals currently exist only at the repo level, tying governance to codebases rather than the packages they consume, leaving wide gaps and inconsistent enforcement. To close these gaps, shift governance from code to packages by introducing organization-wide policies, role-based access control, package approval workflows, and license restrictions. These will apply before any package is downloaded or used. Because packages are discrete, versioned units with clear metadata, they are easier to scan, approve, track, and block than arbitrary code changes in a repo. Enforce these controls at the package manager level so only vetted packages from trusted feeds can be consumed by developers or CI/CD pipelines. 

Why this helps: Packages’ structured format makes governance more precise and less burdensome, allowing enforcement to happen earlier and more consistently. This stops unsafe or non-compliant packages from ever entering development environments, removes policy drift between teams, and gives leadership a single, centralized view of compliance across all projects.  

✅ Curation: Pre-Approve for Instant, Safe Reuse 

Currently, teams vet the same OSS packages in isolation, and usually only after they’ve been downloaded into a repo, leading to redundant work, inconsistent results, and the risk of unsafe packages slipping through. To fix this, adopt a curated-feed model where packages are pre-scanned for vulnerabilities, license compliance, and other organizational standards before approval. Approved packages are stored in trusted feeds that any team or CI/CD pipeline can consume without re-vetting, and because packages are immutable, versioned, and carry rich metadata, they can be safely reused across projects with complete traceability. 

Why this helps: Eliminates repetitive reviews, accelerates development, and shifts security left, ensuring only safe, compliant packages enter the ecosystem and preventing last-minute rework or production delays. 

✅ Distribution & Visibility: Make Internal Code Discoverable 

Distribution today is code-centric; internal components live inside individual repos and, when packaged, are often published only to project-scoped feeds. This limits discoverability, creates version silos, and scatters usage and provenance data, making audits and impact analysis slow and error-prone. Shifting to a package-centric model means centralizing all internal packages in an organization-wide registry with rich metadata, usage tracking, and SBOM generation at the package level, along with search and discovery tools that surface vetted, reusable packages to developers and CI/CD pipelines across all teams. Because packages are immutable and versioned, their usage can be traced across every project without manual effort. 

Why this helps: Turns internal packages into trusted, reusable building blocks, ensures organization-wide visibility, and enables rapid zero-day response by instantly pinpointing where vulnerable dependencies are deployed. 

✅ Scalability: Scale Governance, Not Workload 

Scalability today is code-centric; every new repo adds linear effort, with security scans, license checks, and package updates repeated independently for each project. This duplication increases workload, delays releases, and heightens the risk of inconsistent enforcement. Adopting package-centric scalability standardizes workflows through multi-feed architecture, CI/CD integration, and automated promotion of packages from dev → staging → prod. With governance, approvals, and security checks applied at the package level, a single vetted package can be reused across all projects without repeating the same work. 

Why this helps: Governance scales without adding proportional workload, enabling consistent security, compliance, and quality controls even as the organization grows to hundreds of projects. 

By moving beyond repo-scoped thinking and adopting modern package-centric practices, organizations can unlock a step-change in efficiency, security, and developer enablement. This shift eliminates duplicated effort, standardizes governance, and creates a foundation for platform engineering and long-term scale, while giving developers the freedom to innovate without sacrificing control or compliance. 

Enterprise-grade platforms like ProGet make this transition practical. It turns siloed, project-based wins like improved automation or centralization into a unified, organization-wide capability that accelerates every stage of software delivery.