The Hybrid Repository Structure: Balancing Control and Flexibility

And now, let’s dive into part three: How 

 keep your multi-format repositories secure, consistent, and developer-friendly.

In the first two blogs of this series, we explored why repository structure matters and how Cloudsmith’s Hybrid Repository Structure balances control with flexibility. While we touched on policies and permissions, we didn’t dive into the 

 mechanics of how access control ensures artifact security, traceability, and consistency, especially in 

, where different packages, languages, and tooling coexist in a single place.

While multi-format repositories allow for more flexibility in how your repositories are set up, they can introduce a new way of thinking about how and when different artifacts can be accessed and by whom. This blog breaks down how Cloudsmith provides fine-grained, flexible, and secure controls for teams of any size.

Cloudsmith provides the following user roles:

These roles help limit access based on organizational need and provide the foundation for more granular permissions.

You can explore the full breakdown of Cloudsmith roles, permissions, and privileges in our documentation.

You can read more about user roles, permissions, and privileges in Cloudsmith 

Every Cloudsmith customer is given the opportunity to set default global privileges. These global default privileges are set for the “Member” user role in Cloudsmith, which is often suited best for individual developers. Within a customer’s global workspace privileges, organizations can choose to grant members the ability to create new teams, invite new users, and even create new repositories. Organization owners can also grant “blanket” repository privileges to all users within Cloudsmith. 

While we offer the flexibility for organizations to shift responsibility and access to the developer, we often see our enterprise customers lean away from blanket permissions and access toward more fine-grained permissions. As an example, we have a semiconductor manufacturing customer that has disabled default workspace global privileges so that only Organisation owners are the only users who can invite new users, create new teams, invite 3rd-party collaborators, and create new repositories. 

In addition, this customer has access control, and privileges are scoped down to specific teams. Default global repository privileges are disabled so that they can choose exactly which team(s) should have access to repository(s). Even Cloudsmith service accounts are grouped together within a team for ease of tracking permissions and access when it comes to build and deployment times. 

If we zoom in once and look at the repository level in Cloudsmith, we can assign a default privilege for organization members for accessing packages within the repository, and we can assign specific privileges for specific teams, users, or service accounts.

This is the stage where you’ll have to consider what packages the repository is storing and if you want developers and service accounts to have default admin, read, or write permissions to the repository. Continuing to use my customer example, they have chosen to set default read permissions for all repositories; however, specific service accounts have write and 

 to different repositories. You may be okay with your developers downloading artifacts to their local machine for testing or even service accounts requesting stored artifacts tied to staging and production environments.

On the other hand, there are customers that may not want their developers having the ability to write to every repository and would most likely want specific service accounts tied to their CI/CD pipelines to only have write permissions. While this is generally best practice, there are certainly exceptions to this rule, as we also have platform teams that choose to grant specific developer teams write access to specific artifact repositories.

On top of the permission and access control settings we’ve discussed, Cloudsmith goes even further to ensure that, through various additional settings, platform teams can decide exactly what their developers need and don’t need to be reconfigured within a repository.

Platform teams are able to grant or deny developer permissions, such as:

Copying Packages From One Repository to Another

Moving Packages From One Repository to Another

Managing, Using, Or Viewing Entitlement Tokens

If you thought that wasn’t enough, Cloudsmith takes it a step further by scoping down permissions to the individual developer’s generated packages. So while platform teams can restrict tampering of artifacts generated by other developers or systems, they can also decide if they would like to allow developers the ability to scan, move, copy, delete, or resync their own packages.

Most of the enterprise customers I work with allow developers to do as they please with their own packages to avoid a developer mutiny! In either case, these user actions are catalogued in our 

 for enhanced observability across your Cloudsmith environment.

For instances where our customers want to be very particular about what, how, and when users can access specific packages, Cloudsmith offers 

. These scoped tokens are read-access only, so there is never a risk of a user performing a write action against the repository they have limited access to.

Customers are able to restrict access by creating a precise search query to narrow down specific packages within a repository, should they choose not to provide visibility into all the packages within the repository. On top of visibility restrictions, customers can also add token usage restrictions to avoid prolonged access and usage of the token. Parameters include:

Typically, we see our customers use entitlements for 3rd party software distribution or even for systems that don’t require logins to Cloudsmith.

