By submitting this form, you agree to our 

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

Various tools are available to strengthen supply chain security in the DevOps processes. DevOps tools for supply chain security include artifact repositories imposing trust, dependency vulnerability scanners, and monitoring platforms that detect suspicious activity.

These tools will offer constant guardrails without slowing down delivery when included in CI/CD pipelines. The process is not only about using the tools; the most important thing is to make sure that they are embedded into the pipeline in a form that creates consistency across all builds and releases.

By combining these strategies, DevOps will make security a facilitator and not a barrier. Organizations that integrate these practices into their pipelines generate a solid structure where supply chain risks are continuously monitored, mitigated, and addressed

It is not only a list of tools that is needed to mitigate software supply chain risks, but it is also a process-driven and cultural change in the way organizations approach development and operations. The following are the best practices that organizations need to embrace to enhance the security of their supply chain within DevOps:

1. Integrate security early and continuously

Security should not be bolted on at the end of development. Rather, integrate it throughout the beginning and the entire lifecycle. This implies the inclusion of security checks in source code repositories, builds, and deployments.

DevOps security best practices ensure that vulnerabilities are detected at the time of writing code or pulling in dependencies rather than after deployment. When detected earlier, it cuts down the cost of remediation and acts before the risks can move downstream.

Compliance requirements are becoming strict across industries. DevOps governance and compliance policies need to be part of the organizational workflows.

This includes imposing a licensing check on open-source libraries, ensuring that the code is within regulatory standards, and maintaining audit logs. Effective governance not only mitigates financial and legal risk but also fosters customer and regulator trust.

3. Focus on continuous monitoring and threat detection

The velocity of DevOps implies that deploying a new piece of code occurs regularly, and risks can occur at an equivalent rate. Organizations need to implement ongoing security controls to monitor activity within pipelines, repositories, and production environments.

Anomaly alerts in real time, auto-responses to suspicious behaviors, and connections with SIEM systems help to make sure that threats are detected before they harm the system. Monitoring also offers valuable insights for improving future defenses.

The use of hundreds of third-party libraries, tools, and vendor integrations is central to modern applications. Both introduce third-party risk in DevOps that needs to be addressed carefully.

Organizations are supposed to have a list of all third-party components, check their security posture, and regularly update or replace old dependencies. Reduced inherited risk can also be achieved through vetting the vendors to practice supply chain security themselves.

Moving processes manually is liable to errors and cannot be used at the pace of modern DevOps. Consistency, accuracy, and reliability are attained through automation.

Some of the fields that can be automated are dependency scanning, verification of artifacts, vulnerability patching, and compliance checks. By making automation a core part of risk mitigation strategies in DevOps, organizations ensure that protection keeps pace with delivery velocity.

The weak point of the supply chain is usually trust. 

 strategy makes sure that all the processes, dependencies, and artifacts are validated prior to use.

The principle works in pipelines, repositories, and production environments. By eliminating implicit trust, organizations reduce the risk of malicious code being absorbed through an undetected method.

Finally, tools and policies are effective only when they are adopted by the teams. Companies need to embed a security-first culture in their environment, in which developers, operations, and security professionals are held accountable for protecting the security of the supply chain.

Parul Jhawar

Marketing

The DevOps Guide to Mitigating Software Supply Chain Risks

The adoption of artificial intelligence is seen in just about all industries, with software engineering experiencing large benefits from AI assistants. Tools like Anysphere’s 

 are driving a fundamental shift in how engineering teams build and ship software. However, as development teams rush to integrate LLMs and generative capabilities into their products, a critical blind spot is emerging in the software supply chain.

While security teams have spent years fortifying their pipelines against vulnerable Docker images and malicious npm packages, the introduction of AI artifacts (specifically ML models and their associated datasets) has opened a new, largely ungoverned frontier for software development teams. The challenge is no longer just about securing the code you write, but about verifying the provenance and integrity of opaque binary blobs that are often pulled directly from public repositories into production environments.

 has become the de facto standard for discovery and storage, playing a role similar to what 

 for containers. It is a massive, thriving community where developers can easily download pre-trained checkpoints, fine-tune them with 

, and deploy them via inference endpoints. Yet, the very openness that makes these platforms engines of innovation also introduces significant risk. Just as software engineering leaders would never want or allow a developer to pull an unverified executable from the open web directly into their banking application, they must stop treating these ML models as benign assets during this new age of AI software development. These are executable artifacts that require the same rigour, scanning, and governance as any other critical dependency in the software stack.

