GitHub Universe 2026 takes place October 28–29, 2026, at Fort Mason Center in San Francisco, CA. Doors open at 7:30 AM on day one, with the opening keynote at 9:00 AM. The closing keynote starts at 2:00 PM on October 29. A separate Day of Learning runs at GitHub HQ on October 30 and needs its own ticket.

When and where is GitHub Universe 2026?

Yes. The virtual pass is free and includes the streamed keynotes, virtual-only content and access to session recordings once they're available. In-person passes are $1,399, with 20% off for groups of four or more.

Can I attend GitHub Universe 2026 virtually?

Cloudsmith is a Gold sponsor in the Festival Pavilion during expo hours on October 28 and 29. Look for the Cloudsmith coffee cart. On October 28 from 6:00 to 9:00 PM, join us at San Francisco Brewing Company for DevOps on Draft: A Universe Git-Together.

Where can I find Cloudsmith at GitHub Universe 2026?

Frequently asked questions (FAQs)

The 10 GitHub Universe 2026 sessions we recommend for platform, DevOps, and security teams cover software supply chain security for npm and GitHub Actions, guardrails for AI agents, agentic workflows at scale, and enterprise AI adoption. GitHub Universe 2026 runs October 28–29 at Fort Mason Center in San Francisco, with a free virtual pass for online attendees.

GitHub Universe 2026 at a glance: dates, location, and agenda tips

More than 6,000 developers, platform engineers, and security leaders are heading to Fort Mason Center for GitHub Universe 2026. This year's theme is the agentic era, and the big question isn't whether to bring AI into the software development lifecycle. It's how to do it at scale, with trust built in from the first commit.

With 100+ sessions across two days, there are a lot of options. We've picked the 10 talks we think platform, DevOps, and security teams will get the most from. Cloudsmith will be in the Festival Pavilion all week, so come and find us between sessions.

📍 Fort Mason Center, San Francisco, CA

👋 Festival Pavilion (look for the Cloudsmith coffee cart)

1. What happens behind the scenes when you run npm install

Wednesday, Oct 28 | 4:30 PM - 5:10 PM PDT

Most people run npm install dozens of times a day without a second thought. Karen Li and Leo Balter from GitHub will trace those dependencies back through the people, permissions and release processes that publish and protect them. Expect a clear look at what npm audit can't catch, and where package provenance and OpenID Connect (OIDC) fit in.

This is our top pick because software is assembled more than it's authored, and every install is a trust decision. Knowing how a package reaches your build is the first step to governing it. If you leave this talk wanting to control what enters your environment before it arrives, come and see us in the Festival Pavilion.

2. Disrupting supply chain attacks: A threat framework for GitHub Actions

Wednesday, Oct 28 | 2:30 PM - 3:00 PM PDT

A workflow with access to credentials and the power to publish a release is a high-value target for attackers. Steve Glass and Greg Ose will map known supply chain attack techniques to the GitHub Actions controls that stop them, across three layers: the Actions ecosystem, the workflow attack surface, and runner infrastructure.

For platform teams, this is a practical framework for deciding where defenses belong in a pipeline you'd trust with a release. Incidents like tj-actions showed why the build pipeline is a critical control point. This session moves the conversation from what went wrong to what good looks like.

3. Open pull requests, don't merge them: Fine-grained authorization for hosted MCP servers

Thursday, Oct 29 | 10:30 AM - 10:45 AM PDT

Hosted MCP servers often enable agents to do everything a human can do. Nick Taylor will demo an identity-aware proxy that adds per-identity authorization in front of any hosted MCP server, with no upstream changes. The live demo shows Copilot opening a pull request and leaving the merge to a human reviewer.

We love this session because it treats guardrails as infrastructure, not an instructions file the agent might ignore. The same principle applies to dependencies. Agents move fast, so the controls around them need to be machine-enforceable and in place before the agent acts.

4. From writing code to managing agents: Scaling 50+ services at GitHub

GitHub's Lifecycle team swapped hand-coded fixes across 50+ services for an agentic pipeline. AI agents classify issues, research codebases, write implementation plans, and open draft pull requests. Anjuan Simmons will share the real numbers, how the team built it with GitHub Actions and Copilot, and why engineers still write some code by hand on purpose.

