---
title: "Goodbye Image Pull Secrets, Hello Kubernetes Credential Providers"
description: "Using Kubernetes credential providers for identity verification when pulling images from private repositories"
canonical_url: "https://cloudsmith.com/blog/goodbye-image-pull-secrets-hello-kubernetes-credential-providers"
last_updated: "2025-06-19T14:49:23.699Z"
---
# Goodbye Image Pull Secrets, Hello Kubernetes Credential Providers
The tools security teams reach for first inspect code at different points in the development process: at the PR stage, at build time, or monitoring what's running in production. They're solving real problems, and they're good at them. What they don't do is govern which packages are allowed to enter your environment in the first place.
That control happens at the artifact registry, which is the one place every package, team, and pipeline passes through. A scanning tool that runs at PR time sees a dependency after it's already been fetched. A runtime tool sees it after it's deployed. Cloudsmith sits upstream of both: before a dependency reaches a developer, a build tool, or a CI job, Cloudsmith checks against current threat intelligence and uses your policies to clear or block it. The scanning you already have gets cleaner input. Cloudsmith provides the enforcement layer the security stack was missing.
Three capabilities form the foundation of a dependency firewall posture: controlled upstream ingestion, continuous metadata enrichment, and a customizable policy engine. Together they create a control layer that decides what enters your environment automatically and keeps re-evaluating that decision as intelligence updates.
## **TL;DR:**
Most security tools evaluate packages after they enter your environment. Cloudsmith governs what's allowed in before a build runs and checks everything in your repositories when new threat intelligence drops. No team has to configure its own pipeline rules to get that coverage. This guide covers upstreams, continuous enrichment, and an OPA-backed policy engine, from initial configuration through to enforcement.
## **Controlled ingestion**
Cloudsmith [upstreams](https://docs.cloudsmith.com/repositories/upstreams) route all public registry requests through your Cloudsmith repositories rather than letting build tools pull from registries directly. Every package request resolves through a configured upstream. Cloudsmith fetches each package once and caches it permanently, serving it from your repository from that point forward. When a public registry has an outage, your builds continue.
The security consequence matters more than the availability benefit: you have a single point through which all package traffic flows. Without it, policies can't enforce consistently because downstream rules only catch what passes through them. The upstream is the prerequisite everything else builds on.
[Upstream trust](https://docs.cloudsmith.com/supply-chain-security/upstream-trust) closes dependency confusion attacks at the configuration level, before policy evaluation runs. When you mark a public registry as untrusted, Cloudsmith won't fetch a newer version of a package from that registry if a local version already exists. A higher version number on the public registry doesn't win. An attacker publishing **`acme-utils@9.9.0`** to npm can't shadow your internal **`acme-utils@1.2.0`**. The attack surface closes at configuration, not after detection.
## **Continuous metadata enrichment**
Cloudsmith evaluates every package against the [OSV](https://osv.dev/) database (which aggregates records from GitHub Security Advisories, the OpenSSF Malicious Packages Project, the NVD, and language-specific datasets), [EPSS](https://cloudsmith.com/blog/cloudsmith-introduces-epss-scoring-in-enterprise-policy-management-epm) scores from [FIRST](https://www.first.org/epss/) for real-world exploitability, and SPDX license metadata. For Docker images, Cloudsmith generates a full software bill of materials ([SBOM](https://docs.cloudsmith.com/artifact-management/sbom)) automatically at publish time.
The part that separates this from point-in-time scanning: Cloudsmith polls its intelligence sources continuously. When a new advisory is published, Cloudsmith checks every package already in your repositories, not just what arrives after the disclosure. A package that cleared evaluation yesterday can be quarantined today, automatically, without anyone manually triggering a re-scan.
This is the enforcement model that most registries and scanners don't offer. A scan at ingestion tells you whether a package was safe when it arrived. Continuous re-evaluation tells you whether it's still safe now. When new malware signatures drop, or a previously low-severity vulnerability gets weaponized and its EPSS score spikes, Cloudsmith checks your inventory for a match and triggers policy enforcement.
Policy evaluation also runs at package promotion events and when new packages are published, and on a fallback schedule if nothing else has changed.
## **Policy engine**
Cloudsmith's policy engine runs on Open Policy Agent ([OPA](https://www.openpolicyagent.org/)), the same open standard used in Kubernetes environments and across the cloud-native ecosystem. Policies are written in Rego and managed through Cloudsmith's [Terraform provider](https://cloudsmith.com/changelog/manage-policies-as-code-with-terraform), giving you full lifecycle management of rules, precedence, enabled state, and actions as code, all version-controlled alongside the rest of your infrastructure.
Cloudsmith puts policy enforcement, malicious package detection, vulnerability matching, and license governance in one platform, under one policy model. That means policy-as-code in OPA/Rego with structured exception workflows, instead of binary allow/block toggles spread across multiple UIs.
The engine normalizes package metadata across 30-plus formats, so a single Rego policy applies consistently whether you're managing npm packages, Docker images, Maven artifacts, or Python wheels. Policy input includes CVSS scores, EPSS scores, OSV malware identifiers, license type, fixed versions, repository names, uploader identity, build-time tags, and for Docker images, the full component-level SBOM.
Cloudsmith provides policy templates and a [Rego recipe cookbook](https://cloudsmith.com/campaigns/cloudsmith-rego-policy-cookbook) to accelerate policy authoring. Every policy evaluation creates a decision log record, which includes the input data, what the policy matched, and which actions ran, giving you the traceability to audit decisions and roll back when needed.
## **Creating a baseline policy set for a dependency firewall**
Four policies form a strong starting point. Each addresses a distinct risk; together they cover the primary ways malicious or non-compliant packages enter a production environment.
**Block malware globally.** Packages carrying an OSV malware identifier get quarantined across every repository in the workspace – current and future. The coverage is immediate and unconditional, and the signal quality is high enough that there's almost no argument against this policy. Apply it globally, set its precedence to #0 (first), and move on.
**Hold new packages with a [cooldown policy](https://cloudsmith.com/blog/your-upstream-is-not-your-friend-why-security-teams-are-demanding-package-cooldown-policies).** A cooldown is a timed hold for newly fetched packages from public registries, enforced at the index level. Cloudsmith won't download or cache packages within the cooldown window, making them unavailable to build tools. Compromise attacks on trusted packages are typically identified within days of publication. A three- to seven-day hold gives threat intelligence time to catch up before a package reaches a pipeline. When a malware identifier matches during the window, the package gets quarantined. When a package clears the window clean, it downloads, caches, and becomes available automatically. Clean cases need no human decision.
**Set a vulnerability threshold. **Cloudsmith exposes both the CVSS score and the fixed version in policy input metadata, so policies can distinguish between risk profiles rather than applying a single blanket rule. A package with a **CVSS score of 9.5** and **a patch available** warrants a different response than one with the same score and _no fix yet_. Blocking a team where no remediation path exists creates friction without reducing risk.
**Add license policies. [Copyleft](https://en.wikipedia.org/wiki/Copyleft)** packages (e.g., GPL, AGPL) entering through transitive dependencies create legal exposure that surfaces late and expensively. A license policy flags or quarantines non-compliant license types at ingestion. Teams that catch a GPL dependency at the boundary have a straightforward remediation path. Teams that discover it during a security audit or acquisition due diligence do not.
When policies match a package, they take actions: quarantine, tag, or both. Tags trigger webhooks, which route to Slack notifications, Jira tickets, CI/CD events, or any supported alerting tool. Add a tag action to every policy. It makes enforcement decisions visible and actionable outside the Cloudsmith UI.
## **Simulate before you enforce**
Before adding quarantine actions to a live policy, Cloudsmith's [simulation API](https://docs.cloudsmith.com/supply-chain-security/epm/getting-started#step-4-simulating-the-policy) runs the policy against your existing repository contents without creating decision log entries or touching any live package state. The response shows which packages would match, the reasons, and what actions would be taken.
This is how you measure blast radius before enforcement. A policy that looks narrow on paper can match more packages than expected when run against a production repository. Simulation lets you find that out before a build breaks. The recommended path: start policies with tag-only actions. Use decision logs to review what matched, assess signal quality, and surface false positives. When you're confident, add the quarantine action to the existing policy. The Rego logic stays the same. Moving from reporting to enforcement is a configuration change, not a rewrite.
## **What developers see when a policy fires**
Engineers trying to hit delivery commitments route around security controls that slow pipelines, generate unexplained blocks, or require manual steps outside normal workflows. A dependency firewall handles this by making the secure path the fast path: packages that evaluate clean pass through without any additional steps in the developer's workflow.
When a developer requests a specific package version that's in quarantine, they receive a `403` response with policy context in the body. The message is configurable: you set it in the policy description. Point developers to the exemption workflow, the right Slack channel, or a PR template for requesting a waiver. They know what caused the block and have a clear path forward.
When using a cooldown policy and a developer requests the latest version of a package with a quarantined release, Cloudsmith removes the quarantined version from the repository index and serves the most recent policy-compliant version.
## **Exception and waiver workflows**
Security policies need a structured exception path. Without one, practitioners route around controls entirely, which defeats the purpose of having them.
The recommended approach uses an allowlist-style [exemption](https://github.com/cloudsmith-io/rego-recipes/tree/main/exemptions) policy that marks specific packages as approved and releases them from quarantine. Developers enter the exemption flow through the `403` response, which points them to the process. From there, a GitOps workflow handles the rest: a developer raises a pull request to add their required package to the allowlist; the security team reviews and approves; automation merges the change, re-evaluates the policy, and sets the package to available. The PR review is the only manual intervention required for this process.
Git records every decision with a person, a timestamp, and a reason. The audit trail exists outside the platform, changes are reversible, and your CI tooling handles the reconciliation.
## **Audit and observability**
Decision logs record every policy evaluation: the exact input data used, what the policy matched, and which actions were taken. The `policy_input` field contains the data that drove the decision, which is useful when you need to explain a quarantine to an auditor, a team lead, or a compliance reviewer. If you query for all policy matches in the last seven days and you get a concrete, reportable picture of your threat landscape.
Webhooks fire on quarantine events, tag additions, or releases from quarantine. Configure them to route notifications to your alerting tools of choice (Slack, Jira, etc.) to ensure the right people get the information they need without manual polling. Manage webhooks through infrastructure as code at the repository level to ensure every repository carries the same alerting setup.
## **Getting started**
Establishing a dependency firewall with Cloudsmith starts with controlled ingestion. Enable the malware block globally and put it into enforcement. Add cooldown, vulnerability threshold, and license policies with tag-only actions first. Use the simulation API to understand blast radius. Review decision logs to assess signal quality. When you're confident in what each policy matches, change the action from tag to quarantine. The policy logic doesn't change.
Teams that add Cloudsmith alongside Snyk, Wiz, or other security and scanning tools get pre-ingestion control where they didn't have it before and without replacing the scanning that already works. The packages that reach your downstream tools already clear evaluation at the registry. Your existing scanning layer gets cleaner input. And when new threat intelligence drops, Cloudsmith re-evaluates everything in your repositories automatically. Threat intelligence updates continuously, and with Cloudsmith enforcement does too.
[Book time with the team](https://cloudsmith.com/book-a-demo) to see how a Cloudsmith dependency firewall fits alongside your current stack.
Scanning for malicious packages at deployment catches issues already inside your environment. Scanning at the pull request catches what your CI pipeline already ran. If security controls don’t see a malicious package until after ingestion, it already has multiple chances to execute.
This is an architecture problem that requires an architectural answer. A dependency firewall is that answer. It’s a security posture that places guardrails between your development environment and public registries, evaluating what enters before any build runs.
## **How malicious packages enter your build environment without inspection**
Build tools connecting directly to public registries like `npm`, `PyPI`, `Maven Central`, and `Docker Hub`, and packages arriving as requested is a common approach to open source software consumption. When scanning runs at the pull request, in the pipeline, or at deployment, the package is already inside your environment.
Software composition analysis ([**SCA**](https://en.wikipedia.org/wiki/Software_composition_analysis)) tools identify known vulnerabilities in packages already present in a codebase. That's genuinely useful. But even with the best scanners, an architectural gap exists between ingestion and where the first scanner sits. Establishing a control point in that gap allows teams to better govern the packages that enter their environments.
Two patterns produce this gap consistently.
- The first is when no artifact management exists at all and developers pull directly from public registries. Teams can’t implement security controls because the layer necessary to do so isn’t in place.
- The second, and it’s more common than most organizations realize, is when an existing artifact management tool handles the storage of software artifacts but enforces no security controls on the consumption of those artifacts (for example: AWS CodeArtifact or GitHub).
A third pattern is emerging due to the use of AI coding tools.
- These agents generate code that expands the attack surface faster than most security programs have adjusted for. Tools like Cursor, AI-assisted editors, and LLM-powered agents recommend and install packages as a normal part of their workflow. Teams need governance that can match the pace of AI-powered development.
Developers tend to accept those recommendations without the scrutiny they'd apply to a manual dependency addition. The packages arrive through the same registries and the same pipelines as they would with manually-written code, but the human review step between "_the model suggested it_" and "_it's in the project_" is often gone.
## **Modern attacks execute before the scanner runs**
The latest supply chain compromises exploit trusted open source packages. The [Axios](https://cloudsmith.com/blog/axios-npm-attack-response), [LiteLLM](https://cloudsmith.com/blog/how-cloudsmith-can-protect-against-the-litellm-attack), and the [Shai-Hulud](https://cloudsmith.com/blog/shai-hulud-the-second-coming-what-you-need-to-know-and-do-now) attacks succeeded because they targeted specific packages developers already trusted and executed payloads at install time – before any scanner ran.
Cloudsmith's analysis of 2025 OSV.dev data, comparing when malicious versions were published to npm against when OSV flagged them, shows that **99 percent of npm package compromise attacks are identified within 72 hours of publication**. A package scanned within that exposure window looks clean because no malware identifier exists yet. By the time the community flags the threat, pipelines are already running it.
## **Scans are snapshots – threat intelligence isn't**
There's a second failure mode related to scanning that plays out more slowly. A package enters your environment, the scanner runs, nothing matches, and it's marked clean. That evaluation is correct at that moment because no known vulnerability exists. Then six months later, a researcher discloses a critical CVE. Nothing triggers a re-evaluation, so the original point-in-time scan remains the most recent one and the package is still in production.
An example of this is the [**Log4Shell**](https://osv.dev/vulnerability/CVE-2021-44228) vulnerability in Apache `Log4j`. That package existed in production codebases for years before threat intelligence identified the vulnerability. The problem in cases like this is when you treat a one-time evaluation at the boundary as permanent clearance.
New advisories arrive constantly for packages that evaluate as clean at ingest. A scanner that runs once, when a package first arrives, doesn't protect against what threat researchers find next month or next year. The scan result ages out the moment new intelligence contradicts it.
That said, scanning remains essential. But the fluid nature of supply chain threats, packages that evaluate as clean at ingest and become risks as new intelligence emerges, reveals a gap that point-in-time evaluation can't close on its own. Addressing it means supplementing scanning with controls that operate earlier in the process, before packages enter an environment where they can execute.
## **The control point that doesn't depend on developer behavior**
A dependency firewall addresses both failure modes described above by changing where and when evaluation happens. The first is early detection at the boundary: identifying threatening or malicious dependencies before they enter your environment, rather than after they had the chance to execute. The second is ongoing assessment: unlike a scanner that runs once and treats the result as permanent, this posture evaluates continuously as new threat intelligence arrives. A package that cleared evaluation at ingest doesn't remain cleared by default; it remains cleared only if current intelligence still supports that conclusion.
Developers start their work with packages that clear those guardrails, meaning the inputs to their work are more likely to be secure from the start. Vulnerabilities, threats, and license flags caught at the boundary save considerable rework compared to discovering the same issues in a PR review, a pipeline scan, or a post-incident forensic report.
For the vast majority of packages that clear evaluation, the process is entirely transparent and frictionless to developers. When friction occurs, like disabled scanner plugins, skipped linting rules, and manual approval workflows, developers create workarounds. Developers don’t need to bypass a control they don’t interact with. Compliance that relies on structural enforcement is more reliable than manual, behavior-based approaches.
For security and DevSecOps teams, the value is consistency at scale. Every developer, every AI agent, every pipeline, and every team in the organization hits the same guardrails. Policy applies universally and automatically, closing the gap between what policy says and what enforcement carries out.
A dependency firewall posture doesn't replace the scanning you already have. It moves the trust decision to the ingestion boundary, so your team uses safe, evaluated packages before anyone writes a line of code.
_For a practical guide to building a dependency firewall, covering controlled ingestion, continuous policy evaluation, and the OPA-backed policy engine, read [How to use Cloudsmith as a dependency firewall](https://cloudsmith.com/blog/how-to-use-cloudsmith-as-a-dependency-firewall)._
Or _[book a demo](https://cloudsmith.com/book-a-demo) to see it in action._
When you run `npm install`, you're not just installing the requested package. You're also pulling in every transitive dependency in the package’s dependency graph. Many of these are packages you didn’t consciously choose, from maintainers you don’t know, including code that executes automatically before any build pipeline step runs. An average React application can pull in over 900 dependencies, most of which arrive automatically, not by selective choice.
That's the architecture of modern software development. Reusing open source packages at scale makes it possible to ship complex applications that meet the high expectation of users without rebuilding foundational infrastructure from scratch. But the security model currently in use wasn’t designed to address the exposures created by reusing open source packages.
A leaked npm publish key makes that exposure visible. The credential isn't the problem, rather it's what reveals the gap between where organizations believe enforcement happens and where it actually happens.
The evolving nature of software development and the rise of security supply chain attacks changed who's paying attention to this gap. Security teams don't need to experience an incident to start conversations around their supply chain. The [axios](https://cloudsmith.com/blog/axios-npm-attack-response) compromise, the [Shai-Hulud](https://cloudsmith.com/blog/tanstack-npm-packages-compromised-in-mini-shai-hulud-attack)-style worms, and near-misses reported by high-profile engineering organizations present a threat environment that makes industry signals a catalyst for change. So, while the trigger is different, the gap is the same.
## Downstream effects of a leaked key
It may seem like a leaked npm key is a credential rotation problem and not a supply chain problem. Here’s how we get from key to attack.
No matter how a publish key gets exposed, whether that’s in a CI log, a repository that was briefly public, or a secret rotation that wasn't fully completed, that key grants write access to one or more packages on the public npm registry. Write access means the ability to publish a new version.
The attacker publishes a version that looks legitimate: same package name, incremented version number, valid metadata. In the axios compromise, the malicious versions were tagged `latest` and `legacy`. Consumers pulling the latest version get the malicious one automatically on their next install.
Here's where the transitive dependency becomes the attack surface. Most downstream consumers aren't pulling the compromised package directly. They're pulling a framework that depends on a tool that depends on the package. No developer makes a conscious choice to install it. The package manager resolves the dependency graph and pulls everything in. In the axios case, the attackers added a new software dependency named [**`plain-crypto-js`**](https://www.resecurity.com/blog/article/supply-chain-malware-alert-plain-crypto-js-compromises-axios-packages) which serves as a legitimate encryption and hashing utility. The associated npm [`postinstall`](https://news.ycombinator.com/item?id=45263347) script runs automatically during installation. The malicious code executed before any build step, before any scanner ran, before anyone knew the package arrived.
By the time a developer or CI job completes [**`npm install`**](https://docs.npmjs.com/cli/v8/commands/npm-install), attack code can exfiltrate credentials, establish remote access, and take steps to avoid detection.
The credential leak opened the door. The artifact pipeline, specifically, the absence of an interception point between a package being requested and when the package is executed. This is precisely where the adversary makes an impact.
## What existing tooling misses
Investing in security tooling can create a sense of false confidence. Especially as organizations grow, adapting to nuanced changes in the software development process at scale can be challenging. So, this confidence makes sense: they have application security scanning, CI/CD pipeline scanning, and endpoint detection. These are good tools, but where they sit in the timeline is the problem.
**AppSec and static analysis tools** analyze the code your team wrote. SAST tools like Checkmarx, Veracode, Snyk, and Semgrep, do serious work and find real vulnerabilities. They analyze source code before the build runs. The SAST tool already finished its pass by the time your build system is pulling packages from npm. It has no visibility into the dependency tree. So, a compromised transitive dependency gets pulled in, its installation script executes, and the SAST report comes back clean because the SAST tool never saw the dependency tree.
**CI/CD scanning** runs after the package manager pulls the requested packages. In npm, `postinstall` scripts run during download, not during execution. When the malicious code runs at install time and your pipeline scanner runs afterward, then it's checking the pool for contaminants after the swimmers have been in it for an hour. The tool works correctly and you get a clean report, but that’s because the timing is wrong once again. The attacker already has your credentials.
**Endpoint and runtime security** is excellent at detecting anomalous behavior once code is running, like suspicious network traffic, unusual file operations, and credential access patterns. CrowdStrike, your EDR tooling, etc., catch these things, but they're reactive by design. By the time your endpoint detection notices the suspicious outbound connection, the credentials are already gone. Detection at minute three doesn't help much when the exfiltration happened at minute one.
This is the architecture of the standard security model, and it has a structural blind spot: every control point operates after ingestion. Code downloads and executes before any of those controls see it. That's not a problem you solve by adding another scanner at a later stage in the same pipeline. Adding more tooling downstream of the gap doesn't close the gap.
## The control plane has shifted
Consider a fire department. They detect and respond to fires. We need fire departments. But we also need a fire code that prevents fires from starting. The fire code is embedded in the design and operation of buildings; it’s invisible because it's foundational. Fire response and prevention are different things, and both matter. The difference is that only one of them stops the problem before it starts.
The artifact registry functions like the fire code. It’s where that kind of foundational control can actually live for software supply chains. It sits at the boundary between untrusted software, like everything on the public internet, and your trusted environment. Every package your developers and build systems consume passes through it. That makes it the one place in the entire delivery pipeline where enforcement can happen before code downloads, installation scripts run, or anything executes.
Enforcement at the trust boundary changes the attack timeline entirely. A compromised version of a package previously marked as safe gets evaluated against policy before it enters the environment, so doesn’t reach your environment at all. Policy stops being advisory ("_this package is risky, here's a dashboard entry_") and instead becomes an automated enforcement control ("_this package is not entering this environment for this reason_").
A few things become possible at the artifact layer that aren't possible anywhere downstream:
**Continuous re-evaluation.** A package that was clean when it arrived six months ago and has a new CVE or a threat intelligence flag today gets re-evaluated without manual action. Build-time scanning doesn't revisit what's already in the environment, but an enforcement layer at ingestion can.
**Richer signal than CVEs.** Most modern supply chain attacks don't begin with a known vulnerability. They begin with compromised open source maintainers. These threats don't appear in a common vulnerabilities feed and instead rely on scanning the open source upstream registries (PyPI, npm, Packagist, etc.) for unwanted code changes ([**malicious packages**](https://github.com/ossf/malicious-packages)) using a database like OSV.dev. . This data is actionable at the artifact layer, before the package is introduced into any developer builds.
**An audit trail that answers the incident question.** When something goes wrong, "_were we exposed?_" should be answerable from a single system of record. An enforcement layer at ingestion is that record – what entered, when, under what policy state, with what provenance. Not a multi-tool investigation across disconnected logs.
## The problem with bolt-on security
The instinctive response to a supply chain incident is to add tooling. Buy the additional security module. Enable scanning at another pipeline stage. Each addition addresses a visible gap and each one is a reasonable decision in isolation.
The accumulated result is a different problem: a patchwork of controls with seams between them. Each tool has its own configuration requirements, its own maintenance cycle, its own expertise to operate correctly. The security stack grows in response to incidents until nobody fully understands how it fits together or what to do when something falls through a seam. The operational burden of the stack becomes its own risk.
This pattern shows up consistently in teams that started with a repository and added security on top: fragmented coverage, high maintenance overhead, and a circumvention problem. When authentication against an internal proxy creates enough friction, developers route around it and pull directly from the public registry. A control that gets bypassed at scale is worse than no control because it creates the appearance of coverage while the actual exposure grows.
The architectural distinction matters here. Controls built into the artifact layer from the foundation behave differently from controls added on top of a repository designed for something else. The former is simply infrastructure while the latter is configuration layered on infrastructure with a different original purpose. Those are two different approaches that behave differently under pressure.
Teams choosing a platform built for supply chain security describe making that choice explicitly to avoid assembling the capability from components. The assembly works, until it doesn't. The seams are where attacks succeed.
What the incident actually reveals
The leaked npm key is almost never the actual exposure. It's the event that made the exposure visible.
The supply chain incident – the credential, the flagged package, the build that broke in a way nobody could explain quickly – functions as a diagnostic. It reveals where enforcement actually lives in the pipeline, which is almost always different from where teams assumed it lived.
The useful question that comes out of the diagnostic: where in your pipeline does enforcement actually happen? Does it occur before packages enter the environment, or after?
For most organizations running standard CI/CD scanning on top of a repository, the answer is after. The follow-on question is what it would take to move it upstream. The teams that have made that move describe the same outcome: not more tooling on top of the existing architecture, but a different architectural starting point. A platform where enforcement at the boundary is the foundation, not an addition.
_Cloudsmith is a cloud-native artifact management platform that enforces policy at the point of ingestion – before packages enter your environment – and provides continuous re-evaluation, full audit logging, and developer-transparent controls across every package format your teams use.See how Cloudsmith protects your software supply chain from dependency attacks. [Schedule a conversation to discuss your tech stack today](https://cloudsmith.com/book-a-demo)._
Leaked [API keys](https://docs.cloudsmith.com/policy-management/api-key-policy) are one of the most common and well-understood security failures in software development. A credential committed to a repo, copied into a script, or exposed in a CI log can sit undetected until abuse makes it visible. By then, the damage is done.
Cloudsmith is now a member of the GitHub Secret Scanning Partner Program. That means [Cloudsmith-issued API keys are uniquely identifiable](https://github.blog/changelog/2026-06-17-secret-scanning-updates-june-2026/), and GitHub can detect them automatically when they appear in a repository.
#### How it works
Cloudsmith issues API keys with a unique prefix. That prefix is registered with GitHub's secret scanning infrastructure, so when a Cloudsmith credential appears in a repo – in source code, a config file, a committed `.env`, or anywhere else GitHub indexes – GitHub detects and flags those credentials automatically.
When a leak happens, Cloudsmith notifies the affected customer directly. Teams can revoke or rotate the compromised key before it gets misused.
The workflow is straightforward: detection happens automatically, notification is immediate, and your team decides how to respond.
#### Why this matters for your team
The window between a credential leak and credential abuse is short and it closes fast. Automated scanners can pick up a key exposed in a pull request or pushed to a public repo within minutes. Discovering issues through billing anomalies or abuse reports put teams in a challenging position, and one they want to avoid.
Automatic detection of leaked API keys changes that dynamic. When exposure triggers an immediate notification, the response begins before most incidents have a chance to develop.
This works inside the workflows your team already uses. There is no new tooling to adopt, or new configuration required on your end. GitHub-based teams get detection in place from the moment they issue their next Cloudsmith API key.
_See how Cloudsmith secures your software supply chain end to end. [Book a demo](https://cloudsmith.com/book-a-demo) to learn more._
AI dev frameworks are becoming a key target for software supply chain attackers. The logic is rather simple: if you can compromise the framework itself, you have the ability to compromise highly sensitive infrastructure today. That includes LLM API keys, cloud provider secrets, the kind of credentials that would allow an attacker to move laterally from there.
On June 17, a sophisticated software supply chain incident, specifically targeted **Mastra**, through a simple typosquatted [**easy-day-js**](https://www.stepsecurity.io/blog/mastra-npm-packages-compromised-using-easy-day-js) package name. Mastra is a popular open-source TypeScript framework used for building AI agents and [RAG pipelines](https://www.ibm.com/think/topics/retrieval-augmented-generation).
By hijacking a former contributor’s creds, attackers were able to inject a malicious dependency across 144 packages in the Mastra ecosystem. With core components like [**`@mastra/core`**](https://www.npmjs.com/package/@mastra/core) pulling nearly a million weekly downloads, the blast radius of an attack like this is massive. In this blog we’ll look at how the attack unfolded, how the malware evades detection, and how developers can secure their environment today.
## How the attack unfolded
The attackers executed a multi-stage campaign that relied on a blend of account takeover, social engineering (via package mirroring), and a dynamic second-stage runtime payload designed to bypass traditional static analysis.
The groundwork was laid a day prior to the primary breach. An npm user named `sergey2016` published version `1.11.21` of a package called `easy-day-js`. At this point, the package appeared entirely benign, indicating it was a fully functional clone of the highly popular [**`dayjs`**](https://www.npmjs.com/package/dayjs) date library.
By copying the original library’s version numbering, MIT license, and author metadata ([**`iamkun`**](https://www.npmjs.com/~iamkun?page=1)), the attackers ensured that any casual visual or automated sanity check of the package structure would look clean - one of the many ways the attacker is evading detection.
In the next stage, the threat actor updated the `easy-day-js` package to version `1.11.22`. Again, this version looked identical to its predecessor but introduced a relatively small, obfuscated file named `setup.cjs`, along with an execution trigger in the `package.json`. Following a wave of community concern, `npm` recently announced it would [**disable postinstall scripts by default**](https://opensourcemalware.com/blog/npm-v12-security-theatre) in its next major version. This is why.
```json
{
"_key": "922ea43c7c58",
"_type": "code",
"code": "\"scripts\": {\n \"postinstall\": \"node setup.cjs --no-warnings\"\n}",
"filename": null,
"language": "javascript",
"markDefs": null
}
```
The `--no-warnings` flag was explicitly used to suppress the Node.js runtime environment warnings, which ensured devs remained unaware during the installation.
A few minutes later, the attackers struck the **Mastra** ecosystem. They hijacked the `npm` account belonging to `ehindero`, a legitimate former Mastra contributor whose organisational scope access had never been revoked. From there, they used an automated script that rapidly populated the `@mastra/*` org and mass-published updates to **144 packages** in just over an hour. Each package was updated to include the malicious dependency:
```json
{
"_key": "a6154d1e4142",
"_type": "code",
"code": "\"dependencies\": {\n \"easy-day-js\": \"^1.11.21\"\n}",
"filename": null,
"language": "javascript",
"markDefs": null
}
```
Because of the way that `npm` resolves semantic versioning (`^`), any fresh install or build runner pulling the clean pinned version `1.11.21` was automatically forced to resolve and download the malicious `1.11.22` patch. From an execution perspective, when a dev or automated CI/CD pipeline runs `npm install`, the `postinstall` hook fires immediately, which causes the `setup.cjs` script to initiate a highly-evasive first-stage dropper into the environment.
## How the malware evades detection
The underlying mechanics of the first-stage execution reveal a strong emphasis on evasion and anti-forensics. It has four clear evasion tactics:
1. **TLS cert bypassing**: The `NODE_TLS_REJECT_UNAUTHORIZED = '0'` allows the script to safely reach out to an attacker’s C2 infrastructure even if the interception tools or self-signed proxies attempt to inspect or block the traffic.
2. **Process detachment**: By leveraging the `detached: true` and `.unref()`, the second-stage payload is then able to spin out into its own OS process. When the core `npm install` routine finishes or is terminated, the malware continues running silently in the background.
3. **Self-deletion**: Finally, the script finishes by calling `fs.rmSync(__filename)`. By removing the `setup.cjs` immediately after execution, the installer leaves behind a clean directory tree, baffling standard post-incident file scanners.
4. **Missing attestations**: Mastra utilises npm's trusted publisher flow inside their CI pipeline, generating robust Sigstore-backed SLSA provenance attestations for authentic releases. However, while Mastra generated provenance, their `npm` org policy **_did not enforce it_**.
The tragedy of this fourth evasion tactic is that it was entirely preventable. Because a strict verification policy wasn't required on the registry side, `npm` willingly accepted the attacker’s mass updates pushed directly from a stolen PAT, even though they dropped the cryptographic provenance signature. Any client configuring a strict signature-verifying installation policy would have immediately blocked this entire campaign.
## How developers can secure their environments today
By using open infrastructure tooling like `osv-scanner`, organisations can detect the malicious `easy-day-js` package as well as the various malicious packages published to the compromised Mastra org on June 17.
- `easy-day-js` ([**MAL-2026-5979**](https://github.com/ossf/malicious-packages/blob/6cd7ce45f8d8acf40e00150580af7443c2351d65/osv/malicious/npm/easy-day-js/MAL-2026-5979.json#L12))
- `@mastra/agent-browser` ([**MAL-2026-5996**](https://github.com/ossf/malicious-packages/blob/6cd7ce45f8d8acf40e00150580af7443c2351d65/osv/malicious/npm/%40mastra/agent-browser/MAL-2026-5996.json#L15))
However, security shouldn’t just be reactive. Developers can’t just wait for security advisories. While `npm` has stepped in to pull any compromised versions from the registry, if you had run an install during the exposure window, before these advisories were published, you should treat the environment as compromised.
Securing your software supply chain requires a proactive architecture. If you're managing external dependencies using Cloudsmith, here’s how you could mitigate attacks like `easy-day-js`:
1. **Enforce upstream cooldown policies**: You’ll be hearing this from us a lot, but cooldown policies really are one of the most effective solutions to this recent wave of open-source supply chain attacks. Malicious packages are often caught and reported within hours of publication. By establishing an upstream proxy with a cooldown window (let’s say, holding newly-published packages for _one or two days_ before they become eligible for download), you create a natural buffer that keeps automated pipeline scripts from pulling zero-day dependencies.
2. **Lock down your semantic versioning**: As highlighted earlier, you should never rely purely on range-based specifiers (either `^` or `~`) for high-value upstream dependencies. Where possible, ensure a strict `package-lock.json` or a `yarn.lock` is enforced across all local and CI/CD builds. This guarantees that your builds anchor exclusively to known, cryptographically hashed versions.
Most cooldown policy implementations work at the download layer. A package request occurs, the policy intercepts, the download is blocked, and the build fails. The package manager already committed to that version so the enforcement is technically active, but it hands developers a broken build and no clear path forward. Many respond by pinning around the policy or going direct to public registries. The control becomes a process tax rather than a security layer.
Cloudsmith's cooldown policy enforces at the index. Packages that don't meet the configured minimum age don't appear in the index at all – the package manager resolves to the next compliant version automatically, with no build failure and no developer intervention required. The security happens before the build even knows there's a decision to make.
That design choice matters more now than it did a year ago. [Shai Hulud](https://cloudsmith.com/blog/shai-hulud-the-second-coming-what-you-need-to-know-and-do-now) and [axios](https://cloudsmith.com/blog/axios-npm-attack-response) made the exposure window visible at scale: both attacks moved from publication to compromise within hours. A cooldown policy doesn't guarantee it catches every attack, but index-level enforcement means newly published packages can't reach your builds before threat intelligence has time to catch up – and it does it in a way developers won't route around.
```json
{
"_key": "99d711e5349d",
"_type": "wistiaVideo",
"id": "r0icqoj24t",
"markDefs": null,
"thumbnail": {
"_type": "image",
"asset": {
"_ref": "image-b669c2179fc8dd27672d547dc6de94bdcf104c95-1280x720-png",
"_type": "reference"
}
},
"title": "Cooldown policies"
}
```
## How the index-level enforcement works
The primary target for cooldown policies are **packages your Cloudsmith workspace has not cached yet.** These are packages the platform would normally proxy directly from a public upstream like PyPI or the npm registry. Cloudsmith does not download or cache these packages while they're inside the cooldown window, so they're absent from the index from the start.
When the package manager receives a request for a newly published package it resolves to the next index-compliant version without retries or build failures. In this case the cooldown policy is completely invisible to developers.
Friction only surfaces when no compliant version exists. For example, when a lockfile or exact version pin targets a package still inside the cooldown window. In that case, the build receives a 404 Not Found or a customizable 403 Forbidden response. Rather than leaving developers with an error to debug, Cloudsmith returns an enhanced message that includes policy name, a customizable description, and a policy ID. You control what that message says – who to contact, a link to your exemption process, or an internal runbook. The right information to move forward reaches the developer, in their terminal or build log, without any client-side configuration.
Cloudsmith determines a package's age from upstream metadata: the `time` field for npm packages and the `upload-time` field for Python packages. If that metadata isn't populated by the package maintainer, the policy fails open, which means that Cloudsmith does not hide the package from the index. This is worth accounting for when you're evaluating policy coverage: Cloudsmith won’t block packages with missing age metadata.
## How to write cooldown policies
No two organizations have the same requirements. Policy-as-code, written in [Rego](https://docs.cloudsmith.com/supply-chain-security/epm/getting-started), gives companies the flexibility to tailor policies to their specific needs and to exercise greater control over their development pipelines.
Documentation with [step-by-step instructions for creating cooldown policies is here](https://docs.cloudsmith.com/supply-chain-security/epm/cooldown-policy). Users have two options to create and manage cooldown policies. One is through the Cloudsmith web app, which exposes all the configurable fields and handles the Rego scaffolding for you. The other is through the [Cloudsmith API](https://docs.cloudsmith.com/api/workspaces/policies/create), which allows you to manage policy configuration programmatically or through infrastructure-as-code.
Cooldown policies have two fixed structural constraints that users cannot change: the policy always runs at precedence 0 and is always terminal, which means the platform evaluates it first and, if a match occurs, no additional policies run for that package.
The key variables in the default template are `within_past_days`, `supported_formats`, `included_repositories`, and `excluded_repositories`. For example, setting `within_past_days` to `7` hides any npm or Python package published within the last week from the index. By default the cooldown policy applies across all repositories in the workspace, but you can scope policies to include or exclude specific repos as well.
The `include_local_packages` flag controls whether the policy applies to packages uploaded directly to Cloudsmith rather than proxied from a public upstream. The default for this flag is `true`. Most teams will want to evaluate this explicitly because packages your team publishes internally carry a different trust model from packages arriving from public Python or npm registries.
## Getting started with cooldown policies
Supply chain attacks don't announce themselves. The window between when a malicious package is published and when it's identified is exactly where modern development pipelines are most exposed, and closing that window requires enforcement that works with your build process.
Cloudsmith's cooldown policies are built on our policy-as-code engine, which means the same infrastructure that enforces minimum package age requirements also powers malicious package blocks, allowlists, high-risk vulnerability blocks, license compliance, and more. You can scope policies to specific repositories, formats, and packages – giving teams the precision to enforce exactly what they need without creating blanket restrictions that slow teams down.
Check out the [documentation](https://docs.cloudsmith.com/supply-chain-security/epm/cooldown-policy) to learn more or [request a demo](http://www.cloudsmith.com/book-a-demo) to see them in action and to learn more about what's available for your team.
### **Exploring AI and the future of the software supply chain**
AI assistants will shape the future of the software supply chain, and today, we’re sharing a glimpse of a powerful idea in motion: [Cloudsmith MCP](https://cloudsmith.com/product/mcp-server), a **proof of concept** server that connects large language models (LLMs) like ChatGPT and Claude directly to your software supply chain using the emerging [**Model Context Protocol (MCP)**](https://github.com/modelcontextprotocol) standard.
Imagine managing policies, surfacing security insights, or orchestrating package workflows with a simple natural language prompt. No dashboards, no scripting, just a simple question or instruction that delivers the right end result. If this sounds interesting, you should [register for early access](https://cloudsmith.com/product/mcp-server).
This isn’t a launched product (yet), but it’s a clear signal of where we think Cloudsmith is headed: toward **smarter, more conversational workflows** that make it easier to control your software supply chain.
## **Why we believe MCP matters**
**MCP **is a standard way to make information available to LLMs. Similar to an API, MCP provides a documented, standardized way for a client to integrate services from external sources.
MCP enables AI assistants to query and interact with software supply chain data, so it creates a foundation for smarter workflows and more accessible control over artifact management.
In essence, adding MCP capabilities to Cloudsmith offers up an entirely new interface to your software supply chain, with AI agents and LLMs working together to achieve your goals. We're exited to see MCP becoming a flexible new point of integration between our customers' third-party services and Cloudsmith.
## **What we've built**
```json
{
"_key": "fd0e8d6b0b48",
"_type": "wistiaVideo",
"id": "g7hl8ptomq",
"markDefs": null,
"thumbnail": {
"_type": "image",
"asset": {
"_ref": "image-b66ccc0f00d0da476d5d665dbed8b245218c2279-3840x2160-png",
"_type": "reference"
}
},
"title": "MCP server demo"
}
```
Our MCP prototype leverages Cloudsmith’s API-first architecture to provide programmatic access to developers through their AI assistant. Through standardized MCP requests, you can ask questions about your software supply chain or take safe, controlled actions - like managing policies or promoting packages - directly within Cloudsmith. This opens up conversational workflows with the Cloudsmith platform.
For example, you might ask your AI assistant to identify what package is trending up in usage month over month or see all of the versions of a particular package in use across your workspace. In the future, your AI assistant will be able to review your organization’s compliance and security requirements and recommend or create a set of policies in Cloudsmith’s Enterprise Policy Manager based on that input.
## **What we’ve learned**
Building this prototype was a good reminder of a few fundamentals. First, an API-first foundation makes it easier to experiment, so it’s good that Cloudsmith is built truly API-first. Second, the data running through platforms like Cloudsmith can offer valuable insights when it’s made accessible to clients in lots of different ways. We’re giving developers and AI assistants simpler ways to ask questions, take actions, and get things done.
There’s still plenty to figure out, but MCP is already making artifact management and software supply chain management more intuitive and straightforward, especially at enterprise scale.
## Help us shape the release version
[Cloudsmith MCP](https://cloudsmith.com/product/mcp-server) is currently a **proof of concept** and will be available in **early access** for select customers and partners. If you're exploring the intersection of DevOps, AI, and supply chain security, we’d love to work with you. [Register for early access](https://cloudsmith.com/product/mcp-server) on the announcement page.
As Generative AI (GenAI) reshapes the software development landscape, the risks and complexities around managing what gets built, where it comes from, and how it’s secured are growing just as fast. The [****Cloudsmith 2025 Artifact Management Report****](https://cloudsmith.com/campaigns/2025-artifact-management-report) dives into this shift, offering critical insights into how teams are adapting their infrastructure and software supply chain security practices in response to the AI-generated code.
### Half of codebases are now AI-generated
According to our survey, ****42% of developers using AI report that at least half of their codebase is now generated by AI tools****. Where in 2024 this might have been considered a theoretical shift, in 2025 we need to accept that this is not a practical reality reshaping how software is written. AI isn't just a helper on the sidelines; it’s actively contributing to the core of modern applications and transforming the day-to-day workflow of developers. While the rapid rise of GenAI is often seen as a leap forward in productivity and innovation, it also introduces new security risks and software supply chain vulnerabilities that can’t be ignored.
```json
{
"_key": "b5064bb7fac7",
"_type": "image",
"alt": "A chart showing a breakdown of responses re: how much code is AI-generated",
"asset": {
"_createdAt": "2025-07-10T10:37:31Z",
"_id": "image-1db9fefdd0deec7b438daefa3b8e1f213ec8a85a-3833x3583-png",
"_rev": "x0ldlkijNt10eyLbFQAQ9t",
"_type": "sanity.imageAsset",
"_updatedAt": "2025-07-10T10:37:31Z",
"assetId": "1db9fefdd0deec7b438daefa3b8e1f213ec8a85a",
"extension": "png",
"metadata": {
"_type": "sanity.imageMetadata",
"blurHash": "eFO43@-:?;N2?qx@j?V]RkV].MM|x?xs8$%eRjRSxtti?;WBDTt6x?",
"dimensions": {
"_type": "sanity.imageDimensions",
"aspectRatio": 1.0697739324588333,
"height": 3583,
"width": 3833
},
"hasAlpha": false,
"isOpaque": true,
"lqip": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAATCAIAAAAf7rriAAAACXBIWXMAABcRAAAXEQHKJvM/AAADU0lEQVR4nG2U2W7bRhiF+dCNfRG0V0lQtCh8UytW4ziWUbtRrEiq5NiptTu2tojUQlLchotIips45MzwBYqRlRZGC3yYC3IOf+KcM8PwRjDT1gvdF4xgDjxOdWbamjf8OfBY2ZmDtebCVZT9L4zqJIoDVQdqbqI6UHZixYnVNX0or2LFjg0f/VdmhRRGMbFiIuBgMyA7fKI7BFhEUvCUS2azRNKQ7hIr3GEGBNhYtTAjyGghphJApk+sMDOcTFGJOCMiS4attPo2KB15N8VwcAclFZs+WUWZ4REJIEFGjKxjUUGyjo01ASsiLsj0HrMdzHVJtwwLL9e5PfvND87FgdeoRrxIZxgeUUwk6ZiRDbxUkQSQomNhjtkeHt/ir7eYbZO7P+H5T15u3z58Zuf27dNX7m05WgippKOlhmQDM4KEZvN0Nk8XHOK+4HGDiicdPB8Stp82K5vLI//khZvbt3N79u8/r9vXEcclMz4VJMQoOp3M84h7QFT5F5608YIlKsjAisgAc2z6uRSdvnIP9+z8c7vy1v86ohYqBmasIDM9spTwqJne19LBNZo+YBVkVvAtlSBb8KhWCPLPncNn9sXBetyHhkesIGPoaz8TeHz/KWl/gHfVZDpChkNd/Qdgk+5N/O6F++t3duFH96ETmx7dQMWml/FzfFdPWu9htwy5ETLcJ2LDzfpd+MeB9+Z79/wXr9+BxvqbmE4W6ORmEXZKcNxLVeOJWLPIQwtW8mHxIKidhOw4fQycildRJmtk2Exal7D1AX65SuYs0ixaNdOntk0naaO0qebDaj5sVeOltCssQ1saZbpDpiPUqyatImxfwrs6HPYSbpLOWDTsJc2Pm9pxWH4dXhXCQQ+C1e6/GGBjzcbAwUsZjdpp5yNsXMQ3Z5tPhejmfPP5fHN1GlV/Cyuvw9px2KnHvJDqLgEuBg5hlgrixXSppKqFRREPW0mzGNePo0ouLOfCyiNHYf0k6tTi+RSpJpZ1JMipqCBG0pAoo6VKz42xzpYyHvXSZim+Pouu3lGuz6LG5abfhIJAU9BdIgF6HJYaZgyPFv0xdBqbn6km4RdoMkhGPcpkkCwWSDWpeY+d2e6n687tfwm367Z2hksxt9+1thfAk/sgyv4GKSTEY1g2BqcAAAAASUVORK5CYII=",
"palette": {
"_type": "sanity.imagePalette",
"darkMuted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#351b7d",
"foreground": "#fff",
"population": 0,
"title": "#fff"
},
"darkVibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#2e176c",
"foreground": "#fff",
"population": 0,
"title": "#fff"
},
"dominant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#a8a3d0",
"foreground": "#000",
"population": 0.62,
"title": "#fff"
},
"lightMuted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#a8a3d0",
"foreground": "#000",
"population": 0.62,
"title": "#fff"
},
"lightVibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#9775f4",
"foreground": "#fff",
"population": 0.1,
"title": "#fff"
},
"muted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#6054ab",
"foreground": "#fff",
"population": 0.04,
"title": "#fff"
},
"vibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#7753d9",
"foreground": "#fff",
"population": 0.21,
"title": "#fff"
}
}
},
"mimeType": "image/png",
"originalFilename": "Artifact-Management-survey_AI-charts_03.png",
"path": "images/rafvlnhi/production/1db9fefdd0deec7b438daefa3b8e1f213ec8a85a-3833x3583.png",
"sha1hash": "1db9fefdd0deec7b438daefa3b8e1f213ec8a85a",
"size": 222483,
"uploadId": "2TIWyt7d2CmPqSOEnnxNWnUegiLvYoeJ",
"url": "https://cdn.sanity.io/images/rafvlnhi/production/1db9fefdd0deec7b438daefa3b8e1f213ec8a85a-3833x3583.png"
},
"caption": "42% of developers using AI report that at least half of their codebase is now generated by AI tools",
"link": {
"_type": "link",
"href": null,
"openInNewTab": false
},
"markDefs": null
}
```
### ****Attackers Are Targeting the Software Supply Chain****
Adversaries are increasingly shifting their focus from traditional infrastructure attacks to targeting the software supply chain itself. Rather than breaching networks directly, they’re infiltrating the ecosystem through techniques like [****slopsquatting****](https://www.raconteur.net/technology/how-to-protect-your-cyber-supply-chain-from-ai-slopsquatting) (the creation of malicious packages with names deliberately designed to mimic legitimate ones).
These deceptive packages are easy to overlook, especially in fast-paced development environments. Developers, often under tight deadlines and relying heavily on AI-assisted tooling to manage dependencies, may unknowingly pull in these malicious components without thorough vetting. The result is a stealthy but highly effective method for attackers to introduce vulnerabilities directly into production code.
### AI and automation: a double-edged innovation
Survey respondents anticipate that GenAI-driven automation will bring both benefits and complications, which should accelerate development workflows while also straining infrastructure with unpredictable behaviors and dependency complexities. Tools like [****GitHub Copilot****](https://github.com/features/copilot) and [****Anysphere Cursor****](https://www.cursor.com/) promise greater speed and efficiency in coding, but they also raise new red flags for security teams. As automation becomes more deeply embedded in the development process, the potential for AI-generated code to introduce unknown risks or unstable dependencies grows, which challenges the long-held assumptions about trust and reliability in the software pipeline.
These concerns are further amplified by the widespread adoption of Large Language Model (LLM)-based technologies. While LLMs can significantly boost developer productivity, they also pose new threats (such as recommending non-existent or harmful packages). When asked whether AI would worsen open-source [****dependency chain abuse****](https://cloudsmith.com/blog/owasp-ci-cd-part-3-dependency-chain-abuse) risks like typosquatting or dependency confusion, nearly ****80% of respondents agreed it would****, with almost ****a third warning of a significant rise in exposure****.
These evolving development patterns are expanding an already vulnerable software supply chain. Without rigorous artifact validation and integrity checks, developers face growing risks - not just from external attackers, but also from the very tools designed to help software development teams move faster.
```json
{
"_key": "38d90a9ac8de",
"_type": "image",
"alt": "30% of respondents say that AI will significantly exacerbate OSS malware threats",
"asset": {
"_createdAt": "2025-07-10T10:37:51Z",
"_id": "image-8a5ac6354fb652d7e4e3ecce161d038df4b0cd1b-3833x3583-png",
"_rev": "x0ldlkijNt10eyLbFQATMa",
"_type": "sanity.imageAsset",
"_updatedAt": "2025-07-10T10:37:51Z",
"assetId": "8a5ac6354fb652d7e4e3ecce161d038df4b0cd1b",
"extension": "png",
"metadata": {
"_type": "sanity.imageMetadata",
"blurHash": "eGN^iPt7?;x[?=X7WBt6M}ah?;RjtNtP8$.5M|MzxttO.MobDTRl%d",
"dimensions": {
"_type": "sanity.imageDimensions",
"aspectRatio": 1.0697739324588333,
"height": 3583,
"width": 3833
},
"hasAlpha": false,
"isOpaque": true,
"lqip": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAATCAIAAAAf7rriAAAACXBIWXMAABcRAAAXEQHKJvM/AAADRElEQVR4nH2Ti2/aVhTG+aPXRJP2kFZN0zZtk7YFSJM2WfNQmqUxCaGkJDzSBYghBhs/sbGvMQb7Gpv72h8w2U22VqomHV1Zuvr5fOc7380J4xmvuV3Z6coOrwJeBXdKWiM7sBfYjdgUsmn06crJdiha86HpD0x/aPqiNRetueyEpp84AQEhc/8HdgJiB9heoMfC1gwbNlZ1LIlocL8SJaRb2J7TT8BuyLJK79yQmoCIAm5fJ41SXNmHJ4XgpBhUX8HOX4luERBQN2QgpCCgIGQ53cbqGBkTPPGINsbdVvL2aHn+HHJFePRzsPXlLL/uPftqdvDL4qoUyQqaeCTVNUaGTXIjFQ1FJMloJKNOPXmzF3FFyBVgqQj//C3Yeern172NJ15+3dv9zq9xKa8YaCiuFBXnTJeMAdFNzN+uqocpWdqElT+iBhe3KvHlcXRcWDz/xs+vefk17+Cn+W09NmxiAmJNSc6FqZ+6RW4q8dlW2vPNXtSuJ4qKxw4xLCL0V5Uj+OKpv/HE2/zCK++Fqo7f7y/nRgyEbCTh2vGSK8CzZ/DmItEM8u+GQECHA3S6FRQ/9zbWvKNfF/e9FQgzeBoxZ0EHvVX1IOLy8GIn4t8h22fTZQZnvxgDWjuNtr+e/f6Z9/IHv3MTOwv6Hyzwq+p+Cld2o/4tcuaPcJR+WFPaqsa736bKX37vt5sfwCCgooAuD5dcHpa3YfsqMZ2PImF7tP8OlV9Ehz8Gr4tB/24FgveyM8NUDTe4uLSZbqj2ainwyHIpCNL8OD4zTab26aBJ2hXUuV6pGrZ96ixo2nkascmU3rWSyi48LcCzLVg7XnabK0nEmkZVkUp3VO4wjf9bF5ihUd3Eio51Ez/AbshUFbfK8fl2lpDNdPgml/Tq5L5B+tdEaJBRl41VZrtMn2BJRoqGHuDUNp9KIm6ex+WdLCpF+HY/7lzgXo30auS+SRSBWg6zfWq6RLOwPnns/MDPqaLgTj25OlleHkSN1zF/hYUbInaIIhLLYWDOJjOqWVhWkWp8DGfOMxNQWcYDHg17WJWIoVFzwpxZOtoUMmfONJMMRTRSPpD9MDxkbnamj26RGZ6tI01LFhgXMhMQSUayiv4BrqHA+cVJnIAAAAAASUVORK5CYII=",
"palette": {
"_type": "sanity.imagePalette",
"darkMuted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#40505d",
"foreground": "#fff",
"population": 0.01,
"title": "#fff"
},
"darkVibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#2f166e",
"foreground": "#fff",
"population": 0,
"title": "#fff"
},
"dominant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#9474e3",
"foreground": "#fff",
"population": 9.43,
"title": "#fff"
},
"lightMuted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#acc4cc",
"foreground": "#000",
"population": 0,
"title": "#fff"
},
"lightVibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#9876f4",
"foreground": "#fff",
"population": 0.07,
"title": "#fff"
},
"muted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#6f7099",
"foreground": "#fff",
"population": 0.58,
"title": "#fff"
},
"vibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#9474e3",
"foreground": "#fff",
"population": 9.43,
"title": "#fff"
}
}
},
"mimeType": "image/png",
"originalFilename": "Artifact-Management-survey_AI-charts_02.png",
"path": "images/rafvlnhi/production/8a5ac6354fb652d7e4e3ecce161d038df4b0cd1b-3833x3583.png",
"sha1hash": "8a5ac6354fb652d7e4e3ecce161d038df4b0cd1b",
"size": 223543,
"uploadId": "eQjRHYHKdshaTkY5tD9S9qDf4w7woWlt",
"url": "https://cdn.sanity.io/images/rafvlnhi/production/8a5ac6354fb652d7e4e3ecce161d038df4b0cd1b-3833x3583.png"
},
"caption": "30% of respondents say that AI will significantly exacerbate OSS malware threats",
"link": {
"_type": "link",
"href": null,
"openInNewTab": false
},
"markDefs": null
}
```
To address these emerging threats, modern artifact management solutions must embed intelligent access controls and offer end-to-end visibility into artifact provenance. With dynamic access control policies, organizations can ensure only authorized users and processes can interact with sensitive assets, reducing the likelihood of unauthorized changes or malware insertion. Coupled with robust policy-as-code frameworks, enterprises can establish and enforce security protocols that adapt as threats evolve, especially in environments where AI-generated code is becoming commonplace.
### Where in the SDLC are AI-generated risks coming from?
While the speed and efficiency benefits of using AI in software development are clear, the oversight is not.
****Only 67% of developers surveyed review AI-generated code before every deployment****, leaving large portions of production code potentially unvetted. This is quickly becoming a growing vulnerability in the software supply chain. This behaviour, driven by a desire to move faster, is dramatically expanding the attack surface. AI isn’t just introducing new code, it’s also introducing new risks, often at scale. Traditional concerns like artifact integrity, dependency management, and [****SBOMs****](https://help.cloudsmith.io/docs/sboms) (Software Bill of Materials) are being compounded by AI’s ability to rapidly consume and reuse unknown or untrusted code.
```json
{
"_key": "8f84fd33247b",
"_type": "image",
"alt": "41% of respondents identified code generation as the riskiest point of AI influence",
"asset": {
"_createdAt": "2025-07-10T10:38:05Z",
"_id": "image-28d8d0c83effcb09c75bc9a751860282efb07dbb-3833x2083-png",
"_rev": "bT7RrsHy27fOmttnOu98X4",
"_type": "sanity.imageAsset",
"_updatedAt": "2025-07-10T10:38:05Z",
"assetId": "28d8d0c83effcb09c75bc9a751860282efb07dbb",
"extension": "png",
"metadata": {
"_type": "sanity.imageMetadata",
"blurHash": "MUOD%}DmRkt7t6??tMV]ahV]MztNx?t6j[",
"dimensions": {
"_type": "sanity.imageDimensions",
"aspectRatio": 1.840134421507441,
"height": 2083,
"width": 3833
},
"hasAlpha": false,
"isOpaque": true,
"lqip": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAALCAIAAADwazoUAAAACXBIWXMAABcRAAAXEQHKJvM/AAABo0lEQVR4nI2O3W/SYBjF+z9vu9Fk0YuZeGOyJc5soTNC1AXdhowxNqUV9wEFIzh4KVDK+0Hb9wvK2/YfMKDzQsey5OTkXDy/cx7tR9/73iONHrEArHZGtQ6sAVgHqNHFTce3sXQDhXiMRfK/tC6WXSxsIgHiAPK53wYbS8cLRzS6k8Qi0Ya+csbKIZFDItePIIsgj+e+EOLxslksEq0PZw1r+rUkL8qTNlCQ/nuKlpBYJFrbDk/2mb4xzrzwL82J6y3duQP+CaYHe8HWGtp9Qswz6XoxkQ+Gb0D4FzaKcoCiEY0hjRFPEE+wiO95Xru5XX71mOQz7KoyrVfDVmsGeqrbV72hGiA1HEejYNEiF/od/sB6sLWKN1eQvuG92wyy27Twlpc/yS85US7wyjm/rshWK+y7ysELEeV68zqtbc/yGbqzTrYf4dTT8etnXvq5n30Z5HR2mKJHOs2naXGfGQV2VWH1a1mvCcuizebEHkSa7cyMojhIBdmd4FCnuTcsn2Yn7/npB176KD4fSeN4YhakUWRGyb8o80uTfTN9q8o7HfULi8UxipitIUgAAAAASUVORK5CYII=",
"palette": {
"_type": "sanity.imagePalette",
"darkMuted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#341880",
"foreground": "#fff",
"population": 0,
"title": "#fff"
},
"darkVibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#2d156f",
"foreground": "#fff",
"population": 0,
"title": "#fff"
},
"dominant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#aba8d1",
"foreground": "#000",
"population": 0.37,
"title": "#fff"
},
"lightMuted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#aba8d1",
"foreground": "#000",
"population": 0.37,
"title": "#fff"
},
"lightVibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#957cf4",
"foreground": "#fff",
"population": 0.11,
"title": "#fff"
},
"muted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#6459a4",
"foreground": "#fff",
"population": 0.02,
"title": "#fff"
},
"vibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#8664e1",
"foreground": "#fff",
"population": 0.01,
"title": "#fff"
}
}
},
"mimeType": "image/png",
"originalFilename": "Artifact-Management-survey_AI-charts_01.png",
"path": "images/rafvlnhi/production/28d8d0c83effcb09c75bc9a751860282efb07dbb-3833x2083.png",
"sha1hash": "28d8d0c83effcb09c75bc9a751860282efb07dbb",
"size": 129215,
"uploadId": "pZ4L2QG0lM0JfWo5xuh3K1xXMzjn6tRF",
"url": "https://cdn.sanity.io/images/rafvlnhi/production/28d8d0c83effcb09c75bc9a751860282efb07dbb-3833x2083.png"
},
"caption": "41% of respondents identified code generation as the riskiest point of AI influence",
"link": {
"_type": "link",
"href": null,
"openInNewTab": false
},
"markDefs": null
}
```
****41% of respondents identified code generation as the riskiest point of AI influence****, yet practices around review and trust remain inconsistent:
1. 66% said they only trust AI-generated code after manual review.
2. Just 20% fully trust AI output without extra scrutiny.
3. 59% apply additional reviews to AI-generated packages, but only 16% treat them like any other package, without further checks.
### ****The Need for Secure Artifact Management in the AI Era****
This uneven approach is happening against a backdrop of expanding AI usage: alarmingly, ****86% of organizations have seen more AI-influenced dependencies in the last year, with 40% seeing a significant increase****. Yet, only ****29% of teams feel very confident in their ability to detect malicious code in open-source libraries****, which is the very ecosystem where AI tooling tends to source its suggestions. The threats, according to those surveyed, range from sensitive data leakage to the inclusion of compromised dependencies. These risks are amplified when developers blindly trust AI-generated code or package suggestions without security oversight.
These findings point to a critical inflection point. AI is becoming a core contributor to the software stack, but we haven’t fully adapted our trust models, tooling, or policies to match this new reality. Relying on developers to manually spot every risk (especially under time pressure) is not sustainable.
****What’s needed is a secure checkpoint for AI-assisted development:****
- Automatically-enforced policies to catch unreviewed or untrusted AI-generated artifacts.
- Artifact provenance tracking to distinguish between human-authored and AI-authored code.
- Integration of trust signals directly into the development pipeline, so that reviews become automatic rather than an optional decision.
### Download the 2025 Cloudsmith Artifact Management report
Explore the latest trends, insights, and best practices for securing your software supply chain and managing AI-generated code responsibly.
****Download**** - [2025 Cloudsmith Artifact Management Report](https://cloudsmith.com/campaigns/2025-artifact-management-report)
****Webinar**** - [From AI to Scalability: 2025 Trends in Artifact Management](https://cloudsmith.com/events/webinars/from-ai-to-scalability-2025-trends-in-artifact-management)
```json
{
"_key": "4614b519a3b4",
"_type": "image",
"alt": "Download the report",
"asset": {
"_createdAt": "2025-07-09T18:41:45Z",
"_id": "image-c8b06a5caa75bae4dce5a135335ab0e65f966939-3840x2160-png",
"_rev": "bT7RrsHy27fOmttnOqH6VG",
"_type": "sanity.imageAsset",
"_updatedAt": "2025-07-09T18:41:45Z",
"assetId": "c8b06a5caa75bae4dce5a135335ab0e65f966939",
"extension": "png",
"metadata": {
"_type": "sanity.imageMetadata",
"blurHash": "MmKA,W^-%39Y%N%3NFWBt7az-rWAaxogR%",
"dimensions": {
"_type": "sanity.imageDimensions",
"aspectRatio": 1.7777777777777777,
"height": 2160,
"width": 3840
},
"hasAlpha": true,
"isOpaque": true,
"lqip": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAALCAYAAAB/Ca1DAAAACXBIWXMAABYlAAAWJQFJUiTwAAACjElEQVR4nGWSW0iTYRjHd51kBeWgYiXpVdmmonkqlbY5T+Va6vAEKlJpeGNeZCewKEvpRJcVqTU3lU3nN10zLTd3IMMtdnZSEbTygKWs1lT4x/d+1NAufjw87+H3/F94WbOmdcwY1zBjWsWM8S8hUn2mNfjM9H4ILn0AjokVglO/DOfEMqkOUlfgmQyS8yxaZhtfgeXlAizahX91anQJTv0vMsyincezx2bcvTeC9g4Kt9vVYe6o8eC+FkNyF1yGn2B5JkMwDs9huM/H0D8LqteLUdUnTI/9gMcYwoDchYrzHUguqkdC4Rlw8+sIvPw6xIlqkCFuxPWb/bC9XmSEBuorkVAKL4YUHihlDtKbRr7B/iYARbcNBdXXEMMvxwF+GWL4ZYg+LsW+7GKw004iOrMUTS1PYB2bY4STGkaolrsJKpkTAz0ujKo+Ykq3BEXXe4hrb+BgTi2DqBYxggpwsoqxK/XE/0I95YeqxwnlCzuRKWVODMrdGBv8TJ4t77RCUN4CdqoEUSmnEJUixo6kQkQm5iGCJwQn4/QmocZPEtEStdwDtcIDnfID3uoW4TYE0dNpRWbJBUQm5CKCl4MtPGEYLn+j0GtcxbtX32HQ+GGg/CStnvoCs3Ye9okAvMYQeXJhVStis6qxJ02KnclibE8swLbEPGyNF4FztARNl55imhb6TOvkktvwm6Rx0eiDpKeH0fQ/d6Dq7CNkia8gOb8JcYJ67D9Wib3pUrCPSBCbXYnmy51MQlpIf26COQxZJ596FX3ddkhq2sAVNuCwsAHcnAYcEpxDvKiR9OlFzbja2gvr+BxYG2SbpIx4DYouG/jSi2CnSLA7rZSko0V04tySWyitfoi2NooI/wDu1nEHeXEteQAAAABJRU5ErkJggg==",
"palette": {
"_type": "sanity.imagePalette",
"darkMuted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#344c54",
"foreground": "#fff",
"population": 0,
"title": "#fff"
},
"darkVibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#0a2f44",
"foreground": "#fff",
"population": 26.32,
"title": "#fff"
},
"dominant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#dcc4fc",
"foreground": "#000",
"population": 40.73,
"title": "#000"
},
"lightMuted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#adb0d6",
"foreground": "#000",
"population": 1.66,
"title": "#fff"
},
"lightVibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#dcc4fc",
"foreground": "#000",
"population": 40.73,
"title": "#000"
},
"muted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#6474a4",
"foreground": "#fff",
"population": 0.07,
"title": "#fff"
},
"vibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#9980dc",
"foreground": "#fff",
"population": 0.2,
"title": "#fff"
}
}
},
"mimeType": "image/png",
"originalFilename": "Report download 1920 x 1080.png",
"path": "images/rafvlnhi/production/c8b06a5caa75bae4dce5a135335ab0e65f966939-3840x2160.png",
"sha1hash": "c8b06a5caa75bae4dce5a135335ab0e65f966939",
"size": 843259,
"uploadId": "IjSXSFK6PkmSYoLXpUq5wBuhFOf78xuc",
"url": "https://cdn.sanity.io/images/rafvlnhi/production/c8b06a5caa75bae4dce5a135335ab0e65f966939-3840x2160.png"
},
"caption": "Download the report",
"link": {
"_type": "link",
"href": "https://cloudsmith.com/campaigns/2025-artifact-management-report",
"linkType": "href",
"openInNewTab": false
},
"markDefs": null
}
```
Researchers at Trend Micro have uncovered a critical unauthenticated remote code execution (RCE) vulnerability [[CVE-2025-3248](https://nvd.nist.gov/vuln/detail/CVE-2025-3248)] affecting [Langflow](https://cloudsmith.com/navigator/pypi/langflow) versions prior to **1.3.0**. 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.
```json
{
"_key": "2e3d7859d835",
"_type": "image",
"asset": {
"_createdAt": "2025-06-17T14:41:46Z",
"_id": "image-f0b7723d4380b45ce1133909fc40864254851923-872x609-png",
"_rev": "8MqCphtmQoMdZfTLqTaYGv",
"_type": "sanity.imageAsset",
"_updatedAt": "2025-06-17T14:41:46Z",
"assetId": "f0b7723d4380b45ce1133909fc40864254851923",
"extension": "png",
"metadata": {
"_type": "sanity.imageMetadata",
"blurHash": "V5TI%U?ak8-;ov~ptMM}WBa_y4RlRmfiaz?cM$tfocRl",
"dimensions": {
"_type": "sanity.imageDimensions",
"aspectRatio": 1.431855500821018,
"height": 609,
"width": 872
},
"hasAlpha": false,
"isOpaque": true,
"lqip": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAOCAIAAACgpqunAAAACXBIWXMAAAsTAAALEwEAmpwYAAABAUlEQVR4nJVSi47DIAzr/3/trS2PkMQ5OdBNdzttOwuhQGPsGrbWpYuYGf6PTdVU1R3xAYBw40C2b57Ig+LtcA0pIQWuXG4AJve9rMdoUb+i7bARcZGn8ks4VCAF/eCsnTskT7wUDRvRD7Qdo1FfCnceys8m4aQF0nCPfkIqDbM+oP2H7UzFV6RSV2t2s1YJv76awC3JcLixT4WWtIe0qDfUHf1E25nQaGlkImWuwMxHYxLtQL1lJBWjgYKF/5l389cjiQg39vWTglPZxuVf6WjeagoymntAJMPd1HXAjP7dVgiecbCemfhK5361KzD7AG6zjfPkp/JSWPi1fNp/vItv9HQ+PBX+FC8AAAAASUVORK5CYII=",
"palette": {
"_type": "sanity.imagePalette",
"darkMuted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#3b2474",
"foreground": "#fff",
"population": 0,
"title": "#fff"
},
"darkVibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#331f65",
"foreground": "#fff",
"population": 0,
"title": "#fff"
},
"dominant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#b8a8d5",
"foreground": "#000",
"population": 0.12,
"title": "#fff"
},
"lightMuted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#b8a8d5",
"foreground": "#000",
"population": 0.12,
"title": "#fff"
},
"lightVibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#a484f1",
"foreground": "#000",
"population": 0.01,
"title": "#fff"
},
"muted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#8274b2",
"foreground": "#fff",
"population": 0.01,
"title": "#fff"
},
"vibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#9074d4",
"foreground": "#fff",
"population": 0,
"title": "#fff"
}
}
},
"mimeType": "image/png",
"originalFilename": "image.png",
"path": "images/rafvlnhi/production/f0b7723d4380b45ce1133909fc40864254851923-872x609.png",
"sha1hash": "f0b7723d4380b45ce1133909fc40864254851923",
"size": 32091,
"uploadId": "0WiJLE5m3NVktCZupR1V3RzRwQDJ4fFj",
"url": "https://cdn.sanity.io/images/rafvlnhi/production/f0b7723d4380b45ce1133909fc40864254851923-872x609.png"
},
"caption": "Source: Cloudsmith Navigator",
"link": {
"_type": "link",
"href": null,
"openInNewTab": false
},
"markDefs": null
}
```
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 **/api/v1/validate/code** endpoint.
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 [Known Exploited Vulnerabilities](https://www.cisa.gov/news-events/alerts/2025/05/05/cisa-adds-one-known-exploited-vulnerability-catalog) (KEV) catalog, indicating confirmed exploitation in the wild.
```json
{
"_key": "8dd3fd079548",
"_type": "tableBlock",
"firstRowIsHeader": false,
"markDefs": null,
"table": {
"rows": [
{
"_key": "f284e62a-c0f4-47ce-9db3-0d607c793c8b",
"_type": "tableRow",
"cells": [
"CVE Identifier",
"CVE-2025-3248"
]
},
{
"_key": "022286e6-e9fe-4df5-9c9c-f3174b3f27af",
"_type": "tableRow",
"cells": [
"CVSS Score",
"CVSS Score: 9.8 (Critical)"
]
},
{
"_key": "eb159084-f76f-4256-83c5-46950adf0c97",
"_type": "tableRow",
"cells": [
"Vector",
"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"
]
},
{
"_key": "698c4a59-685b-4a04-8fb7-fc28fd6c6eee",
"_type": "tableRow",
"cells": [
"Affected Versions",
"Langflow versions before 1.3.0"
]
},
{
"_key": "77a638fb-4241-4290-9c98-fd250b154ae4",
"_type": "tableRow",
"cells": [
"Vulnerability Type",
"Missing authentication, Code Injection"
]
},
{
"_key": "b35fe75e-a7c3-4172-ace3-a19580a93324",
"_type": "tableRow",
"cells": [
"Impact",
"Allows remote unauthenticated attackers to execute arbitrary code"
]
}
]
}
}
```
### How to Quarantine Affected Langflow Packages using Cloudsmith EPM
Cloudsmith [Enterprise Policy Management](/blog/enterprise-policy-management-with-cloudsmith) (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 [OPA Rego policy](https://www.openpolicyagent.org/docs/policy-language) that flags packages with a **CVSS score above 6, if** they have a **known fix available**. This policy will detect vulnerable versions of Langflow, which have a **CVSS score of 9.8**. The vulnerability was addressed in **version 1.3.0**.
```json
{
"_key": "14864a805615",
"_type": "code",
"code": "package cloudsmith\nimport rego.v1\n\ndefault match := false\n\n# Define minimum CVSS score threshold\nmax_cvss_score := 6\n\n# Define time-based policy threshold (Vulnerabilities older than 10 days)\nolder_than_days := -10\n\n# Define CVEs to ignore\nignored_cves := {\"CVE-2023-45853\", \"CVE-2024-12345\"}\n\nmatch if {\n # some vulnerability in input.v0.security_scan.Vulnerabilities (deprecated)\n some target in input.v0.security_scan\n some vulnerability in target.Vulnerabilities\n\n not ignored_cve(vulnerability)\n vulnerability.FixedVersion\n vulnerability.Status == \"fixed\"\n\n some _, val in vulnerability.CVSS\n val.V3Score >= max_cvss_score\n\n t := time.add_date(time.now_ns(), 0, 0, older_than_days)\n published_date := time.parse_rfc3339_ns(vulnerability.PublishedDate)\n published_date <= t\n}\n\nignored_cve(vulnerability) if {\n vulnerability.VulnerabilityID in ignored_cves\n}",
"filename": null,
"language": "rego",
"markDefs": null
}
```
Langflow includes numerous dependencies (such as [**langchain**](https://pypi.org/project/langchain/), [**pydantic**](https://pypi.org/project/pydantic/), and [**fastapi**](https://pypi.org/project/fastapi/)) 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 -**-no-deps** flag to avoid downloading unnecessary dependencies.
```json
{
"_key": "95738ad52bf5",
"_type": "code",
"code": "pip download langflow==1.2.0 --no-deps",
"filename": null,
"language": "shell",
"markDefs": null
}
```
The package was pushed to Cloudsmith with a custom tag referencing **CVE-2025-3248**. Note that it was synchronized and automatically quarantined based on the EPM policy we put in place.
```json
{
"_key": "cfea04a6f3c4",
"_type": "code",
"code": "cloudsmith push python acme-corporation/acme-repo-one langflow-1.2.0-py3-none-any.whl -k \"$CLOUDSMITH_API_KEY\" --tags CVE-20205-3248",
"filename": null,
"language": "shell",
"markDefs": null
}
```
```json
{
"_key": "4802e1ba04df",
"_type": "image",
"asset": {
"_createdAt": "2025-06-17T14:44:20Z",
"_id": "image-eb606a4d461af2c9260eda60e21f7be0676f9d17-1600x527-png",
"_rev": "8MqCphtmQoMdZfTLqTc37c",
"_type": "sanity.imageAsset",
"_updatedAt": "2025-06-17T14:44:20Z",
"assetId": "eb606a4d461af2c9260eda60e21f7be0676f9d17",
"extension": "png",
"metadata": {
"_type": "sanity.imageMetadata",
"blurHash": "D25Y80_N%MtRk8-=xvtQocWA",
"dimensions": {
"_type": "sanity.imageDimensions",
"aspectRatio": 3.0360531309297913,
"height": 527,
"width": 1600
},
"hasAlpha": false,
"isOpaque": true,
"lqip": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAHCAIAAACHqfpvAAAACXBIWXMAAAsTAAALEwEAmpwYAAABF0lEQVR4nG3QV26EMBAAUI7CAgY3mikuLAazxbRsSPb+d4nIJhEfkZ5G8zPV6ebJrKuZtu72rvq1bqZCWJqbACsfSR/JU8TdsP6X002zWd46+1BmKZVNqwtlBqU6pM2ONGCnANnzAEkPil/cae2ox7m9r82wcj2VyjJxz+przAxlPcl7nHUvJO9h0v40ok2ApTOMH5fpcxifxj71dVP9wrVlaqBli9kZ5xqmLSBNsNeov1v87xUcPWxn81DdIvRcNrdMmlS0pFawqFEhaalR1vpYulC4kO/x8AIn5X1caczOUSajVESZgJkMUx7QCiQ8ShSIlYflCYkdFMf/OajkqBAg4R6uPFKDWISx8pE4hbUbHfHjzFfxF53vU149w+MeAAAAAElFTkSuQmCC",
"palette": {
"_type": "sanity.imagePalette",
"darkMuted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#343464",
"foreground": "#fff",
"population": 0.01,
"title": "#fff"
},
"darkVibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#140c34",
"foreground": "#fff",
"population": 0,
"title": "#fff"
},
"dominant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#343464",
"foreground": "#fff",
"population": 0.01,
"title": "#fff"
},
"lightMuted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#b4b4cc",
"foreground": "#000",
"population": 0,
"title": "#fff"
},
"lightVibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#a393e6",
"foreground": "#000",
"population": 0,
"title": "#fff"
},
"muted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#7c749c",
"foreground": "#fff",
"population": 0,
"title": "#fff"
},
"vibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#4f2fcf",
"foreground": "#fff",
"population": 0,
"title": "#fff"
}
}
},
"mimeType": "image/png",
"originalFilename": "image.png",
"path": "images/rafvlnhi/production/eb606a4d461af2c9260eda60e21f7be0676f9d17-1600x527.png",
"sha1hash": "eb606a4d461af2c9260eda60e21f7be0676f9d17",
"size": 339567,
"uploadId": "IandGPcMrw01hYCbzHeXvcUgwzCsUVxp",
"url": "https://cdn.sanity.io/images/rafvlnhi/production/eb606a4d461af2c9260eda60e21f7be0676f9d17-1600x527.png"
},
"link": {
"_type": "link",
"href": null,
"openInNewTab": false
},
"markDefs": null
}
```
In the Cloudsmith UI, you can see that the **Langflow 1.2.0 package** (containing the known vulnerability) was successfully quarantined right after it synced. Alongside the automatically generated SBOM, the package also has an additional **policy-violated** tag applied by the EPM policy, indicating that it was quarantined due to a security policy violation.
```json
{
"_key": "a017db77dc0b",
"_type": "image",
"asset": {
"_createdAt": "2025-06-17T14:44:36Z",
"_id": "image-a5ec63d7f6720eb4d3ad5709cb6718b176457fd8-1600x882-png",
"_rev": "oCTNwUG7Gqordp10rd7GGp",
"_type": "sanity.imageAsset",
"_updatedAt": "2025-06-17T14:44:36Z",
"assetId": "a5ec63d7f6720eb4d3ad5709cb6718b176457fd8",
"extension": "png",
"metadata": {
"_type": "sanity.imageMetadata",
"blurHash": "M6S?DXxuD%?bM{_4WAoeIVj]9axuIoxuRj",
"dimensions": {
"_type": "sanity.imageDimensions",
"aspectRatio": 1.8140589569160999,
"height": 882,
"width": 1600
},
"hasAlpha": true,
"isOpaque": false,
"lqip": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAALCAYAAAB/Ca1DAAAACXBIWXMAAAsTAAALEwEAmpwYAAABZElEQVR4nIWRS27eMAyEdf9r9ADd9ihF0UWArrpJbOtB8aUpSPlP0geaxWfZY2k0JMvLNXD1iUaCPhV9ChopxjSwOsRWwrLQquM8DL07JjuIDZP3vjjz87miHJVwNkIn2Rsk8G2mDrUFNSQswJzbPP7xzVRHZ0UdjFIb4awdgxiiBrUgjBwslpqvhbUAX8jVLC4zSKzmGWKwgtVQqA3QIIgo3FcSpiyaWhwOQ/O4ZJsnvnVfC5r/9nehq2HShKrtFB4laSZmvg0f2uTfEi+8Ix4ACnUCRblirwnlLjcusdTwpmWSt/LXH5TJCmIBs0BEIKo51RiGBR6pkesD/4dmt1ayuYEoiGaWOnLaMclt+BjIh/hCiUbntNQy6ZhBpN767tfHRGvCo0xm0Nx0muiD0AZh0AQxv047WqH/4bgqvj39QDmv6se5eTlOf77Z75cfZ1D9vJq31r33vwn96/cn//T5i/8Cm4le0soU8uMAAAAASUVORK5CYII=",
"palette": {
"_type": "sanity.imagePalette",
"darkMuted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#2c4454",
"foreground": "#fff",
"population": 0,
"title": "#fff"
},
"darkVibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#112b39",
"foreground": "#fff",
"population": 0.23,
"title": "#fff"
},
"dominant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#112b39",
"foreground": "#fff",
"population": 0.23,
"title": "#fff"
},
"lightMuted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#b4d4dc",
"foreground": "#000",
"population": 0,
"title": "#000"
},
"lightVibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#926fed",
"foreground": "#fff",
"population": 0.05,
"title": "#fff"
},
"muted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#b4748c",
"foreground": "#fff",
"population": 0.05,
"title": "#fff"
},
"vibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#7450e0",
"foreground": "#fff",
"population": 0.01,
"title": "#fff"
}
}
},
"mimeType": "image/png",
"originalFilename": "image.png",
"path": "images/rafvlnhi/production/a5ec63d7f6720eb4d3ad5709cb6718b176457fd8-1600x882.png",
"sha1hash": "a5ec63d7f6720eb4d3ad5709cb6718b176457fd8",
"size": 202533,
"uploadId": "umQxXlpR19OIozh6viXHLs2iLfXpEa7n",
"url": "https://cdn.sanity.io/images/rafvlnhi/production/a5ec63d7f6720eb4d3ad5709cb6718b176457fd8-1600x882.png"
},
"link": {
"_type": "link",
"href": null,
"openInNewTab": false
},
"markDefs": null
}
```
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 **/api/v1/validate/code** endpoint.
```json
{
"_key": "5089fc0a0721",
"_type": "image",
"asset": {
"_createdAt": "2025-06-17T14:44:54Z",
"_id": "image-4282c95a51b283c13907eaa684a4797ddd54cbc1-1600x882-png",
"_rev": "8MqCphtmQoMdZfTLqTcDxf",
"_type": "sanity.imageAsset",
"_updatedAt": "2025-06-17T14:44:54Z",
"assetId": "4282c95a51b283c13907eaa684a4797ddd54cbc1",
"extension": "png",
"metadata": {
"_type": "sanity.imageMetadata",
"blurHash": "M6S$u@-=IV-=M{_4Iot7RQofD*%LInxuR*",
"dimensions": {
"_type": "sanity.imageDimensions",
"aspectRatio": 1.8140589569160999,
"height": 882,
"width": 1600
},
"hasAlpha": true,
"isOpaque": false,
"lqip": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAALCAYAAAB/Ca1DAAAACXBIWXMAAAsTAAALEwEAmpwYAAABYUlEQVR4nI1TW04DMQzM/W/BBfjmIHzBR4UQooh22+2+Ejv2oHG2tLwkKo3sNMl4ZqJN/bjgNBWMs2DKimkRjItgzhVFDVI9UMQxjob+WDFNFUsxLEUDPMf7232PNGf53MhSkUuNWsSg1aHmUUUduThybuRFCYPEUAsBhyEjBRGnyKpGDUW4VqiStKHEEI2+mqNWj+qOAHveTbQ3zM1ipgqhEg4RyEpgRiVULxBV2BWRY8Xap3lRjLNiLhaEtEJ7YUUvts/qaa+pww+YAylnBUkjNxIFAVpmzDRgAWZGRB8RIc7G+bVPKhUidc3KYeskqmi5tewCyqFtzQiYm3k7f3685O7wyOSSC3+szKqh5Xi9/nrHUY1RWCPkv23zfzhP/k7IR0wh/2zpCnzNv8D9LIol84NYonb9gIfNM1LXj/YbjqfJ+uEnDqfJ9v1gu36w7a6zp5c3e33v7P5xYze3d/YBWgte7shIbskAAAAASUVORK5CYII=",
"palette": {
"_type": "sanity.imagePalette",
"darkMuted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#2c4454",
"foreground": "#fff",
"population": 0.01,
"title": "#fff"
},
"darkVibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#1c394c",
"foreground": "#fff",
"population": 0.03,
"title": "#fff"
},
"dominant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#a2b1d7",
"foreground": "#000",
"population": 0.04,
"title": "#fff"
},
"lightMuted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#a2b1d7",
"foreground": "#000",
"population": 0.04,
"title": "#fff"
},
"lightVibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#9c78f7",
"foreground": "#fff",
"population": 0.01,
"title": "#fff"
},
"muted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#718c9c",
"foreground": "#fff",
"population": 0.01,
"title": "#fff"
},
"vibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#7450e0",
"foreground": "#fff",
"population": 0.01,
"title": "#fff"
}
}
},
"mimeType": "image/png",
"originalFilename": "image.png",
"path": "images/rafvlnhi/production/4282c95a51b283c13907eaa684a4797ddd54cbc1-1600x882.png",
"sha1hash": "4282c95a51b283c13907eaa684a4797ddd54cbc1",
"size": 171346,
"uploadId": "iq4GsJokvcWS9z9fzWuu3jlIPoKLxG2i",
"url": "https://cdn.sanity.io/images/rafvlnhi/production/4282c95a51b283c13907eaa684a4797ddd54cbc1-1600x882.png"
},
"link": {
"_type": "link",
"href": null,
"openInNewTab": false
},
"markDefs": null
}
```
### Understanding if you’re affected
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 [Shodan](https://www.shodan.io/search/report?query=Langflow).
We could craft a similar [GitHub Search query](https://github.com/search?q=%28langflow+OR+gradio+OR+fastapi%29+AND+%28%220.0.0.0%22+OR+%22host%3D0.0.0.0%22+OR+%22%3A7860%22+OR+%22%3A8501%22+OR+%22%3A8080%22%29+AND+%28path%3A*.py+OR+path%3A*.env+OR+path%3A*.yml+OR+path%3A*.sh%29&type=code) to detect publicly exposed Langflow servers by targeting typical indicators in configuration files, environment files, and code snippets. Langflow is typically launched via FastAPI and Gradio, often bound to a public IP like 0.0.0.0 with a known port like 7860 or 8501.
```json
{
"_key": "34fa4b1a609f",
"_type": "code",
"code": "(langflow OR gradio OR fastapi) AND (\"0.0.0.0\" OR \"host=0.0.0.0\" OR \":7860\" OR \":8501\" OR \":8080\") AND (path:*.py OR path:*.env OR path:*.yml OR path:*.sh)",
"filename": null,
"language": null,
"markDefs": null
}
```
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).
### How is vulnerability exploited?
The attacker uses a [public proof-of-concept from GitHub](https://github.com/verylazytech/CVE-2025-3248) 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.
The vulnerability lies in the **/api/v1/validate/code** endpoint, which is meant to validate Python code. This endpoint lacks proper authentication and executes user-submitted code using Python's [ast.parse()](https://how.dev/answers/what-is-the-astparse-method-in-python), 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.
### Securing everything that comes from PyPI
CVE-2025-3248 highlights the power of auditing and securing everything that comes from public upstreams. When you use [upstream proxying and caching](https://changelog.cloudsmith.com/en/proxy-and-cache-python-packages-through-cloudsmith), 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.
Insecure system configuration is a textbook example of how neglected settings can create an entry point for attackers targeting your CI/CD pipelines. It’s rarely the cutting-edge zero-day that causes a breach. More often, it’s the unpatched service, the overly permissive role, or the default password that was never changed.
While this risk overlaps with CI/CD credential hygiene (covered in [**Part 6**](/blog/owasp-ci-cd-part-6-insufficient-credential-hygiene) of our OWASP CI/CD series), the focus here is much broader. This blog post addresses the overall hardening of systems across your pipeline. Yes, weak or default credentials may be part of the problem, but they’re just one symptom of a larger issue in misconfigured systems that were never designed with security in mind.
##### Why Insecure System Configuration is a Top CI/CD Security Risk
At Cloudsmith, we think about this risk constantly. Configuration is the foundation of your security posture. And when you’re managing artifacts (arguably the most sensitive assets in your software supply chain) you need absolute confidence in the integrity and security of every system that touches them.
### The problem with “Insecure by Default” in CI/CD Pipelines
Continuous Integration and Continuous Delivery (CI/CD) stacks are a composite of systems, some SaaS, others self-hosted, and often from different vendors and with distinct security models. Each layer (application, network, and infrastructure) contributes its own configuration surface area. Misconfigure any piece, and the entire chain inherits the weakness.
**Examples of these common CI/CD misconfigurations:**
- Outdated Jenkins or GitLab runners with known vulnerabilities. For [**example**](https://gitlab.com/gitlab-org/gitlab/-/issues/363614), in GitLab, managing a large fleet of runners at the group level can make it difficult to track which ones are out of date. Runners that aren’t upgraded regularly may miss critical security patches, leaving your pipeline infrastructure exposed.
- Artifact repositories exposing ports or APIs publicly. For [**example**](https://github.com/search?q=%22artifact%22+AND+%28%220.0.0.0%2F16%22+OR+%220.0.0.0%3A8081%22+OR+%22public%22%29+AND+%28path%3A*.conf+OR+path%3A*.yml+OR+path%3A*.env+OR+path%3A*.tf+OR+path%3A*.json%29&type=code), you could query for Terraform or IaC exposing artifact repo via an open port. By running a modified version of the _GitHub Search_ query below, adversaries could find Terraform (**.tf**) or similar configs where artifact systems are binding to all interfaces or exposed ports:
```json
{
"_key": "706c274a91eb",
"_type": "code",
"code": "\"artifact\" AND (\"0.0.0.0/16\" OR \"0.0.0.0:8081\" OR \"public\") AND (path:*.conf OR path:*.yml OR path:*.env OR path:*.tf OR path:*.json)",
"filename": null,
"language": null,
"markDefs": null
}
```
- Default credentials **should never be used** in any environment, not even in staging, and especially not when those credentials are publicly accessible. Staging environments should be secured to the same standards as production.
- Pipeline agents being afforded full OS access with persistent credentials in memory. Reference the [**OWASP Cheatsheet**](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html#25-handling-secrets-in-memory) for best practices around minimizing the time window where a secret is in memory and limiting access to its memory space.
- Poor logging setups, leaving no audit trail when something does go wrong. We’ll talk about this in greater detail in [**part 10**](https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-10-Insufficient-Logging-And-Visibility) of the OWASP series. Attackers could, [**for example**](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html#34-logging-and-accounting), use an admin interface or automated job to exfiltrate secrets using encryption or **double base64** encoding. In this way, we should be logging every action within our CI/CD system.
### Cloudsmith’s perspective on “Secure by Design”
As a fully managed, cloud-native artifact management platform, Cloudsmith is built around secure configuration by default. Here’s how our approach mitigates the types of risks outlined in [**CICD-SEC-7**](https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-07-Insecure-System-Configuration):
1. **Immutable infrastructure with managed updates:**
Self-hosted repositories and build systems often lag on patching due to upgrade complexity. Cloudsmith removes that burden. As a SaaS platform, patches and security fixes are applied continuously behind the scenes. No action is required by customers, and no outdated binaries are exposed.
2. **Fine-grained access controls:**
CI/CD misconfigurations often stem from over-broad permissions. In Cloudsmith:
- You can define [**token bandwidth controls**](/blog/restore-authority-with-token-bandwidth-controls), [**Entitlement Permissions**](https://help.cloudsmith.io/docs/entitlements#permissions) scopes and lifetimes with surgical precision.
- Enforce [**RBAC**](https://help.cloudsmith.io/docs/access-controls) for users and teams to help ensure least privilege at the org, repo, and user level.
- Artifact access is always protected by HTTP/S with authentication to prevent users from anonymously accessing public artifact repositories. Go a step further by enforcing [**Multi-Factor Authentication**](https://help.cloudsmith.io/docs/two-factor-authentication) (MFA) for all users in Cloudsmith.
3. **Secure defaults:**
Misconfigured systems often rely on insecure defaults. Cloudsmith’s default posture includes:
- Cloudsmith repositories that are [**Private by Default**](https://cloudsmith.com/product/formats/p2-repository) and require authentication for access. Users can choose between entitlement token authentication or HTTP Basic Authentication for accessing these private repositories.
- Cloudsmith doesn't have default username and password credentials for API access. Instead, [**users authenticate using their API key**](https://help.cloudsmith.io/docs/api-key), which can be retrieved through the _cloudsmith login_ command or by accessing their user settings. For SAML SSO users, the [**CLI supports authentication with SAML**](https://changelog.cloudsmith.com/en/cloudsmiths-cli-now-supports-authenticating-with-saml-single-sign_on), eliminating the need to retrieve API keys from the web application.
- Cloudsmith enforces [**strict rate limiting**](https://help.cloudsmith.io/reference/rate-limits) and automated IP reputation filtering. Unless specified otherwise, all requests to the API are rate limited to prevent abuse, accidental or otherwise.
These defaults matter, especially when systems are being provisioned and connected to CI tools automatically.
4. **Audit and traceability:**
Finally, you can’t secure what you can’t see. Cloudsmith's [**Audit Logs**](https://help.cloudsmith.io/docs/repo-audit-logs) track every action (upload, download, token use, deletion) with full audit trails and webhook integrations. This makes it significantly easier to trace incidents, validate configurations, and enforce compliance.
### Hardening beyond artifacts
Whether you’re using Cloudsmith or managing your own stack, here are **6 proactive actionable steps** we recommend in our [**OWASP eBook**](https://cloudsmith.com/campaigns/guide-to-mitigating-owasp-top-10-ci-cd-security-risks):
```json
{
"_key": "69edb49e16cb",
"_type": "tableBlock",
"firstRowIsHeader": true,
"markDefs": null,
"table": {
"rows": [
{
"_key": "031167c5-f7a9-4fcf-9b34-22e22e65179e",
"_type": "tableRow",
"cells": [
"Recommendation",
"Description"
]
},
{
"_key": "aba36ad6-684e-4846-9ae4-2e7493af4614",
"_type": "tableRow",
"cells": [
"Maintain an inventory of systems and versions",
"Track all systems and their versions, mapping each system to an owner. Regularly check for known CVEs and apply patches, or restrict access."
]
},
{
"_key": "443f47ad-56bd-4058-b89e-90505f076b2e",
"_type": "tableRow",
"cells": [
"Ensure least-privilege network access",
"Limit network access to systems strictly based on need, ensuring only necessary services can communicate."
]
},
{
"_key": "13b35d11-939a-4b1f-856d-806e26113945",
"_type": "tableRow",
"cells": [
"Periodically review and optimise configurations",
"Regularly audit system configurations to ensure all security settings are aligned with best practices and properly optimised."
]
},
{
"_key": "02aa1ce7-a990-46fc-936f-7a6272f937e1",
"_type": "tableRow",
"cells": [
"Enforce least-privilege permissions",
"Assign permissions based on the minimum required for functionality. Avoid granting debug permissions to engineers, as this could expose sensitive data or elevate privileges unintentionally."
]
},
{
"_key": "8250d90d-2e49-4128-86f3-42b5c4f917b1",
"_type": "tableRow",
"cells": [
"Secure SaaS CI/CD configurations",
"While SaaS solutions reduce some risks, ensure that the security configurations of the chosen SaaS CI/CD tools are set correctly and follow recommended best practices."
]
},
{
"_key": "d2348a4b-fb17-4c14-bda0-403254db0f3e",
"_type": "tableRow",
"cells": [
"Proactively manage security posture",
"OpenSSF’s Minder helps enforce security best practices by continuously monitoring repositories and ensuring they are configured securely through policy enforcement."
]
}
]
}
}
```
### Secure Your CI/CD Pipelines With Cloudsmith
At Cloudsmith, we strongly believe artifact management is about **trust**, **control**, and **visibility**. And secure configuration is where that trust begins.
If you’re looking to harden your pipeline end-to-end, don’t feel like the job is done after scanning your code. Scan your infrastructure. Review your configs. And if you’re managing your artifacts, consider doing it somewhere that’s [**already hardened for you**](https://help.cloudsmith.io/docs/security).
If you found this content helpful and want to dive deeper into securing your CI/CD pipelines, beyond credential hygiene best practices, be sure to check out our free Cloudsmith eBook on the OWASP Top 10 for CI/CD security risks - [**download it here**](https://cloudsmith.com/campaigns/guide-to-mitigating-owasp-top-10-ci-cd-security-risks).
```json
{
"_key": "7bc2a0e27466",
"_type": "image",
"asset": {
"_createdAt": "2025-06-17T14:33:58Z",
"_id": "image-b4503c55a088b4cd7808383513b963a525b0aa77-1000x563-png",
"_rev": "8MqCphtmQoMdZfTLqTXryy",
"_type": "sanity.imageAsset",
"_updatedAt": "2025-06-17T14:33:58Z",
"assetId": "b4503c55a088b4cd7808383513b963a525b0aa77",
"extension": "png",
"metadata": {
"_type": "sanity.imageMetadata",
"blurHash": "M-G,,??]ofIBt7ofRQWBofkBt7V[fQkCay",
"dimensions": {
"_type": "sanity.imageDimensions",
"aspectRatio": 1.7761989342806395,
"height": 563,
"width": 1000
},
"hasAlpha": false,
"isOpaque": true,
"lqip": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAALCAIAAADwazoUAAAACXBIWXMAAAsTAAALEwEAmpwYAAACRklEQVR4nGPY9vTKpgfnN9w7u/H+uQ33zq27c2bt7dMb7p/b8eLq2rtnO7etL184v3TBvKJ5c0BoPhjNm1O9bNGk/dsY1tw8teTioYVnDyw8u3/eqb2zj+2af2rf8itHNz08P/vE3tC6FtOoDP3QFK3ABA3/eI0AENL0i7WKy0rtn8iw9OLhOcd3zTq6c9bRHTMOb59+cNuicwe3PL645/WNaYd3uWaXKbtGKjiFSdsFiVj48hi5cxu4CRi4qTiHhdQ0MSy5eHjW0Z0zD2+feWTH7GO75hzfvfTSkZ0vrh38eG/msT0+xTUGISmGISm6AYmKruFC5j58Ru5ixp7a7pFhdc0M6++eXX7l6NJLh5dcOLTs0uEVV4+uvnFy29Mr+97dnn50t1tBuap/rJp/rJJ3tKR9EJ+JJ4+hm4Chu4pbeEhtE8OuVzd2PLu6/enlrY8vbX18advTy9ueXt714tq+t7emHt5pm14gYusvbOsnZO3LZ+rJbeDGbejGY+gm7xIaXNvEcPDjvYMf7x78ePfAhzsQtB9EgkSmHt5pkZjDY+TBbegOQgZu3AZufEbufEbuCq5hIXVNDIc/Pzj8+f7hL0gIzD30+R5Ic0IOt4Ebl74rF1Snh6CJp4CRh6JrWChYM1Q1mhEIzYYgzTyGIJ0Cxp6Cpl78Rh4wm5HthKIHh788OPT5/tQjMM0GrryG7gLGHqKmXpLmPkLGHvIuYSA/Q5QegZFwBNa8yyIhh8fQndfQnc/YU9DEU8nC19AmUNbUG6IZABESY6PtboKAAAAAAElFTkSuQmCC",
"palette": {
"_type": "sanity.imagePalette",
"darkMuted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#32455a",
"foreground": "#fff",
"population": 1.44,
"title": "#fff"
},
"darkVibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#0a3043",
"foreground": "#fff",
"population": 29.98,
"title": "#fff"
},
"dominant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#0a3043",
"foreground": "#fff",
"population": 29.98,
"title": "#fff"
},
"lightMuted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#acd3c4",
"foreground": "#000",
"population": 0.06,
"title": "#fff"
},
"lightVibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#c4fce2",
"foreground": "#000",
"population": 0.12,
"title": "#000"
},
"muted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#6e9390",
"foreground": "#fff",
"population": 1.19,
"title": "#fff"
},
"vibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#ba5777",
"foreground": "#fff",
"population": 0.27,
"title": "#fff"
}
}
},
"mimeType": "image/png",
"originalFilename": "image.png",
"path": "images/rafvlnhi/production/b4503c55a088b4cd7808383513b963a525b0aa77-1000x563.png",
"sha1hash": "b4503c55a088b4cd7808383513b963a525b0aa77",
"size": 306589,
"uploadId": "deu08p8pUopNMNqVF5heaKGs0mzacMzH",
"url": "https://cdn.sanity.io/images/rafvlnhi/production/b4503c55a088b4cd7808383513b963a525b0aa77-1000x563.png"
},
"link": {
"_type": "link",
"href": "https://cloudsmith.com/campaigns/guide-to-mitigating-owasp-top-10-ci-cd-security-risks",
"linkType": "href",
"openInNewTab": true
},
"markDefs": null
}
```
This post, part six of our ****OWASP CI/CD Top 10**** series, looks at some of the common risks associated with Insufficient Credential Hygiene. By better understanding the flaws that affect credential hygiene, we can better understand how even the most sophisticated pipelines were compromised.
### What is Insufficient Credential Hygiene?
CI/CD systems rely heavily on credentials (application secrets, tokens, deploy keys, and more) to operate. These [****secrets****](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-what-is-secret) move between services, repositories, environments, and human actors, creating a complex web of access points.
When these credentials are:
- poorly managed,
- overly permissive,
- hardcoded in code,
- or left unrotated,
they become prime targets for attackers. Once compromised, these secrets offer [****lateral movement****](https://attack.mitre.org/tactics/TA0008/) opportunities to adversaries with the intention of directly accessing your code, infrastructure, and data.
### Why is it so hard to get right?
The challenge lies in ****context**** and ****scale****.
Secrets live in many places: code repositories, CI/CD configuration files, container images, build logs, and even in the runtime environment. They're used by humans, machines, and processes across different trust boundaries - each with their own associated requirements and risks.
Unlike a centralized authentication system, secrets management is often distributed, ad hoc, and invisible until breached.
### Common credential hygiene pitfalls
Here are some of the most pervasive and dangerous practices seen in real-world CI/CD environments.:
1. ****Secrets accidentally committed to code****
Whether intentional or accidental, [****secrets committed to version control****](https://softwareengineering.stackexchange.com/questions/382587/keeping-secrets-out-of-source-control-are-we-just-moving-the-problem) are a time bomb. Even if deleted from the latest branch, they remain visible in the commit history to anyone with access.
2. ****Overly-permissive credentials in pipelines****
CI/CD pipelines often use credentials to access source code, artifact repositories, cloud resources, and production systems. Without ****tight scoping**** (which limits what actions credentials can perform and what resources they can access) and ****context-aware permissions**** (which grant access only under specific conditions like IP Address, time of day, or workload identity) these credentials can become open doors for unauthorized access.
Ask yourself:
- Does each pipeline only access the secrets it needs?
- Are secrets scoped to specific environments or job steps?
- Can unreviewed code access production secrets?
Where possible, organizations should enforce the [****principle of least privilege****](https://devops.com/resolving-ci-cd-permissions-issues-to-address-delivery-needs/#:~:text=Practice%20Least%2DPrivilege%20Access) to credentials.
3. ****Secrets embedded in container image layers****
[****Build-time secrets****](https://docs.docker.com/build/building/secrets/) (such as API tokens or SSH keys) can inadvertently remain in [****container image layers****](https://docs.docker.com/get-started/docker-concepts/building-images/understanding-image-layers/). Anyone with access to the image can retrieve them, even if they’re not meant to persist beyond the build.
4. ****Secrets printed to build logs****
Even a secure secret, once [****printed in plain text****](https://stackoverflow.com/questions/79136976/hiding-secrets-in-github-actions-workflow-logs) during a build, becomes a liability. Logs may be stored indefinitely, aggregated into third-party observability platforms, or exposed through dashboards.
5. ****Unrotated, long-lived credentials****
Static credentials that never expire are dangerous - especially in environments with high personnel turnover or external contractors. Without regular rotation, credentials accumulate risk with every day they remain active. [****Ephemeral credentials****](https://www.chainguard.dev/unchained/the-principle-of-ephemerality#:~:text=Ephemeral%20credentials) is a production best-practice that ensures credentials are short-lived.
### Real-world breaches caused by poor credential hygiene
1. ****Travis CI & Public Repository Exposure****
In 2021, [****Travis CI experienced a security issue****](https://travis-ci.community/t/security-bulletin/12081) where secure environment variables (type of secrets) were exposed during builds triggered by pull requests to public repositories. Even though secrets were encrypted in storage, they were made accessible during build execution, potentially leaving them susceptible to compromise by anonymous users issuing pull requests against public repositories.
While the Travis CI team quickly patched the issue, it highlighted how even secure systems can leak secrets when trust boundaries are not well-defined. In this scenario, Travis CI has strongly recommended that both Public and Private Repository customers rotate their secrets on a regular basis****. ****If possible, users affected in these scenarios should set expiration dates on those tokens or rotate their secrets regularly; this reduces the risk of old secrets being exploited.
1. ****Uber’s Double Breach via GitHub****
Uber wasn't so fortunate. They experienced two major breaches tied to credential mismanagement. These breaches, detailed in the [****FTC’s Federal Register****](https://www.ftc.gov/system/files/documents/federal_register_notices/2018/04/152_3054_uber_revised_consent_analysis_pub_frn.pdf), highlighted a harsh reality:
```json
{
"_key": "b7ac2117c705",
"_type": "quote",
"content": [
{
"_key": "9c9cf89c5619",
"_type": "block",
"children": [
{
"_key": "c9b2070cbbfe0",
"_type": "span",
"marks": [],
"text": "When credentials leak, attackers don’t break in - they log in."
}
],
"markDefs": [],
"style": "normal"
}
],
"markDefs": null
}
```
In both breaches, no sophisticated exploitation was needed, just access to secrets that had been mishandled and left vulnerable.
****The 2014 Breach: A public repo exposure****
In May 2014, attackers discovered an AWS access key that was accidentally committed to a public GitHub repository. The key granted full administrative access to Uber’s Amazon S3 datastore. As a result, the intruder accessed sensitive personal data of over 100,000 drivers, including:
- Unencrypted names and driver’s license numbers
- Bank account and routing numbers
- Social Security numbers
Uber didn’t detect the breach until September 2014 (four months later) and continued uncovering additional impacted users well into 2016.
****The 2016 Breach: A private repo with public impact****
In a second incident between October and November 2016, attackers gained access to Uber’s private GitHub repositories. This time, the intrusion was facilitated by a combination of weak security controls:
- Credential reuse by engineers across personal and professional accounts
- Lack of multi-factor authentication (MFA)
- No policies to prevent leaked or reused passwords
Attackers used compromised credentials (previously exposed in unrelated breaches) to access Uber’s GitHub repositories, where they found yet another AWS access key. This key unlocked Uber’s S3 storage once again - leading to the theft of:
- 25.6 million names and email addresses
- 22.1 million mobile numbers
- Over 600,000 driver’s license numbers
Most of this data was stored in unencrypted backup files collected prior to 2015.
### Recommendations for sufficient credential hygiene in CI/CD
To mitigate these risks, organizations must adopt a proactive and layered approach to secrets management:
****1) Map the credential landscape****
- Continuous inventory where credentials are stored and used (across code, pipelines, and infrastructure).
- Classify & Tag secrets by sensitivity and exposure risk.
****2) Classify secrets by sensitivity and exposure risk****
- Scope each secret to the narrowest possible use case (per pipeline, environment, or job).
- Avoid shared credentials across teams or systems.
****3) Prefer ephemeral credentials****
- Use short-lived, automatically rotated credentials (such as IAM roles, OIDC tokens, Kubernetes Secrets).
- For static secrets, enforce periodic rotation and audit stale secrets.
****4) Restrict credential usage context****
- Bind secret usage to specific IPs, services, or identities.
- Block secrets from being used outside of intended pipelines or systems.
****5) Prevent secret leaks in code****
- Use tools like Git hooks, IDE plugins, and secret scanners to catch leaks before they hit the repository.
- Periodically scan historical commits for exposed secrets.
****6) Secure console output****
- Scrub secrets from build logs.
- Configure pipeline tools to redact or prevent printing sensitive data.
****7) Clean artifacts thoroughly****
- Inspect container images, binaries, and Helm charts for embedded secrets before deployment.
- Use dependency mapping to identify and visualize all software dependencies within your applications, such as a Docker image within a Helm chart that may contain sensitive credentials.
### Download our free eBook
If you found this content helpful and want to dive deeper into securing your CI/CD pipelines, beyond credential hygiene best practices, be sure to check out our free Cloudsmith eBook on the OWASP Top 10 for CI/CD systems - [****download it here****](https://cloudsmith.com/campaigns/guide-to-mitigating-owasp-top-10-ci-cd-security-risks).
```json
{
"_key": "13ead1839524",
"_type": "image",
"asset": {
"_createdAt": "2025-06-11T13:16:19Z",
"_id": "image-a4c45ba21450d0222e365fbc3d4d4fee19ba0e8f-1000x563-png",
"_rev": "h0mNXVMLila98w7dvLNq4B",
"_type": "sanity.imageAsset",
"_updatedAt": "2025-06-11T13:16:19Z",
"assetId": "a4c45ba21450d0222e365fbc3d4d4fee19ba0e8f",
"extension": "png",
"metadata": {
"_type": "sanity.imageMetadata",
"blurHash": "M-G,,??]ofIBt7ofRQWBofkBt7V[fQkCay",
"dimensions": {
"_type": "sanity.imageDimensions",
"aspectRatio": 1.7761989342806395,
"height": 563,
"width": 1000
},
"hasAlpha": true,
"isOpaque": true,
"lqip": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAALCAYAAAB/Ca1DAAAACXBIWXMAAAsTAAALEwEAmpwYAAACcklEQVR4nG3QS0hUURjA8Vmr2WgWSISPLKwI544OSmVBOS/f2jhiYSkYRbmQolxkLqxNqygw84GmqAVlmtQ4js+Z62hZM+YTy2eIIUWR2P4f914zkxZ/Dhw4P77vqGzLE7QvjtA27+Hlgpe2eS8vZt/TMvOOtgUv9pVJWuY83LW1Ulxfx/XHtVytrVGqW6+2hpvNDTzos6F6/nGYxlEX9Z5+6j191A73UD3ooG64lycTbto/j1D9poes0jvozlwiKquAgxl5RKadJzJd6UBqLkfOXebCvfuomkZFaoYcVLk7qXLbeSR2UOG00eB18mpplO5v0zwUHeiv3GCvPofQk1Z2H88kKC4FP60RX40BtcZAxCkrlpIyVI2jooxVih1UDtjl6WqGumgaG6BzZQrn6jyVg90kXytBYylAsBRwOD2fMH02gbHJ+GuN7Io2c8iYg7X0NqrWOY+8WtOYSOMHF81jIk8n3Tybfov0v70/Zqhwd2EoKmZfWi7703IJTzpL8IlM/GPM+AkG1IKRCEM2lltlqBxfp7F/maRjeZzXS2NytuVxOcfKFL3fP1EudhJ/sYig+DR2xKcSeDQFf51ZXtdXMMhoSEIWpyVQWsm5OifX/3N2oz75VO4lMC6/ED+tCV/BqCRhGoO8slSo3oqltAyVuLaIuLaA+GtL63eutXkFzCuUAZ8oPT4bmImAGDNqrYkwvZUsBfz7+H/wP6CggNKKEqaONhOgS2S71rRpwq2TbbQo51pboHxgE6jRs00woo42sVOXSHBsMoHRJkISrMof/nk4sOncnAI6ZNBPMMqYvzRZjJnwuBSEYxns0SVtgL8BZxE+1uiCF24AAAAASUVORK5CYII=",
"palette": {
"_type": "sanity.imagePalette",
"darkMuted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#32455a",
"foreground": "#fff",
"population": 1.44,
"title": "#fff"
},
"darkVibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#0a3043",
"foreground": "#fff",
"population": 29.98,
"title": "#fff"
},
"dominant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#0a3043",
"foreground": "#fff",
"population": 29.98,
"title": "#fff"
},
"lightMuted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#acd3c4",
"foreground": "#000",
"population": 0.06,
"title": "#fff"
},
"lightVibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#c4fce2",
"foreground": "#000",
"population": 0.12,
"title": "#000"
},
"muted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#6e9390",
"foreground": "#fff",
"population": 1.19,
"title": "#fff"
},
"vibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#ba5777",
"foreground": "#fff",
"population": 0.27,
"title": "#fff"
}
}
},
"mimeType": "image/png",
"originalFilename": "image.png",
"path": "images/rafvlnhi/production/a4c45ba21450d0222e365fbc3d4d4fee19ba0e8f-1000x563.png",
"sha1hash": "a4c45ba21450d0222e365fbc3d4d4fee19ba0e8f",
"size": 334809,
"uploadId": "W6vbW2XYLykEQcS0rO32k8Tz1h7AYy24",
"url": "https://cdn.sanity.io/images/rafvlnhi/production/a4c45ba21450d0222e365fbc3d4d4fee19ba0e8f-1000x563.png"
},
"link": {
"_type": "link",
"href": "https://cloudsmith.com/campaigns/guide-to-mitigating-owasp-top-10-ci-cd-security-risks",
"linkType": "href",
"openInNewTab": false
},
"markDefs": null
}
```
This blog contains the takeaways from our webinar "State of the Union: Modern security approaches for the Software Supply Chain." Watch the full discussion [here](/events/webinars/state-of-the-union-modern-security-approaches-for-the-software-supply-chain). Key topics include how to secure your CI/CD pipeline and software artifacts using SBOMs, Docker Hardened Images, and artifact lifecycle best practices.
Software supply chain attacks are on the rise, prompting a critical shift in how we secure modern software. Recent incidents like SolarWinds, XZ Utils, and Log4Shell underscore the urgent need for stronger security measures beyond just protecting production systems. Attackers are now targeting earlier stages of the supply chain, particularly build pipelines, impacting software integrity before it even reaches deployment.
In our [recent webinar](/events/webinars/state-of-the-union-modern-security-approaches-for-the-software-supply-chain), ****"****State of the Union: Modern security approaches for the Software Supply Chain****,"**** we brought together industry experts to tackle these challenges head-on. Michael Donovan, VP of Product at Docker, Ralph McTeggart, Principal Engineer at Cloudsmith, and Jack Gibson, Senior Software Engineer at Cloudsmith, shared their insights on how leading teams can defend themselves. During the session, they explored the evolving threat landscape, outlined a secure artifact lifecycle, and discussed strategies such as SBOMs to inject visibility, provenance, and trust into workflows without creating developer friction. While the focus was on container images, the principles discussed were equally applicable to other formats.
### ****Rethinking Software Supply Chain Security****
Software supply chain attacks have grown dramatically in both frequency and impact, prompting a fundamental shift in how software is secured. Incidents like SolarWinds, the XZ Utils backdoor attempt, and Log4Shell illustrate a sobering truth: attackers are now aiming upstream. Rather than targeting production systems directly, modern threats exploit vulnerabilities during the software build and integration phases, where visibility and control are often weakest.
As this attack surface expands, it’s no longer enough to harden runtime environments or secure production endpoints. The entire artifact lifecycle - from development to deployment - must be secured. This shift has led organizations to reassess their tooling, processes, and practices around software composition, packaging, and distribution.
### ****The Shift in Emphasis on Software Supply Chain Security****
```json
{
"_key": "e7e4f21fb24d",
"_type": "wistiaVideo",
"id": "5yy57xs7ii",
"markDefs": null,
"thumbnail": {
"_type": "image",
"asset": {
"_ref": "image-458acec144ba204a0f05af293a1c42d4d3b82529-900x506-png",
"_type": "reference"
}
},
"title": "The Shift in Emphasis on Software Supply Chain Security"
}
```
The strategic focus of software security has moved upstream. Major breaches have shown how attackers exploit weaknesses in CI/CD pipelines, source code repositories, and registry infrastructure, areas traditionally outside the purview of security teams.
Events like the SolarWinds compromise in 2020, which leveraged a poisoned build system, or the 2024 XZ Utils incident, where malicious code was inserted by a fake maintainer, underscore how early-stage compromises can lead to widespread downstream impacts. Similarly, Log4Shell revealed the global exposure caused by a single vulnerable dependency, forcing organizations to redirect substantial resources just to locate and patch affected systems.
In response, governments and regulatory bodies have escalated their focus on software supply chain security (SSCS). Executive directives, such as the U.S. Cybersecurity Executive Order, FedRAMP requirements, the EU’s NIS2 directive, and the forthcoming Cyber Resilience Act, demand secure development practices, transparent artifact composition, and provable software provenance.
As attacks increasingly originate at the source, securing the artifact lifecycle is now a foundational requirement - not a future goal.
### ****The Evolving Threat Landscape****
Modern software development is built around composability and speed. Applications today rely heavily on third-party libraries and frameworks, with open-source components making up as much as 75% or more of a typical codebase. The prevalence of transitive dependencies - indirect libraries brought in through direct ones - adds complexity and opacity to risk assessment.
At the same time, the efficiency of CI/CD pipelines can leave little room for traditional gatekeeping. Code is integrated, tested, and deployed rapidly, often using packages pulled directly from public registries with minimal verification. Unsigned artifacts, missing provenance data, and outdated registry configurations persist across many organizations.
This environment creates ideal conditions for silent, hard-to-detect supply chain threats. In response, software teams must move toward practices that ensure transparency, verification, and control at every phase of the build and release cycle.
### ****Using SBOMs and Establishing Provenance****
```json
{
"_key": "401ac20ef445",
"_type": "wistiaVideo",
"id": "vjxo35q4ax",
"markDefs": null,
"thumbnail": {
"_type": "image",
"asset": {
"_ref": "image-ce3ec448c20d98ebbede7948d29c482cbad60bd4-900x506-png",
"_type": "reference"
}
},
"title": "Using SBOMs and Establishing Provenance"
}
```
A foundational step in securing the software supply chain is understanding exactly what is being built and shipped. This is where three elements play a critical role:
- SBOMs (Software Bills of Materials): These list all components within a software artifact - names, versions, authors, licenses, and dependency relationships. Tools such as Syft and Trivy support SBOM generation in SPDX and CycloneDX formats. Docker supports SBOMs natively through the docker sbom command. Cloudsmith accepts external SBOM uploads or can auto-generate CycloneDX SBOMs for container images, exposing them via API for automation and policy enforcement.
- Digital Signatures: A signature confirms that an artifact originated from a known and trusted source. Tools like Cosign allow developers to sign and verify containers. Signed images enable downstream consumers to confirm authenticity before deployment.
- Provenance: Provenance data describes the origin of a build, including input sources, build parameters, and environments. Docker Buildx supports automated provenance generation using the --provenance flag, capturing crucial metadata such as build arguments and platforms.
Together, these elements create an auditable trail of software origin and composition. In regulatory contexts, SBOMs are now a standard requirement. But beyond compliance, they provide security teams with the ability to trace vulnerabilities to specific packages, drastically reducing remediation time and effort. Cloudsmith’s Enterprise Policy Management (EPM) leverages SBOM metadata for automated policy actions, such as quarantining risky images or enforcing license compliance based on live dependency data
### ****Tightening Security with Docker Hardened Images****
```json
{
"_key": "0a4d8de8ba26",
"_type": "wistiaVideo",
"id": "0wttolf9fj",
"markDefs": null,
"thumbnail": {
"_type": "image",
"asset": {
"_ref": "image-2797942ff9273aa36d1b7a33b305befac8f7a9e2-900x506-png",
"_type": "reference"
}
},
"title": "Tightening Security with Docker Hardened Images "
}
```
As organizations grapple with securing sprawling software pipelines, Docker Hardened Images (DHIs) offer a straightforward way to integrate trusted, verifiable container artifacts into modern workflows, without slowing down development.
Available on Docker Hub, DHIs are a curated set of container images designed to minimize vulnerabilities out of the box. They are built with a smaller attack surface, and include a full suite of embedded security metadata by default. This makes them ideal for teams looking to adopt zero-trust practices without adding complexity or friction.
Each Docker Hardened Image ships with:
- Software Bill of Materials (SBOMs)
- Vulnerability scan results
- VEX (Vulnerability Exploitability eXchange) metadata
- Malware and secret scan outputs
- Digital signatures
- Build provenance data
These attestations provide comprehensive visibility into the contents and origin of each image. Because they are packaged directly with the artifact, they integrate seamlessly into downstream platforms like Cloudsmith or any private registry. This removes the burden of generating and attaching this metadata later in the pipeline.
The impact is significant: DHIs can reduce vulnerabilities in base images by as much as 95%, offering a hardened starting point for secure application builds. Just as importantly, they help teams meet compliance and audit requirements from day one, with verifiable transparency and traceability.
By building security directly into the image and surfacing critical metadata in machine-readable formats, Docker Hardened Images simplify the process of building secure containers—and make modern supply chain security accessible by default.
### ****Building a Secure Artifact Lifecycle****
```json
{
"_key": "ddd6d7912419",
"_type": "wistiaVideo",
"id": "vgm2z9yk7v",
"markDefs": null,
"thumbnail": {
"_type": "image",
"asset": {
"_ref": "image-60a3679756dc2c7d95fae3253ec1e504e5265bce-900x506-jpg",
"_type": "reference"
}
},
"title": "Building a Secure Artifact Lifecycle"
}
```
A secure software supply chain requires continuous validation from development through delivery. This is where centralized artifact management platforms like Cloudsmith become essential.
```json
{
"_key": "a1169bf896a3",
"_type": "image",
"alt": "Secure artifact lifecycle",
"asset": {
"_createdAt": "2025-06-09T06:08:02Z",
"_id": "image-b28a36c08f6264c3b275b90f0a5b4a8079d71a93-960x540-png",
"_rev": "mGuYZ52WCGE15ngsaQQ0xX",
"_type": "sanity.imageAsset",
"_updatedAt": "2025-06-09T06:08:02Z",
"assetId": "b28a36c08f6264c3b275b90f0a5b4a8079d71a93",
"extension": "png",
"metadata": {
"_type": "sanity.imageMetadata",
"blurHash": "MYN^[Gt8xuIoRkM}WDWFoIfP~TWBWAt7oe",
"dimensions": {
"_type": "sanity.imageDimensions",
"aspectRatio": 1.7777777777777777,
"height": 540,
"width": 960
},
"hasAlpha": false,
"isOpaque": true,
"lqip": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAALCAIAAADwazoUAAAACXBIWXMAAAsTAAALEwEAmpwYAAACWElEQVR4nE2SyWsTURzH548SiiB4FcWLJ/GgXoSqoNYFBL1US2ltUdEuxO6LSDWSprFNqWlqbEht0qRLUk2aTJZpJu/NvDd5byazZN7MQZIWET6n3/K5fL+cIBslqPEi5UUqyIZEGdLcf2DNwRrDDYY1hjTn/xXSXK4kNbNV8/exwQOzipsVmRUA4yGrYiZiq1hTcgLMCiB3LJUgBcSG1KmRFpA6XHDX8KzRkVX6fV/PCM2VpD60QsdC9OehEc/C6cBm74S/Z3yxbyrgXU8eFMmvI9MfbwR29K2cxb1eIlffwCsDYChIfmSMfp9yuVe89hbObJBArNT5KnDu9uzZzrnzd+eeecKhFJjeoPcm5EfTaDykcqOr9NaodOM9HA/RWM4cDpLr78CdMXkhSn0x8eZgquNh6kzXXkdX4smH/fCeNBeh9yfR4xk0ua5yvm19wF/v/aoEEo2saMey5peYtpTQU0UrtIseeHKXXuQvdPMXu7MvPx5tZtBCVH06j59/UuYjGufdavT56j1exZ/QecjygO0WrYzQrGCWLqvzofKgt9D/uTDozfuiQrqsbmT0qbA6G9FCBwa3dWR9S+pLCT1esATk5AHbLzf/VO2q4vCwGUmTb3Ec2EbLO3g7p1ZQU8AsD+wCtCuIcYC4Yt0RFQdQB1JXQA4PWVlmNeIeHtsLUW0kSIeDxLNGlpN6UWK44eJW/i24kyYg1ZHbSC1FC1l1C5CF06Y/ri+2s4nlrApm6PSGSZRx7QcG6jao25CwE8WpSHUAcWp1R6y3W0FcqT2HxK5iU1SsvxP8JAhUitfsAAAAAElFTkSuQmCC",
"palette": {
"_type": "sanity.imagePalette",
"darkMuted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#3c5464",
"foreground": "#fff",
"population": 0,
"title": "#fff"
},
"darkVibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#042474",
"foreground": "#fff",
"population": 0.05,
"title": "#fff"
},
"dominant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#aeb4c8",
"foreground": "#000",
"population": 0.11,
"title": "#fff"
},
"lightMuted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#aeb4c8",
"foreground": "#000",
"population": 0.11,
"title": "#fff"
},
"lightVibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#6cb4fc",
"foreground": "#000",
"population": 0,
"title": "#fff"
},
"muted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#747c92",
"foreground": "#fff",
"population": 0.01,
"title": "#fff"
},
"vibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#146cdf",
"foreground": "#fff",
"population": 0.07,
"title": "#fff"
}
}
},
"mimeType": "image/png",
"originalFilename": "unnamed.png",
"path": "images/rafvlnhi/production/b28a36c08f6264c3b275b90f0a5b4a8079d71a93-960x540.png",
"sha1hash": "b28a36c08f6264c3b275b90f0a5b4a8079d71a93",
"size": 46865,
"uploadId": "dsAGFK43EvBbvo0tZwF4adICruqOabZO",
"url": "https://cdn.sanity.io/images/rafvlnhi/production/b28a36c08f6264c3b275b90f0a5b4a8079d71a93-960x540.png"
},
"link": {
"_type": "link",
"href": null,
"openInNewTab": false
},
"markDefs": null
}
```
By configuring repositories to proxy public registries (e.g., Docker Hub, NPM, PyPI), Cloudsmith performs key security checks automatically:
- Vulnerability scanning
- License and compliance verification
- Policy enforcement using EPM
Artifacts are cached and versioned, offering security and development teams full visibility and control over dependencies. When an image is pulled, verification steps - including signature checks and attestation validation - ensure that only known, trusted, and reproducible software is admitted into builds or deployments.
However, the ecosystem still faces gaps. Many widely used packages, particularly in NPM and PyPI, lack signatures or attestations. As of late 2024, only 5% of the top 360 packages on PyPI had provenance data published through the trusted publisher workflow. This makes it difficult to assert origin or integrity for many upstream dependencies.
To address this, teams should introduce a secure intermediary - like Cloudsmith - between developers and public sources. This provides enforcement points for policy, visibility into dependencies, and the opportunity to filter and block unverified packages before they can compromise the build.
Once builds are finalized, signing them and recording those signatures in transparency logs (e.g., Sigstore’s Rekor) ensures traceability and trust. This final step solidifies confidence that artifacts were not tampered with before reaching production.
### ****Create Easy Paths to Security****
Security features must be accessible, automated, and non-disruptive to gain widespread adoption. Teams are more likely to maintain best practices when secure workflows mirror familiar development patterns.
To support this, [Docker Hardened Images](/blog/securing-containers-at-scale-docker-hardened-images-cloudsmith) come pre-equipped with SBOMs, digital signatures, and SLSA-compliant provenance. These attributes allow teams to build secure pipelines without requiring additional tooling or custom scripting.
When paired with Cloudsmith, this enables organizations to:
- Centrally manage and enforce policies on all artifacts
- Control access and visibility across engineering teams
- Integrate security checks without altering development velocity
The result is a zero-trust pipeline where software integrity is maintained automatically, and security is treated as a first-class concern throughout the SDLC.
### ****Closing Thoughts****
The shift towards modern security approaches is undeniable. SBOMs, signatures, and attestations are becoming fundamental elements in software development. The impending legislation, particularly in the EU with the Cyber Resilience Act, will further mandate these practices.
For a deeper dive into securing your container workflows, check out our companion blog post, "[Securing Containers at Scale: Docker Hardened Images and Cloudsmith](/blog/securing-containers-at-scale-docker-hardened-images-cloudsmith)," and watch the full [webinar recording](/events/webinars/state-of-the-union-modern-security-approaches-for-the-software-supply-chain).
```json
{
"_key": "1723038d0ea0",
"_type": "image",
"alt": "Cloudsmith x Docker webinar",
"asset": {
"_createdAt": "2025-06-05T08:04:14Z",
"_id": "image-2b34848675dd811c6c047150553981bf3ea64615-2400x1254-png",
"_rev": "gnJeqIUmT5gWK5E6lfsH3V",
"_type": "sanity.imageAsset",
"_updatedAt": "2025-06-05T08:04:14Z",
"assetId": "2b34848675dd811c6c047150553981bf3ea64615",
"extension": "png",
"metadata": {
"_type": "sanity.imageMetadata",
"blurHash": "Mi7yrttpnyn#XBozoJoekCj?afjYoeofoc",
"dimensions": {
"_type": "sanity.imageDimensions",
"aspectRatio": 1.9138755980861244,
"height": 1254,
"width": 2400
},
"hasAlpha": true,
"isOpaque": true,
"lqip": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAKCAYAAAC0VX7mAAAACXBIWXMAAAsTAAALEwEAmpwYAAACU0lEQVR4nF2S21JSYRiGuZJ2A7JTRARxytRA3KQgiIhpNTmOITWluQNLEfc0Tp2ZpjOpgFoHHTTjjSRXAKzFoqau4Wn+hebUwTvfd/I/877v92sG3yvMH/9mJv2L9hWZ6sk8pokrmf+TYTyHbugMfX8WfX+aqmCauoenOEe+UP3gGE1vqkR07ydPd3/gWZaxzRawTheonRIzT91MgdrpPDWv8pgn8xiiOUyPzqgfzmAbSmMayGAdPsX++DOmcBZNa0LCn1IIbil0b5ToWJVxJWVaFiXakrLqunVJwjFXVN0bozkaR78x8OwjvZFd7MNpzIPHGEIZbvmP0NxdkOjZUPC/LeNLKfg2FbrXFTpWS3g3FbwpBXdSxj5XrESO5nCOfCU09g7vky2s4U/oghlu+g+55j1A07Qo07Wu4N0s07mm0L4qYJXZuapwL1miIVasRL7o0BQ+weFNYOtZwhDYU/vU9qW50XuI5s6CTMeaiFv+C7qcbcsKTQuy2qPoT0gfOUfXu4eleZRa13OM/m3MgycYQtnLyDL318v0bJTpWlPoWhezAvesiLglbr+WsM4U1A4FUOvfx9wSodr1kirfNlX/OHwjqY8FpH2l4kqAKnsJV7JEa6KEMy5hmSqgHz9HFzjA4p7A4plF799BH7oA+g7ROONFmhdlWhIyAu6MSTTEJBrnJRriEo5YEfuchG1G9FhAH/mOPrCPwz2G3fMCU+ADxvCJCrwugPWzBRrni6rEXnPRVfXkVW/iGJef3CAcBo8wu6cxtsXR+nbQ9mXVuOLKfwCwPePa/AKDKAAAAABJRU5ErkJggg==",
"palette": {
"_type": "sanity.imagePalette",
"darkMuted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#4a648a",
"foreground": "#fff",
"population": 0.09,
"title": "#fff"
},
"darkVibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#043c90",
"foreground": "#fff",
"population": 0.01,
"title": "#fff"
},
"dominant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#2c6ce4",
"foreground": "#fff",
"population": 19.03,
"title": "#fff"
},
"lightMuted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#bcd1e2",
"foreground": "#000",
"population": 5.07,
"title": "#000"
},
"lightVibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#8cc4fa",
"foreground": "#000",
"population": 1.67,
"title": "#fff"
},
"muted": {
"_type": "sanity.imagePaletteSwatch",
"background": "#4c8898",
"foreground": "#fff",
"population": 0.01,
"title": "#fff"
},
"vibrant": {
"_type": "sanity.imagePaletteSwatch",
"background": "#2c6ce4",
"foreground": "#fff",
"population": 19.03,
"title": "#fff"
}
}
},
"mimeType": "image/png",
"originalFilename": "Cloudsmith-Docker-webinar_LinkedIn-1200x627-with-speakers_no-date.png",
"path": "images/rafvlnhi/production/2b34848675dd811c6c047150553981bf3ea64615-2400x1254.png",
"sha1hash": "2b34848675dd811c6c047150553981bf3ea64615",
"size": 409719,
"uploadId": "dQHMU1TdigCQpbiB7OHFtWWbiBqMsHFm",
"url": "https://cdn.sanity.io/images/rafvlnhi/production/2b34848675dd811c6c047150553981bf3ea64615-2400x1254.png"
},
"link": {
"_type": "link",
"href": "/events/webinars/state-of-the-union-modern-security-approaches-for-the-software-supply-chain",
"linkType": "webinar",
"openInNewTab": false,
"webinar": {
"_ref": "73e5bbf2-430d-484e-9b71-3589f0e21ef9",
"_type": "reference"
}
},
"markDefs": null
}
```