By submitting this form, you agree to our 

the artifact management market is up for grabs

. In a hot market, you’re going to see some interesting and not-entirely-logical attacks. And if I could creatively paraphrase 

, it’s hard to get someone to understand something when their company’s success depends on them not understanding it.

I’m thinking about a curious criticism that one of our competitors, JFrog, leveled at us in a 

. They said they spotted some “red flags” about Cloudsmith, the first and most damning being that we are “

packaging [a] competitor’s open source as an enterprise solution,

[s]elling a paid ‘security’ solution that’s little more than a thin UI layer over someone else’s open-source tool.

 and the underlying Trivy DB as one source of software package vulnerability data.)

They stick to this point pretty persistently, saying we are “

charging you for an open-source solution,” 

rely on open source software as [our] SCA solution,

“if Trivy becomes unsupported or compromised, Cloudsmith’s entire SCA capability could suffer, leaving users vulnerable.

JFrog has it wrong on several counts here.

For starters, pretty much every enterprise tool in the last few decades, including 

, is built on foundations of open-source software (OSS). Does this mean we’re all “charging” customers for “packaging” OSS as an “enterprise solution” in some nefarious way? Like most OSS, Trivy DB is “generic by nature,” which leaves room for developers and software vendors to build custom capabilities on top of it. Which is exactly what Cloudsmith has done. If Cloudsmith is wrong for using “generic” OSS, then we’re all wrong.

In accusing Cloudsmith of using a “competitor’s” OSS, they’re referring to Aqua Security. They’re confused on several key points.

First, they’re failing to acknowledge the distinction between the role of a primary OSS maintainer and a commercial vendor. Aqua Security, the company, is the primary maintainer of the Trivy OSS project. It is also the vendor behind Aqua Enterprise, a commercial product that is built around Trivy.

Second, they’ve tellingly assumed that Cloudsmith considers Aqua Security to be a competitor. We very much don’t. We regard Aqua as a complementary solution; we support integration between Cloudsmith and Aqua Security; and we see Cloudsmith as the data plane & control plane for software supply chain security, so customers can process metadata and execute policies based on vulnerabilities identified by Cloudsmith’s scanning process, or sourced from third-party vulnerability data from the likes of Aqua Enterprise or others, or a combination.

 software can “become unsupported.” But that actually tends to be a much bigger risk with commercial software than with OSS. Trivy is published under an Apache 2.0 license. Even if the maintainers stop publishing future versions as open source, the community could fork an older version. We don’t think this will happen, but if it does, Cloudsmith relies on multiple data sources, and we can easily change our mix from time to time. There are numerous other providers of data similar to Trivy’s.

So why is JFrog attacking Cloudsmith so stridently for relying on OSS, like virtually every commercial software company does, and specifically for relying on Trivy? I can only speculate, but JFrog sees its own security product, Xray, as an important revenue source, and they seem to regard Aqua Security, along with other similar companies, as competitors to Xray.

To state the obvious point: of course we embrace open source. 

 about Cloudsmith’s support for OSS projects, and we Cloudsmithers all believe deeply in the power of software reuse via OSS. I’m old enough to remember when reuse was essentially an unsolved problem in software; we never could have envisioned back in the 1990s how OSS would fundamentally change that. The core functionality of our platform helps enterprises everywhere to efficiently and securely manage the thousands of OSS artifacts and dependencies that make up such a large part of any company’s software supply chain.

And to state another obvious point: we’re not just serving up generic OSS and then somehow convincing customers to pay us for it. It’s what Cloudsmith has built on top of OSS that we’re really charging for. Things like our unmatched global cloud-scale infrastructure, our 24x7 service levels, our policy-as-code enterprise policy manager (EPM) that evaluates every package using your company’s risk criteria, our ability to proxy and cache public upstream registries at unmatched performance levels, our artifact synchronization process that performs scanning and metadata enrichment before a package even hits your repository and gets served to CI/CD pipelines or developer IDEs, our stellar customer support, and much more.

