By submitting this form, you agree to our 

Answer twenty questions about your artifact and supply chain practices. Get a custom report card showing your maturity score against key regulatory and compliance frameworks.

Artifact Security Maturity Assessment

AI agents pick, update, and install dependencies on their own. You might review the code they produce, but the packages they pull rarely get the same scrutiny. Agents also let people outside engineering, often called citizen developers, build applications in the same environments your developers use. Their installs cross your trust boundary too.

One unreviewed install is enough. An agent can pull a 

 package, or resolve to a fresh version that carries a self-replicating worm. Shai-Hulud spread this way. It ran its payload through npm 

Securing what agents install takes two steps: find and fix what they’ve already pulled, then set guardrails so every future install starts secure.

Continuous risk detection tracks what agents already pulled

If your AI agents have been allowed to pull packages directly from public registries, you might already have risky packages in your environment. The first step toward securing packages AI agents pulled is to identify and track risky packages that already crossed your environment’s trust boundary.

In Cloudsmith, continuous risk detection matches advisories from 

 against every package already in your repository whenever an advisory is published or updated. A match triggers a fresh policy evaluation, and Cloudsmith applies whatever actions your policy defines, such as quarantining or tagging the affected packages. From there, you can remediate by upgrading to a fixed version or removing the package.

Scope the blast radius, then rotate credentials and rebuild

Remediation starts with a blast radius analysis. Use client logs to see which tokens, IP addresses, and user agents pulled which package versions. Export the logs before you delete any tokens, because deleted tokens disappear from log entries.

Quarantine malicious and vulnerable packages to mitigate their impact, then invalidate and rotate every credential that’s reachable from any machine, runner, or sandbox that installed a compromised package.

The actual fix may be a patch, upgrade, or roll back. Move to a safe version, then rebuild any artifacts produced while the compromised package was installed.

Route every install through your registry

With the cleanup done, the next step is making sure every new install starts secure by configuring agents to pull packages through your artifact manager.

Agents often run in their own shell, container, or VM. There, they can’t see the .npmrc or pip.conf that points your workstation or CI runner at your private registry. When an agent runs npm install, the package manager goes straight to the public registry and skips your policies entirely.

Close that gap where the agent runs. Sandbox agents by default, and give them access only to the runners and shells they need. When you control the environment, build the registry config into the base layer of the container, devcontainer, or CI runner, and inject a short-lived token issued through OIDC. Then restrict egress (outbound traffic from the agent’s environment) so your private registry is the only package source the agent can reach.

Creating policies at the registry level ensures they apply to all paths that route through the artifact manager, whether a developer or agent wrote the code. Start with a 

 (malware blocking, cooldown, vulnerability and licensing checks) and add policies that align with your organization’s security posture.

 can guard against slopsquatting or install-time attacks by holding newly published packages for a specified period (e.g., 3–7 days). This gives researchers time to identify threats and publish advisories. (Note: a cooldown policy won’t catch a malicious package that ages past your cooldown window.) If your package manager is configured to automatically pull 

, the cooldown policy resolves to the latest compliant version by default.

An agent that approves its own exceptions essentially makes policy optional. Set up a release process for false positives, and put a person at the approval step if possible. When an agent’s request returns a 

, that person reviews the block, raises an allowlist pull request, and approves it. Automation then re-evaluates the policy and releases the package.

AI agents load more than open source packages and dependencies for a project. Other resources may include AI skills, MCP servers, plugins, and IDE extensions from GitHub or other public registries. These resources often enter the development environment without review, but they can inherit the agent’s system access and permissions.

These artifacts and tools deserve the same review and governance that open source packages receive. Governance for this layer of AI-powered development is in its early stages, so teams are primarily limited to restricting the sources agents can access and maintaining an approved list of sources.

Enforce policy at the registry once and every agent inherits it

AI agents move fast and produce a lot of code, which makes their output challenging to review and secure. Enforce policy at the registry and every agent, workflow, and developer gets the same protections, wherever the code comes from.

Jason Myers

Technical Content Marketer

Secure the packages AI agents install on their own

KubeCon + CloudNativeCon North America 2026 takes place November 9–12, 2026, at the Salt Palace Convention Center in Salt Lake City, Utah. CNCF-hosted co-located events run on Monday, November 9, and the main conference opens with keynotes at 9:00 AM MST on Tuesday, November 10.