The most pressing concern facing development teams today is the specific architecture of these models, particularly regarding "

". Pickle files are Python-based modules used to serialise and deserialise code, a standard method for storing trained ML models. However, this format is inherently insecure by design. Threat actors have weaponised this necessity, embedding malicious payloads that execute arbitrary Python code during the deserialisation process. Security researchers have already identified hundreds of malicious models on public hubs that utilise these techniques to deploy web shells or execute remote code evasion tactics. While platforms like Hugging Face are proactively deploying 

 tools and warning users, the sheer volume of community uploads means that reliance on the public source alone is an insufficient security posture for the enterprise.

Furthermore, the security challenge extends beyond the model itself to the ecosystem that supports it. An AI project is rarely just a model file; it is a complex dependency tree involving Python packages, libraries like 

 (tool for building and deploying AI-powered agents and workflows) or 

 (OpenAI's Text-to-Image Transformer), and various system-level binaries. A secure model running on top of a vulnerable version of a Python library offers a wide-open door for attackers. Therefore, true AI supply chain security requires a holistic approach that governs the model, the dataset, and the OSS dependencies simultaneously. If you are scanning your models for malicious pickles but failing to check the 

 of the Python packages they rely on, the supply chain remains broken.

This is where the concept of a centralised system of record becomes non-negotiable. To mitigate these risks without stifling innovation, software engineering, DevOps and security teams must implement some sort of architecture of isolation and control. This involves 

 public registries. By placing a controlled layer between the developer and the public internet, dev teams can ensure that every artifact (whether it is a Docker image, a Python package, or a Hugging Face model) should be scanned for malware, vulnerabilities, and license compliance before it ever enters the internal network. This allows developers to use standard CLI tools and workflows they love, while security teams enforce policies in the background, quarantining suspicious artifacts before they can cause harm.

 approaches this challenge by extending traditional artifact management to include the specific nuances of AI and ML workflows. By providing a single point of control, Cloudsmith allows enterprises to manage ML models alongside their existing software packages, creating a unified source of truth. The platform proxies and caches external sources like Hugging Face, automatically stripping out risks and verifying provenance. This ensures that when a developer runs a command to pull a model, they are receiving a version that has been vetted against enterprise policy and validating trustworthiness. It bridges the gap between the data science team’s need for speed and the security team’s need for governance.

Ultimately, the future of secure AI development lies in consolidation. The separation of "

" is a dangerous dichotomy. As AI becomes intrinsic to application development, the distinction between a code dependency and a model dependency vanishes. By utilising a platform like Cloudsmith to centralise access control, enforce read-only entitlement tokens, and automate policy management, platform engineers can protect their organisation’s intellectual property and their infrastructure. It turns the supply chain from a vector of attack into a controlled, observable pipeline, ensuring that the only thing your AI models deliver is value. If you’d like to learn more about Generative AI threats like Slopsquatting, register for our 

Typosquatting & Slopsquatting: Detecting and defending against malicious packages webinar

Nigel Douglas

Head of Developer Relations

Software Supply Chain Security in the Age of AI

Securing the intersection of AI models and software supply chains

Artificial intelligence has moved beyond a futuristic concept to a daily collaborator for almost all development teams today. Tools like GitHub Copilot and ChatGPT are writing functions, suggesting dependencies, and building application skeletons at a blistering pace. This revolution in speed is undeniable, but it comes with a critical, often-overlooked consequence: AI-generated code is fundamentally changing the demands on artifact management.

We're moving faster than ever, but that speed has created massive blind spots in our software supply chain. The core question is no longer just "

Does AI check its sources and provide provenance checks?

Let's address the first fundamental question. When an LLM suggests a software package or a new dependency, does it perform 

" if a dependency is credible, accurate, or safe. It's not testing that package in a sandbox. It's making a statistically probable recommendation based on the data it was trained on.

This creates a terrifying new attack vector. The AI has no concept of:

, pulling in a malicious package. Oftentimes it depends on what you ask for, and sometimes you get exactly what you asked for - whether that’s a good package or not.

: AI can't scan a dependency for malware before recommending it. After the ‘s1ngularity’ and ‘

’ attacks on the NPM ecosystem, there is a heightened focus on understanding the contents of open-source packages that we consume from these upstreams.

: AI doesn't differentiate between a well-maintained library from a trusted foundation like the CNCF vs. an abandoned, vulnerable package from a random user that likely will not be actively maintained going forward.

If a developer accepts that suggestion, a compromised dependency is instantly pulled into the codebase, bypassing all traditional human vetting.

Typosquatting is a type of cybercrime where attackers register domain names, or in this case dependency names, that are common misspellings or slight variations of legitimate websites/packages/dependencies to trick users into visiting a malicious site or downloading a software dependency that ultimately contains malware. A perfect example is the 

 example we mentioned earlier. One extra letter and many users wouldn’t immediately recognise it as a typo. Let’s query PyPi to see the owner of both packages:

 (AKA bitprophet). Whereas, the typosquatted package name returns “

” for the owner. You’ll have probably noticed by now that this package no longer exists on PyPi as it was intentionally created to cause harm - and has since been removed. While that’s good for the community, there’s a chance that an organisation may have already cached that package locally. In those cases, the OSV.dev public API can be really useful to identify whether your cached dependencies were created as part of a typosquatting campaign:

So what’s all this got to do with generative AI? Well, GenAI is just as guilty of hallucinating and recommending package names that simply don’t exist. Adversaries pick up on the behaviour, and thus create more typosquatted upstream packages in the hope that “

” code generation recommends one of those typosquatted package names. This is commonly known as 

. To stay ahead of slopsquatting, modern artifact management are expected to have full provenance checks on all software artifacts to understand who created them, are they credible, and have they already been flagged as compromised according to the 

Malware, unlike vulnerabilities in software, is a dedicated piece of software that is specifically designed to disrupt, damage, or gain unauthorised access to a computer system. Traditional vulnerability scanners are looking for flaws in an application code that can be exploited. These are marked by CVEs (like 

). However, malware contained within compromised upstream packages will not show-up in those CVE reports. Instead, we can use the same OSV.dev public API to see if an open-source upstream package, such as 

After running this command, you see that the package is identified as containing malware, with a unique identifier - 

. Now you couldn’t be expected to run this manual action every time you want to check if a specific dependency and version contain malware, that would take all day. Thankfully, Cloudsmith integrates the 

 API directly within our product. So on package synchronisation, we will automatically scan for known Malware identifiers (ie: MAL-YEAR-ID) associated with the open-source software dependency. If there’s a match, we can quarantine this automatically through 

Most recently, a variant of PhantomRaven malware was found in 

, designed to steal GitHub Tokens from developers. If LLMs cannot quickly identify whether an upstream package is compromised or not, what stops these generative AI tools from suggesting compromised packages? As the prevalence of malware in upstream repositories increases, this simultaneously changes the demands being put on artifact management. Modern artifact management solutions need to be able to identify and prevent compromised open-source software packages from being used by developers.

AI models used for code generation are trained on vast, uncurated datasets of public repositories, learning statistical patterns rather than semantic quality. This training methodology makes them incapable of assessing 

. The model does not understand that a CNCF-hosted project undergoes rigorous security audits, has a dedicated maintenance team, and follows a clear governance model. To the AI, that project's code patterns may look statistically similar to an abandoned, single-maintainer package on GitHub that contains known CVEs or is a prime candidate for a typosquatting attack. This "

" means the AI's suggestions are based on pattern frequency, not on a risk assessment of the dependency being recommended.

This blind spot directly reflects the current software supply chain risk. An AI can confidently recommend a dependency that, while functionally correct for the prompt, introduces significant security debt. This is backed up in the data. Chainguard’s "

" found that 1 in 5 respondents said that their engineers are not allowed to use AI for some of the most time-intensive tasks, such as patching vulnerabilities, running tests, or conducting code reviews. These are the tasks where technical credibility is needed to make those final judgements.

Furthermore, AI models trained on these OSS software ecosystems will inevitably learn from and recommend historically compromised packages from those upstreams. This problem is recognised by security foundations like OWASP, whose "

" lists risks like "Insecure Output Handling" (LLM03) and "Training Data Poisoning" (LLM04), where the model's output or its training data can be leveraged to inject vulnerabilities directly into a developer's workflow.

Ultimately, the credibility of these outputs can be benchmarked against frameworks such as the 

. This project was built by open-source developers to help secure the critical projects the community depends on. It assesses open-source projects for security risks by running a series of automated checks. You can use it to proactively analyse the security posture of your own code and make better-informed decisions about acceptable risks. The tool also helps you evaluate other projects and dependencies, giving you a basis to work with LLMs on improvements before you integrate into your codebase.

Does this mean we should be discouraged from using AI-generated code?

The short answer is 'no,' but a cautious and deliberate approach is essential.

We view generative AI much like any other programmable interface. It excels at following instructions, which means the quality of the output is directly dependent on the quality of the input.

A developer who is skilled in their domain will understand how to instruct the AI to produce high-quality, relevant content, thereby accelerating their workflow. For example, knowing precisely which software packages and versions are appropriate for a production application prevents the AI from referencing and introducing compromised dependencies.

By providing specific context, such as example code, the application framework, established code styles, library usage, specific dependency versions, and error handling protocols, a developer can guide the AI. This ensures it follows established rules and helps produce code significantly faster than manual methods.

Regardless of popular sentiment, our view is that generative AI is not close to replacing human intelligence in software development. Its current, practical role is to speed up and facilitate the quality work humans do, ultimately increasing overall productivity.

This new power, however, requires a corresponding increase in diligence for software governance, provenance checks, and vulnerability scanning. Maintaining control over AI-generated code means knowing exactly what is running in the estate, who created it, and being confident whether it is safe or not. This is all achievable through a comprehensive artifact management platform. If you’d like to learn more about this, we have an 

 on the topic of slopsquatting in the age of GenAI.

AI generated code is changing the demands being put on artifact management

At approximately 0300 on the 24th of November 2025, a new wave of compromised open source packages began circulating in the npm ecosystem. This iteration (dubbed “Shai-Hulud: The Second Coming” by the attackers) is designed to leak developer secrets, including GitHub tokens, CI/CD credentials, and cloud credentials.

This is a targeted supply chain attack affecting over 425 packages, including high-traffic dependencies.

Here is what we know, how we responded, and what you need to do.

The malware creates unauthorized GitHub repositories on a compromised developer’s account. While the naming convention of the repository is random, the description reads “Shai-Hulud: The Second Coming”. The attack vector also involves specific malicious workflow files injected into repositories.

High-traffic packages confirmed as affected include 

 continues to grow as upstream providers identify and remove malicious versions.

Cloudsmith response: We have notified impacted customers

Cloudsmith immediately initiated an investigation and identified customers who may have pulled the compromised versions of these packages. We have notified potentially impacted customers with recommended remediation steps.

However, because upstream providers are still identifying and removing malicious versions, we strongly recommend you perform the audit steps below.

Investigate all repositories for dependencies that include affected packages.

Remove and block: Remove malicious packages immediately and implement blocking rules to prevent re-introduction.

Clean environment: Clean your npm cache and reinstall all packages in project environments. Ensure you use a package lock file and pinned versions.

Rotate secrets: Rotate environment variables and secrets (GitHub, NPM, Cloud credentials). Crucial: Ensure this is done after the malicious packages have been removed and the workstation is deemed safe.

Investigate repositories: Check all GitHub repositories (organization and employee accounts) for any containing the description “Sha1-Hulud: The Second Coming” or suspicious workflow files like .github/workflows/discussion.yaml.

Workstation audit: Check potentially affected workstations for downloads of these affected versions. Ensure EDR tooling scans are carried out to eradicate local copies of compromised packages.

Any GitHub, NPM, development related environment variables or secrets and Cloud credentials potentially affected should be monitored for misuse and rotated if compromise is suspected, ensuring this is done after the malicious packages have been removed and the workstation environment deemed safe

Future-proofing: detection is not prevention

The software supply chain has been weaponized such that the challenge with supply chain attacks like Shai-Hulud is the gap between the 

 and its detection. Attackers rely on this window to infiltrate builds before security feeds have a chance to catch up.

To close this gap, organizations need to address protection in two distinct phases: defending against the unknown (Zero-Day) and managing the known (N-Day).

In the initial hours of an attack, before a CVE or MAL identifier exists, security tools are often blind. The most effective defense here is not signature detection, but metadata-based policy.

allows you to implement a "cool-down" period for new assets. By creating a policy that blocks or quarantines packages published within the last week, you effectively neutralize the threat of pulling malicious packages prior to detection. This ensures that no package enters your pipeline until it has been in the wild long enough to be vetted by the community and security researchers.

Once a threat is identified and cataloged, as these packages now are, the focus shifts to immediate isolation.

 constantly re-evaluates your stored artifacts against the latest threat intelligence streams. As soon as a package in your registry is flagged with a MAL identifier or vulnerability, Cloudsmith detects the change in status. When paired with Enterprise Policy Management, the platform can automatically trigger a quarantine action, preventing that specific version from being served to developers or build agents, without requiring manual intervention.

By layering these two approaches, metadata policies for zero-day prevention and continuous scanning for known threats, you replace manual investigation with automated governance.

We are continuing to monitor the situation. If you need assistance analyzing your logs or setting up EPM policies for package cool-down periods, please reach out to our support team.

Nick Peacock

VP, Customer Success

Shai-Hulud: The Second Coming - What You Need to Know and Do Now 

For most developers, the traditional security pipeline is a source of friction, not a tool for enablement. You push a new feature, the CI build kicks off, and suddenly you're facing a wall of 1,200 critical CVEs from a transitive dependency you didn't even know you had. The release is blocked, and the security team becomes the "Department of No" - a metaphorical bottleneck that seems to exist solely to slow down velocity. This dynamic is broken. The goal isn't to have 

 security; it's to have smarter security that enables speed; that requires moving from noisy alerts to prioritised, actionable risk.

" culture is a direct result of missing context. When a security team sees a thousand CVEs, they have to assume all are critical. Without clear software provenance, every new dependency is a potential "

" - an unaudited package that could be anything from a benign tool to a typosquatted nightmare. An SBOM (Software Bill of Materials) provides the "what," but it doesn't provide the "so what?" This is why developers get buried in alerts for vulnerabilities that aren't even reachable in their code. To fix this, you need a system that doesn't just find problems, but also provides the context to 

This is where the pipeline needs to get smarter, starting at the build. A tool like 

 integrates directly into your CI pipeline to provide this missing context 

 an artifact is ever created. Its job isn't just to find every CVE; it's to intelligently triage them. By performing context-aware analysis, it determines if a vulnerability is 

 within your application's call path. This is the practical power of 

 (Vulnerability Exploitability eXchange) reporting. That jaw-dropping list of 1,200 CVEs becomes a manageable, actionable list of something like 

 that can genuinely pose a threat. Kusari acts as the guardian of the build, generating a tamper-proof evidence packet containing a signed SBOM, a VEX report, and a provenance attestation, ensuring you only build what you trust.

Once Kusari verifies a build and signs its evidence packet, the artifact can be pushed to the Cloudsmith artifact repository. Cloudsmith isn't simply a passive vault, it also serves as an intelligent admission control layer via Enterprise Policy Management (

 offering allows users to quarantine packages with a deep-level of context. This is where you set the rules: "Block any artifact with a non-compliant license from being pulled," or "Prevent any package with a critical-severity CVE from being deployed to production, if we know there’s a fix already available." It gives you the "last mile" of control, ensuring that only verified, secure, and compliant artifacts are distributed and consumed by developers and production systems.

This combination of Kusari and Cloudsmith creates a closed-loop security system that finally busts the "Department of No" myth. For developers, this means an end to the noise. You get fast, actionable feedback directly in your CI pipeline, allowing you to fix the five critical, reachable vulnerabilities instead of arguing about the 1,200 that aren't. For the organisation, it means security transforms from a reactive bottleneck into a proactive, automated discipline. You can trust that anything you pull from Cloudsmith is pre-vetted, and security teams have an end-to-end, auditable trail from source to deployment. This is how you stop fearing security and start automating it, enabling your team to ship with confidence and speed.

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

The npm ecosystem was hit yesterday by a malware attack affecting popular packages like 

. Both packages are typically bundled into frontend builds. Once included, the malicious payload executes.

These attacks are becoming more frequent - we reported on a 

similar attack on npm packages just 12 days ago

How you react depends on what is known about the threat:

Cloudsmith Blog

The DevOps Guide to Mitigating Software Supply Chain Risks

Securing the intersection of AI models and software supply chains

AI generated code is changing the demands being put on artifact management

Shai-Hulud: The Second Coming - What You Need to Know and Do Now

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

npm ecosystem alert: What you need to do today with Cloudsmith

NX npm Supply Chain Attack: How Cloudsmith Would Have Contained the Blast Radius

Compliance policies in EPM

Typosquatting a package? How about typosquatting the whole registry!

Six Hours Too Late: Why Malware Detection Must Be Built Into Artifact Management

Managing Malicious Packages with Cloudsmith EPM

Malicious Package Detection in Cloudsmith