Prevent Inadvertent Software Supply Chain Exposures When Allowing Public Access to Private Registries

At JFrog, we’re serious about software supply chain security. As a CVE Numbering Authority, our JFrog Security Research team regularly discovers and discloses new malicious packages and vulnerabilities posing a threat to development organizations. We know that in order to deliver trusted software on demand, you must have a secure software supply chain — making security a priority in everything we do.

While organizations are oftentimes hyper-focused on finding CVEs, blocking malicious packages, or runtime attacks, we can’t forget about the security of the tools you use to manage and deliver your supply chains. Probably the most foundational of those tools is where you store and manage your packages, builds, binaries and artifacts — such as JFrog Artifactory. Let’s take a look at one key area that can open up your organization to software supply chain attacks if you’re not careful — allowing public access to your private registries or repositories.

Allowing public access to your private registries

The whole point of having private package repositories and registries is to ensure control over which software components are included in your software supply chain and who can access them. So why would you want to allow any random person on the internet to access your private registries?

There are many legitimate reasons a business would want to allow anonymous users to access their registries/repos:

• Providing easy access to/download of public facing software such as libraries and SDKs
• Collaborating with internal or external development teams who need to access the latest versions of 1st party software components
• Allowing public access to non-sensitive information, such as documentation
• Supporting integrations and automation with third-party applications and services
• Contributing to open source projects

The issue with allowing public access to repos/registries arises when they’re made public accidentally or when artifacts containing sensitive information such user tokens, credentials, and keys are accidentally stored in repositories with “public” access.

Avoiding misconfigurations and accidental exposures

The good news is, whether you intend to allow public access to your registries or not, it’s fairly straightforward to keep this part of your supply chain secure. Here are four easy steps you can take to prevent inadvertently exposing yourself.

1. Double-check your security configurations

This is probably the easiest preventative measure you can do today (and should probably take a quick moment after you’re done reading this to go do it!). Third-party solutions for private registry/repos typically have configurations that allow admins to set whether a repo/registry can be accessed by users not managed under your development organization.

For example, here’s how you can double-check that you don’t accidentally have this setting turned on in Artifactory:

As an admin, login and navigate to Administration > User Management > Settings (see screenshot below for reference).

If the “Allow Anonymous Access” setting is checked, you’re opening the gate to potentially allowing access by non-logged in users to your repos.

2. Double-check your user permissions

If you do want to allow non-logged-in access to your registries, it’s probably best to double check what anonymous users can access and do with the artifacts in those repos/registries. Your solution should have robust RBAC settings, including for anonymous users.

For Artifactory you can check those permissions by navigating to Administration > User Management > Users > “anonymous” user (see screenshot below for reference).

When you click on the user you can see what permissions anonymous users are granted. In Artifactory you create permission sets and then add users/user groups to them. You can manage your permissions via the “Permissions” section under “User Management” (see documentation for more details).

A best practice we recommend is setting anonymous users to read only and clearly defining which repos they have access to.

3. Keep public and private content separate

At a bare minimum, you should establish separate repositories for artifacts that are intended to be publicly consumed. However, best practice is to not mix private content with public content within the same Artifactory instance, or whatever repository/registry solution you use. Instead, keep public and private assets on separate instances with a different set of permissions and access controls.

Clearly define who within your organization can deploy artifacts into your public-facing instance and regularly review the contents of those registries to ensure only appropriate artifacts are stored there.

These actions ensure private content doesn’t inadvertently get co-mingled with private assets and reduce the likelihood of misconfigurations.

4. Scan your public-facing registries for secrets

After you’ve double checked all your settings and permissions, and created a dedicated space to manage public content, there is an additional layer of protection you can add – leveraging a security tool to scan the contents of public-facing registries/repos for secrets. Taking this final step will help ensure you’re not exposing sensitive information via the components within the repo/registry.

If you’re using JFrog Artifactory and Xray this can be configured to occur any time an artifact is deployed to the public-facing repository and even automatically block the artifact from being deployed if secrets are detected.

Preventing misconfigurations in the first place

JFrog is serious about secure software supply chains, from the components within them to the tools used to deliver them. While allowing anonymous access to private repositories is a feature supported in Artifactory, it’s not enabled by default. Seeing that we can do even more to protect our users against misconfiguring undesired public access to repositories, we’re taking the following actions, and recommend other solution providers do the same:

1. UI changes that make it less likely a setting was selected in error, in addition to updating the labels around these settings
2. If a configuration is set that could impact supply chain security, admins will be alerted in plain language as to the implications, and have to verify the configuration is intended.
3. Default settings that highly restrict what “anonymous” users – if enabled – can access and do in public-facing registries.

Now you know how to prevent inadvertently exposing private registries/repos and mitigate risk when intentionally doing so. If you’d like to learn how you can better secure your software supply chain, check out our regular Solution Engineering sessions for JFrog Artifactory or JFrog Xray where we answer your questions and share best practices to deliver trusted software with JFrog Platform.

Thanks to our colleagues at Aqua Nautilus, Aqua Security’s research team for recently highlighting this concern.