For our security-conscious customers, Cloudsmith also offers the ability to configure 

 based on country, with an easy-to-use preconfigured list of countries to choose from. Choose to deny or allow access from specific countries. Although keep in mind that theoretically, no unauthenticated user should have access to your Cloudsmith workspace in general. This restriction applies more towards open-source repositories that you may be hosting in Cloudsmith, but it’s always a good idea to practice defence-in-depth!

If geo-based restrictions are too broad, you can scope down to IP-based restrictions to either allow or deny client access based on IP address. This added protection ensures that requests coming from clients with an unapproved IP address do not have access to your repositories. 

With all of these configuration options, it can be tricky to decide how you want to best enable your developers while balancing security and flexibility. Not to worry—the Cloudsmith Customer Success team is here to help you in your decisions throughout the onboarding process. We’ve walked through these decisions with many customers and have outlined decision impacts for you so you’re not left wondering “what if”. Learn more about Cloudsmith 

 to get started with us. See you on the other side! 

1. What is access control in a multi-format repository?

Access control defines who can read, write, or administer artifacts across different package formats stored in the same repository. It ensures secure, consistent governance across diverse tooling.

2. How do permissions work in Cloudsmith for multi-format repositories?

Cloudsmith supports global, repository-level, team-based, and user-specific permissions, allowing organizations to tailor access to packages, teams, service accounts, and even individual artifact actions.

3. Why is fine-grained access control important in software supply chain security?

Fine-grained controls reduce the blast radius of errors, prevent unauthorized writes, and help organizations enforce policies required by modern software supply chain frameworks like SLSA and SSDF.

4. What are entitlement tokens used for in Cloudsmith?

Entitlement tokens provide scoped, read-only access to specific artifacts without requiring user accounts, making them ideal for external distribution, automation, or least-privilege workflows.

5. Can developers manage their own packages in Cloudsmith?

Yes. Cloudsmith allows permissions that let developers manage only the packages they personally created—without putting others’ artifacts at risk.

6. How does Cloudsmith support secure CI/CD pipeline access?

Service accounts can be granted precisely the permissions needed for pipeline operations (like write or admin) while keeping developers and collaborators restricted to read-only or scoped access.

7. What’s the difference between global and repository-level privileges?

Global privileges affect the entire workspace, while repository-level privileges enable granular control over specific teams, users, or service accounts interacting with a particular repository.

Access Control & Permissions for Multi-Format Repositories

 continue to rise, and organizations are under intense pressure to build trust in both the code they create and the open-source software (OSS) they consume.

To address this growing challenge, many teams are turning to the 

Secure Supply Chain Consumption Framework (S2C2F)

 designed to strengthen how organizations ingest, validate, and govern open-source components.

This blog is the second part of our Supply Chain Integrity Series. If you haven’t read the first article yet, check out:

Secure Supply Chain Consumption Framework

. It is a security model created to help organizations safely adopt open-source software by improving 

, integrity, and governance across the entire consumption lifecycle.

 side, how teams ingest, validate, scan, store, and trust OSS before it becomes part of their build pipeline.

 development lifecycle, S2C2F gives teams a clear, maturity-based path to reduce 

Why S2C2F matters for open source security?

Modern software is overwhelmingly built on open source. However, the speed and flexibility of OSS come with significant risks. Without a framework like S2C2F, teams are vulnerable to:

S2C2F helps teams systematically reduce these risks by defining the controls required at each maturity level, starting with simple ingestion hygiene and moving all the way to full hermetic, zero-trust infrastructure. It supports 

How S2C2F works: A maturity-based path to integrity

The framework defines four maturity levels. You don’t need to jump to Level 4 immediately; 

 is designed to support incremental adoption as your organization grows.

Level 1: Ingestion control (The Baseline)

 Stop pulling directly from public registries.

 Protection against removal events, registry outages, and basic dependency integrity issues. You also gain a foundational inventory of all OSS components.

Level 2: Secure consumption & faster MTTR

 Prevent packages with known vulnerabilities from entering the build loop and eliminate manual CVE checking.

Audit that consumption is through the approved ingestion method.

Level 3: Malware defense & Zero-day detection

 Defend against malicious actors and typo-squatting.

 becomes proactive. You are protected from dependency confusion and advanced attacks.

Proactive reviews for yet-undiscovered vulnerabilities.

