By submitting this form, you agree to our 

A practical guide to AI artifacts and LLMOps

Securing non-deterministic systems

 Dependabot is great at keeping dependencies current, but update automation and ingestion control solve different problems. Cloudsmith acts as an upstream gatekeeper; ensuring packages are verified before they ever enter your environment. Together, they cover more of the supply chain than either does alone.

Let’s frame a scenario: a new dependency version is released. Within hours, Dependabot opens a pull request to upgrade your application.

The change looks routine. The PR is merged.

But this version wasn’t just an update - it was part of a coordinated malware campaign.

Before long, the compromised package has made its way into your build environment, cache layers, and developer workstations. Your security team is pulled into incident response, and a difficult question follows:

How did this get through so quickly, and how do we prevent it next time?

How dependency updates become a supply chain risk

To understand how this scenario unfolds, it’s worth breaking down what actually occurs between a dependency being published and a pull request being merged. When a new version of a package is released by a maintainer (or malicious actor in this case), it becomes immediately available in upstream registries such as npmjs, pypi, Maven Central, or DockerHub.

Tools like Dependabot continuously scan your repository’s dependency files for updates. As soon as a new version is detected, Dependabot compares it against what your application is currently using. If a valid upgrade path exists, it automatically opens a pull request with the updated version. From a developer’s perspective, everything looks normal:

The dependency comes from a trusted source

The version increment appears routine (ie. “It’s probably a patch or security fix”)

The pull request follows a familiar, repeatable workflow

Nothing appears out of the ordinary - which is exactly how these attacks are designed.

At no point in this process is there a built-in mechanism to evaluate whether a newly released version is too new, potentially unverified, or part of a broader security incident without additional manual investigation. To make matters worse, it often takes time for security researchers to identify and report malicious packages, leaving a window where compromised versions can spread undetected.

That's not a criticism of the tool, it's a reminder that no single layer of automation was built to catch everything.

The problem isn’t automation; it’s the absence of an upstream control layer that determines when a dependency can be trusted and safely consumed

Dependabot cooldowns: Helpful, but not a complete safeguard

To address the risk of organizations rapidly adopting new dependencies, Dependabot offers a cooldown feature that allows platform teams to introduce a delay before opening pull requests for newly released dependency versions.

In practice, this means that even if a new version becomes available in the registry, Dependabot will intentionally wait for a defined period of time before suggesting the update through the pull request.

This provides an additional layer of protection:

It gives the ecosystem the time to detect and flag malicious packages

It reduces the likelihood of of immediately adopting unverified releases

It helps avoid 0-Day exposure to newly published vulnerabilities

For many teams, this delay can significantly reduce risk. However, it’s important to recognize what this control does and does not protect against. Dependabot’s cooldown feature operates at the pull request level, meaning that it controls when an update is suggested, but it does not control what is ultimately available to your build systems or developers once a version is accessible in a registry.

Once a dependency version is published and reachable, it can still be:

Downloaded outside of Dependabot entirely

In other words, Dependabot’s cooldown feature only influences one path to consumption, but not all paths. This naturally creates a gap: even with cooldown in place, a malicious package can still be consumed before it is ever flagged or blocked. While Dependabot’s cooldown can help reduce noise and delay exposure, they do not enforce a boundary around what dependencies your organization is allowed to consume.

If Dependabot’s cooldown helps reduce the speed of adoption, the next question becomes:

What controls when a dependency is allowed to exist in your environment at all?

Dependabot's cooldown helps slow the rate of adoption, but it doesn't control what dependencies are reachable in the first place. To close that gap, organizations need a control layer that sits upstream of their build systems entirely - one that determines whether a dependency is even available before any tool can request it.

Introducing an upstream gatekeeper for dependency security

 comes in as your upstream gatekeeper. Instead of allowing direct, unrestricted access to upstream packages, Cloudsmith acts as a controlled gateway. With Cloudsmith Advanced Security, organizations can also introduce cooldown periods as policies to introduce time-based buffers to quarantine newly published dependency versions across a variety of different package formats.

For example, I currently work with a customer who has implemented a 5-day cooldown period for all npm packages with an updated version within that 5 day window. During this time, the customer can:

