If you're running workloads in AWS, you're already managing IAM credentials. Wouldn't it be great if those same credentials could authenticate your services with Cloudsmith without creating, storing, or rotating yet another API key?

. Your AWS workloads can now exchange their IAM identity for short-lived Cloudsmith tokens on the fly. No long-lived secrets sitting in environment variables. No API keys to rotate. Just cryptographically signed, time-limited credentials.

, which can now issue signed JSON Web Tokens (JWTs) that external services like Cloudsmith can verify and trust. Here's the flow:

Your AWS workload calls STS and asks for an OIDC token, specifying Cloudsmith as the intended audience

STS returns a cryptographically signed JWT containing your AWS identity information

You pass this token to Cloudsmith's OIDC endpoint

Cloudsmith fetches AWS's public verification keys and validates the token's signature

If everything checks out, Cloudsmith hands back a short-lived JWT you can use for API calls

You're authenticated, no API key required

There are three pieces to configure: AWS permissions, AWS external identity federation, and Cloudsmith OIDC settings. Let's walk through each.

Your AWS role or user needs permission to call the 

 API. Add this policy to any IAM principal that needs to authenticate with Cloudsmith:

Enable Outbound Identity Federation in AWS

Before your account can issue these external identity tokens, you need to flip the switch. Head to the 

, and enable outbound identity federation.

Once enabled, AWS generates a unique issuer URL for your account. This URL hosts the OIDC discovery endpoints that external services use to verify your tokens. It looks something like 

. Keep this URL handy since you'll need it for the Cloudsmith configuration.

 which allowed Cloudsmith to fetch the required metadata to verify received tokens.

Now tell Cloudsmith to trust tokens from your AWS account. Navigate to your Cloudsmith organization settings at 

Settings > Authentication > OpenID Connect

With everything configured, here's how to actually authenticate from your AWS workloads.

 must match what you configured in Cloudsmith's required claims. We used 

Now swap that AWS token for Cloudsmith credentials:

 with your Cloudsmith service account slug, and 

 with your Cloudsmith organization identifier.

If everything's configured correctly, you'll see something like:

aws-pipeline

This pattern works anywhere you have an AWS IAM identity. The short-lived nature of both tokens keeps things secure, and you're leveraging identity you're already managing.

 can use their instance profile to request OIDC tokens. Add the token exchange to your startup scripts or application initialization.

 work the same way through task roles. Grab a token during container startup or lazily when you first need Cloudsmith access.

 can request tokens during cold start or on-demand within your function code. The overhead is minimal because both API calls are quick.

CodeBuild, CodePipeline, and other AWS services

 with an IAM role attached can participate. Build pipelines become much cleaner without injected API key secrets.

AWS outbound identity federation combined with Cloudsmith's OIDC support is a clean solution for a common problem. You're extending trust from identity you already manage, exchanging it for short-lived credentials exactly when you need them, and eliminating the operational overhead of API key management.

No more secrets in environment variables. No more key rotation schedules. No more "who has access to that API key?" conversations.

AWS outbound identity federation documentation

Authenticate to Cloudsmith with your AWS identity

The danger of implicit naming in container security

At Cloudsmith, we believe in building a secure, transparent, and reliable software supply chain. When teams migrate their container workflow to a private, unified registry like Cloudsmith, one subtle habit often carries over from the days of exclusively using Docker Hub: implicit image path naming.

Relying on implicit names is dangerous because it introduces ambiguity, undermines security, and can lead to unexpected build failures.

This article explores what implicit naming is, why it's a risk, and why you should adopt a policy of using fully-qualified domain names (FQDNs) for every single container image reference.

Implicit vs. Explicit: build with confidence

Whether you are building a new image or deploying an existing one, you need absolute confidence that you are requesting the correct source from the correct registry, repository, and base image, with the right dependencies, and without any unverified or malicious components. Trust in your pipeline means knowing every artifact comes from a verified source, every dependency is accounted for, and nothing has been silently altered along the way. Without that assurance, you’re not just building software – you’re building in potential vulnerabilities.

