By submitting this form, you agree to our 

Software today is built on an ever-expanding mesh of open-source components, third-party libraries, container images, package registries, automated systems, and build services. While this ecosystem accelerates development, it introduces a terrifying reality: a single compromised dependency or an unexpected upstream change can ripple through your entire product stack in minutes.

It has become one of the most critical pillars of modern DevSecOps. When your dependencies are trustworthy, verifiable, and governed correctly, you reduce the risk of malware insertion, dependency confusion, tampering, or upstream failure. Without this foundation, even the strongest supply chain security controls at the application layer won’t matter.

This blog, the first in Cloudsmith’s new series on 

, breaks down what software supply chain integrity actually means, why maintaining it is so challenging, and how frameworks like 

S2C2F (Secure Supply Chain Consumption Framework)

 help organisations implement consistent, secure open-source consumption practices.

Ready to understand where your supply chain security stands? Take our 

Software Supply Chain Maturity Assessment

 refers to the ability to ensure that every component in your software, from source code to dependencies to build artifacts and containers, remains authentic, untampered, verified, and sourced from trusted origins.

Do we fully trust the software we’re using?

Are we confident it hasn’t been altered, compromised, or replaced?

It goes beyond traditional application security. While AppSec focuses on your code, integrity focuses on the 

Where did this software originate? Can we verify the source?

Was it built by who it claims to be built by?

Has anything been modified, injected, or tampered with?

How do we enforce policies around what can (and cannot) enter our supply chain?

Can we rely on the upstream source, or do we have a trustworthy internal copy?

As organizations scale, maintaining this integrity moves from "nice to have" to "mission-critical."

Why supply chain integrity is challenging today?

Modern engineering teams consume thousands of open-source packages and containers from public ecosystems like npm, PyPi, Maven, and Docker Hub. These communities evolve fast, and threat actors have learned to weaponize that speed.

The "trust but verify" model is dead. We are now in a "verify, then trust" era. Here is why the landscape has shifted:

1. Malicious package uploads / Typosquatting

Attackers publish packages with names similar to legitimate ones (e.g., reqeust instead of request) to trick developers or automated tools into installing them. Once installed, these packages often run "post-install" scripts that exfiltrate environment variables or keys.

If you use an internal package name (e.g., my-company-auth) that isn't registered publicly, attackers can register that name on a public registry with a higher version number. By default, many package managers will pull the "latest" version -tricking your build system into downloading the attacker's public malware instead of your private code.

If an open-source maintainer’s credentials are stolen, attackers can modify widely-used packages, injecting backdoors, data exfiltration, or crypto-mining code into thousands of downstream applications instantly.

4. Upstream removal or "Left-Pad" incidents

It’s not always malice; sometimes it’s chaos. A popular OSS package can be unpublished by its author (like the infamous left-pad incident), breaking builds across the globe. If you rely on public registries directly, your pipeline is at the mercy of their uptime.

Malware embedded inside base images, compressed binary artifacts, or build scripts can spread downstream silently and undetected.

This modern threat landscape requires a shift in thinking. It’s not just about using open source securely; it’s about maintaining centralized ingestion, policy enforcement, provenance checks, and continuous monitoring

The pillars of software supply chain integrity

To help teams build strong governance around software dependencies, several core integrity principles have emerged. These align closely with industry standards, such as SLSA (Supply Chain Levels for Software Artifacts) and S2C2F.

Software supply chain integrity relies on a set of proven pillars that help teams control how software is sourced, validated, stored, and consumed. These include:

Never pull directly from the public internet in production builds. Consume OSS and third-party software through a centralized "front door", an artifact repository controlled by your organization. This acts as a firewall for your code, preventing accidental consumption of malicious packages and shielding you from upstream outages.

You cannot secure what you cannot see. A Software Bill of Materials (SBOM) provides a clear inventory of all dependencies, versions, and transitive packages. It's critical for identifying risky components and responding quickly to new vulnerabilities.

Automate detection at the gate. Scanning must happen 

 a package enters your environment. This includes checking for:

Known CVEs (Common Vulnerabilities and Exposures)

 standards. Establish global rules for approved packages, permitted licenses, vulnerability thresholds, and immutability. Governance ensures that developers in Team A and Team B are subject to the same safety standards and regulations.

Verify the origin. Ensuring your binaries match their source code is essential. Provenance checks confirm who built the software, where it was built, what tools were used, and whether the artifact signature matches the builder's key.

To achieve maximal integrity, organizations rebuild OSS packages inside their own trusted environment, signing them and generating SBOMs for each build.