Check security advisories for any potential malware

Validate the upstream maintainer and perform additional reconnaissance

Only after the 5 day cooldown period is the package unquarantined and made available for download. When combined with Dependabot’s cooldown feature, organizations can layer the Dependabot cooldown with Cloudsmith’s to maximize security. Here’s an example workflow:

On Day 0, a new dependency version is released.

 The version exists upstream, but Cloudsmith intentionally keeps it out of reach in quarantine state. It cannot be pulled by developers or CI/CD pipelines.

 The version becomes available through Cloudsmith after the cooldown period has passed.

 Dependabot is pointed to Cloudsmith, and now detects the newly available version and opens a pull request.

Cloudsmith controls when the version becomes consumable, while Dependabot controls when the version is proposed. Together, they ensure that updates are both safe and timely, without exposing the organization to newly released, potentially risky artifacts.

Modern software delivery depends on automation, and tools like Dependabot have made keeping applications current easier than ever. But automation can only work safely within the boundaries set for it. Without an upstream control layer, every newly published dependency version is immediately exposed to your systems, trusted by default, not by design.

By pairing Dependabot with Cloudsmith's upstream cooldown policies, you create a model where trust is earned over time rather than assumed at the moment of release. Small in implementation, significant in impact: that shift is what allows teams to move fast without leaving the door open.

This layered approach is essential for organizations looking to strengthen their 

 without slowing down development velocity.

Cristian Garcia

Senior Customer Success Manager

Layered defense for dependencies: Why dependabot needs an upstream gatekeeper

For years, the bottleneck in software was “how fast can we write code?” Today, Generative AI shifts that bottleneck to 

For years, the bottleneck in software was “how fast can we write code?” Today, Generative AI shifts that bottleneck to “

As organizations move from experimentation to production-grade AI, they are discovering that traditional DevOps tooling wasn’t built for a non-deterministic world. For example, static software composition analysis (SCA) scanners that assume deterministic dependency graphs or CI policy gates that validate known build artifacts. When a model generates code rather than a human, the software supply chain changes overnight.

Securing non-deterministic systems: A practical guide for AI artifacts and LLMOps

, explores three emerging security frontiers that every organization adopting AI must address:

1. AI-generated code introduces supply-chain hallucinations

LLMs generate dependencies probabilistically, not deterministically. This creates the emerging 

 attack vector, where attackers register hallucinated package names suggested by AI tools and weaponize them with malicious payloads.Without validation and artifact governance, a single copied command can silently compromise an enterprise environment.

2. AI models behave like executable software, not passive data

Modern model formats can execute arbitrary code during deserialization, most notably through Python pickle-based loading.This 

 means downloading an unverified model from public registries such as Hugging Face or Ollama can result in full system compromise.Secure AI development requires scanning, signing, and favoring restricted formats like 

, alongside enforcing trusted provenance for every model artifact.

3. AI productivity and orchestration layers expand the attack surface

Frameworks that connect models to enterprise data and automate workflows introduce a new class of high-impact vulnerabilities.Recent RCE exploits in orchestration tools demonstrate that 

LLMOps infrastructure itself is now part of the software supply chain

, and must be sandboxed, authenticated, and governed like any production system.

Our full guide provides a strategic roadmap for navigating the shift from DevOps to LLMOps, deconstructing threats in frameworks like Langflow, and building a “sandbox-by-default” development lifecycle.

Parul Jhawar

Marketing

AI artifacts: The new software supply chain blind spot

As software supply chain attacks become more sophisticated, organizations have shifted from "why" to "how." We’ve moved past simply discussing the need to protect sources and secure builds. Today, the industry relies on frameworks like 

 Adopting a framework is only the first step. To achieve true 

, you must move from subjective trust to objective measurement. In this final post of our series, we explore seven key 

Why metrics are essential for software supply chain integrity

Security without measurement is guesswork. Many organizations claim to have a secure software supply chain, but struggle to answer basic questions like:

Can we prove where our production artifacts came from?

How quickly do we detect new dependency risks?

