You’re likely pulling OSS packages straight from NuGet.org, npmjs.com, or PyPI.org, via the CLI. It’s the path of least resistance and the fastest way to get what your teams need. But without something sitting in the middle, it’s hard to know exactly what’s being pulled in or whether it meets your org’s requirements.

When you pull OSS packages straight from public registries, they aren’t getting a full check for vulnerabilities, malicious code, or license issues. Most of the time, developers grabbing the “right” version of an npm package are basically trusting it themselves, and that’s if they even look at it at all. When these quick, ad-hoc decisions happen across scattered teams, your apps end up carrying the risk. What you really need is a practical way to bring all your package handling together

In this article, I’ll talk about how your current OSS practices are leaving your organization exposed to long-term risks, and how a more centralized approach is the solution to protecting your pipeline and apps.

Direct OSS = Direct Risk

OSS packages are a central part of software development, but aren’t always completely vetted before teams pull them directly. It’s pretty scary when anyone can upload packages to most public registries like npmjs.com and NuGet.org, meaning your directly pulled OSS packages are potentially directly pulled risks:

⚠️Vulnerabilities: OSS packages can contain vulnerabilities or hidden exploits that sometimes only come to light long after they’re published. How much they impact your apps depends on context, but some (like the infamous Log4Shell) can let attackers run code remotely, so you definitely want those blocked. And it’s not just old vulnerabilities, there have been plenty of recent cases where widely used OSS packages, like certain JavaScript libraries, were compromised to steal user funds.

⚠️Non-compliant Licenses: Unlike vulnerabilities, package licenses are visible upfront. But when developers pull OSS packages directly, they won’t always check them against a central standard, especially without automated policies in place. That’s an easy way to end up with non-compliant code in production. Even common licenses like GPL-3 need a careful look, otherwise, you could be facing legal trouble, as in the Entr’ouvert v. Orange S.A. case.

⚠️ Low Quality Code: Pulling packages as a quick fix can leave you with buggy or poorly maintained code in your builds. Packages can be abandoned without warning, leaving you stuck with deprecated code. Worse, they can be removed from the registry entirely. For example, version 0.4.3 of jaxlib was deleted from PyPI, and a flaw in RubyGems once let external users yank packages maliciously.

Pulling these risks makes your CI/CD pipeline fragile, the friction felt by frustrated developers, tasked with constant debugging and untangling dependency conflicts and version mismatches, all in an effort to replicate unreproducible environments.

Scaling teams leads to the chaos compounding, perpetual firefighting becoming the norm, which drives developers towards undocumented packages and third-party tools, using shadow IT to Band-Aid the instability. It’s not scalable, growing disorder alongside the organization, and a stable foundation with enforced OSS standards is needed as a solution.

Building a Scalable Foundation

A central internal registry that allows your OSS to be pulled from proxy feeds means only vetted, application-approved packages end up in production, while preserving the speed and accessibility of your existing workflows.

💡 Proxy feeds pull packages from the official source via connectors, eliminating any direct connection between your network and the Wild West that is the OSS landscape. 

💡 Connectors are handy for reducing namespace attacks as well, only allowing secure, compliant packages through. 

Proxied packages should live in a single, developer-accessible internal registry and be automatically scanned for vulnerabilities and license issues. That way, you have one trusted source of truth, letting teams focus on development instead of constant ad-hoc checks. We call building a vetted package library an approval flow, a single, reliable path for OSS access that eliminates direct pulls and reduces Shadow IT.

A centralized registry means it’s easy to apply enforceable governance, since your oversight isn’t torn between scattered repositories. Auditing builds and tracking packages and dependencies with SBOMs is way more manageable when all teams use the same tools and environments. Also, it’s much easier to diagnose crashes when your data’s centralized, rather than playing a detective searching for evidence outside their jurisdiction.

Having the solution in mind is only one side of the equation, and you’ll need a flexible package management tool to implement these practices.

Centralizing Your OSS with ProGet

Using ProGet to centralize your package management is easily done. Simply create a connector when setting up your feed to protect your pipeline from namespace attacks. This lets you cache and store OSS packages, instead of directly pulling them from public registries.

ProGet scans your feeds for vulnerabilities and licenses automatically, with customizable policies at the global or feed level. If a requested package is blocked, admins can perform ad-hoc assessments, determining if the package is context-safe, and create exceptions. For an extra layer of control, promote vetted packages to approved feeds accessible by developers.

Auditing your OSS usage is easy with the ability to analyze your imported SBOMs, and a more visually friendly output of your build’s vulnerabilities and licenses is viewable from the Policies & SCA page.

Firefighting version conflicts is as easy as blowing out a candle when your dependencies are visible, so you can focus on finding the right package to remediate, instead of hunting down the problem.

Secure Your Packages From the Starting Line

Directly pulling packages can be synonymous with directly pulling in risky vulnerabilities and licenses. Without standards in place, developers determine what’s safe ad hoc, pulling in dubious quick-fix packages from the shadows when needed. Sure, you get your solution, but what about the security risks, hidden lawsuits, and low-quality code that come with it?

Instead, proxy your OSS packages within a centralized repository using ProGet. When all packages are approved and visible, it’s easy for devs to collaborate, and oversight can be focused on one registry, not divided among sprawled toolsets.

I covered a lot today, so make sure to favorite this page for when you need a refresher. Even better, grab a copy of our free eBook “Package Management at Scale.” It contains everything on this page and more, from implementing scalable governance and distribution to providing a framework to assess your org’s package management. Download your free copy today!

Or, take the next step and implement a CMPR solution in your own organization using ProGet. You can start a 30-day free trial of ProGet Basic and see how centralized package management streamlines workflows, improves compliance, and boosts developer productivity firsthand.