Introducing S2C2F: A framework for supply chain integrity

One of the most practical and widely adopted frameworks for implementing software supply chain integrity is the Secure Supply Chain Consumption Framework (S2C2F).

Originally created by Microsoft in 2019 to secure their massive internal development loops, it was donated to the Open Source Security Foundation (OpenSSF) in 2022. It now serves as the industry standard for how organizations should 

 open-source software (as opposed to SLSA, which focuses on how you 

S2C2F offers eight core principles and four maturity levels to help organizations enhance their approach to consuming open-source software.

 All external artifacts must come through a central, controlled location.

 You must maintain a complete list of all OSS components you use.

 Vulnerabilities must be patched within a defined SLA.

 Developers must be prevented from bypassing secure methods technically.

 You must log and audit all ingestion sources and changes that occur.

 Automated scanning for CVEs and malware is mandatory.

 For high security, rebuild OSS on a trusted infrastructure.

 If a patch isn't available, fork and fix it yourself temporarily.

To keep this focused, we’ll dive deeper into S2C2F, including maturity levels and practical implementation steps, in Part 2 of this series.

1. What is software supply chain integrity?

Software supply chain integrity is the practice of ensuring that every component in your software development lifecycle—dependencies, containers, build artifacts, and scripts—is authentic, verified, tamper-free, and sourced from trusted origins. It answers the question: "Is this code exactly what it claims to be?"

2. Why is software supply chain integrity important?

Modern software relies heavily on third-party and open-source components that can be compromised, removed, or tampered with. Integrity prevents attacks such as dependency confusion, malware injection, and supply chain compromise.

3. What is the difference between SLSA and S2C2F? 

Think of them as two sides of the same coin. SLSA (Supply-chain Levels for Software Artifacts) focuses on securing the 

 process (how you create software). S2C2F (Secure Supply Chain Consumption Framework) focuses on the 

 process (how you consume open-source software). You need both for a complete software supply chain security strategy.

4. How does Cloudsmith prevent dependency confusion attacks?

The most effective way is to use a private artifact repository (like Cloudsmith) that supports "upstream proxying" with namespace protection. This ensures that if an internal package name exists, the build system will never look for it on the public registry, preventing the injection of malicious public packages.

5. How does Cloudsmith support supply chain integrity?

Cloudsmith acts as a secure "supply chain firewall." It allows organizations to centralize OSS ingestion, automatically scan for malware and vulnerabilities, manage SBOMs, enforce license policies, and verify provenance—automating the requirements of frameworks like S2C2F.

Parul Jhawar

Marketing

Security Maturity Assessment Guide

What is Software Supply Chain Integrity?

The rise of software supply chain attacks isn’t slowing down. While many developers are familiar with typosquatting, a new, AI-driven threat has emerged: slopsquatting (also known as "phantom dependencies"). Last week, Cloudsmith hosted a webinar unpacking the mechanics of these attacks, their real-world impact, and the practical ways engineering teams can defend their development pipelines.

If you missed the live webinar, don’t worry; here’s a recap of the biggest insights, examples of attacks, and expert perspectives shared by our speakers, 

Nigel Douglas (Head of Developer Relations)

What is causing the increased threat from Typosquatting?

Typosquatting has been around for years, but attacks are now increasing rapidly thanks to:

developers relying more on autogenerated code

the ease of publishing look-alike packages in public repositories

As Claire Speedy (Senior Growth Marketing Manager) framed it during the opening:

“These threats are everywhere. If you're shipping software, you can’t afford to ignore them.”

This session explored not just how these attacks occur, but how open-source data sources, security tooling, and artifact management workflows can be used to stop them before they ever reach production.

Understanding typosquatting and slopsquatting attacks

Typosquatting is a cyberattack where malicious actors register package names that are slight misspellings or variations of legitimate ones. The goal is to trick users into installing a deceptive, malicious package.

Visual lookalikes (Character Swaps, misspellings, or reordering):

Attackers register names that look nearly identical to popular packages, relying on cognitive shortcuts. Users,and increasingly AI agents, glance at the text and "autocorrect" the error in their minds.

 Swapping characters, omitting letters, or using "homoglyphs" (characters that look alike).

matplotltib (pretending to be Python's matplotlib)

reqeust (classic persistence, still actively blocked daily)

Soundsquatting (Sound-alike or pronunciation-based variants)

This tactic targets developers who learn package names verbally (e.g., from podcasts, team calls, or YouTube tutorials) or use voice-to-text tools. The package name is spelled differently but sounds identical to the legitimate one.

 Using homophones (words that sound the same) to bypass mental spelling checks.

colors vs colours (exploiting regional spelling differences)

snyk vs snick (phonetic variations of branded tools)

Instead of misspelling a name, attackers append "trust signals" -words like "-official", "-security", or "-plugin" to a legitimate brand name. This tricks developers (and AI models) into believing the package is an official extension of a trusted library.

lodash-js or lodash-plugin (mimicking extensions to lodash)

discord-dev (mimicking official Discord developer tools)

noblox.js-proxy (mimicking the popular noblox.js wrapper)

2. Real-world example: A typosquatted PyPI package

Nigel demonstrated a live example using the OSV (Open Source Vulnerabilities) API, querying a malicious PyPI package called 

, a near-match for the legitimate requests library.

“A typosquat on a popular package… delivering a crypto-miner payload.”

Even if PyPI removes the malicious package hours later, it might still be cached in an internal artifact store or build environment, making retrospective scanning essential.

3. Why this problem exists: The “Wild West” of package ecosystems

Public upstreams like PyPI, npm, and crates.io are intentionally open and permissive - great for innovation, but also beneficial for attackers.New packages are uploaded daily. Manual vetting is almost impossible. That allows malicious typo-squatted packages to accumulate downloads before maintainers can detect and disable them.

Example: a typo-squatted npm package that sat unnoticed for 

 and still collected hundreds of downloads.This is exactly why organizations need to pull dependencies into a controlled platform like 

 instead of sourcing them directly from public registries; it provides an opportunity to scan, quarantine, and validate packages before they reach your developers or pipelines.

4. Introduction to Slopsquatting: The new AI threat

Slopsquatting is the modern evolution of this threat, driven by Generative AI. It occurs when Large Language Models (LLMs) hallucinate plausible-sounding package names that don't actually exist.

Attackers scan these LLM outputs to find "phantom dependencies" - packages that ChatGPT or Copilot 

 exist but don’t. The attackers then register these names on public registries like npm or PyPI.

"AI tools hallucinate nonexistent packages. Attackers register them. Developers copy-paste the code and accidentally install them. It’s a perfect exploitation chain."

 - Liana Ertz, Product Manager at Cloudsmith

Recent research (AI Incident Database) indicates that 

of hallucinated package names in Python and npm were converted into actual malicious uploads in 2023.

In 2024, hallucination rates for package names still range from 

5. Developer behaviour is increasing the risk

Many developers said the majority of their code is AI-generated, and much of it is pushed to production with fewer peer reviews than ever before.

Nigel described this pattern as - he rise of vibe-coding, generating code, trusting it, and shipping it without the right checks. Combined with slopsquatting, this creates a perfect storm for open-source malware infiltration.

6. How Cloudsmith helps detect & block malicious packages

Today, Cloudsmith integrates directly with the OSV data feed to automatically:

Enrich packages with vulnerability & malware context

Provide package insights, provenance, and trust signals

Nigel demonstrated Cloudsmith’s policy engine in action:

A malicious package was uploaded → OPA policy detected OSV’s MAL- identifier → the package was 

This happens before it reaches your developers or build systems.

Liana also shared what’s coming next:We're ingesting more provenance metadata, publish dates, download activity, maintainers, to help identify high-risk packages early. We're also exploring MCP and upstream trust features to prevent dependency confusion.”

 AI hallucinations are creating "phantom dependencies" that attackers are actively exploiting.

 It's no longer just about misspellings; it's about confusing the developer 

 You cannot manually vet every npm or PyPI package. You need policy engines that block bad artifacts at the door.

 By ensuring only trusted, verifiable artifacts reach your pipeline, you neutralize the risk of "vibe-coding" errors.

If you couldn’t join the live session, here are the highlights you missed:

Real demonstrations of malicious PyPI packages

Examples of AI hallucinating dangerous package names

Research on developer behavior and AI reliance

A walkthrough of Cloudsmith’s quarantine + policy engine

Q&A covering provenance, signatures, SLSA, and more

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

In recent years, the software supply chain has become a prime target for attackers. From dependency vulnerabilities to third-party risks in DevOps, organizations face mounting challenges to keep their software secure and uncompromised. Traditional security models no longer hold up. Adversaries are exploiting every stage of the pipeline, from code through deployment.

This is why the role that DevOps teams play in security has become more significant than ever. Speed and agility are no longer the only concerns for DevOps; it is now resilience and trust with risk management. Organizations can keep ahead of threats by ensuring that security is incorporated in all stages of the development and delivery lifecycle, and minimize their exposure to software supply chain threats.

The guide gives a simple, high-level overview of how supply chain security in DevOps operates, challenges that organizations face, and what strategies organizations can adopt to reduce risks. This complete guide comes with a 101 explanation of how DevOps enhances security in your organization.

A software supply chain risk is any weakness, vulnerability, or exposure that gets into your system via the components, tools, and processes of building and delivering software. Since modern applications are dependent on countless third-party libraries, external services, and automated pipelines, organizations face the risks associated therewith.

The majority of applications rely on open-source libraries and frameworks. In case such dependencies have unpatched vulnerabilities, attackers would use them for access.

Vendors, contractors, and external integrations can accidentally place insecure code, improper configurations, or malicious programs into the environment.

Build and deployment pipelines are prime targets. Once attackers gain access, they can insert malicious code or modify software before it goes into production.

Packages, binaries, and containers available in repositories can be abused in case they are not secured and validated correctly. It can lead to the distribution of poisoned releases to the customers.

Attackers can intentionally introduce malicious code into dependencies or update streams to attack software integrity.

Risk may be deliberately or accidentally brought in by employees or contractors who have high access. They have the ability to bypass the controls or have sensitive information mismanaged.

Lack of visibility into licensing, provenance, and security standards elevates risk to legal and operational risks.

In the absence of vulnerabilities, real-time monitoring and suspicious activities can be identified only after they have been exploited.

Why DevOps plays a key role in supply chain security

The old model of software security, which implements verification at the end of software development, is no longer able to cope with the current threat environment. Modern software is developed and deployed in a continuous manner with the help of code contributed by multiple developers, open-source ecosystems, and cloud-native infrastructures. Such an interconnected environment needs a new model of security that keeps up with the same development pace. 

This is where DevOps comes in. By inserting security directly in the delivery pipeline and development, organizations can detect and remove threats prior to production. Security in DevOps supply chains guarantees trust and integrity throughout the lifecycle, including source code to deployment.

Here are the key reasons why DevOps is essential for securing the software supply chain:

The greatest myth about security is that it slows down development. As a matter of fact, DevOps enables an organization to integrate security into its current work processes, which helps teams develop quickly and remain secure. Automated vulnerability scanning, policy enforcement, and patching can ensure that faster releases do not produce new risks.

Manual security checks are subject to supervision. Using DevOps, organizations can make security controls, such as dependency scanning or artifact validation. This does not only minimizes errors but also offers continuous safeguarding against threats that arise in real-time.

DevOps focuses on transparency. Teams obtain end-to-end visibility of the entire pipeline, from the source of dependencies to the integrity of artifacts in repositories. This visibility helps detect suspicious changes early, supporting continuous security monitoring across the lifecycle.

Regulatory demands are becoming increasingly complex, and hence, compliance cannot be an afterthought. DevOps permits DevOps governance and compliance frameworks, in which licensing, data protection, and security standard checks are incorporated in the delivery pipeline. This minimizes the chances of penalties that follow non-compliance and promotes accountability.

Traditional models discover risks too late, often after deployment. DevOps makes sure that vulnerabilities (for example, dependency vulnerabilities and misconfigurations) are identified during development or build stages. This risk management approach of DevOps avoids expensive remedies and minimizes the exposure.

Now, security is no longer the responsibility of an individual team. DevOps is based on the principle of a shared responsibility model in which developers, security experts, and operations teams collaborate. This partnership will make sure that DevOps security best practices are implemented in all workflows.

 offers an opportunity to change the paradigm of reactive defence and move to proactive prevention by combining speed, automation, and governance. The outcome is a secure software delivery lifecycle that shields both organizations and customers against supply chain threats.

What role does artifact management play in software supply chain risk?

Artifact management is a core pillar of DevOps supply chain security because it ensures that every software component—packages, binaries, containers, dependencies, and metadata—is stored, tracked, and delivered securely. A secure 

 prevents tampering, unauthorized access, and the introduction of malicious or unverified packages into the DevOps pipeline.

By centralizing and governing all build outputs, artifact management helps organizations:

Verify the authenticity and integrity of artifacts before deployment

Reduce dependency vulnerabilities and third-party risk in DevOps

Strengthen DevOps risk management with full traceability

Enforce consistent policies across environments

Maintain trusted sources for all production releases

 also enable continuous scanning, SBOM generation, and governance controls—making them critical for mitigating software supply chain risks and securing fast-moving CI/CD workflows.

Common supply chain security risks in DevOps

Despite sound DevOps practices, organizations face risks related to the speed and complexity of modern software delivery. These risks also tend to rise out of the tools and processes that render DevOps effective.

Continuous Integration and Continuous Delivery (CI/CD) pipelines automate the process of code flowing between development and production. Nevertheless, in case the attackers crack into a pipeline, they are able to inject malicious code, steal credentials, or tamper with builds. Weak access controls, poor secret management, and the absence of integrity checks create serious vulnerabilities.

2. Third-party dependencies and open source

Third-party integrations and open-source libraries are fast to innovate, but this increases the attack surface. When an outdated dependency, abandoned dependency, or compromised dependency is used, it may result in critical dependency vulnerabilities spreading across the application.

Repositories hold applications’ software artifacts like containers, packages, binaries, and so on. However, if these repositories have a shortage of integrity validation, version control, or proper access policies, attackers can poison artifacts, resulting in downstream compromise. Artifact repository security is important to safeguard against tampering.

Employees, contractors, or partners with privileged access can intentionally or accidentally introduce risks. In the absence of granular permissions, monitoring, and auditing, insider threats still constitute one of the most overlooked aspects of DevOps risk management.

DevOps is fast-driven, but without organized policies and controls, compliance can languish. Lack of proper DevOps governance and compliance poses risks associated with data privacy, licensing breaches, and regulatory fines.

The fast-paced nature of DevOps often results in a lack of monitoring. Without continuous security monitoring, new vulnerabilities or attacks may exist under the carpet until it is too late.

How DevOps mitigates software supply chain risks

The actual power of DevOps is that it unites speed and control. By integrating security into workflows and automation of controls, DevOps reshapes supply chain security from a reactive process into a proactive approach. The following are the main lifecycle-wide risk mitigation benefits of DevOps:

1. Building a secure software delivery lifecycle

The software delivery lifecycle of a DevOps environment is continuous, meaning vulnerabilities can propagate rapidly unless controlled. A secure software delivery lifecycle (SDLC) makes sure that all the phases of software development—from planning to deployment—have inbuilt security.

This practice implies that when vulnerabilities are identified at an earlier stage, they are cheaper and easier to fix. Code analysis, dependency verification, and security checks are all part of pipelines and not a one time assessment. The outcome is a development cycle that results in trusted, secure, and reliable releases.

2. Applying DevOps security best practices

The basis of protection against threats to the supply chain is laid in the form of DevOps security best practices. These are regular code reviews, automatic vulnerability scanning, and patching. When these practices are codified into pipelines, security becomes part of the process rather than a point of congestion.

Additional best practices are restricting access to sensitive repositories, rotating secrets, and adopting least-privilege considerations. A combination of these reduces both external and insider threats.

Attackers usually target CI/CD pipelines as they determine how code reaches production. The safety of 

 is ensured through the implementation of access controls, anomaly detection, and verification of all the build artifacts.

Embracing zero trust in the software supply chain implies that no step in the pipeline is implicitly trusted—all processes, dependencies, and artifacts must be tested. This significantly decreases the chances of tampering with the pipeline or unauthorized changes to code.

4. Leveraging the software bill of materials (SBOM)

 (SBOM) in DevOps is one of the most powerful tools for securing modern supply chains. An SBOM is a comprehensive list of components, dependencies, and open-source libraries that are utilized in an application.

With such a degree of transparency, organizations will be able to soon identify whether they are disclosed to newly discovered vulnerabilities. SBOMs also help in compliance by demonstrating that software components can fulfill security and licensing specifications.

5. Strengthening cloud-native supply chain security

Cloud-native supply chain security becomes important when organizations transition to containerized and microservices-based architectures. New attack surfaces, that are presented by containers, orchestrators, and serverless functions need to be secured.

Container image scanning, runtime monitoring, and Kubernetes (or other orchestration platform) policy enforcement are best practices in this context. The above measures will guarantee the ability to expand workloads safely without creating new vulnerabilities in the ecosystem.

6. Implementing risk mitigation strategies in DevOps

Good risk mitigation practices in DevOps extend beyond technical controls- including processes and governance. Automated incident response, compliance audits, and ongoing risk assessment enable organizations to react more quickly to growing threats.

Cultural change is also needed in risk mitigation. Security should be treated as a team effort where developers, operations, and security experts work in harmony. This cultural alignment ensures resiliency in the entire software supply chain.

7. Using DevOps tools for supply chain security

Cloudsmith Blog

What is Software Supply Chain Integrity?

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

The 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

XRPL Supply Chain Attack and How to Block it Using Cloudsmith’s Enterprise Policy Management

Enterprise Policy Management with Cloudsmith

Cloudsmith Achieves ISO 27001:2013 Recertification

World's First Private Hex Repository with Cloudsmith