Are security policies enforced, or just documented?

 depends on visibility, enforcement, and accountability. Metrics turn those concepts into something observable and repeatable. More importantly, they shift security from a reactive function to a governed system, ideally managed within a 

Quick reference: S2C2F metrics and maturity mapping

The 7 key metrics for a secure software supply chain

 The percentage of production artifacts with verifiable, cryptographically signed provenance. 

 If you can’t prove how an artifact was built, who built it, and what went into it, you’re relying on trust instead of evidence. Provenance is the foundation of 

 High coverage indicates a strong source and builds integrity, while preserving traceability throughout the artifact lifecycle.

 How many artifacts in your repositories are signed and verified before use. 

 Unsigned artifacts are indistinguishable from tampered ones. A 

 depends on cryptographic verification, not naming conventions or environment assumptions. 

 Mature teams enforce signature verification at the 

 Whether Software Bills of Materials (SBOMs) are complete, accurate, and generated per artifact version. 

 An outdated or partial SBOM creates false confidence. SBOMs are only useful when they reflect exactly what was shipped, including transitive dependencies.

 High SBOM completeness supports transparency, auditability, and rapid incident response.

4. Mean time to dependency risk detection (MTDR)

 How quickly new vulnerabilities, malicious packages, or license issues are detected after entering the supply chain. 

 Speed matters more than perfection. The longer a risky dependency lives in your pipeline, the greater the blast radius. 

 Short MTDR indicates continuous verification instead of periodic scanning.

 The percentage of builds, promotions, and downloads governed by enforceable security policies. 

 Security guidelines without enforcement don’t reduce risk. Policy must be automatic, consistent, and unavoidable. 

 High enforcement rates reflect a shift from advisory controls to preventative ones.

 How often teams reuse verified artifacts instead of rebuilding the same components across environments. 

 Rebuilding introduces inconsistency, increases attack surface, and weakens traceability. Reuse strengthens integrity and simplifies audits. 

 Mature organizations promote trusted artifacts through environments rather than recreating them.

7. Exposure window for vulnerable artifacts

 The time between vulnerability disclosure and when affected artifacts are blocked, quarantined, or replaced. 

 Every hour a vulnerable artifact remains available is measurable risk.

 Short exposure windows indicate automated response and strong 

artifact management for supply chain security

 reveal more than individual control gaps. They show whether S2C2F principles are operationalized within the organization.

Organizations with low S2C2F maturity often:

Rely on CI logs instead of artifact metadata.

Detect risk late in the lifecycle (often at deployment).

Enforce security inconsistently across different teams.

Treat the artifact as the system of record:

 All security metadata is attached directly to the artifact.

 to build; they only care what the cryptographic signature 

 as a security gate, not just a storage bucket.

How do you measure software supply chain security?

You measure it by tracking objective data points across the artifact lifecycle, specifically focusing on provenance coverage, cryptographic signing rates, and the speed of vulnerability detection (MTDR).

S2C2F metrics are specific indicators used to track the implementation of the Source-to-Container-to-Factory framework. They include artifact integrity checks, build service security, and dependency trust levels.

S2C2F maturity is measured by the degree of automation and enforcement in your pipeline. Level 1 focuses on basic visibility, while Level 4 requires automated policy enforcement, reproducible builds, and 100% provenance coverage.

How do you track software supply chain integrity?

Integrity is tracked through a combination of SBOMs, cryptographic signatures, and "attestations" stored within a secure artifact repository. These tools provide a verifiable record that the software has not been tampered with.

Closing the series: From framework to outcomes

How S2C2F strengthens open source and build security.

The core principles behind trusted software delivery.

This final step, measurement, is where theory becomes practice. When organizations clearly measure trust, integrity, and risk across their software artifacts, supply chain security stops being aspirational. It becomes operational.

 to learn how Cloudsmith accelerates your path to S2C2F maturity.

Security Maturity Assessment Guide

7 key metrics to measure software supply chain security

Software supply chain security has moved from a niche concern to a board-level priority. While source code receives much of the focus, significant risk lies in the "grey area" between build and production, where developers store, share, and consume software artifacts.

artifact management for software supply chain security

 becomes foundational. When implemented correctly, a secure repository acts as the connective tissue that turns the Secure Supply Chain Consumption Framework 

 from a theoretical model into an operational reality.

