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 “how fast can we secure it?”

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.

AI artifacts: The new software supply chain blind spot

A single typo is all it takes. A simple oversight and your whole application is handing out 404 errors like an episode of Oprah’s favorite things.

Bad actors leverage typos to introduce malicious code into the software supply chain. Once these packages get into your supply chain they can create a lot of damage. And it’s not just end users unable to access your application. We’re talking PR nightmares, data leaks, security threats, and all sorts of disruptive events. Having a central security and control plane for your software supply chain helps to identify and mitigate threats from typosquatting and other malicious software.

This post discusses typosquatting and how using an artifact manager can significantly mitigate these threats. We’ll look at some best practices for dealing with typosquatting and some Cloudsmith features that help you create a proactive security posture that doesn’t interfere with developer velocity.

: Typosquatting & Slopsquatting: Detecting and defending against malicious packages – Watch on-demand 

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

To level set things, let’s define typosquatting. If you’re already familiar with the term feel free to skip to the next section.

 is a form of cyberattack where bad actors create packages that contain malicious code. They give these packages names that are similar to, or slight variations of known, trusted packages. They’re banking on developers making typing mistakes and not noticing them, essentially tricking devs into pulling these packages into their production environments where they can do damage.

: This is a variation of typosquatting driven by generative AI large language models (LLMs). These LLMs hallucinate package names that sound realistic, but do not actually exist. Bad actors identify these names and create malicious packages using the previously non-existent name, so the next time an LLM suggests the package, it exists, and it’s malicious. At present the standard defence against slopsquatting is to review PRs that may contain untrusted package names, and ensure all package pulls come from a trusted source. This article focuses on typosquatting, but it’s helpful to be aware of slopsquatting and how it fits into the typosquatting process.

These bad actors understand that speed in development is a driving force. This is especially true as developers experiment with new tools and technologies. It’s common for developers to see if a solution works first, then go back and think about security later. As a result, security struggles to keep up with the overall pace of development. It’s in this gap where typosquatting is at its most threatening.

Because anyone can upload packages to public open source registries (we’re talking about places like npm, PyPI, Maven Central, and the like), bad actors have ready access to distribution platforms for their malicious packages. Maintainers of these public registries may not have the time or authority to remove malicious packages. Plus, bad actors can upload packages faster than maintainers can address them.

That means the end user takes on the security burden by default. Developers benefit from an artifact manager to act as a firewall between public registries and their development environments. An artifact manager, like Cloudsmith, functions as a control plane for the entire software supply chain.

An artifact manager determines what enters, moves through, and leaves the software supply chain. It proxies packages from public registries and caches them in a private registry. Setting that private repo as the default location for package pulls ensures consistency across a development team and/or organization. It creates a private repository of known, trusted, and secure artifacts.

Why does all this matter for typosquatting? When developers default to public registries and pull directly from them for all their builds, they introduce the risks of typos or mistakes that could pull a typosquatted package into their environment. Pulling from a private repo in an artifact manager ensures you pull the same package every time.

Simply having a private repo does not make your packages secure. This is where security policies come into play.