This is a look at agents running in production at platform scale. For engineering leaders weighing the same move, it's a grounded blueprint for where automation pays off and where humans stay in the loop.

5. Treat your AI context as infrastructure

 Platform engineering, developer experience

Having the right context is critical for getting your agents to generate useful output. In this session, Christopher Harrison will break down what custom agents, agent skills, instructions files, MCP servers, extensions, and plugins each do best, and how to choose between them for real use cases. He’ll discuss strategies for how to distribute the right context consistently across a team as your setup grows.

Platform engineers already know this story. Anything that works for one developer but can't be versioned, shared, and governed becomes sprawl. This session applies golden path thinking to AI context, and it's a natural fit for teams looking to build those paths for their developers.

6. Beyond pass or fail: How agents verify AI-generated code

The tests passed, so why is the app still broken? Jeff An will show how agents investigate applications, reproduce unexpected behavior, and tell real product bugs apart from flaky tests or infrastructure failures. He'll also cover the deterministic controls that limit what those agents can do while they investigate.

As AI writes more of our code, verification becomes the bottleneck. This talk looks at earning the trust that speed requires, with clear boundaries on what agents are allowed to touch.

7. The 2 a.m. RCA agent: Architecting AI that investigates, not hallucinates

Anyone who has had to spend hours late at night researching root cause analysis (RCA) will want to attend this one. Achin Gupta and Divya Mahajan will present a RCA architecture where deterministic code handles signal collection, topology traversal, correlation, and scoring. The language model only narrates evidence it didn’t have to collect.

The result is a clean split of responsibilities where the machine-enforceable parts stay deterministic, and the model adds clarity where needed. SREs and platform teams will leave with a design they can borrow.

Wednesday, Oct 28 | 11:30 AM - 12:10 PM PDT

Getting developers to try Copilot is the easy part. Getting them fluent – using agents to plan, write, and ship real work – is harder. Jared Hatfield will share how UPS moves developers from awareness to fluency, why motivation and measurement matter as much as tooling, and where to focus first at enterprise scale.

For VPs of Engineering and platform leads rolling out AI across large organizations, this is a candid view from a team doing it today. Adoption at this scale also means more packages, pulled faster, by more people and agents. It's worth planning the controls alongside the rollout.

9. Code is the easy part: Building Home Assistant in the open

Wednesday, Oct 28 | 2:10 PM - 2:25 PM PDT

Home Assistant builds everything in the open, from ideas and UX to architecture and the roadmap itself, across 20,000 contributors and a dozen GitHub organizations. Franck Nijhof will show how the Open Home Foundation runs its whole roadmap through issues, projects, and discussions, including being wrong in public and fixing it in public.

Open source is the foundation for every modern software supply chain. This session is a great reminder of the people and process behind the packages we all depend on, and what it takes to run a healthy project at scale.

10. The view from the labs: What's next for AI-assisted development

 Cara Phillips, Anthropic; Rohan Varma, OpenAI; Kate Catlin, GitHub

To close out our list, an interactive panel with leaders from the labs that power GitHub Copilot. Cara Phillips, Rohan Varma, and Kate Catlin will take a candid look at the next two years of AI-assisted development, and what it means for the people building software.

AI changes the laws of physics for how fast teams can move. Hearing where model capabilities are going next will help platform and security teams plan the guardrails that let developers and agents keep that pace.

Between sessions, come and say hello. Cloudsmith is a Gold sponsor at GitHub Universe 2026, and you'll find us in the Festival Pavilion throughout expo hours on October 28 and 29.

 Grab a drink from the Cloudsmith coffee cart and refuel before your next session.

 Watch how Cloudsmith acts as the control layer for your software supply chain. Govern every package, container, and ML model that enters your environment, enforce policy-as-code at first pull, and publish straight from GitHub Actions with OIDC (no long-lived API keys).

 Bring your questions about AI coding tools, dependency governance, or moving off a self-hosted artifact server. Our engineers are happy to dig in.