When and where is KubeCon North America 2026?

Yes. CNCF-hosted co-located events on November 9, including Open Source SecurityCon, Platform Engineering Day, and Agentics Day: MCP + Agents, require an All-Access Pass. Picks 4, 6, 9, 10, 11 and 12 on our list are co-located sessions.

Do I need a separate pass for the co-located events?

Start with "Signed, Sealed, Denied" from AT&T, "I Packaged My Application in a Container Image, and Now What?", and "Mythos vs Maintainers." On Monday, Open Source SecurityCon adds AMPEL for SDLC hardening, VEX at scale, and the OpenSSF golden path panel.

Which KubeCon North America 2026 sessions cover software supply chain security?

Cloudsmith is at Booth 175 in the Solutions Showcase. Catch our booth lightning talk on Tuesday, November 10 at 10:45 AM, play supply chain Jeopardy, and join us at AprèsKube SLC on Wednesday, November 11.

Where can I find Cloudsmith at KubeCon North America 2026?

KubeCon North America 2026 FAQs

The 13 KubeCon + CloudNativeCon North America 2026 sessions we recommend for platform, DevOps, and security teams cover software supply chain security, policy-as-code with OPA and Kyverno, packaging AI agents as OCI artifacts, and governing agentic workloads on Kubernetes. KubeCon North America 2026 runs November 9–12 at the Salt Palace Convention Center in Salt Lake City, Utah. All times below are MST.

With hundreds of sessions across four days, it can be hard to know where to start. We recommend stopping by Cloudsmith at Booth 175 to say hello, play a round of supply chain Jeopardy, and catch a lightning talk from our Head of Security.

As for the conference programming, here's our curated roadmap of the 13 talks we think will help you build with clarity, control, and confidence.

📍 Salt Palace Convention Center (100 S West Temple, Salt Lake City, UT 84101)

1. Signed, Sealed, Denied: Attestation-Driven Admission with Kyverno + CEL at AT&T

Your image is signed. But does its evidence meet your deployment requirements, and can you prove that to an auditor? 

 built platform-managed controls where GitHub Actions emits Sigstore-backed Artifact Attestations and Kyverno's ImageValidatingPolicy evaluates them at admission. Every decision is retained as audit evidence.

This is our top pick because it tackles a problem platform teams know well: internal builds and upstream images with different trust roots, living side by side. The talk covers mixed-source verification in Kyverno 1.19 and 1.20, plus patterns for exceptions and failure handling. If you want compliance that runs at machine speed instead of through spreadsheets, start here.

 Hyatt Regency | Level 4 | Regency Ballroom B-D

An AI agent consists of a model, prompts, skill files, MCP servers, and code spread across Git repos, object storage, and loose config files. In this lightning talk, 

 shows how KitOps, a CNCF Sandbox project, bundles all of it into one versioned, immutable OCI artifact called a ModelKit, signed with Cosign and pushed to any registry you already use.

When something breaks, the first question is always "what was actually running?" Treating agents as versioned artifacts gives AI the same provenance and governance teams already expect for container images and packages.

3. Mythos vs Maintainers: Drowning in the Vulnerability Tsunami

 Hyatt Regency | Level 2 | Salt Lake Ballroom DE

LLMs are changing both sides of open source security. Attackers use them to scale campaigns against GitHub Actions misconfigurations and package ecosystems like PyPI and npm, while well-meaning researchers use them to file a flood of vulnerability reports. 

 play out both roles, attacker and maintainer, using real examples from in-toto's Witness project.

The session moves from recon and disclosure to remediation and using AI to proactively secure the project. For anyone consuming open source at scale, it's a look at why the trust decisions you make about upstream packages matter more than ever.

See the Mythos vs Maintainers session details

4. The Golden Path Doesn't Exist Yet: What Platform Teams Told Us About OpenSSF Tools

The OpenSSF DevRel community asked platform teams a blunt question: what's standing between "this is a good idea" and "this is working for us"? 

 report back on the real blockers, from SBOM accuracy and portability to air-gapped friction, and map them against Sigstore, Zarf, GUAC, and SLSA.

This panel addresses the gap between supply chain tooling and day-to-day adoption. Platform teams should expect to learn which tools solve which problems today.

See the OpenSSF golden path panel details