Yes, we rely on OSS, and we think that’s a significant strength from which customers benefit.


Glenn Weinstein

Of Course We Embrace Open Source!

Researchers at Trend Micro have uncovered a critical unauthenticated remote code execution (RCE) vulnerability [

. Langflow is a Python-based visual framework for building AI applications and boasts over 70,000 stars on GitHub and over 21,000 global weekly downloads from the public PyPI upstream.

Versions released before 1.3.0 contain a serious flaw in the code validation logic, which allows arbitrary code execution. Unauthenticated attackers can exploit this vulnerability by sending specially crafted POST requests to the 

Malicious payloads were found embedded within argument defaults and decorators of Python function definitions. Because Langflow lacks proper input validation and sandboxing in its code evaluation process, these payloads are compiled and executed directly within the server’s context, which results in full remote code execution.

On May 5, 2025, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2025-3248 to its 

 (KEV) catalog, indicating confirmed exploitation in the wild.

How to Quarantine Affected Langflow Packages using Cloudsmith EPM

 (EPM) is an OPA-based engine which enables quarantining of high-risk packages before developers create a dependency on them, and before they reach production environments. The Gist below includes a generic 

. This policy will detect vulnerable versions of Langflow, which have a 

Langflow includes numerous dependencies (such as 

) which can significantly increase download times due to dependency resolution. For the purpose of this demo, we only need the raw package for scanning, so I used the -

 flag to avoid downloading unnecessary dependencies.

The package was pushed to Cloudsmith with a custom tag referencing 

. Note that it was synchronized and automatically quarantined based on the EPM policy we put in place.

In the Cloudsmith UI, you can see that the 

 (containing the known vulnerability) was successfully quarantined right after it synced. Alongside the automatically generated SBOM, the package also has an additional 

 tag applied by the EPM policy, indicating that it was quarantined due to a security policy violation.

By clicking into the identified vulnerability in the Cloudsmith UI, we can confirm that it correctly maps to CVE-2025-3248: a code injection flaw exploitable via the 

If you’re already using centralized artifact management, then you’ll already know that versions of Langchain prior to 1.3.0 are vulnerable and therefore should not be used. According to Trend Micro, the attackers in this scenario likely initiated the attack by first gathering a list of IP

 addresses and ports of publicly exposed Langflow servers, potentially using tools like 

 to detect publicly exposed Langflow servers by targeting typical indicators in configuration files, environment files, and code snippets. Langflow is typically launch

ed via FastAPI and Gradio, often bound to a public IP like 0.0.0.0 with a known port like 7860 or 8501.

This should return public Github configurations for Langflow or related servers listening on public interfaces and also Gradio apps being served publicly (which is fairly common in Langflow setups).

 to gain remote shell access to vulnerable systems. Once inside, they run various bash commands to gather system information and send the results to a command-and-control (C2) server.

Next, the attacker installs and runs the Flodrix Botnet on the compromised system. After connecting to the C2 server, the botnet can receive commands over TCP to launch distributed denial-of-service (DDoS) attacks. If the malware doesn’t receive the correct input, it deletes itself.

 endpoint, which is meant to validate Python code. This endpoint lacks proper authentication and executes user-submitted code using Python's 

, compile(), and exec() functions. Attackers can craft malicious code that gets executed on the server when submitted, allowing them to remotely execute code without needing to log in.

CVE-2025-3248 highlights the power of auditing and securing everything that comes from public upstreams. When you use 

, Cloudsmith fetches and caches open source packages (e.g. most dependencies), while you can also upload and use the packages you own to your artifact management repository. This is how customers use Cloudsmith as a first-class cache and a central source of truth for packages, to insulate their development teams from issues that would arise by downloading directly from public indexes like PyPI.

Nigel Douglas

Head of Developer Relations

CVE-2025-3248: Serious vulnerability found in popular Python AI package

Pulling Docker images from private registries for containerised applications presents a security challenge. It requires authentication management, network access, and trust across distributed systems. Credentials must be securely handled and rotated, and image pulls can break due to network restrictions or expired tokens. All of this makes deployment and security harder.

To address this, you can use OpenID Connect (OIDC) when pulling Docker images from Cloudsmith into Kubernetes. OIDC adds a layer to OAuth 2.0 that identifies who is making the request. Cloudsmith can then verify that the requests come from a trusted source and can grant short-lived access tokens. So you no longer have to rely on long-lived credentials, enhancing security and simplifying credential management.

Kubernetes clusters often need to pull Docker images from private registries like Cloudsmith. Traditionally, this meant storing long-lived credentials in the cluster, which has some security risks:

Credentials could be compromised if the cluster is breached.

Regular rotation of credentials becomes a manual, error-prone process.

It's hard to apply the principle of least privilege effectively.

Before we dive into the solution, let's review what an Image Pull Secret is in Kubernetes.

An Image Pull Secret is a way to pass credentials to the kubelet to authenticate with a private container registry. Typically, the secret contains:

While Image Pull Secrets solves the immediate authentication problem, using them with long-lived credentials still exposes us to the security risks mentioned earlier. The credentials don’t automatically expire, leaving them vulnerable to misuse if leaked or unrotated.

OpenID Connect (OIDC) allows us to use short-lived tokens instead of long-lived credentials, reducing risk exposure. Here's how it works in the context of Kubernetes and Cloudsmith:

Kubernetes has its own identity in the form of a service account. The service account has an associated JWT (JSON Web Token). During runtime, the following steps are taken:

Kubernetes issues the signed OIDC token (a JWT).

Cloudsmith receives and verifies the JWT and exchanges it for a short-lived Cloudsmith token.

Kubernetes uses the short-lived Cloudsmith token to create or update an Image Pull Secret.

At runtime, the pod requests to pull an image.

Kubernetes pulls an image from Cloudsmith using the Image Pull Secret for authentication.

To automate the process, we use a Kubernetes CronJob. This job runs at regular intervals and performs the following tasks:

Retrieves the Kubernetes service account token.

Exchange service account token for a Cloudsmith token via OIDC.

Create or update an Image Pull Secret with the new Cloudsmith token.

Here's an example of what this CronJob might look like:

2. Gets the Kubernetes service account token.

4. Creates or updates an Image Pull Secret named cloudsmith-pull-secret.

Implementing this OIDC-based solution offers significant benefits:

: The CronJob ensures the token is regularly refreshed, maintaining a good security posture without manual intervention.

: There's no need to manually update credentials, reducing operational overhead.

: The token only has the permissions it needs for a limited time, aligning with security best practices.

Once the Image Pull Secret is created or updated by the CronJob, you can use it in your pod specifications like this:

This pod will use the cloudsmith-pull-secret to authenticate with Cloudsmith and pull the specified image.

Using OIDC to pull Docker images from Cloudsmith into Kubernetes eliminates the need for long-lived credentials. It reduces the risk of leaked credentials, removes the need for manual credential rotation, and aligns with current security best practices.

Authentication in Kubernetes is evolving with significant recent enhancements. Kubernetes v1.20 saw the introduction of 

. These allow the kubelet to dynamically request credentials for a container registry instead of storing static credentials on disk. This was enhanced in v1.33 to support automatic use of the service account token for image pulls. This enables short-lived authentication without needing to manage Image Pull Secrets and reduces complexity. Cloudsmith remains vigilant, and these updates help with our goal of increasing automation in supply chain security.

Ian Taylor

Tech Content Director

Ian Duffy

Site Reliability Engineer

Secure Docker Image Pulls from Cloudsmith to Kubernetes using OIDC

Yet another supply chain attack has surfaced, this time using the xrpl library to sneak through malicious packages. 

 is recognised as the recommended npm library for integrating the 

 with JavaScript/TypeScript applications, and has over 140k downloads a week.

Our security team quickly responded to this threat and found that no Cloudsmith customers are currently using any of the affected versions.

The attack strategy was to introduce five suspect versions of the library, masquerading as genuine releases. They inserted a crypto-stealing backdoor by adding malicious code that could leak private keys and silently sign fraudulent transactions.

npmjs have recently released version 4.2.5, which overrides the compromised versions.

 can get a full and detailed description of the attack from Charlie Eriksen at 

XRP supply chain attack: Official NPM package infected with crypto stealing backdoor.

The vulnerability is logged with the CVE Dictionary Entry of 

XRPL Dependencies - A Critical Security Risk

The XRPL is a Layer 1 blockchain built for payments and asset transfers. Layer 1 blockchain is the foundational infrastructure of a blockchain. This is where core functions are handled, such as validating transactions, securing the network, and ensuring consensus around transactions and ownership.

The XRPL is used by financial institutions, fintech companies, developers, and startups, mostly for payments, asset tokenization, and building lightweight financial applications.

A supply chain attack on a package integrating with the XRPL can have serious implications. It could expose private keys, hijack transactions, or leak sensitive data, without compromising the ledger itself. If xrpl.js is compromised, any apps using it could unknowingly sign malicious transactions or leak user information, which could result in stolen funds. XRPL dependencies are critical to security.

Any security features can and should be tested against real-world threats. Cloudsmith’s Enterprise Policy Management (EPM) includes policy-as-code, meaning custom policies can be written against precise requirements to block known exploits.

For the xrpl.js attack, we know the bogus versions, so it’s easy to write Rego code that checks your repository against the known versions. Cloudsmith can then quarantine the packages if there’s a match against npm packages named xrpl:

 information on setting up and configuring policy code, see 

Enterprise Policy Management Example: Quarantine Packages Using Policy as Code

smith and see how it can stop supply chain attacks.

XRPL Supply Chain Attack and How to Block it Using Cloudsmith’s Enterprise Policy Management

Enterprise Policy Management (EPM) is a programmable policy-as-code layer that controls the security, compliance, and flow of artifacts across the software supply chain. Teams can codify rules once and apply them continuously across repositories. With Cloudsmith’s platform, organizations extend policy enforcement across teams, environments, and geographies without introducing friction, including the open source packages that the chain depends on.

Our EPM solution is powered by data at every stage. The policy engine has access to all available package metadata to inform decisions. Every policy action is recorded with full context, providing detailed logs for customers to support audits and investigations. EPM includes compliance dashboards, that surface insights in security, compliance, and policy activity. This gives you continuous oversight and helps you refine your approach.

This article provides an overview of EPM and how it strengthens the software supply chain. For a worked example using policy as code, see 

We built EPM because governance should not slow you down; it should accelerate trust. Threats to your software supply chain are evolving faster than human oversight can track, and automation is the only viable path to resilience. EPM puts policy enforcement early in the development process. It makes decisions transparent and implements your security and compliance posture into something repeatable, testable, and version-controlled, like the rest of your codebase. Developers get immediate insight to help select packages. They know which meet policy standards for security, licensing, and quality.

Policies are codified rules that automate decisions and enforce rules on which packages are allowed in your software supply chain. They provide guardrails that ensure security, compliance, and operational consistency. Policies can block vulnerable packages, restrict problematic licenses, and control access.

For example, an enterprise may add a policy that stops packages with high-risk vulnerabilities from reaching production environments. The policy would be prescribed by logic as follows:

Define logic that evaluates vulnerability criteria and applies a quarantine action to affected packages.

The criteria specifies that the vulnerability must be listed in the Common Vulnerabilities and Exposures (CVE) database.

The policy then checks if the vulnerability exceeds a defined 

If conditions are met, the package can either be quarantined and blocked from promotion to production or tagged with additional context for further forensics.

This previous example is a vulnerability policy and is one of the types Cloudsmith EPM supports:

 prevent non-compliant code from being used.

 automate tagging, quarantining, or deleting based on metadata.

Without strong policy management, teams face increased risk and unnecessary effort:

- Missing automation allows known CVEs or malicious packages to reach production.

 - Teams must scramble for audits instead of demonstrating continuous compliance.

- Engineers spend hours reviewing dependencies or waiting for late-stage approvals.

Without shared policies, standards vary across teams and environments.

Without codified policies, organizations cannot fully benefit from the scale and speed of the cloud.

Catching vulnerabilities early in the software delivery lifecycle reduces both the financial cost of remediation and the risk of reputational damage.

EPM was built to avoid these issues in response to real-world supply chain threats and close collaboration with our customers. Codification and automation provide a unified approach for teams to enforce decisions that were previously enforced manually and inconsistently, proving less robust or scalable.

In an automated delivery environment, policies are essential for reducing manual overhead, preventing costly mistakes, and proving compliance, and have particular relevance within the organization:

-For CISOs, policies are the cornerstone of a secure software supply chain. They enable proactive threat mitigation, enforce compliance with frameworks like SLSA and SC2CF, and provide the audit trails required for regulatory confidence. Cloudsmith’s EPM lets CISOs shift from just enforcing checklists to actively collaborating with engineering teams by using the same tools. Implementing automated policies makes it easier for the engineering team to build securely.

- CTOs are focused on enabling product velocity without compromising architectural integrity. Effective policy management acts as a safeguard for CTOs, giving them confidence to move fast with greater safety, supporting both innovation and security goals. With EPM, they can align engineering output with business goals, ensure consistent implementation of best practices, and reduce the operational burden of manual reviews.

Teams immediately benefit by switching from public repositories to Cloudsmith as a curated repository for their developers. Policies then provide clarity, speed, and safety for engineering teams. Instead of guessing what is allowed, developers get immediate feedback when a package or dependency violates a rule. Our EPM integrates policy checks directly into the artifact pipeline, shifting decision-making left and reducing the noise and frustration caused by late-stage security reviews. 

EPM: Cloudsmith’s Approach to Policy Management

Maximum Flexibility: Policy-As-Code, Open Policy Agent, and Rego

Cloudsmith builds for developers, and EPM continues that focus by applying code's flexibility and automation to policy management. EPM takes a policy-as-code approach using an engine built on codification to make policies flexible, versioned, testable, and part of the everyday development workflow. It uses repeatable logic and brings security and compliance into the same toolchain engineers already use.

 - Teams write policies in Rego to define clear, actionable rules that operate on artifact metadata, repository structure, and scan data. We chose 

 because it is an established, open-source policy language widely used in infrastructure and platform security. Rego allows teams to write expressive, testable rules and reason over structured data, which aligns with how Cloudsmith models package metadata and security inputs.

 OPA is a general-purpose policy engine that evaluates rules written in Rego. Cloudsmith integrates OPA into its EPM engine to provide a programmable, scalable way to enforce policy across artifacts. Because OPA is already well established in platform tooling like Kubernetes and Terraform, teams can manage policies in a format they know and trust, without switching tools or inventing new processes.

- EPM also offers key features through the Cloudsmith UI. This supports essential policy management controls, letting users operate EPM without the need to dive into policy-as-code.

You can see an example of the Rego code used to implement the policy given in Vulnerability Policy Example above.

Cloudsmith’s policy engine lets you create and automate vulnerability policies to an exact specification. Policies evaluate packages as they arrive and apply structured logic to make decisions based on severity, exploitability, and metadata. We made package data available so you have the information to tailor and align your policies to the datasets that matter most.

The following capabilities form the foundation of Cloudsmith’s approach to automated vulnerability policies:

Vulnerability Management & Dependency Awareness

 - EPM scans artifacts continuously and examines both the dependencies developers choose directly and the ones that come bundled with them. This helps teams understand the full scope of their exposure, especially when vulnerabilities are introduced through nested packages or upstream registries.

 - CVSS scores represent how severe a vulnerability is, while EPSS scores estimate how likely it is to be exploited in the real world. Cloudsmith supports both scoring systems to help teams write policies that prioritize the vulnerabilities that pose the highest risk.
See 

Cloudsmith introduces EPSS Scoring in Enterprise Policy Management

 - Teams can preview how a policy will behave before activating it. This reduces the risk of unintended disruption and helps refine logic before activation. Once a policy is active, EPM logs each decision, making actions traceable and audit-ready.

EPM continues to evolve, and we’re expanding the scope of what policies can evaluate. This includes extending scanning to third-party sources like OpenSSF Scorecards. We’re enriching package metadata with contextual signals, giving policies a broader view to make more accurate decisions.

Legal teams and engineering organizations need to manage license risk at scale. Cloudsmith EPM allows teams to define precise rules about which licenses are permitted, restricted, or prohibited across repositories and environments. Policies can block packages with unknown, copyleft, or non-compliant licenses before they are introduced into critical environments. These rules operate on package metadata and are enforced automatically at sync, ensuring consistent application across teams and projects.

EPM license management includes the following key capabilities:

 - Packages with prohibited licenses are blocked by codifying license rules into policy logic. These policies evaluate license metadata before packages reach environments where risk cannot be tolerated, such as production environments or regulated systems.

 -Policies can reflect both internal legal requirements and external compliance frameworks. Teams can author policies that support organization-specific license strategies while aligning with broader standards such as SPDX or OpenChain.

Manage Internal Remediation SLAs with Time-Based Policies

Time-based policies help teams manage the lifecycle of packages based on changing risk, review cycles, or policy timing. These policies allow organizations to enforce rules that adapt over time, such as delaying access to a package until it has passed a minimum review period or increasing enforcement if a vulnerability remains unaddressed beyond a defined threshold.

EPM’s time-based policy management includes CVE lifecycle enforcement. A policy can allow packages with a known high severity CVE to remain in a non-production repository for a defined period. If no fix is applied during that window, the policy escalates enforcement by blocking promotion, triggering quarantine, or flagging the package for remediation. This gives teams time to assess and respond while maintaining clear accountability and control.

We’re extending policy capabilities to increase support for time-based controls. This includes defining policies that delay promotion, trigger re-evaluation, or expire package access after a specific time window. This will support workflows like phased rollouts, cooling-off periods, or automatic clean-up of outdated packages.

Cloudsmith EPM allows teams to define precise policies in line with their organization’s compliance requirements. These examples reflect common use cases in vulnerability management, license enforcement, and exploitability scoring.

Time and Score Balanced CVE Remediation Policies

Customers can use EPM to build policies that align with their organisation’s internal CVE remediation timelines or industry best practices. Policies could escalate enforcement based on how long a CVE has gone unpatched.

For example, quarantine any package that has a:

CVE with a CVSS score of 9 or more that was reported 7 or more days ago.

CVE with a CVSS score of more than 7 that was reported 30 or more days ago.

CVE with a CVSS score of more than 4 that was reported 60 or more days ago.

Customers can use EPM to control which software licenses are permitted in their environments. Many organizations prevent the use of copyleft licenses because these licenses can require proprietary source code to be made public. Copyleft licenses, such as the GNU General Public License (GPL), impose obligations that conflict with closed development. Teams often prefer permissive licenses such as MIT, Apache, or BSD to minimize legal risk.

Quarantine any package that carries a GNU General Public License (GPL).

Quarantine any GPL-licensed package found in production repositories, with the highest legal exposure.

Customers can strengthen their vulnerability management by using the 

Exploit Prediction Scoring System (EPSS) 

as an additional prioritization tool. EPSS provides a daily probability estimate for the likelihood of a CVE being exploited in the wild. This helps teams move beyond severity alone and focus remediation efforts on the vulnerabilities most likely to be targeted.

Quarantine any package containing a CVE with an EPSS score of 0.2 or more.

EPM: Policy Management for the Vigilant Enterprise

Software governance is an operational necessity. Cloudsmith EPM provides a programmable layer that helps teams codify their organization's vision for secure and compliant software and then enforces those standards automatically.

By aligning security, legal, and engineering teams around shared, automated rules, EPM removes friction and gives control, making governance part of the pipeline.

To discover how EPM can solve your policy management needs, 

Enterprise Policy Management with Cloudsmith

: KubeCon London 2025 (KubeCon EU) showed a cloud-native ecosystem shifting from fragmentation to unification of policy, security, observability, and artifact management. Wasm is moving from hype to real-world use, OPA is expanding into FinOps, and signing everything (with SBOMs, attestations, and metadata) is becoming standard. Artifact registries are evolving fast, becoming unified platforms for governance, provenance, and automation across the software supply chain.

There’s something unmistakably electric about being at KubeCon in person. Maybe it’s the hallway chats, the animated late-night debates (helped along by the thump of House of Kube), or the shared momentum in the air – this year felt like a shift in the literal sense. Cloud-native isn’t just evolving; it’s maturing, solidifying, and meeting the pace of a world increasingly hungry for scale and simplicity.

, held at ExCeL London from April 1 to 4, brought together thousands of practitioners to explore the state of Kubernetes and the cloud-native stack. Several clear themes emerged across keynotes, breakout sessions, and late-night conversations.

 and cost optimization, and the ongoing reinvention of 

. Below, we’ve curated the significant highlights, with talk titles, speakers, and links to recordings and resources, plus our take on what they mean for the road ahead.

The conference vibe was exuberant and technically charged. CNCF celebrated its tenth anniversary of Kubernetes with a look forward: how to keep bridging cloud-native innovation with real-world production needs. The 

 introduced a fun twist on professional development: the 

 designation (and yes, now we want them too, at Cloudsmith).

This new CNCF program recognizes attendees completing 

all 13 CNCF certifications plus the LFCS Linux admin exam

, showcasing their cloud-native mastery. If you saw folks wearing unique Kubestronaut beanies or jackets, now you know why. The challenging economic climate also underscored a focus on 

: many hallway conversations compared notes on balancing cloud costs and complexity with on-prem solutions, highlighting that sometimes on-prem isn’t worth the trade-offs in agility.

 ~12,000+ attendees, 229 sessions, and countless community meetups and parties (don’t worry, the famous 

 party returned for those who could snag an invite, sponsored again, of course, by Cloudsmith, along with our friends at Humanitec, Tailscale, Sysdig, and Chainguard). Read on for our curated highlights of sessions relevant; we’ve organized the recap into thematic sections for easy scanning.

The Rise of Wasm in Cloud‑Native Applications

: Wasm is no longer experimental — it’s powering plugins, policy engines, and serverless runtimes in real deployments. Tools like wasmCloud and Spin are leading the way.

 emerged as a star of the show, signaling that 2025 is the year Wasm goes from promise to production in cloud-native systems. A standout session was 

"Was I Right or Wasm I Wrong? A Review of the Wasm Ecosystem”

Cloudsmith Blog

Of Course We Embrace Open Source!

CVE-2025-3248: Serious vulnerability found in popular Python AI package

Secure Docker Image Pulls from Cloudsmith to Kubernetes using OIDC

XRPL Supply Chain Attack and How to Block it Using Cloudsmith’s Enterprise Policy Management

Enterprise Policy Management with Cloudsmith

KubeCon London 2025 Recap: Cloud-Native Insights on Security, Wasm, and More

Fortify Dependency Management With Cloudsmith + Dependabot

How to Audit Your Software Supply Chain Security

Take control of user management with Cloudsmith's new SCIM capabilities

Cloudsmith's Enhanced Security with Policy Management

How to Manage Your Vulnerability Workflows with Cloudsmith

Cloudsmith Supports OpenSSF's Efforts to Secure OSS