Join us for DevOps on Draft: A Universe Git-Together

Wrap up day one with us. On Wednesday, October 28, from 6:00 to 9:00 PM, Cloudsmith is hosting a happy hour at San Francisco Brewing Company, co-sponsored by Tailscale, Eficode, Octopus Deploy, and Chainguard. Expect good beer, good company, and plenty of conversation about what everyone saw that day. Spaces are limited, so 

AI is changing how fast teams build software, and that's exciting. We'll see you in San Francisco to talk about keeping that speed with clarity, control and confidence.

10 GitHub Universe 2026 sessions not to miss

Attackers only need one weak point in your supply chain to disrupt your builds, so security teams have to take precautions against every threat and advisory that comes out. Most teams no longer ask whether a software supply chain attack will affect them. They ask whether the right controls are already in place when it does.

Artifact management is the one layer every package passes through

Proactive defensive measures give teams the best opportunity to neutralize supply chain attacks before they strike, or to catch them early, before they can do significant damage. The artifact registry is the ideal location to enforce security policy because it provides a control point at ingestion for incoming packages. Because every stage of the development process pulls packages from the same artifact registry, policy decisions made at ingestion apply to developer workstations, CI builds, and production deployments.

A package cleared at ingestion enters downstream stages already vetted against your policies. A package blocked at ingestion never enters the build environment in the first place.

The attack model evolved but security controls didn’t

Attacks are more sophisticated now, targeting points earlier in the development process. Traditional malware, like ransomware, targeted individual machines and impacted them in an obvious way. Endpoint tools that scan files before execution evolved to combat this attack vector, and much of today’s security stack assumes this attack model as the default.