5. Rego Without Borders: Breaking Down Language Barriers for Security Policy

 will show how the Rego Intermediate Representation lets the compiler generate execution plans that other languages consume natively, so Rego-powered security policy can run inside Swift and Java applications too.

At Cloudsmith, teams write policy-as-code in Cloudsmith using OPA and Rego. Consistent policy across more runtimes means fewer gaps between what you intend and what you enforce.

See the Rego Without Borders lightning talk details

6. Set the Terms for Your Agents and Let Your Humans Be Creative: How to Govern Code Nobody Reviewed

 Salt Palace | Level 1 | Grand Ballroom BDF

Anyone can generate an application in minutes, but deploying it safely remains a challenge. 

 give platform owners a framework of "desired state" abstractions that let teams develop, deploy, and verify AI-generated code. Their live demos start with vibe-coded apps that violate SLSA, GDPR, and internal architecture decisions, then bring them into line.

This session treats AI-assisted coding as something to enable, not fear, and puts the guardrails in the platform rather than in a review queue. That's the same approach Cloudsmith takes toward governing the dependencies those apps pull in.

See the governing AI-generated code session details

7. I Packaged My Application in a Container Image, and Now What?

You built your image and pushed it to a registry, but what comes next? 

 walks step by step through signing images, generating an SBOM, checking for vulnerabilities and whether they're exploitable, and using attestations, with live demos you can repeat locally and in CI/CD.

This session looks to be one of the clearest on-ramps to software supply chain security on the schedule.

See the container image supply chain session details

8. The Identity Crisis: Who is the AI Agent in Your Cluster?

Kubernetes was built for deterministic, stateless microservices with static identity boundaries. AI agents generate dynamic network calls, trigger external APIs, and run machine-generated code on the fly. In this keynote, 

 asks a simple question with big consequences: when an agent calls a tool or a database, what identity does it present?

Identity is the foundation every other control builds on, from authorization to audit. This keynote sets up a theme you'll hear all week, and the emerging open source standards that aim to answer it.

9. End to End Software Development Lifecycle Hardening with AMPEL

Hardening a pipeline requires a lot of checking: who can run CI, how repositories are configured, commit signatures, build provenance, and vulnerabilities. There's a tool for each step, but stitching them together gets messy fast. 

 introduces AMPEL, a supply chain policy engine that uses policy-as-code to evaluate each stage of the SDLC and block builds that don't meet the bar.

This is a hands-on session, so bring a laptop and a project. You'll map controls to frameworks like the OSPS Baseline and NIST SSDF.

10. Upstream First Security: Keeping Telco Infrastructure Secure at Cloud Native Scale

When a CVE lands in a Go dependency under 5G infrastructure, waiting until next quarter isn't an option. 

 share how they triage CVEs across a dependency tree spanning 15+ upstream repositories, why they always fix upstream first, and how they keep production within one minor version of the latest release.

They'll share info about time to fix and the real cost of backporting versus upgrading. This should be a grounded business case for treating dependency hygiene as a core engineering practice.

See the upstream-first security session details

11. Creating VEX Documents at Scale: A Look into One Supplier's Process

What is a VEX, what goes into it, and when should you create one? In this lightning talk, 

 answers those questions through a case study of how 

 is preparing to automate VEX document creation, covering CSAF VEX required fields and OpenVEX.

With the EU Cyber Resilience Act (CRA) asking for VEX alongside SBOMs, and AI speeding up vulnerability discovery, VEX is how suppliers tell customers which vulnerabilities actually matter.

See the VEX at scale lightning talk details

12. The Agent Did What? Reconstructing MCP Tool-Call Attacks

 Salt Palace | Level 1 | Grand Ballroom IG

An agent reads a web page with a hidden instruction, then uses Model Context Protocol (MCP) tools to retrieve data and send it outside your environment. 

 reproduces the attack in a controlled demo, then rebuilds it step by step by joining MCP tool-call logs with cloud audit logs, using a minimal MCP audit proxy that emits OpenTelemetry spans to Jaeger.

This session shows how to build a repeatable method for turning an agent incident into a trace, and gives a clear sense of what those logs can and can't prove.

See the MCP tool-call attacks session details

13. Platform Engineering after the AI Hype: Why IDPs Must Become Intent-Driven

 Hyatt Regency | Level 2 | Salt Lake Ballroom C

 looks at what comes after the first wave of platform engineering: templates, golden paths, and self-service APIs. Infrastructure requests now come from copilots and agents operating at machine speed, so platforms need capabilities that encode organizational policy, security, and operational knowledge for humans and AI alike.