When you interact with a Docker image using the standard Docker CLI, the client makes an assumption if you omit the registry namespace. This assumption is known as an implicit path.

The Docker client automatically prefixes the image name with the default registry and library namespace, which is 

The explicit standard (The Cloudsmith way)

The explicit approach requires you to specify the 

 of the registry as a prefix. This removes all ambiguity.

When you use Cloudsmith as your private registry, your images must be pulled or pushed using a path that looks like this:

Starting with Kubernetes 1.34, distributions powered by the CRI-O runtime (including OpenShift and 

) enforce precise image name resolution. The rule is simple: Kubernetes no longer pulls container images unless you explicitly define the source.

With Kubernetes 1.34, CRI-O removes the implicit path assumption. To ensure deterministic builds and deployments, every image reference must now include its fully qualified registry path. Without it, the pull request is rejected, and the deployment fails.

This shift validates a long-argued point by security experts: ambiguity is a vulnerability.

The critical risks of relying on implicit paths

Why is this subtle difference a massive liability in a software supply chain?

Risk 1: Supply chain confusion and hijacking

In complex build scripts, Dockerfiles, or Kubernetes manifests, it’s easy to mix explicit and implicit references.

 You push your application image to Cloudsmith using the FQDN (

). However, an internal Dockerfile pulls a base image using an implicit path (

 to come from your private Cloudsmith repo, but the FQDN is missing, the build system will instantly default to Docker Hub and try to pull a public image.

This creates a vulnerability if a bad actor pushes a malicious image with the same name (

) to Docker Hub, hijacking your dependency stream (a technique known as Dependency Confusion or Registry Confusion).

If the implicit image exists on Docker Hub 

 in your private Cloudsmith repository, the behavior of which image your build pulls can become non-deterministic, often depending on local client configuration (like 

In one environment, the local client might be configured to prioritize Cloudsmith, pulling your private image. In another CI/CD environment, the client might default to Docker Hub, causing:

 If the image is private on Docker Hub and the environment isn't logged in.

 Pulling the wrong, possibly outdated, public image.

Using implicit paths throughout your build scripts fundamentally locks you into the Docker Hub default. If the Docker client changes its implicit behavior or if network rules block access to Docker Hub, your builds will instantly break.

A fully-qualified path, like one pointing to your Cloudsmith repository, is 

The best practice: adopting the FQDN standard

To maintain the highest level of security, clarity, and reliability in your supply chain, we strongly recommend adopting a strict policy:

Every single image reference, whether it’s a base image in a 

, a deployment manifest in Kubernetes, or a call in a CI/CD script, must include the registry FQDN.

Cloudsmith tip: streamline your base images

To make this explicit policy easier to enforce for common base images (like 

) those images into a dedicated, private Cloudsmith repository

This allows you to control the exact version, scan it for vulnerabilities, and use a consistent, explicit path for all base images:

By making all paths explicit, you transform your dependency graph from a set of ambiguous references into a predictable, auditable, and secure supply chain.

Implicit path naming is a relic of simpler times. In today's landscape of container security and supply chain complexity, ambiguity is a vulnerability. By adopting the standard of always using fully-qualified domain names (FQDNs), you make your builds robust, auditable, and resilient to dependency confusion attacks.

Ready to secure your container supply chain and enforce clarity? 

 and start managing every package with the confidence of an explicit, reliable path.

Eliminating ambiguity: The case for explicit Docker image paths

Software supply chain attacks aren’t theoretical anymore–they’re operational risks.

 Because organizations rely on open source and third-party components, maintaining 

 is a fundamental security requirement. But how do you secure the thousands of external components flowing into your development environment every day?

That’s exactly why the Secure Supply Chain Consumption Framework (

 provides a practical, principles‑driven approach to strengthening trust specifically for the 

 of open source software (OSS). Unlike other frameworks that focus on how you 

, explain how they work together, and show how they help organizations consume open source software with confidence.

 Before diving in, we recommend reading our previous post in the series:

Understanding S2C2F: How It Strengthens OSS Security

software supply chain integrity framework

 designed to reduce the risk of consuming malicious or vulnerable open source components. Originally developed by Microsoft and contributed to the OpenSSF, it shifts the focus from "secure coding" to "secure consumption."

The framework is built on a maturity model that helps organizations move from ad-hoc ingestion to a fully governed, secure supply chain.

Why S2C2F matters for supply chain integrity

Instead of vague promises about "security," S2C2F defines clear expectations for how external code enters your ecosystem. The S2C2F security principles focus on:

Reducing the attack surface of external dependencies.

Improving inventory visibility (knowing what you have).

decreasing mean-time-to-remediate (MTTR) when vulnerabilities are found.

The S2C2F framework is organized into eight distinct areas of practice. Individually, they address specific consumption risks; collectively, they create a "defense in depth" strategy for your 

The first and most critical practice is defining 

 open source packages enter your organization. Instead of allowing developers to pull directly from public registries (like npm or PyPI), which exposes you to 

 and "dependency confusion" attacks, S2C2F mandates using a central artifact repository.

 Centralize and cache all external dependencies.

Prevents "left-pad" incidents (deleted packages) and establishes a single control point for policy enforcement.

 This practice focuses on maintaining a complete, accurate record of all third-party artifacts used across your organization. This goes beyond a simple list; it requires generating and managing a 

When the next Log4j happens, you can instantly query 

 they are used. S2C2F emphasizes scanning not just for known vulnerabilities (CVEs), but also for malware, license compliance, and heuristic risk signals.

 Stop bad packages before they reach the build server.

 Reduces technical debt by blocking high-risk components early in the lifecycle.

 Software rot is a security risk. This practice ensures that your organization has a process for keeping dependencies up to date. Outdated packages are the number one vector for exploitation.

 Automate dependency updates (e.g., via bot PRs).

Minimizes the "vulnerability window" that attackers can exploit.

Explicitly define trust boundaries . The "Enforce" practice involves setting policies that automatically reject components that don't meet your security standards (e.g., blocking packages with critical CVEs or unacceptable licenses).

Automated policy gates at the ingestion point.

 Prevents human error and ensures compliance with supply chain integrity principles.

 Every action in the supply chain–from ingestion to deployment–should be logged. This practice ensures that you can trace exactly who brought a package in, when it was scanned, and where it was used.

Enables forensic investigation and proves compliance to auditors.

 For organizations with high security requirements , trusting the binary isn't enough. This practice involves rebuilding open source packages from the source code on your own trusted infrastructure to verify that the distributed binary matches the source code.

Verify artifact integrity independent of the upstream publisher.

Mitigates sophisticated attacks where the upstream build system is compromised (like SolarWinds).

 Security is a community effort. This practice encourages organizations to fix vulnerabilities they find in open source projects and, critically, contribute those fixes back to the upstream community.

 Strengthens the entire open source security framework and reduces the maintenance burden of carrying private patches.

Taken together, these eight practices provide a structured way to understand, assess, and control risk in complex, dependency‑driven ecosystems.

For organizations that rely heavily on open source, the 

 (Yes, because we have Audit logs and Update paths.)

By addressing these questions directly, S2C2F becomes a practical 

 model, moving you from reactive patching to proactive governance. Using an artifact manager to apply and enforce these practices allows organizations to automate and incorporate security into development pipelines without creating extra work for developers. 

Secure Supply Chain Consumption Framework (S2C2F) is a security framework adopted by the OpenSSF that focuses on securing how organizations consume (ingest) open source software. It outlines eight core practices and four maturity levels to improve supply chain integrity.

2. What is the difference between S2C2F and SLSA?

S2C2F is for consumers (focusing on ingestion, scanning, and inventory of dependencies), while SLSA is for producers (focusing on the build integrity and provenance of the artifacts you create). They are complementary frameworks.

3. Why are S2C2F practices important for open source security?

Because most modern applications are 80-90% open source code, the supply chain is the largest attack surface. S2C2F provides a standardized way to vet and manage this code, preventing attacks like dependency confusion and malicious injection.

Understanding the practices is only one step toward stronger supply chain integrity. Now, it's time to assess your maturity.

Software Supply Chain and Artifact Management Maturity Assessment

 Check if your developers are pulling directly from public repositories, like npm and Maven, or using a secure proxy.

 automates the Ingest, Scan, and Enforce pillars of S2C2F today.

The 8 core principles of S2C2F

Our mission at Cloudsmith is to provide development, DevOps, and platform engineering teams with an incredibly powerful, easy-to-use tool for controlling and securing software artifacts globally. We build features with the enterprise in mind–features that provide centralized management and policy enforcement across hundreds of teams and thousands of developers.

We have an ambitious vision to run the world’s software supply chain more efficiently, more securely, and more intelligently than is possible with the traditional set of tools available in our market.

To that end, we made fantastic progress in 2025 in extending the reach of Cloudsmith to organizations new to enterprise-grade artifact management platforms, as well as organizations upgrading from legacy vendors to meet their internal scalability and security requirements. Let’s review some key milestones we achieved in 2025 with our customers and partners.

A peek behind the curtain into the goings-on at Cloudsmith HQ.

 and many of our existing investors. This investment reflects the confidence our customers place in Cloudsmith to control their mission-critical software build workloads, as well as the hard work from every Cloudsmither. We’re using the funding to build an even better Cloudsmith that can cover more use cases, handle near-infinite scale, and be the fastest and most reliable solution on the market.

We added quite a few Cloudsmithers, increasing our total headcount by 92% in 2025. We’re using all that effort and brainpower to stay on top of the software supply chain security space, so we can help our customers protect their own build pipelines against emerging threats.

A couple of notable honors made their way to Cloudsmith HQ this year:

: Tech Visionary of the Year – Cloudsmith CTO Lee Skillen.

 Leaderboard 2025: Cloudsmith ranked number 59.

Ships are nothing new in Belfast, our home city which has a proud shipbuilding history. That said, at Cloudsmith, we prefer to ship code. Here are a few highlights from the new features and capabilities we launched in 2025:

: Cloudsmith extends artifact management and governance to 

 and datasets, allowing you to control and manage AI artifacts alongside the rest of your software supply chain. ML models flow through the same access controls, policies, scanning, and audit trails as packages and containers, so adopting AI doesn’t introduce new blind spots or require parallel tooling.

 Enables you to define policies as code that match how your pipelines and security rules actually work. Policies can incorporate context such as package metadata, vulnerability severity, and licenses, and enforce those criteria before promoting or using artifacts.

: Automatically checks artifacts for vulnerabilities, malware, and malicious packages on a rolling basis, generating reports hourly. When a new vulnerability is reported against a previously allowed package, EPM triggers a re-evaluation of artifacts against your standing policies and automatically takes actions, such as blocking or quarantining.

Malware scanning and malicious package detection:

 Adds malware and malicious package detection to traditional vulnerability scanning, preventing malicious packages from entering repositories or being distributed. This helps teams avoid pulling in unsafe dependencies from upstream sources and reduces the risk of compromised software spreading through CI/CD pipelines or to customers.

: Enable teams to distribute software to customers or partners in a developer-native way, using the same delivery platform and governance they rely on internally, while presenting it through a branded, customer-facing experience. Customers can restrict, audit, and revoke access without setting up parallel systems or losing visibility–so external delivery doesn’t become a security or operational exception.

: We added new upstreams for four supported formats this year (

), and increased our support for native signing to include 

: When you want to give your eyes a rest, dark mode is at the ready!

We know our customers derive business value from Cloudsmith, because they’re building more software with Cloudsmith.

Total package delivery increased 352% YoY.

The most popular artifact types were Python, npm, NuGet, rpm, Debian, and Maven, which together made up 90% of all artifact requests.

The most consumed formats by size (accounting for 90% of total gigabytes delivered) were Docker, Python, raw, npm, and NuGet.

💡Interesting fact: In total bytes, Docker image deliveries in the first 

 of December 2025 was nearly the same as that for the entire month of January 2025.

npm and Python package delivery requests increased by 400% YoY.

Plays Well With Others: Community, Events, and Integrations

The Cloudsmith platform does a lot of heavy lifting, and it does even more together with our partners. We trotted (a good portion of) the globe and scoured the corners of the internet to deliver a better artifact management experience to developers and organizations alike.

We were active in the developer community in 2025. We sponsored or attended 18 events across North America and Europe, connecting with developers and platform teams in 10 cities at KubeCon + CloudNativeCon, GitHub Universe, PlatformCon, SRECon, and Container Days.

We’re in it for the bright lights and big stages, but some of our favorite moments came from smaller, high-impact community meetups like Kubernetes Community Days in New York and Edinburgh, Cloud Native Dublin, and BSides in our hometown of Belfast.

At every stop, big or small, our goals were to learn from the community, share what we’re building, and help teams ship software with confidence.

It’s worth noting that Cloudsmithers from all over the world also gathered three times this year in our home city of Belfast for all-hands offsites to learn, share, and grow together.

We’re developers building for developers. For us, it’s important to improve the developer experience. We built integrations for developer tools this year to make it easier for users to manage and secure their development pipelines. Here are a few highlights from 2025.

: Allows users to manage experiments run on ML models and collaborate in a centralized location for machine learning test cases.

 integration for better observability and monitoring of how artifacts flow through your software supply chain.

, both public and private Chainguard registries, natively with Cloudsmith.

: Explore and inspect your artifacts from within your 

: Bringing secure artifact management to machine learning development.

From initial conversations, to migrations, to ongoing support, Cloudsmithers provide users with the service and attention they need to make artifact management “just work.” Our customer support satisfaction rose to 

Here’s some of our favorite feedback from customers:

"It's rare these days to see this level of support and engagement when dealing with SaaS support."

"I must say that the support we have received from Cloudsmith has been outstanding."

"I feel it’s important to recognise the Cloudsmith team who have been wonderful throughout the whole process...[they] were patient, fun to talk with (just real-human), knowledgeable, flexible, and truly listened to our needs."

We also published new case studies that demonstrate Cloudsmith’s value, showing how the Cloudsmith experience unfolds from the customer’s point of view.

 shifted focus from infrastructure to managing artifacts securely with Cloudsmith.

 migrated to Cloudsmith and eliminated outages entirely.

consumer and industrial electronics organization

 leveraged Cloudsmith’s Enterprise Policy Manager for better package visibility and governance.

We’re proud of what we helped customers achieve in 2025. And we’re doubling down on our R&D investments in 2026 to deliver an artifact management platform that exceeds anything on the market today.

We want Cloudsmith to be a platform that:

Takes full advantage of our massive-scale, multi-tenant architecture to deliver previously unthinkable performance and scalability to CI/CD pipelines and IDEs no matter where they’re located.

Provides practical solutions for securing the enterprise software supply chain from open source vulnerabilities and malicious packages without hindering productivity.

Works in conjunction with your DevOps stack to deliver a single source of truth for software artifacts, informed by huge public data sets and AI-powered insights.

And we’ll do it all with our ultimate customer–the software developer–foremost in our minds.

Please reach out to me at ceo@cloudsmith.com with your thoughts and suggestions as we seek to build the artifact management platform that the world truly needs. 

Cloudsmith 2025: By the Numbers

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.

Cloudsmith Blog

Securing LLM dependencies against serialisation attacks

Securing AI-generated code with Cloudsmith

From ingredient list to control point: SBOM-based component-level security

Protect your software supply chain from typosquatting with Cloudsmith

How Artifact Management Enables S2C2F Maturity

Secure containers by default with Cloudsmith and Docker Hardened Images

Securing LLM dependencies against serialisation attacks

Top 10 most popular LLM models on Hugging Face

7 Key Metrics to Measure Software Supply Chain Security

Authenticate to Cloudsmith with your AWS identity

Eliminating ambiguity: The case for explicit Docker image paths

The 8 core principles of S2C2F

Cloudsmith 2025: By the Numbers

Access Control & Permissions for Multi-Format Repositories

Understanding S2C2F: How it strengthens OSS security