Why artifacts are the "unit of trust" in S2C2F

Every software delivery pipeline produces artifacts: packages, container images, binaries, and 

. These are what actually run in your production environment.

Yet, many organizations treat repositories as passive storage. To achieve 

, you must treat your artifact repository as security-critical infrastructure.

 Only scanned and approved artifacts move to production.

 Artifacts cannot be altered once stored.

 Every binary is linked back to its build and source.

 focuses on the secure ingestion of open-source software (OSS). Artifact management provides the enforcement layer for these core practices:

1. The secure "front door" (ingest and control)

S2C2F requires a controlled point of entry for OSS. A secure artifact repository acts as a proxy, caching external dependencies so they can be scanned before they reach a developer’s machine.

You cannot secure what you can’t see. Advanced artifact management automatically generates and stores metadata, providing a "living" inventory of every dependency in your ecosystem – a key requirement for the 

 allows you to set automated "gates". For example, if a package in your repository has a critical CVE, the management system can automatically block it from being pulled into new builds.

Mapping artifact management to the S2C2F maturity model

 requires evolving your artifact strategy from simple storage to an intelligent control plane.

Artifact repository security: Beyond storage

 is about maintaining a "chain of custody" for your software. To advance your 

 Preventing "hidden" updates to existing versions.

 Using tools like Cosign to sign artifacts, ensuring they haven't been tampered with in transit.

 A complete log of who accessed what and when, which is essential for incident response.

Why it’s a differentiator for supply chain integrity

 doesn't add friction; it adds velocity. By centralizing security controls at the repository level, developers can move fast, knowing that the "ingredients" they are vetted against the 

When secure artifact management is embedded in the pipeline:

 Vulnerabilities are caught at the repository level, not in production.

 Every artifact has a "digital passport" (metadata and signatures).

What is artifact management in software supply chain security?

It is the process of securely storing, governing, and distributing binaries and packages. It ensures that the software being deployed is exactly what was built and hasn't been tampered with.

How does artifact management enable S2C2F?

It operationalizes the framework by providing a central location to ingest OSS, store SBOMs, scan for vulnerabilities, and enforce consumption policies.

What is the S2C2F maturity model for artifacts?

It is a 4-level progression where an organization moves from using public registries directly (Level 0) to rebuilding and verifying every OSS component internally (Level 4).

Why is artifact repository security critical for supply chain integrity?

Because the repository is the final gate before production. If the repository is compromised, an attacker can swap a safe artifact for a malicious one, bypassing all previous source-code security checks.

S2C2F provides the blueprint, but artifact management is the foundation. By strengthening your 

, you turn supply chain integrity from a goal into a reality.

If you haven’t explored the foundations of S2C2F yet, we recommend starting with the previous post in this series:

Understanding these principles will help you see exactly how artifact management fits into the broader S2C2F journey and why it is such a critical enabler of supply chain integrity.

How artifact management enables S2C2F maturity

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

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

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

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

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

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

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

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

Understanding S2C2F: How It Strengthens OSS Security

software supply chain integrity framework

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

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

Why S2C2F matters for supply chain integrity

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

Reducing the attack surface of external dependencies.

Improving inventory visibility (knowing what you have).

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

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

The first and most critical practice is defining 

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

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

 Centralize and cache all external dependencies.

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

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

When the next Log4j happens, you can instantly query 

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

 Stop bad packages before they reach the build server.

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

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

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

Cloudsmith Blog

Layered defense for dependencies: Why dependabot needs an upstream gatekeeper

AI artifacts: The new software supply chain blind spot

7 key metrics to measure software supply chain security

How artifact management enables S2C2F maturity

The 8 core principles of S2C2F

Understanding S2C2F: How it strengthens OSS security

What is software supply chain integrity?

Slopsquatting and Typosquatting: How to Detect AI-Hallucinated Malicious Packages

DevOps guide to mitigating software supply chain risks

Breaking the "Department of No": Ship fast but also secure

Malicious Package Detection in Cloudsmith

Multiple Malicious Packages Discovered on PyPI, npm, and RubyGems