See the intent-driven IDPs session details

Cloudsmith is a Gold sponsor at KubeCon North America 2026, and we're bringing plenty to keep you busy between sessions. Find us at Booth 175 in the Solutions Showcase.

 On Tuesday, November 10 at 10:45 AM, our Head of Security 

Patient zero is a dependency: tracing one attack two ways

. Grab a coffee after the keynotes and join us.

Claire Speedy

Senior Marketing Manager

13 KubeCon North America 2026 sessions not to miss

Two critical core PHP vulnerabilities, together known as PHP2Shell, were disclosed this week and emergency patches are available. The flaws sit in PHP itself, so any site, developer environment, or CI pipeline running an unpatched version of PHP is exposed.

This kind of vulnerability requires a fast patch. PHP comes into environments in lots of places - in base images, CI runners, developer containers, and open source package repositories. In this scenario, ideally you’ll want a single view of your dependencies, so you don’t have to do a search across fragmented tools.

When PHP hits an out-of-memory error, a flaw in how it handles memory lets an unauthenticated attacker run arbitrary commands or read sensitive data from server memory.

The flaws affect every PHP release from 5.4 through 8.5.11. 

PHP reported that they consider consider the risk highest for mod_php

. There is a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.

See which PHP versions your teams pulled and stop affected versions from being used

Cloudsmith can be the source of truth for what packages came into your environment, by which users, and when. That gives you a clear picture of your exposure.

Search your Cloudsmith repositories and package logs for the affected PHP versions.

Patched versions are available, but 8.5.12, 8.4.27, 8.3.36, or 8.2.35. PHP 8.1 and earlier are end of life and will not receive a fix.

Block critical vulnerabilities automatically: 

Set a vulnerability policy that blocks packages with critical vulnerabilities. It applies as soon as an advisory is published and protects you against future critical vulnerabilities.

 When new threat intelligence lands, Cloudsmith re-checks all existing packages in your Cloudsmith repositories against your policies automatically.

 with Cloudsmith for a custom assessment of your software supply chain.

Meghan McGowan

Product Marketing Manager

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

an attacker compromised the popular Python package LiteLLM

, publishing version 1.107.0 to PyPI and pushing trojanized images to Docker Hub and GitHub Container Registry (GHCR). This is the second time we’ve seen an attack on LiteLLM, the first in March 2026.

If your organization pulled or installed 

 on or after October 21, rotate your cloud credentials, SSH keys, browser sessions, and AI provider API keys immediately. The malicious release executed a credential stealer designed to exfiltrate secrets and query LiteLLM databases.

Here is what happened, how to check your environments for exposure, and how to block compromised packages automatically using Cloudsmith.

At 11:39 UTC on October 21, an attacker uploaded version 1.107.0 of LiteLLM to PyPI alongside compromised Docker tags (

). The compromise occurred when stolen GitHub CLI OAuth tokens were used to access maintainer accounts, override branch protections, and trigger a release pipeline pointing to a lookalike repository.