The first time you push a package of any kind to Cloudsmith, the platform scans for malware. 

 have access to additional security features that detect package vulnerabilities and malicious packages. This includes scanning packages against trusted third-party databases, e.g., Open Source Vulnerability (

, which tell you what, if any, vulnerabilities exist for each package. It also uses Common Vulnerability Scoring System (

), and Exploit Prediction Scoring System (

) to score those threats and provide information about the severity impact of those vulnerabilities.

You can use this information to create your own policies that suit your security needs. For example, you may want to quarantine some packages. Others you may want to tag. You can build automations using these actions and policies to support a scalable security posture. Learn more about the current EPM actions 

Regarding typosquatting, qualified plans provide you baseline package health information before you ever create a security policy. A baseline understanding is not the same thing as proactive prevention, so let's take a look at how to begin addressing typosquatting from a policy perspective.

Creating a proactive anti-malware posture

Detection is only as effective as the policy that supports it. To secure the software supply chain without slowing down engineering, organizations need more than just scans. They need systemic governance.

 (EPM) lets you define, interpret, and take action on identified security threats. This translates into the implementation of transparent, automated, and scalable standards that protect the build process while remaining invisible to the developer. What does this look like in practice? Let’s look at a couple different options.

Assume you need to pull in the latest version of the PyPI 

 package. It has a generic name and could easily be typosquatted. There’s a known malicious package called 

. No doubt its author was banking on the fact that developers who forgot the ‘q’ in the package name would load this cryptomining malware into their development pipeline.

Let’s say that because you know this malicious package exists, you want to create a policy to explicitly target it.

An EPM policy to do this starts with the following code:

That policy looks for packages with the exact name 

. If it finds a match, you can define what action you want Cloudsmith to take later in the policy.

: You know the exact package you want to limit and the policy does that.

: You limited the policy to look for one specific malicious package, but others may get through.

package is really important to your work, another approach would be to limit other likely spelling variations that a typosquatted package may take.

You can update the policy in approach 1 to include an array of potential package names.

: You identify the known malicious package, and you proactively identify any other, similar packages that are likely to be problematic.

: This approach isn’t scalable. You would have to become an active threat researcher to properly maintain this policy. It’s also a very narrow policy focused on one specific package.

The first two approaches take a package-centric view of security. And really, they’re both reactive. While both will help you keep typosquatted packages out of your development pipeline, they don’t conform to the principle of least privilege.

Enterprises need a more comprehensive and scalable solution and least privilege does just that. The idea is to define what you 

want to use in your software supply chain and to allow only those packages. You set up rules to deal with anything that doesn’t agree with your policy.

The primary concern with typosquatted packages is that they contain malware. So, in this case, you want a policy that allows the things you 

 want (safe packages) and flags the things you 

 want (malicious packages). A proactive, scalable policy flags all known malicious packages and lets you take whatever actions are appropriate for your organization on them.

This is a simple, straightforward policy that identifies all known malicious packages. In the OSV database, packages with malicious code receive a “MAL-” identifier. For example, the ID for the 

. This policy compares the packages in your Cloudsmith repo with the OSV database and flags all matches with a “

There’s a broad community that, in effect, maintains the OSV database. Relying on this crowdsourced database is much more scalable, reliable, and ultimately accurate than trying to track down threats on your own.

: Scalable, applies principle of least privilege, relies on trusted third-party data for comprehensive scanning.

: Automatic scanning only occurs when a new instance of malware hits the source databases. If you are aware of a new example of malware before it appears in one of the source databases you may need to use one of the other approaches as a stopgap.

There’s one more scenario worth considering (for now) related to typosquatting. What if you already have a typosquatted package in your software supply chain. This may be a dependency that pre-dated current policies, or something that was a temporary exception that the team forgot about. Or perhaps someone found a bit of malicious code in a package that went unnoticed and was previously deemed safe.

Regardless of how it ended up in your supply chain, once knowledge of a compromised package hits the OSV database you want to know if it impacts your software supply chain. For most artifact managers, you would need to initiate a manual scan of your repos. Sure, you can set up alerts for OSV updates and/or schedule scans, but those are the kind of maintenance burdens that users want to avoid.

 feature. As mentioned above, Cloudsmith does an initial security scan when first pushing packages to the platform. Continuous Security, however, checks the source databases (i.e., OSV, Trivy) every hour. When it detects a new vulnerability or malicious package, it looks at your repository to see if it contains anything that may be affected. If so, Continuous Security triggers a scan of your repository against your EPM policies. This process happens automatically so you don’t have to schedule checks or scans.

The constant push to accelerate software development increases potential security risks to developer software supply chains. Bad actors create malware faster than security professionals can identify it. Taking proactive security measures mitigates the risks posed by malicious typosquatted or slopsquatted packages. This will become increasingly important as AI-generated code proliferates more builds.

Utilizing an artifact manager, like Cloudsmith, allows organizations to create policies around package consumption and implement automation for how to handle malicious packages when they appear. By acting as a centralized control point for all package consumption within your organization, Cloudsmith enables a proactive, scalable, and transparent security posture that allows developers to work fast and securely. In the speed vs security tug-of-war, Cloudsmith provides the middle ground that caters to both sides.

Want to see how Cloudsmith can help your organization? Book a 

Protect your software supply chain from typosquatting with Cloudsmith

 know your LLM-generated code? LLM-powered copilots now write a lot of code, and they tend to suggest new dependencies your organization may not have used before. Without systematic security checks, you’re at risk of a hallucination exposing your production systems to a supply chain attack. Our increased reliance on open source and other third-party code increases risk to your builds. AI-generated code exacerbates those risks.

Let’s talk about how Cloudsmith secures your AI-generated code. By leveraging policy-as-code, private repo caching, and other best practices, Cloudsmith helps software development teams adopt a “verify and then trust” architecture, balancing AI-assisted software development with the need to defend system integrity.

Stop LLM hallucinations from breaking your build

LLMs are a great example of an untrusted contributor. They generate code without a complete understanding of your internal security standards. Their code may reference non-existent packages in a phenomenon known as AI hallucinations, and they may pull in malicious dependencies, created via a new attack vector dubbed slopsquatting. Cloudsmith’s 

 revealed that 79% of professionals believe that AI will exacerbate open-source malware threats, including typosquatting and dependency confusion.

The traditional "trust, then verify" model is no longer viable, because there is no true human intent behind an LLM’s package selection. Only 67% of developers review AI-generated code before every single deployment, per the 2025 report. To ship AI-generated code safely, we recommend moving to a "verify, then trust" architecture. This means treating every AI-suggested dependency as a potential threat until it passes a programmable gate.

Cloudsmith acts as that gate. By sitting between your LLM-powered copilots and your package ecosystem, we provide the metadata layer and policy enforcement needed to ensure that AI-generated code only utilizes verified, licensed dependencies within your private, controlled repositories.

Here is how you use Cloudsmith to stop AI-induced challenges at the front door.

The role of programmable security policies

What does “good” software supply chain security look like? It should do a few things:

Builds pull packages from trusted sources.

Scan new dependencies for malware and other vulnerabilities.

Automate blocking vulnerable packages from production environments.

Check package license(s) before it enters a build.

Continuous and systematic performance of these tasks at scale for end-to-end protection.

When you introduce AI into the equation, these tasks become more important. Implementing automated security processes and policies is the best way to make sure they happen.

The tradeoff between power and simplicity is one developers often face. “Checkbox security” is simple and straightforward, but it has its limits. You set policies via UI, using checkboxes, radio buttons, and other basic interface elements. These security interfaces are easy to understand, but they’re static and are not fully customizable to the user, organization, or project. Limited options and functionality mean that checkbox security doesn’t scale for enterprise-level development. It’s hard to do things like apply unique or fine-grained security policies to different projects, teams, environments, formats, and contexts.

Contrast that with policy-as-code where you get granular control over security policies, which is an inherently more scalable approach. 

 (OPA) is an industry standard for policy-as-code. It pairs with the Rego language to define rules for software usage and consumption. While Rego introduces a learning curve, OPA’s benefits are an enterprise-level industry standard.

 acts as an OPA engine so you can use the same 

 you may already be familiar with to create policy-as-code controls in Cloudsmith. You use Rego to create universal, baseline policies for every artifact in your Cloudsmith repos.

With EPM and Rego, you can create custom rules for specific repos, projects, or applications that cater to fine-grained security needs. EPM policies can evaluate SBOM data to ensure end-to-end consistency throughout your data pipeline. Our 

 highlights some of the different approaches to building policies, and serves as a great starting point for creating your own. We also developed the 

 for EPM, you can enforce an organization-wide requirement for a package with a specific version range. The policy evaluates the version of a package against a specified package version. It then triggers an action, like quarantining the package, if the version of the current package being evaluated is older than the specified package version.

Cloudsmith functions as a central source of truth for all your development packages and artifacts. From a security perspective, it functions as a gatekeeper, blocking or quarantining malicious, vulnerable, or non-compliant packages, in accordance with your policies, before they enter your build systems. When you pull packages, you always pull them from Cloudsmith, which makes sure they meet your security requirements.

Are you looking for a complete strategy to protect AI-driven development workflows? Read our practical guide to

securing AI artifacts and operationalizing LLMOps

Securing AI-generated code with Cloudsmith

Software Bills of Materials (SBOMs) are critical for transparency and compliance. Think of them as the ingredients list for software, a simple record of what went in. But as attackers continue to target and exploit software supply chains, that ingredient list plays an increasingly important role in securing your software supply chain.

When you index SBOMs they become an accessible part of day-to-day workflows. They give you a clearer view of what you’re actually shipping and provide enough detail to make decisions earlier, before a risky dependency makes its way further downstream.

This post focuses on the shift in SBOM usage from descriptive document to proactive security tool. We’ll look at how SBOMs support prevention and how teams use SBOM-based policy enforcement to keep risks out of their pipelines.

A container image may look straightforward on the surface, but the real risk often sits several layers deep. The build process can indirectly introduce transitive dependencies and SBOMs expose that level of detail.

Once you have a detailed account of what’s inside an image, you can enforce rules that reflect how you want to build and consume software.

When using SBOMs for prevention, teams can:

Block containers that include components with known vulnerabilities

Apply license policies to the full contents of an image

Catch issues buried multiple levels down the dependency tree

Make security checks consistent across teams and pipelines

Put simply, SBOMs add context to policy decisions by exposing the components inside an image. Alongside metadata, SBOMs make it possible to apply existing rules more precisely when transitive dependencies introduce risk.

How Cloudsmith supports SBOM-driven prevention 

To make SBOM-based policy enforcement dependable, teams need two things: 

Current intelligence about vulnerabilities and malicious packages

A consistent control point that evaluates every container in the same way

Cloudsmith provides both through continuous scanning and automated policy enforcement.

Cloudsmith automatically generates CycloneDX format SBOMs during container image package synchronization. Once created, SBOM data is accessible by the 

 (EPM) schema, allowing you to incorporate them into security policies. You can also retrieve SBOMs via API or download them directly from the Cloudsmith UI.

For non-Docker artifacts, you can store SBOMs directly within packages. More information about how Cloudsmith generates and handles SBOMs is available 

EPM evaluates artifacts automatically whenever they’re pushed, synchronized, or re-checked due to updated intelligence. Built on Open Policy Agent (

) to be highly flexible, EPM enforces policies on both artifact metadata and Cloudsmith-generated SBOM contents, then applies the outcome you define: allow, flag, quarantine, or block.

High-risk or vulnerable component versions

Threat intelligence changes constantly. Risks can emerge through newly published CVEs, the identification of malicious packages, or upstream dependency changes. Cloudsmith keeps this information current by ingesting data from sources like Aqua Trivy, OSV, NVD, the GitHub Advisory Database, and the OpenSSF Malicious Packages project. 

 scoring adds context around how likely a vulnerability is to be exploited in practice.

Cloudsmith’s Continuous Security feature checks these data sources for new vulnerabilities every hour and matches them to artifacts in your Cloudsmith repositories. When Continuous Security detects a threat that affects an artifact in your workspace it triggers an Enterprise Policy Manager policy evaluation with the vulnerability data included in the policy input. This removes the gap between the existence of new information and your system’s ability to act on it.

Because EPM understands SBOMs, Cloudsmith can enforce policies at the component level, not just at the image level. This gives teams fine-grained control without adding friction to developer workflows.

Because of the nature of software supply chain threats and vulnerabilities, developers and security teams need policies that meet threats as they arise. Both proactive and reactive policies play a role in your overall security posture.

These policies help restrict known issues and non-compliant components before they land in a pipeline.

License enforcement: Check transitive dependencies for licenses that don’t meet your organization’s requirements.

Vulnerability thresholds: Define a policy that quarantines any image containing a component with a CVSS score above a specified level.

The pace with which threats emerge makes it impossible to rely solely on proactive policies. Reactive rules can function as an important zero-day stopgap. These rules give teams a predictable way to lock down newly identified risks, before they hit OSV and other data sources, without chasing them manually.

Deny rules for specific components: A deny rule for a specific package or version applies both to direct package downloads and to any Docker image that includes that package as a component, ensuring the same restriction is enforced regardless of how the package is consumed.

Turning SBOM visibility into policy enforcement at scale

SBOMs give you insight into the components you’re shipping, but their true value is in the action(s) this insight triggers. Enterprise Policy Manager lets you use that insight to trigger actions that keep known risks out of your pipeline. EPM uses SBOMs to ensure every component in your pipeline meets your organization’s specific security and license requirements, automatically and at scale.

: Put your SBOMs to work. Contact Customer Success to enable Enterprise Policy Manager. 

: See why the world's leading enterprises trust us to automate artifact policy. 

Q: How does SBOM enforcement differ from traditional vulnerability scanning?

Traditional scanning often focuses on the final artifact's metadata. SBOM enforcement looks at the "ingredients" list (the dependencies) of the artifact, allowing you to block specific internal components even if the top-level artifact is marked as safe.

Q: Can Cloudsmith EPM block builds based on OPA policies?

Yes. Cloudsmith EPM uses Open Policy Agent (OPA) to evaluate artifacts at the moment they are pushed. If an artifact violates a Rego policy (e.g., contains a banned license), EPM can quarantine the file immediately and prevent it from being downloaded, keeping non-compliant packages and dependencies out of your builds.

From ingredient list to control point: SBOM-based component-level 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

Choosing a secure container base image has historically been a game of compromise between costs, tooling, and operational overhead. You either pay for premium images, struggle with the “tooling gap” of minimalist distroless builds, or drown your team in the manual labor of constant patching.

Docker is changing this equation by making its 

Docker Hardened Images (DHI) catalog–over 1,000 minimal, high-integrity images–freely available

. But while the images are free, operationalizing them at scale across a massive engineering org is not.

That is where the combination of Docker and Cloudsmith becomes a cheat code for developers and security teams working at enterprise scale.

The developer advantage: Better ingredients, less prep

For a developer, a Docker Hardened Image isn't just more secure. It’s an evolutionary step forward that better protects against software supply chain threats and risks. DHIs arrive pre-patched and stripped of the bloatware found in typical images. They offer developers:

: These images are smaller, meaning they move across the network fast and start up in seconds.

: Docker handles the continuous patching of DHIs, monitoring upstream sources so you don’t have to.

 Level 3 provenance. You get traceable security data from the very first layer of your build.

The Cloudsmith difference: One endpoint, zero sprawl

Most other artifact managers force you into repository sprawl. If you want to add a new source like DHIs, you’re stuck creating a new remote repository, a new local cache, and a new virtual repository to tie them together. Then, you have to hunt down every CI pipeline and developer config to update the endpoints.

This isn't just an operational challenge, it’s a security bottleneck. When the path to better security requires a manual overhaul of your internal infrastructure, adoption stalls. This friction often forces organizations to stick with "good enough" images, leaving them unnecessarily exposed to vulnerabilities that DHIs are designed to eliminate.

We architected Cloudsmith differently. Our repositories are natively multi-format and upstream-aware. Adding Docker Hardened Images isn't a migration project. It’s a natural extension of your current setup.

 DHI as an authenticated upstream source in Cloudsmith. Developers and build agents continue pulling from the same Cloudsmith URL they already use.

: Keep your existing Docker Hub upstream in place. Cloudsmith handles the authentication, caching, and routing behind the scenes.

: Continue using the same Cloudsmith repository URL you already have. You can keep your existing Docker Hub upstream active alongside DHI. Cloudsmith acts as the single, intelligent integration point between your stack and the outside world.

Cloudsmith Blog

13 KubeCon Europe 2026 sessions not to miss

LLMOps vs DevOps: What LLMOps means for artifact management

Why cloud migrations are the best time to re-evaluate your artifact management

Dependency confusion and trust boundaries in modern builds

LLMs on Kubernetes: same cluster, different threat model

I love Software (in) NI

Securing LLM dependencies against serialisation attacks

Top 10 most popular LLM models on Hugging Face

7 key metrics to measure software supply chain security

AI artifacts: The new software supply chain blind spot

Protect your software supply chain from typosquatting with Cloudsmith

Securing AI-generated code with Cloudsmith

From ingredient list to control point: SBOM-based component-level security

How artifact management enables S2C2F maturity

Secure containers by default with Cloudsmith and Docker Hardened Images