By submitting this form, you agree to our 

Answer twenty questions about your artifact and supply chain practices. Get a custom report card showing your maturity score against key regulatory and compliance frameworks.

Artifact Security Maturity Assessment

 Docker is retiring Docker Content Trust (DCT), and it's time to migrate to open standards like Sigstore. If you're a Cloudsmith user, you're already ahead, since Cosign-based image signing is built-in. Here's how to make the move.

 launched with the goal of giving developers a way to verify the integrity and publisher of container images. It was built on The Update Framework (

Fast forward to 2025: Notary is no longer actively maintained, the industry has evolved, and 

 of Docker Hub image pulls use DCT. Microsoft is dropping support in Azure Container Registry, and now Docker is formally beginning to retire DCT. This starts with Docker Official Images (

If you're using DCT in your pipelines, things may already be breaking.

But there’s good news: the ecosystem is moving forward through 

, an open standard built for the modern software supply chain.

Provenance is becoming a critical part of how we secure the modern software supply chain. At its core, it’s about traceability: being able to answer where a software artifact came from, how it was built, and who was responsible at each stage of the process. Threat actors continue to increasingly target dependencies, build systems, and distribution infrastructure, meaning verifiable metadata about your software’s origin is really important. Being able to establish the provenance of your container images helps teams make informed, trustworthy decisions about what they built, run, and deploy. It’s a key building block for adopting frameworks like 

, and is top of mind for teams in highly regulated environments.

But knowing what happened during a build isn’t enough, you also need a way to attest to that information in a way that others can verify, without adding unwanted friction. So when you think, “why do I need Sigstore?” - that’s the reason. Sigstore is an open-source project that enables cryptographic signing of software artifacts like container images using standard tooling like Cosign, Fulcio, and Rekor.

Unlike DCT, which relied on TUF until the upstream Notary codebase was no longer actively maintained, Sigstore has an active community of contributors and is integrated into a long list of 

Sigstore makes it easy to integrate signing and verification into your CI/CD pipeline without the need for custom certificate infrastructure requirements. You can use keyless signing (via OIDC), or generate and manage your own keys.

While both Sigstore and TUF aim to improve the same software supply chain security issues, they address different layers of the trust and verification problem. For instance, TUF focuses on securing software update systems. It defines certain roles (such as root, targets, and snapshots) as well as providing a metadata-driven approach to protect against rollback attacks or mix-and-match attacks. TUF’s strength and differentiation is in its resilience, so even when some keys are compromised, it can still recover securely.

Whereas, Sigstore is designed specifically for artifact signing and transparency, especially within CI/CD-related contexts. Likewise, Sigstore offers a developer-friendly approach to cryptographic signing, as stated already, it leverages OIDC-identity (keyless) signing, open and auditable transparency logs through Rekor, and dedicated integration with Fulcio for certificate issuance.

Fundamentally, these two approaches have key distinctions in that Sigstore ties identities to signatures (like Github Identity), whereas TUF focuses only on robust update metadata and key delegation. If you’d like to learn more about how these two solutions differ, Bob Callaway and Dan Lorenc delivered a

 on the topic of why Sigstore was created.

Again, Cloudsmith already has native support for Sigstore's Cosign. When you enable “cosign signing" for your repository, every Docker image uploaded to a Cloudsmith repository is 

An ECDSA private key is generated when you create a repository.

Images are signed automatically on upload using this key.

You can download the matching public key to verify signatures.

Or you can use your own Cosign keypair and upload external signatures via the 

This means Cloudsmith customers already have a modern, secure signing solution in place without the need to scramble around for a replacement DCT.

Migrating from Docker Content Trust to Sigstore (Cosign)

 and TUF, which allowed for signature-based verification of container images. But with DCT now deprecated and official support ending, it's time to transition to modern, open tooling.

Here is how to migrate to Cosign with Cloudsmith:

 set in your environment, unset it. Continuing to use DCT after August 8, 2025, will cause failures when pulling Docker Official Images. Unsetting the below environment variable will avoid any unwanted pull failures:

To verify a signed image from Cloudsmith:

 feature flag tells Cosign not to query the Rekor transparency log, which is appropriate since Cloudsmith-hosted signatures are private by default.

In scenarios where you’re using a default Cloudsmith-managed keypair, you’ll need to download the associated ECDSA public key (making sure to replace 

 with your actual Cloudsmith workspace and repository names):

3. Sign images yourself (totally optional)

Prefer signing artifacts manually? You can generate and upload Cosign signatures directly:

Then upload both the image and signature to Cloudsmith. We’ll store and associate them automatically.

Cloudsmith does not log signatures to Rekor when signing on upload, because most customers use private repositories. As a result:

Cosign will warn if you attempt to verify without setting 

To avoid confusion, always include the flag when verifying Cloudsmith-hosted signatures:

f you want to use Rekor for transparency, you can opt into it by signing manually with Cosign and uploading both the signature and the image to Cloudsmith.

. By migrating from Docker Content Trust to Sigstore (via Cosign), you're adopting an open, scalable approach to supply chain security, while simultaneously staying compliant and adhering to industry best practices. And with Cloudsmith, this migration is already built in.

Nigel Douglas

Head of Developer Relations

Migrating from Docker Content Trust to Sigstore

In a recent PlatformEngineering.org virtual webinar, Nigel Douglas, Head of Developer Relations at Cloudsmith, led a deep dive into an increasingly critical topic: 

Identifying vulnerabilities in public Kubernetes Helm charts

With the growing popularity of tools like 

, many teams consume Helm charts without fully understanding the potential security risks they introduce. Over the course 

, Nigel explored practical techniques for analysing, scanning, and securing Helm charts - especially those sourced from public repositories. From using tools like 

 to implementing proper upgrade strategies and understanding runtime behaviour, the webinar provided a wealth of actionable insights for platform engineers, DevOps teams, and security-minded developers.

Although the live session covered a broad range of security concerns, several thoughtful questions from the audience remained. We've gathered them here (along with Nigel’s direct responses) to ensure you don’t miss any of the knowledge shared during this engaging and educational event.


What’s your take on maintaining and upgrading helm charts after we've installed them? How important it is, how often it should be done, how it should be done, etc.

Maintaining and upgrading Helm charts after installation is essential for keeping your Kubernetes workloads secure, stable, and compatible with the evolving ecosystem. Over time, charts can reference outdated container images or 

, which may expose your apps to vulnerabilities or operational issues. Saying that, regularly upgrading your charts can ensure that your apps benefit from upstream improvements such as bug fixes, performance enhancements, or improved and updated best practices as the projects evolve in maturity.

In general, upgrades should be considered every few weeks for critical applications, or at least quarterly for lower-risk workloads. Security patches, however, should be applied immediately when relevant. The upgrade process should involve reviewing chart release notes, performing a 

, as discussed in the webinar, and ideally using tools like the 

 plugin to understand exactly what will change. Automation can also help, using tools like Renovate or GitOps pipelines to track and apply updates. Ultimately, treating Helm charts as living infrastructure (not one-time installations) is the real key to ensuring long-term reliability and security.


Isn't the common factor of all these vulnerabilities a careless/knowledge of the result of a deployment?

We could say the same about quite a few security-related configurations. Many Helm-related vulnerabilities stem from a lack of awareness about the full implications of what a chart deploys - whether that’s in overly-permissive RBAC rules, exposed secrets, or insecure defaults. Helm makes deployment easy, but that convenience can lead to oversight if users don’t audit the rendered manifests or understand what the chart is configuring in the cluster. It’s why tools like helm template, helm diff, and scanners like Trivy are so valuable: they help surface risky configurations before they’re applied. Ultimately, secure Helm usage depends as much on the operator’s vigilance as it does on the chart’s design. As seen with the Microsoft research last month, this type of insecure configuration is rampant in the software supply chain since we consume charts that often don’t enforce these controls by default.


Could you please share recent Kubernetes vulnerabilities and top mitigation techniques?

To find recent Kubernetes-specific vulnerabilities, the best sources are the 

, and tools like Trivy or kubescape that maintain up-to-date vulnerability databases. Top mitigation techniques include enforcing least privilege access (via 

), enabling audit logging, restricting container capabilities, setting 

, and scanning workloads and Helm charts regularly. Incorporating security checks early in the CI/CD pipeline is also key to reducing risk before deployment.


Is there any website or page where we can find Kubernetes vulnerabilities?

Yes, the Kubernetes project provides an official, auto-refreshing CVE feed that publicly lists known Kubernetes vulnerabilities. Since 2022, this feed has been maintained to help users stay informed about security issues as they arise. You can access it here: 

https://kubernetes.io/blog/2022/09/12/k8s-cve-feed-alpha

. It's a valuable resource for tracking vulnerabilities in the Kubernetes ecosystem and planning timely mitigations.


How can we verify that this Helm chart is not vulnerable to attacks? What steps should we follow to perform this assessment?

After scanning your Helm chart with a trusted security tool like Trivy, it's important to address all vulnerabilities marked as 

. Once remediated, scan the chart again to confirm that those issues have been resolved. Rather than repeating this process manually each time, we recommend uploading your updated chart to a secure, centralized artifact management platform like 

. This enables you to maintain control over your chart’s integrity and trustworthiness by signing the chart and verifying its provenance. Relying on a centralized solution (rather than public repositories like 

) also gives you clear insight into the chart’s 

: a detailed record of its origin, changes, and associated contributors. This approach helps ensure that the charts you distribute and deploy are secure and free from known vulnerabilities.


How can you verify that the helm chart does not perform egress calls to sources that you don't want as an organisation? Is that through scanning or network policies on egress traffic?

To verify that a Helm chart doesn't allow or initiate egress calls to unwanted external sources, you should use a combination of static analysis and runtime controls. First, during pre-deployment, tools like Trivy can statically scan rendered Kubernetes manifests (

helm template ./mychart | trivy k8s --security-checks config -

) to detect misconfigurations - like containers without egress restrictions or unrestricted network policies. However, static scanning alone won't always catch dynamic behaviours (like runtime DNS lookups or hardcoded IPs).


Do you need to install Trivy on a cluster?

In our webinar, we used Trivy as a standalone scanner installed on an Ubuntu machine using snap install Trivy. While Trivy does offer a Kubernetes Operator for in-cluster scanning, you don't need to install it on a cluster to analyze Helm charts. For example, we scanned Kubernetes-specific misconfigurations (like Secrets exposed in plain text) by running 

, which renders the chart and scans the output. Alternatively, if you’ve already used helm template to export the chart into a single YAML file, you can scan it directly with 

trivy config --severity HIGH,CRITICAL my-sample-chart.yaml

 to focus on high and critical severity issues. This approach makes it easy to evaluate chart configurations without needing to deploy them.

To enforce egress control at runtime, it's best to implement Kubernetes Network Policies, ideally with a 

. These policies can restrict which destinations pods are allowed to contact, based on CIDRs, namespaces, or label selectors. Defining strict egress policies ensures that, even if a chart includes or results in outbound traffic, that traffic is only permitted to destinations your organisation allows. This dual-layered approach (scanning and runtime restriction) is the most reliable way to prevent unintended or insecure egress behaviour.


 to scan Helm charts for known vulnerabilities and insecure configurations, but there are several other tools that complement this process. 

 analyses Kubernetes YAML (including rendered Helm templates) for security risks. 

 focuses on validating Helm charts against Kubernetes best practices - checking for things like missing resource limits, privileged containers, HostPath usage, and other misconfigurations. For future-proofing, 

 identifies deprecated or removed Kubernetes APIs within your charts, which helps avoid issues during cluster upgrades. Finally, while not a security tool, 

 ensures your chart is syntactically valid - important for catching simple issues before they affect your deployments. Together, these tools offer a comprehensive approach to Helm chart assessment.


Are there any auditing tools yet that run a helm chart and show all of the open ports on the container vs. just what is mapped in the helm chart? Or is that pretty exclusive to Kubernetes network security programs?

This is a great question! Currently, auditing open ports at runtime (beyond what's declared in the Helm chart) is generally outside the scope of Helm-specific tools. Helm templates only define what's supposed to be exposed (e.g. via containerPort, hostPort, or Service definitions), but they can't catch what a container actually opens internally at runtime.

To identify all open ports inside a container, including those not exposed via Kubernetes objects, you’d typically use Kubernetes runtime security tools or network observability solutions, such as:

: Provides deep network visibility and can monitor actual traffic flow, including unexpected egress/ingress.

: Can also audit real network traffic at the pod level.

): Can detect unexpected network behaviour like a container listening on unusual ports.

: While more focused on security posture and cluster vulnerabilities, these tools from the team at Aqua Security can help detect misconfigurations that lead to unintended exposure.

, a combined approach works best. You can use helm template or helm show values to audit the declared ports before deploying the chart in a sandbox cluster. Running tools like 

 inside the container (or from another pod) to observe real ports in use. It's your responsibility then to monitor the traffic using a CNI-based tool like Cilium or Calico for the real-time egress/ingress behaviour. In short: yes, it’s more in the domain of Kubernetes network security tools than Helm itself, but combining both layers provides the most insight.


Is it good practice to deploy the API management server to safeguard the Kubernetes pods?

Yes! Deploying an API management server can be a strong security and governance practice in Kubernetes, especially when your workloads expose APIs. Tools like 

 add layers of protection by enforcing authentication, rate limiting, and monitoring before traffic reaches your pods. They’re particularly valuable for public or partner-facing services where access control and visibility are critical. However, API gateways should complement (and not replace) the core Kubernetes security controls like network policies, pod security settings, and runtime protection. Used together, they form a more comprehensive and effective security strategy.



The event was a great learning experience. What is the 'End Goal' of this event? How long would you continue to have such informative sessions?

At Cloudsmith, we regularly host webinars focused on securing the software supply chain, which you can explore at 

 for upcoming community-driven events - both virtual and in-person.

The end goal of these sessions is to raise awareness around the importance of securing software packages throughout their lifecycle. That means not just scanning once, but maintaining ongoing vigilance through regular scanning, updates, and visibility into provenance. We know this can feel overwhelming, so our aim is to provide practical education, actionable best practices, and tooling insights to help you build safer pipelines with confidence. As long as security remains a moving target (and it always will), we’ll continue running these sessions to support the community.


Nearly everything deployed today in Kubernetes is through Helm Chart templates. If you need to deploy a security program into your cluster, most likely the security vendor you’re working with has a Helm Chart for that. So there’s an especially critical need to monitor and secure those third-party Helm charts that we consume as well. The questions raised during this session bring to light a common theme: many vulnerabilities don’t originate in Kubernetes itself, but in the way it's configured and operated. By applying security best practices, leveraging scanning and enforcement tools like Trivy and OPA, and maintaining a strong awareness of chart provenance and runtime behaviour, platform teams can seriously reduce risk.

Cloudsmith and PlatformEngineering.org remain committed to supporting the community with ongoing sessions like this, and by bringing clarity to the challenges of modern software supply chain security. Sign up today for our upcoming 

, stay tuned for future events, and feel free to contact us anytime with questions about keeping your software artifacts secure.

Responding to questions from our recent Helm security webinar

Welcome to our 2nd blog in our series on how to securely consume Open Source Software (OSS).

Attacks targeting OSS are on the rise, making the security of your software supply chain a top priority. The 1st blog gave an 

overview of some of the most common types of attacks

Secure Supply Chain Consumption Framework (S2C2F)

 that can help you mitigate against these attacks.

In 2019, Microsoft launched an internal initiative to secure its own development practices around the consumption and management of OSS. They donated the resulting framework, originally called the Open Source Software-Secure Supply Chain (OSS-SSC) framework, in 2022 to the Open Source Security Foundation (OpenSSF). Renamed S2C2F, the framework now has 

S2C2F consists of eight core principles and four maturity levels, providing a comprehensive strategy for organizations to incrementally improve their security posture when consuming OSS.

The framework is not revolutionary: it's a practical guide to knowing what OSS you are using, preventing the consumption of vulnerable packages, and efficient patch management.

By using Cloudsmith, you can get a big head start on implementing S2C2F principles, and improving your team’s S2C2F maturity level. Specifically, you can use Cloudsmith to -

Ensure comprehensive package and container scanning

Create rules for vulnerability mitigation

Automate workflows for a wide variety of package formats, CI/CD integrations, CLI, APIs, and webhooks

In this article, we will explore the fundamental principles and ascending maturity levels of the Framework, providing examples of real-world threats it can effectively counter. Additionally, we will illustrate how Cloudsmith assists in implementing these principles, helping you achieve your desired level of maturity.

The framework consists of the following 8 principles. By implementing practices for each, you can create a robust and secure supply chain:

Consume your OSS from 1 location controlled by your organization, like Cloudsmith.

Create a list of all your OSS dependencies.

Update known vulnerabilities in a timely manner.

Force developers to adopt secure practices.

Audit that developers are consuming through the approved ingest method, Validate the integrity of the OSS that you are consuming.

Scan for malware and vulnerabilities using automation where possible.

Have the ability to fork and fix code when necessary for a temporary fix.

The Framework applies these 8 principles across 4 maturity levels to enhance open-source security. Levels 1 and 2 provide the basics for a solid OSS governance program. Levels 3 and 4 get into proactive measures and more sophisticated types of controls.

Let’s have a look at the 4 maturity levels in more detail.

How you ingest your OSS is the most important thing to focus on when getting started with implementing this framework, says Adrian Diglio, Principal PM Manager of Secure Software Supply Chain (S3C), Microsoft at his RSA 2023 talk 

Introducing the Secure Supply Chain Consumption Framework

S2C2F strongly advocates the adoption of an artifact repository like Cloudsmith as a central location for all OSS packages. It's a single point to initiate policy enforcement, conduct scans, and implement stringent security controls for your OSS.

This approach guarantees the availability of OSS package dependencies and acts as a safeguard against potential upstream disruptions like the infamous NPM 

, where a package Maintainer withdrew a popular package from its public repository.

Inventory OSS, hopefully in a standard format like Software Bill Of Materials (SBOM)

Level 2: Secure Consumption and Improved MTTR

Level 2 requires organizations to focus on identifying known vulnerabilities in the OSS they use. This includes using Software Composition Analysis (SCA) tools to scan and detect security issues and automatically update OSS.

Audit that consumption is through the approved ingestion method

Level 3: Malware Defense and Zero Day Detection

In Level 3, the emphasis turns to mirroring external OSS internally. This safeguards organizations with local, controlled package copies, reducing vulnerabilities like the previously mentioned left-pad incident. It also encourages proactive security, including fuzzing, static analysis, and other methods to uncover potential code vulnerabilities.

Proactive security reviews for yet to be discovered vulnerabilities

Verifying the provenance of all open source components to make the binaries match the purported source code

This level is considered aspirational in most cases as it is difficult to implement at scale. It involves rebuilding OSS on Trusted Infrastructure. Also in extreme cases, when a critical vulnerability is discovered, organizations may implement private fixes as a temporary risk reduction measure. This would involve forking the code, implementing the fix and then releasing this version on a temporary basis with the intent of pushing this fix to the main branch as soon as possible.

Cloudsmith is your trusted ally, propelling your S2C2F implementation. Our platform is equipped with a suite of features that align seamlessly with S2C2F principles:

 Cloudsmith isolates and protects your software supply chain from public upstream sources like Maven Central by proxying or caching your OSS artifacts. This protects you from outages or left-pad incidents where an OSS package is removed unexpectedly from an upstream.

Discover and track your dependencies, even their dependencies, using Cloudsmith. Store and validate SBOMs with ease.

Benefit from our powerful integrations with CI/CD tools and APIs, enabling effortless automatic updates.

Cloudsmith automatically scans all packages for malware upon upload and provides vulnerability scanning for CVEs. Our APIs and webhooks facilitate seamless CICD integrations, empowering you to harness security tools beyond Cloudsmith.

Take command with Cloudsmith's policy management features. Centralize rules for software artifacts, manage licenses, vulnerabilities, quarantining and our soon to be released deny lists feature. Easily set your repository to only accept immutable artifacts, semantic versioning or a certain vulnerability level.

 Find out where your packages came from with Cloudsmith. Sign, verify, and trust your OSS sources using metadata, sigstore, checksums, and dependency insights. Streamline package discovery, ensure license compliance, and enhance provenance.

Cloudsmith's support for signing and SBOMs help you verify the provenance of your build.

Host, tag and sign your packages for temporary builds that fix vulnerabilities.

Cloudsmith, coupled with tooling for updating dependencies, getting information about maintainers, and creating SBOMs, can get you to your desired S2C2F level.

 SIG, provides illustrative instances of real-world attacks that the S2C2F framework could have effectively countered.

The S2C2F is a pragmatic approach to securing how you consume OSS. It emphasizes the fundamental principles of knowing your OSS, preventing the introduction of vulnerable packages, and maintaining robust patch management. We at Cloudsmith are big believers in S2C2F!

Keep an eye out for our next blog, where we'll give you actionable steps to implement S2C2F with the help of Cloudsmith.

If you want to discover more about how Cloudsmith can help you secure your supply chain, sign up for a 

Ciara Carey

Solutions Engineer

Mastering Open Source Security: Your Guide to S2C2F

Open-source software (OSS) fuels innovation. Over 96% of commercial applications rely on at least one OSS component (Synopsys, 2023).

At Cloudsmith, we champion OSS and understand its indispensable role in today's software landscape. However, the escalating threat of supply chain attacks targeting OSS demands a robust defence.

Step into our blog series on how to securely consume OSS. Over the next 3 articles, we'll guide you through

OpenSSF's Secure Supply Chain Consumption Framework (S2C2F) which outlines and defines how to securely consume OSS dependencies into the developer’s workflow.

Today, I'll give an overview of some of the most common types of attacks from consuming OSS. These attacks can lead to broken builds, security breaches, unauthorized access, and data leaks.

Attackers are increasingly focusing on OSS, exploiting vulnerabilities to get malicious code into production systems. To achieve this, malicious actors employ three main avenues of attack when it comes to your OSS consumption:

 Publishing bad packages to public indexes like PyPI, npm, or Maven Central.

accounts can be hijacked, projects abandoned, deleted or maintainers can introduce malicious code themselves.

: Risks linked to vulnerabilities in your OSS dependencies, such as Log4Shell, Heartbleed and the recent high-severity vulnerability found in curl.

Languages with community-based package management, like npm for Javascript and PyPI for Python, make publishing and consuming packages easy. One downside to that is that hackers can publish malicious packages to these repositories to trick developers into installing the wrong package.

 found 7,300 malicious OSS packages were discovered across all major package manager registries in 2022 alone.

Let’s have a look at these types of attacks.

Typosquatting is when bad actors upload compromised packages with names similar to popular, existing packages. If a developer makes a typo when including a package name, the malicious but similarly named package is then downloaded and installed instead. This type of attack is tough to detect and can lead to malware execution.

An example of a typosquatting campaign unfolded in early 2023 when thousands of 

malicious Python packages were discovered

 on the public Python Package Index (PyPI). Similar campaigns have been observed in other popular package ecosystems, including:

: The npm platform witnessed a typosquatting campaign leveraging open-source tools, emphasizing the widespread nature of this threat.

: The distribution of SeroXen RAT via a malicious NuGet package raised alarms within the NuGet and Powershell communities.

: Evidence of a malware attack on Rust developers via typosquatting was identified on crates.io.

: Malicious typosquatting malware was uncovered within the Composer repository, underscoring the vulnerability of various ecosystems to such subversive tactics.

: A notable incident involving the exploitation of Kubernetes RBAC via a typosquatting attack on Docker served as a reminder of the far-reaching consequences of this practice.

The prevalence of typosquatting across multiple OSS ecosystems underscores the need for heightened awareness and vigilant measures within the developer and repository communities to effectively detect and mitigate this elusive threat.

Security researcher Alex Birsan found he was able to get “malicious” code (actually just an innocuous test) into software built by more than 35 major companies (He had advance permission from each company to try.) These companies all 

were vulnerable to the injection of malicious packages via public sources

 into their software supply chains. His test demonstrated that the 

 can occur when attackers find out or guess package names in your organization's private repository and pull in the public package instead of the package hosted on the private repository.

. PyTorch had a dependency on a library called torchtriton that was hosted on PyTorch’s private repository. The attacker decided to register a malicous package on the public PyPI repository with the torchtriton name. When a build was triggered pip looked at the public PyPI first and pulled in the malicious package.

What would happen if a bad actor managed to hijack a Maintainer account? Or how about a malicious maintainer intentionally introducing bugs? Yes, sadly, both of those scenarios have happened.

These maintainer-based threats are more likely to happen in projects that have very few maintainers, which is actually the case for many packages in public repositories like npm and PyPI. Let’s look at a few examples.

In 2021, crypto-mining, password-stealing 

 named ua-parser-js. "I believe someone was hijacking my npm account and published some compromised packages (0.7.29, 0.8.0, 1.0.0) which will probably install malware," said Faisal Salman, author of the UAParser.js library. He turned out to be right.

Another npm package, ESLint, had a similar attack in 2018. The attacker gained unauthorized access to the library and inserted code that could have potentially allowed for further malicious activities. These incidents highlighted the need for switching on 2FA for maintainers of popular packages.

A variation on this attack occurred in 2018 with a popular JavaScript library for Node.js called EventStream. The package was 

 that enabled digital attackers to empty Bitcoin wallets. This attack happened when a malicious party used social engineering to be added as a maintainer. The attacker then added a dependency containing malicious code called flatmap-stream. Everyone who used event-stream with the malicious dependency became a potential target.

Although very rare, it is not unheard of for legitimate maintainers to intentionally introduce bugs or delete code in an update for political or other reasons.

 by its maintainer, Brandon Novaki Miller, to protest the ongoing war in Ukraine. He released an update to npm and GitHub that sent peace messages to all users and deleted files belonging to users based in Russia and Belarus.

 were corrupted by their Maintainer, Mark Squires. He intentionally introduced an infinite loop that broke thousands of projects that depend on colors and faker to protest Fortune 500 companies using OSS for free, as well as to highlight his political interests. Mark was locked out of his GitHub accounts, but eventually, he took down his popular faker package altogether.

Cloudsmith Blog

Migrating from Docker Content Trust to Sigstore

Responding to questions from our recent Helm security webinar

Mastering Open Source Security: Your Guide to S2C2F

The Dangers Lurking in Open Source Software