Upon installation or execution, the package injects files into the Python 

). These files execute automatically whenever the Python interpreter starts and deploy a credential stealer targeting:

 and IMDS metadata), GCP service account keys, Azure CLI tokens, SSH private keys, and GPG keys.

 Keys for OpenAI, Anthropic, Cohere, and other providers stored in environment variables or configuration files.

 Upstream credentials stored in local or remote LiteLLM PostgreSQL tables (

 Saved credentials and cookies from Chrome, Firefox, Edge, and Safari.

The payload encrypted harvested secrets via AES-256-CBC and sent them to an attacker-controlled endpoint (

). Active abuse was observed within hours, as attackers tested stolen AWS credentials against LLM foundation models.

Follow these steps to confirm exposure across your developer machines, repositories, and CI/CD runners:

Check for LiteLLM images pulled from Docker Hub or GHCR on October 21 (tags 

Search your Cloudsmith repositories with exact package names to avoid false positives 

(format:python) AND (name:^litellm$) AND (version:^1.107.0$)

Review your Cloudsmith client logs to identify which developer machines or build agents fetched version 

 Check this even if the search returns nothing. Upstreams set to proxy only serve packages without storing them, so those packages won’t show up in search.

Remove installations and rotate secrets: 

 ran in any environment, remove it immediately. Rotate all reachable AWS, GCP, Azure, and AI provider API keys, as well as SSH keys and database passwords. In Cloudsmith, quarantine the package rather than deleting it, so you keep the download history for your investigation

Why AI development is speeding up the attack lifecycle 

AI in the hand of attackers is compressing the supply chain lifecycle. Threat actors write malware faster, target AI tools directly, and reach pipelines through automated agents. 

Attackers use LLMs to build malware faster: 

 analysis noted strong indication of LLM–assisted code generation in the payload, allowing the attacker to iterate rapidly on multi-platform malware.

Packages like LiteLLM sit between applications and LLM providers. Compromise one and you reach upstream API keys, database credentials, and cloud infrastructure in a single step.

Agents install packages at machine speed: 

As engineering teams adopt autonomous AI coding tools and automated CI/CD pipelines, dependencies resolve faster than human review can keep up.

Block compromised packages automatically with Cloudsmith

Public registries supply most of your dependencies, and they serve the ecosystem well. But pulling straight from public registries into builds means a malicious version of a package can reach you minutes after it’s published. Cloudsmith sits between public registries like PyPI and your developers and pipelines, acting as a central control point that protects you in three ways

Many package managers have client-side cooldowns, but they are hard to manage at scale. Cloudsmith enforces the cooldown at the repository level, so they work regardless of client version or script settings, by holding back newly published upstream versions for a defined time window (typically a few days). Attacks like LiteLLM 1.107.0 depend on speed: a malicious version is published, it gets pulled into builds within minutes, and then it’s withdrawn from the public registry.

These policies act on public reports to the OSV malicious packages repository and other sources. Cloudsmith scans packages and matches them against our consolidated database of malware advisories. Cloudsmith 

 helps you block versions flagged as malicious, or matching known indicators. Once a package is identified as compromised, the policy keeps it from reaching any endpoint client, even after a cooldown policy window. This eliminates the need to maintain a manual blocklist.

Cloudsmith acts as the source of package dependencies for every developer, AI agent, and build pipeline across your company. As a central control plane that enforces controls, Cloudsmith produces a comprehensive audit trail of what entered your environment to answer questions like “Were we exposed?”.



If you'd like to understand your current exposure, 

LiteLLM 1.107.0 compromised on PyPI

 that the private keys for eight eMudhra intermediate CA certificates were incorrectly generated and can be recovered by anyone. An attacker could use them to impersonate websites and services to clients that trust these CAs. Mozilla, Chrome, Apple and Microsoft have already blocked the affected intermediates in their browsers and operating systems, but many other clients do not check revocation and only stop trusting them once their CA bundle is updated.

This is not a compromise of Cloudsmith or of your artifacts. The risk comes from software that bundles or consumes a CA trust store. Artifacts that include a bundle from before the fix will still trust the compromised intermediates, wherever they are hosted.

Not yet fixed at the time of writing: Node.js, Bun and FreeBSD ca_root_nss. If you rely on these, please check the vendor for updates and consider the manual workarounds in the incident write-up.

1. Review the packages and images and update to the fixed versions.

2. Rebuild and republish container images rather than patching running hosts, since images and packages are immutable.

3. Check for pinned or vendored bundles (lockfiles, hash-pinned dependencies, copied cacert.pem files), which will not update automatically.

4. Update the trust store on build agents, CI runners and any clients that pull from Cloudsmith.

5. If you use private upstreams secured with eMudhra-issued certificates, review those connections.

6. Optionally, use Cloudsmith vulnerability scanning and policy as code to flag or block outdated CA bundles in your repositories.

Please note that the fixed versions above come from the public incident write-up at 

 and the vendors' own advisories. We recommend confirming against each vendor's advisory for your specific versions.

If you'd like further detailed information on the specific packages detected on your account, please feel free to 

Colin Moynes

Senior Support Engineer

20 October 2026: eMudhra intermediate CA certificates

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.

Cloudsmith Blog

Secure the packages AI agents install on their own

13 KubeCon North America 2026 sessions not to miss

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

LiteLLM 1.107.0 compromised on PyPI

20 October 2026: eMudhra intermediate CA certificates

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

How continuous risk detection replaces point-in-time scans with real-time monitoring