Verify that binaries match the trusted source code.

 Total independence and hermetic security.

 Maximum integrity–even from compromised public upstreams.

How Cloudsmith helps you achieve supply chain integrity

Implementing S2C2F manually is a significant operational challenge. 

 designed specifically to automate software supply chain integrity.

Our platform aligns with S2C2F principles, allowing you to move from Maturity Level 1 to Level 3 almost immediately.

Cloudsmith doesn’t just support S2C2F; it accelerates it, turning 

Software supply chain best practices inspired by S2C2F

To secure the open-source consumption lifecycle, teams should adopt these 

Enforce automated vulnerability and malware scanning

 rather than pulling directly from the wild.

 to ensure code comes from where it claims to.

Rebuild sensitive or high-risk dependencies

S2C2F offers a clear, practical roadmap for improving 

, and strengthening integrity, without overwhelming your team with complex controls from day one.

Whether you're starting at Level 1 or aiming for Level 4, frameworks like S2C2F help organizations adopt open source more safely and confidently.

1. How does S2C2F improve software security?

By enforcing ingestion hygiene, vulnerability scanning, malware defense, and provenance validation, S2C2F reduces the entry points attackers use to infiltrate supply chains.

2. Why does S2C2F matter for open source?

Most software today is open source. S2C2F provides a structured way to safely consume OSS at scale, lowering dependency risks without slowing development.

3. What are the S2C2F steps for securing OSS projects?

Ingest securely → Validate → Scan → Enforce → Audit → Rebuild (when needed).

4. Which frameworks secure software supply chains?

, NIST SSDF, SLSA, CIS guidelines, and SPDX/OSV for standardization.

5. How do you reduce OSS supply chain risk?

You can reduce risk by using private registries, validating provenance, enforcing policies, keeping SBOMs, and scanning for malware and vulnerabilities proactively.

6. What are the guidelines for secure OSS consumption?

Consume through a private proxy, validate integrity, scan frequently, enforce policies, and maintain SBOMs for transparency.

Understanding S2C2F: How it strengthens OSS security

Software today is built on an ever-expanding mesh of open-source components, third-party libraries, container images, package registries, automated systems, and build services. While this ecosystem accelerates development, it introduces a terrifying reality: a single compromised dependency or an unexpected upstream change can ripple through your entire product stack in minutes.

It has become one of the most critical pillars of modern DevSecOps. When your dependencies are trustworthy, verifiable, and governed correctly, you reduce the risk of malware insertion, dependency confusion, tampering, or upstream failure. Without this foundation, even the strongest supply chain security controls at the application layer won’t matter.

This blog, the first in Cloudsmith’s new series on 

, breaks down what software supply chain integrity actually means, why maintaining it is so challenging, and how frameworks like 

S2C2F (Secure Supply Chain Consumption Framework)

 help organisations implement consistent, secure open-source consumption practices.

Ready to understand where your supply chain security stands? Take our 

Software Supply Chain Maturity Assessment

 refers to the ability to ensure that every component in your software, from source code to dependencies to build artifacts and containers, remains authentic, untampered, verified, and sourced from trusted origins.

Do we fully trust the software we’re using?

Are we confident it hasn’t been altered, compromised, or replaced?

It goes beyond traditional application security. While AppSec focuses on your code, integrity focuses on the 

Where did this software originate? Can we verify the source?

Was it built by who it claims to be built by?

Has anything been modified, injected, or tampered with?

How do we enforce policies around what can (and cannot) enter our supply chain?

Can we rely on the upstream source, or do we have a trustworthy internal copy?

As organizations scale, maintaining this integrity moves from "nice to have" to "mission-critical."

Why supply chain integrity is challenging today?

Modern engineering teams consume thousands of open-source packages and containers from public ecosystems like npm, PyPi, Maven, and Docker Hub. These communities evolve fast, and threat actors have learned to weaponize that speed.

The "trust but verify" model is dead. We are now in a "verify, then trust" era. Here is why the landscape has shifted:

1. Malicious package uploads / Typosquatting

Attackers publish packages with names similar to legitimate ones (e.g., reqeust instead of request) to trick developers or automated tools into installing them. Once installed, these packages often run "post-install" scripts that exfiltrate environment variables or keys.