Supply chain attackers don’t need to target a specific machine. They compromise the actual software supply chain and what bad actors are trying to achieve through these attacks is much less transparent. Oftentimes malware exfiltrates sensitive information so that attackers can compromise additional systems. For example, Shai-Hulud spread by stealing npm, GitHub, and cloud tokens. Other times, the goal is to utilize the resources of a compromised machine for activities like cryptomining. These attacks are subtle by design and can delete evidence of their existence before you realize you’ve been compromised (like the Shai-Hulud variant that hit 

Attackers increasingly gain entry through the open source packages you depend on, and most teams rely on open source software to build the bulk of their applications. When an application uses hundreds or thousands of dependencies, attackers only need to compromise one to gain access.

When installing a package means running it

Beginning in September 2025, Shai-Hulud turned install-time malware into a self-propagating worm. TeamPCP, the group behind the Shai-Hulud attacks, open-sourced the code for the worm in May 2026, which 

gave rise to the Miasma and Hades versions

 and spread this attack type to PyPI, RubyGems, and other open source ecosystems.

These worm attacks rely on code that runs automatically at install time (e.g., npm preinstall / postinstall hooks, and equivalent build hooks in other affected ecosystems), so the malicious payload runs the moment a developer or CI runner installs the package.

Note: npm 12, released in July 2026, turns off install scripts by default. However, this feature only works with upgraded and configured versions of npm, and allowlists can re-enable install scripts. It’s also an ecosystem-specific solution, where a registry-level policy applies to every package that gets pulled in.

At that point, downstream scans of the build output or container image aren’t able to see the compromised package. Further, for newly released packages an advisory may not exist yet for the scanner to evaluate against. The critical point here is that this attack model exposes architectural gaps in security posture, not tooling failures. Scanners remain a critical and useful tool; however, they’re not designed to evaluate install-time code execution. As a result, controlling package ingestion is critical for defending against this type of attack. When installing a package means running its code, choosing a version means granting that code execution rights, so package selection becomes a trust decision.

Beyond malware: vulnerability and license risk

The Shai-Hulud class of attacks garners headlines, but software supply chain challenges exist beyond malware. Different organizations have different tolerances for package vulnerability risk signals, like CVSS severity, EPSS exploit probability, or a listing in CISA’s KEV catalog. Similarly, package licensing can have a significant impact on the legality and economic viability of using certain packages. The last thing teams want to happen is to get to the deploy stage only to find a critical vulnerability, or a license issue. Vetting package properties at the registry prevents issues from impacting downstream workflows.

AI agents multiply the dependencies that no one reviews

AI exacerbates the dependency problem. AI agents work at machine speed and can do so around the clock. These tools generate high volumes of code with more dependencies than humans have the capacity to review. Many of these are transitive dependencies and developers may not have visibility into these package decisions, especially with the increased volume of overall dependencies. This is another facet of package trust that can be dealt with by using the artifact registry as a control point for evaluating these packages at ingestion.

Activating the artifact registry as software supply chain control point

If the artifact registry is the ideal control point for the software supply chain, what does that control actually look like?

 allows you to enforce security policy before problematic packages reach your build environment. Policy enforcement is automatic and can be set once at the Cloudsmith workspace level and applied to every pipeline and developer that pulls from it. You can scope policy at the repo level as well, so any repos that require additional protection or leeway can be set up according to your needs.

The general shape of a dependency firewall includes:

: This one is straightforward. Packages with a known 

: This is a configurable, forced hold on newly released packages. Teams typically opt for 3–7 days, as most malicious packages are identified within days (or hours) of publication. A cooldown policy provides protection during the exposure window between when a package is published and when a threat advisory typically emerges.

: Writing policies around CVSS, EPSS, and KEV data. Every company has different thresholds for what they are willing to use, and that may change across environments (e.g., dev, test, prod). Cloudsmith’s policy management lets you write policy-as-code so you can have granular control over what gets in and what gets blocked.

: Write policies that check license type to protect your software from future licensing issues by limiting the types of licenses your developers can consume from the outset. For example, if you want to block copyleft AGPL licenses in distributed software.

The artifact registry touches the entire software development lifecycle. Traditionally, it was a tool for storing artifacts and packages, but its ability to enforce policy at ingestion makes it the ideal control point for software development. Preventing compromised packages from entering your environment denies attackers the opportunity to inflict damage on your systems. Clearing packages at the registry layer also ensures that downstream workflows and processes, like scanning, have safer inputs.

Every control described above is a policy you can write once and enforce across every repo. Learn more about 

Why enforce supply chain security at the artifact registry 

 was compromised. This package has 18k downloads/week and the attack shares a lot in common with the 

August compromise of the "cacheable" and "keyv" packages

. If anything in your organization installed Tensorlake SDK 

 on or after October 8, 2026, treat the npm, GitHub, and cloud credentials on that machine as compromised, along with any AI coding tool configs. The malicious version ran a credential-stealing worm on install. Here’s how to check whether you’re affected, what to rotate, and how Cloudsmith helps keep versions like this out of your builds.

On October 8, an attacker published version 

 of the Tensorlake SDK, a package with about 18,000 weekly downloads. It contained two files that work together:

 runs through a preinstall hook and launches the payload using Bun.

a "math" file, holds the credential stealer and the worm that spreads it to other packages.

The worm exfiltrates npm and GitHub tokens, cloud credentials, and AI coding tool configuration files. It also establishes persistence, so attackers keep access after you remove the package. One infected install can give an attacker the keys to your pipelines and your AI agents at the same time.

 pointed out that this attack closely resembles the August compromise of the cacheable and keyv packages. Both are npm worms built on the mini Shai-Hulud code TeamPCP open-sourced this spring, and both use the same two-file pattern. There’s no evidence yet that the same group is behind both. The Hacker News reports that the attack shows attackers are now going after the AI tools developers rely on.

Two questions determine your exposure: did you install 

Compare the packages and versions in your lockfiles (

Match on whole package names, not substrings.

 When scripting your own checks, anchor on exact package names. Loose substring matching produces false positives (for example, flagging an unrelated package that merely contains an affected name as a fragment) and wastes triage time.

Check whether preinstall scripts can execute.

 Determine your npm client version and whether lifecycle scripts are enabled in your environments. If you are on npm 12+ with scripts disabled by default, an affected version that was pulled but never executed represents materially lower risk.

 could have run on a developer machine or CI runners, remove it. Then rotate npm tokens, cloud credentials and any secrets reachable from that environment, and review recent publish activity on your own packages.

Check Cloudsmith client and package logs.

 Review your Cloudsmith client logs and the package’s download logs to see whether 

 was requested or pulled. Client logs show which environments attempted to resolve the package. Package logs show whether the version entered your repository cache and which identities or pipelines downloaded it.

 Without a cooldown or malware policy, a developer or pipeline may have pulled 

 into your Cloudsmith cache. Search for it and quarantine any copies.

Old, dormant projects with pinned references are usually low risk, because a locked dependency tree keeps the version it already has. The exposure comes from a fresh install or a lockfile refresh that resolved to 

How Cloudsmith keeps newly published malicious packages out of your builds

Public registries supply most of your dependencies, and they serve the ecosystem well, but pulling from them straight into builds also means a malicious version can reach you minutes after it’s published. Cloudsmith sits between the public registry and your developers and pipelines as one policy-enforced control point. Two popular policies at Cloudsmith are cooldown policies and malicious package policies, which work hand in hand. Cooldowns handle the versions nobody has vetted yet. Malicious package policies take over once a version is known to be malicious.

Many package managers have client-side cooldowns built in, but they can be difficult to manage at scale for enterprises. Cloudsmith enforces the cooldown at the registry, whatever the client version or script settings, by holding back newly published upstream versions for a defined window before they become installable. Attacks like this one depend on speed: a malicious version is published, pulled into builds within minutes or hours, then withdrawn. A cooldown policy keeps those versions away from your teams during the window when they are most dangerous, giving the ecosystem time to flag them.

When the community does flag a version, malicious package policies act on it. Packages flowing through Cloudsmith are scanned for malware and matched against our database of malware advisories. With 

 from Cloudsmith, you can block versions flagged as malicious or matching known indicators. Once a package is identified as compromised, the policy stops it from reaching any consumer behind Cloudsmith, including after the cooldown window ends, and no developer has to update a manual blocklist.

When installs resolve through Cloudsmith, you get one place to enforce controls and one audit trail of what entered your environment. “Were we exposed?” becomes a search of your own records, rather than reconstructing it across every machine and pipeline. Policies only cover traffic that routes through them, so the practical first step is making sure your installs go through Cloudsmith instead of going straight to public registries.

With these controls in place, you can answer the next npm worm with one search of your Cloudsmith records.

Tensorlake SDK npm package compromised

Using long-lived credentials in CI/CD and embedding static API keys in pipeline secrets are security risks. The CI platform authenticates a build job’s identity and context, and using short-lived tokens that expire on their own reduces exposure from a credential leak.

Previous discussions of OIDC covered using it to 

, and to authenticate workloads using your 

For any developer, the common denominator with using these tools is your individual workstation, which likely contains long-lived credentials.

At least one of these files on your local workstation likely contains long-lived API keys:

Each tool has its own login command and config file, which contains a copy of the API key in plain text. It’s the owner’s job to manually rotate these keys.

 npm worm targeted files that contained tokens on developer machines, like 

, and used them to access maintainer accounts and workflows.

You can sign into the Cloudsmith CLI with SAML via your company's identity provider. This creates a short-lived token that expires and rotates frequently. Credential helpers enable package managers like Docker and pnpm to borrow this authentication context from the Cloudsmith CLI, avoiding long-lived API keys being stored on disk.

The result is a short-lived access token, issued from your SAML sign-in. The CLI stores the token in your system keyring, and it expires on its own. The CLI renews it with a refresh token, so you are not sent back to the browser each time it expires. If you run 

 again while your session can still be renewed, the CLI simply renews it.

You now have a short-lived, SAML-backed session. The next step is to share that session with your package managers.

Step 2: Set up Cloudsmith credential helpers

Most package managers already know how to ask an external program for a credential. Docker has 

. Each one is a small, standard hook for a single question: 

"Who can give me a credential for this host?"

The Cloudsmith CLI now answers that question for all of them.

A credential helper does not log you in. It hands your active session to your package manager(s).

When a package manager needs a credential, it calls the helper. The helper asks the CLI for the current access token, and the CLI renews that token if it is close to expiry. Nothing is written into the package manager’s config file.

, not the project file, so the helper config never ends up in source control. If you already have an 

 for the same registry, the installer leaves it alone.

The provider answers only for Cloudsmith registries, doesn’t require 

. For crates.io and anything else, the credential helper steps aside and lets Cargo try the next provider.

Terraform does not tell a credential helper which repository it wants, so the installer writes your Workspace and repository into 

 for you. Terraform allows only one credential helper. If you already have one, the installer tells you and does not overwrite it.

 gives pip and uv a keyring backend that gets its credential from the Cloudsmith CLI:

 in that URL is not a secret. It is the literal username that Cloudsmith expects for token authentication. Your 

 names the repository, but it contains no credential at all.

 prints the current credential as JSON, ready for a wrapper script:

We are working on helpers for more package managers. The goal is to make the API key 

Open an issue on the Cloudsmith CLI GitHub repository

 and let us know which tool you use. Your requests help us decide which helper to build next.

Then use your tools exactly as you do today. One SSO sign-in. One short-lived session. Zero keys in your dotfiles.

OIDC took long-lived credentials out of your pipelines. Credential helpers take them off your laptop. Together, they move every part of your workflow toward short-lived, identity-based access.

OIDC removed long-lived credentials from your pipelines. What about your laptop?

Cloudsmith now supports hosting public and private Nix binary caches. Teams that use Nix and NixOS can point existing 

 workflows at Cloudsmith without any additional tooling.

(Note: Nix format support is currently in Early Access.)

Nix builds work differently from most package ecosystems. Initiating a build in Nix begins with an evaluation of all the inputs that go into the build. This includes source code, dependencies, and build instructions, and each item gets hashed. The evaluation output is a derivation (a 

 file), which is a build recipe that describes what’s in the build. Nix then hashes the derivation to compute the package’s store path. Because downloading a pre-built version is faster than building from source, Nix then asks its substituters (remote binary caches like the default 

) whether that store path already exists. If it does and is signed by a key that Nix trusts, then Nix will download it. If it doesn’t exist, Nix builds it from scratch.

 packages from the public cache, but their own builds require a private binary cache, which is typically self-hosted. Relying on the public cache means accepting availability and bandwidth limits, which may not meet the needs of compliance-focused teams. Self-hosting a private cache with 

 or S3 means patching, scaling, and on-call duty for infrastructure that only serves packages.

 for Nix release channels. You must configure a separate upstream for each channel you want to use.

The first time you request a store path that Cloudsmith doesn’t have, it fetches the package from the configured NixOS channel, caches it, and serves it. Subsequent pulls are served from Cloudsmith’s cache, so builds are fast and keep working during a 

You can also push new Nix builds to a Cloudsmith repo, which then functions as a private Nix binary cache, but without the overhead tax of self-hosting.

Signing and verifying Nix packages in Cloudsmith

Where other ecosystems use package name and version number to identify packages, Nix uses a cryptographic hash to identify and verify them. Cloudsmith signs each package’s 

 with the repository’s ED25519 key on every read, and Nix verifies that signature against trusted keys. Because signing happens on every read rather than once at upload, key rotation takes effect immediately, with no backlog of packages to re-sign, and multiple keys can be active and signing simultaneously.

To get started using Nix with Cloudsmith, you can create a dedicated Nix repository. Add that repo to your Nix 

 list, and the repository’s public key to 

. This configuration means Nix treats Cloudsmith like cache.nixos.org. To proxy a public channel, add that as an upstream to the repo.

For private repos, authenticate with an entitlement token in a 

 file. Push Nix packages you build locally to your Cloudsmith Nix repo using 

 flag because locally built packages are unsigned and Cloudsmith handles signing on read.

For detailed setup instructions, see our 

Cloudsmith allows you to consolidate cached Nix packages in a single, cloud-native environment with multi-format repositories. Teams no longer rely on public cache availability, or pay the operational tax of self-hosting. Upstreams cache public channel packages in Cloudsmith for fast, reliable pulls.

Nix packages often sit outside the access controls and audit logging that cover the rest of your software supply chain. Bringing Nix into a Cloudsmith workspace, with 30+ formats in multi-format repositories, lets you govern Nix packages with the same access controls, entitlement tokens, and audit logs that you use on the rest of your software supply chain.

 for more information about using Nix in Cloudsmith.

Cloudsmith expands support to Nix

In Q3 we further improved platform security capabilities and enhanced developer experience.

 this quarter. This roundup provides a brief overview of each.

Policy management and risk detection are key security features in Cloudsmith and they reached general availability this quarter.

This is Cloudsmith’s policy engine that allows users to write policy-as-code across the web app, API, and Terraform provider.

With policy management you can write custom policies in Rego that are automatically enforced across your Cloudsmith account. This includes cooldown policies that hold newly released packages for a set period (see more on these below), policy templates to get started quickly, and decision logs that record evaluation. Everything lives under the 

With policy management, rules about which packages are safe and acceptable are automatically enforced on every package at the registry, before they reach your build environment. Changes in threat intelligence or updates to policies automatically trigger re-evaluation so your risk exposure is always current. 

This feature automatically checks incoming packages and those already in your repository against known vulnerabilities and malicious packages. Detection is powered by 

, which triggers new evaluations as new threat intelligence hits the data feed.

This feature helps compress the gap between when new threat advisories are published and when organizations evaluate packages against those advisories. Because this feature runs continuously, teams don’t need to wait for the next scheduled scan, a delay that widens their exposure window.

Cooldown policies became generally available for npm and Python in Q2, and in Q3 we expanded support to six more formats: 

. You can create cooldown policies via the web app, API, or Terraform. These updates extend the reach of cooldown policies beyond application libraries to include container images and Rust crates. 

This is an improvement in the policy editor that flags Rego problems as you write. On save, the web app and API reject disallowed builtins (such as 

), type mismatches, incorrect argument counts, and unsafe or undeclared variables. The web app editor also warns when a policy is missing `package cloudsmith` or a match rule, highlights malformed Rego inline, and autocompletes schema field names.

Catching mistakes while you type means fewer policies that silently fail to do what you expect, and a shorter learning curve for teams new to Rego.

Download vulnerability findings from the web app

 on a package’s Overview tab to export every vulnerability and malicious package record matched to it as JSON. This data is also available from the Packages Vulnerabilities List API endpoint.

Simplify incident investigation and compliance audits by allowing security teams to send findings to a ticketing system, SIEM, or auditor in one click, without writing an API script.

Hardened images tab for configuring upstreams

Upstream configuration now supports Docker Hardened Images (DHI), Chainguard Containers, and WizOS. The DHI Community and Chainguard Containers Free tiers come pre-configured. For paid tiers, the proxy URL is filled in for you, so you only name the upstream and add credentials.

Making hardened images quick to proxy lowers the cost of adopting them, and every pull is cached, logged, and subject to your policies.

Libraries tab for vendor-curated package registries

 tab quick-configures library registries, which include vendor-curated feeds of open source packages that may be pre-vetted, rebuilt from source, and security scanned. Currently, this feature supports Chainguard Libraries (Maven, Maven Remediated, npm, PyPI, PyPI Remediated) and RapidFort Curated Libraries (npm).

Teams can adopt curated, rebuilt-from-source packages as a drop-in upstream and manage them alongside public upstreams and private packages in one place.

Cloudsmith Blog

Software Supply Chain Defense in Depth: A Stage-by-Stage Guide

13 KubeCon North America 2026 sessions not to miss

Critical PHP vulnerabilities in PHP2Shell expose web infrastructure to remote code execution

Secure the packages AI agents install on their own

LiteLLM 1.107.0 compromised on PyPI

20 October 2026: eMudhra intermediate CA certificates

Software Supply Chain Defense in Depth: A Stage-by-Stage Guide

Cloud Native Digest - July 2026

How to use Cloudsmith as a dependency firewall

10 GitHub Universe 2026 sessions not to miss

Why enforce supply chain security at the artifact registry

Tensorlake SDK npm package compromised

OIDC removed long-lived credentials from your pipelines. What about your laptop?

Cloudsmith expands support to Nix

Everything Cloudsmith shipped in Q3 2026