If you use an internal package name (e.g., my-company-auth) that isn't registered publicly, attackers can register that name on a public registry with a higher version number. By default, many package managers will pull the "latest" version -tricking your build system into downloading the attacker's public malware instead of your private code.

If an open-source maintainer’s credentials are stolen, attackers can modify widely-used packages, injecting backdoors, data exfiltration, or crypto-mining code into thousands of downstream applications instantly.

4. Upstream removal or "Left-Pad" incidents

It’s not always malice; sometimes it’s chaos. A popular OSS package can be unpublished by its author (like the infamous left-pad incident), breaking builds across the globe. If you rely on public registries directly, your pipeline is at the mercy of their uptime.

Malware embedded inside base images, compressed binary artifacts, or build scripts can spread downstream silently and undetected.

This modern threat landscape requires a shift in thinking. It’s not just about using open source securely; it’s about maintaining centralized ingestion, policy enforcement, provenance checks, and continuous monitoring

The pillars of software supply chain integrity

To help teams build strong governance around software dependencies, several core integrity principles have emerged. These align closely with industry standards, such as SLSA (Supply Chain Levels for Software Artifacts) and S2C2F.

Software supply chain integrity relies on a set of proven pillars that help teams control how software is sourced, validated, stored, and consumed. These include:

Never pull directly from the public internet in production builds. Consume OSS and third-party software through a centralized "front door", an artifact repository controlled by your organization. This acts as a firewall for your code, preventing accidental consumption of malicious packages and shielding you from upstream outages.

You cannot secure what you cannot see. A Software Bill of Materials (SBOM) provides a clear inventory of all dependencies, versions, and transitive packages. It's critical for identifying risky components and responding quickly to new vulnerabilities.

Automate detection at the gate. Scanning must happen 

 a package enters your environment. This includes checking for:

Known CVEs (Common Vulnerabilities and Exposures)

 standards. Establish global rules for approved packages, permitted licenses, vulnerability thresholds, and immutability. Governance ensures that developers in Team A and Team B are subject to the same safety standards and regulations.

Verify the origin. Ensuring your binaries match their source code is essential. Provenance checks confirm who built the software, where it was built, what tools were used, and whether the artifact signature matches the builder's key.

To achieve maximal integrity, organizations rebuild OSS packages inside their own trusted environment, signing them and generating SBOMs for each build.

Introducing S2C2F: A framework for supply chain integrity

One of the most practical and widely adopted frameworks for implementing software supply chain integrity is the Secure Supply Chain Consumption Framework (S2C2F).

Originally created by Microsoft in 2019 to secure their massive internal development loops, it was donated to the Open Source Security Foundation (OpenSSF) in 2022. It now serves as the industry standard for how organizations should 

 open-source software (as opposed to SLSA, which focuses on how you 

S2C2F offers eight core principles and four maturity levels to help organizations enhance their approach to consuming open-source software.

 All external artifacts must come through a central, controlled location.

 You must maintain a complete list of all OSS components you use.

 Vulnerabilities must be patched within a defined SLA.

 Developers must be prevented from bypassing secure methods technically.

 You must log and audit all ingestion sources and changes that occur.

 Automated scanning for CVEs and malware is mandatory.

 For high security, rebuild OSS on a trusted infrastructure.

 If a patch isn't available, fork and fix it yourself temporarily.

To keep this focused, we’ll dive deeper into S2C2F, including maturity levels and practical implementation steps, in Part 2 of this series.

1. What is software supply chain integrity?

Software supply chain integrity is the practice of ensuring that every component in your software development lifecycle—dependencies, containers, build artifacts, and scripts—is authentic, verified, tamper-free, and sourced from trusted origins. It answers the question: "Is this code exactly what it claims to be?"

2. Why is software supply chain integrity important?

Modern software relies heavily on third-party and open-source components that can be compromised, removed, or tampered with. Integrity prevents attacks such as dependency confusion, malware injection, and supply chain compromise.

3. What is the difference between SLSA and S2C2F? 

Think of them as two sides of the same coin. SLSA (Supply-chain Levels for Software Artifacts) focuses on securing the 

 process (how you create software). S2C2F (Secure Supply Chain Consumption Framework) focuses on the 

 process (how you consume open-source software). You need both for a complete software supply chain security strategy.

4. How does Cloudsmith prevent dependency confusion attacks?

The most effective way is to use a private artifact repository (like Cloudsmith) that supports "upstream proxying" with namespace protection. This ensures that if an internal package name exists, the build system will never look for it on the public registry, preventing the injection of malicious public packages.

5. How does Cloudsmith support supply chain integrity?

Cloudsmith acts as a secure "supply chain firewall." It allows organizations to centralize OSS ingestion, automatically scan for malware and vulnerabilities, manage SBOMs, enforce license policies, and verify provenance—automating the requirements of frameworks like S2C2F.

What is Software Supply Chain Integrity?

By now it’s clear the use of GenAI tooling like Cursor and Claude has fundamentally changed how code is written. This shift, which we explored in depth in our previous post, moves the security perimeter beyond just the generated code. Today, every engineering team building an AI-native application must equally prioritise securing the AI models and LLMs they pull into their tech stack. This forces us to rethink supply chain security for the AI era.

This post will dive deep into a concrete solution: leveraging Cloudsmith's Enterprise Policy Manager (

) to enforce rigorous security and governance policies on LLMs and datasets sourced from the 

Effective governance hinges on detailed metadata. Cloudsmith addresses this by providing a customised data model specifically for Hugging Face models and datasets. This is the crucial enabler, allowing developers and SecOps teams to write granular policies in 

 that target attributes unique to this package type.

The following examples showcase how EPM policies can be constructed to tackle common, yet critical, supply chain risks associated with adopting LLMs.


Whitelisting trusted publishers to enforce provenance

For mature organisations, time-to-market often depends on leveraging high-quality, pre-vetted artifacts from established entities like 

. Instead of subjecting these known-good sources to redundant policy checks, you can use an EPM policy to create a allowlist.

Create a terminal policy with the highest precedence (

If the model's publisher is on the approved list, the policy immediately sets the package state to '

. All subsequent policies are bypassed, dramatically streamlining ingestion for high-confidence artifacts.

 policy primarily targets packages pulled via a Hugging Face upstream and ignores packages that are pushed directly into Cloudsmith. This ensures reliable traceability, as packages pushed directly to Cloudsmith lack the verified publisher metadata from the Hub.

Blocking Models with Unsafe Files via Security Scans

The concept of a security vulnerability extends beyond traditional CVEs when dealing with LLMs. Models can contain malicious code or file formats. Hugging Face Hub has mitigated this by providing 

Cloudsmith captures this crucial upstream security data and exposes it to EPM. This allows you to write a policy that enforces a zero-tolerance stance on models flagged as unsafe by any of the integrated scanners.

After the policy has been created, associate an 

If a package matches the policy, you can use the decision logs to view the detailed results of the security scan for the package. The 

 will contain the full output of each scanner from Hugging Face.

Hugging Face models and datasets come with 

) for LLMs. It provides essential metadata about the model’s intended use, limitations, and, critically, its training data provenance. To confirm, Model Cards are metadata created by the publisher of a model itself to provide better documentation and transparency about the characteristics of the model. Cloudsmith is able to parse this information and expose it to EPM so you can write policies with this data.

Model Cards currently come in two forms.
One for 

As an example, Hugging Face publishes a language model called 

 section encoded in YAML that states the model was trained on the dataset 

. Perhaps you wish to block models that use this training set.

Imagine an organisation needs to block any model trained using the 

 dataset due to licensing or compliance concerns. The below 

) type to look for that specific training set reference and quarantines the package if a match is found.

Cloudsmith Blog

7 Key Metrics to Measure Software Supply Chain Security

How Artifact Management Enables S2C2F Maturity

Authenticate to Cloudsmith with your AWS identity

Secure containers by default with Cloudsmith and Docker Hardened Images

Eliminating ambiguity: The case for explicit Docker image paths

Cloudsmith 2025: By the Numbers

7 Key Metrics to Measure Software Supply Chain Security

How Artifact Management Enables S2C2F Maturity

The 8 core principles of S2C2F

Access Control & Permissions for Multi-Format Repositories

Understanding S2C2F: How it strengthens OSS security

What is Software Supply Chain Integrity?

Extend EPM policies to Hugging Face artifacts

Slopsquatting and Typosquatting: How to Detect AI-Hallucinated Malicious Packages

The DevOps Guide to Mitigating Software Supply Chain Risks