The Zero Trust security model has emerged as a critical strategy for protecting organizational assets. Zero Trust is based on the principle of maintaining strict access controls and not trusting anyone by default, regardless of whether they are inside or outside the network perimeter.

Many organizations moving from an on-premises solution to the cloud have previously relied on the network perimeter to control access so that anyone inside the network can push or pull artifacts. Moving to the cloud provides an opportunity to strengthen your security posture and thoughtfully design appropriate controls.

 principles to provide robust protection for software supply chains. Here's how Cloudsmith helps organizations like yours implement Zero Trust security, in five simple steps:

Step 1: Provisioning Developers With Zero Trust Access
Step 2: Securing Build Pipelines With Trusted Publishing
Step 3: Continuous Monitoring and Validation
Step 4: Managing Access to 3rd Parties
Step 5: Vulnerabilities in Software Packages

Step 1: Provisioning Developers With Zero Trust Access

Imagine you need to provision thousands of developers with Cloudsmith accounts. Using traditional security models, each developer might automatically gain broad access to your software repositories, potentially leading to security risks. Cloudsmith’s Zero Trust approach, however, ensures that no developer has access by default until explicitly granted.

SCIM to automatically provision and deprovision

 Cloudsmith user accounts based on their status in your Identity Provider (IdP). This ensures that only active developers have access.

 so users can use their existing SSO provider to manage and control access to their Cloudsmith organization account.

 to integrate with your IdP to map groups to Cloudsmith teams. This automates the assignment of developers to specific teams with predefined permissions.

: Control the default privileges at both 

 levels. Developers can be granted read-only access to ensure they cannot move or upload artifacts until explicitly permitted.

: Developers only have access to the resources they need, reducing the risk of unauthorized access and potential breaches.

: Streamlined management of user permissions through IdP integration ensures that access remains up-to-date and secure.

Step 2: Securing Build Pipelines With Trusted Publishing

Securing build pipelines with Trusted Publishing involves using OIDC to authenticate into CI/CD pipelines to ensure that only trusted systems can publish packages.

(API keys not tied to specific users) which is ideal for automated processes requiring write access to repositories.

 to request ephemeral access tokens for Cloudsmith. These tokens inherit the privileges of the linked service account, preventing the exposure of long-lived service account tokens. This is referred to as "Trusted Publishing," where OIDC protects against the issues of having long-lived credentials stored in external tools.

 to set a maximum age policy for your API keys and automatically rotate them at defined intervals. This ensures that any keys older than the set threshold are refreshed. This policy helps prevent misuse of stale or potentially compromised keys, maintaining secure access to your pipelines.

: Ephemeral tokens and strict API key policies reduce the risk of token misuse and unauthorized access.

Automatic API key rotation reduces the administrative burden and helps you comply with stringent security standards, ensuring that security practices align with Zero Trust principles.

 Integrating OIDC and robust API key policies in your CI/CD pipelines protects against the risks of token exfiltration and abuse, making your software delivery process secure and trustworthy.

Step 3: Continuous Monitoring and Validation

Continuous monitoring and validation are core to the Zero Trust model. They ensure that all user activities and sessions are constantly verified for security compliance.

 capture detailed information about who is accessing your packages and from where.

 provide a comprehensive record of all changes made within the Cloudsmith platform.

: SAML session times are defined by the IdP, ensuring that session durations comply with your organization's security policies. Regularly expiring sessions and requiring re-authentication allow you to maintain ongoing session integrity and security.

: Detect and investigate unusual patterns or unauthorized access attempts promptly.

: Regular re-authentication ensures that active sessions remain secure and compliant with your organization's security policies.

It's essential to provide access to third parties without compromising security—like customers who need access to your packages. Cloudsmith’s entitlement tokens offer a solution for fine-grained access management.

 grant read-only access to repository contents, allowing you to control and track your customers' downloads.

, Cloudsmith’s entitlement tokens give you precise control over who can download your software, track usage, and manage licenses.

 Each customer or user can receive a unique entitlement token that grants access to specific packages or files. This setup allows for granular control and tracking of downloads.

Tokens can be revoked if needed, such as when a subscription lapses, ensuring that access is always up-to-date and secure.

Step 5: Vulnerabilities in Software Packages

 to uphold Zero Trust principles on your software packages so that only verified and validated packages are deployed to production.

 Automated scans are conducted when packages are published to detect vulnerabilities and malware in packages before they are deployed.

 Signing every package means that it can be verified by checking signatures and ensuring they originate from trusted sources.

 Continued use of OIDC ensures that only authorized and authenticated entities can publish or access packages.

Packages are automatically scanned and validated against security policies, helping prevent vulnerabilities from reaching production environments.

Adopting a Zero Trust approach is crucial for enhancing security, whether transitioning from traditional on-premises infrastructures or expanding existing cloud-based solutions.

Our comprehensive implementation of Zero Trust principles—through robust authentication and authorization, continuous monitoring, trusted publishing, fine-grained access control, and proactive policy enforcement—provides a powerful framework for securing your software supply chain.

By partnering with Cloudsmith, you benefit from a platform that continuously adapts to the latest security threats and compliance requirements, ensuring that your artifact management is both secure and scalable. 

 to experience firsthand how Cloudsmith can enhance your organization's security posture.

Implementing Zero Trust Security With Cloudsmith in 5 Steps

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.

Another incident of this type occurred in 2016 on npm when 

 removed over 250 of his modules from npm after a disagreement. One of those dependencies was a popular package called left-pad. Laurie Voss, CTO and co-founder of npm, took the unprecedented step of restoring the unpublished left-pad 0.0.3 package.

. The original maintainer may move on or lose interest, and nobody else steps in. These abandoned projects pose a security risk as vulnerabilities go unpatched.

Vulnerabilities in OSS represent an enduring and significant threat. Known vulnerabilities are publicly disclosed weaknesses cataloged in databases like the 

, and are susceptible to exploitation by attackers.

These vulnerabilities can range in severity, with critical ones often enabling Remote Code Execution (RCE) that grants unauthorized control over systems.

At first glance, it might seem easy- if you have an OSS dependency with a known vulnerability in your software, just update it to make the issue go away. But in reality, this can be tricky because:

There's no consistency with how developers are bringing in OSS which leads to security tool blind spots.

You might not be aware that you're using a vulnerable package, particularly when that package is a dependency of another package— commonly known as a transient dependency.

The vulnerable package is a dependency in legacy software that isn’t receiving updates.

The dependency is abandoned OSS. In such cases, nobody is around to fix those vulnerabilities and/or update vulnerable dependencies.

In a nutshell, fixing vulnerabilities in your software isn't always as simple as it sounds, especially when you bring in OSS in different ways, they're buried deep in your software, tied to older programs, or linked to abandoned parts that nobody's looking after.

Let’s take a closer look at the infamous vulnerability Log4Shell to illustrate the threat of vulnerabilities in the OSS you consume.

 was discovered within the widely-used OSS logging tool Log4J, leaving its users and their organizations susceptible to remote code execution attacks.

Log4Shell had an extraordinarily broad and damaging impact:

It had a huge attack surface, including Cloudflare, iCloud, Minecraft servers, Steam, Tencent QQ, and millions more.

 (CVSS) score of 10 (the highest, or worst, possible score) - a successful exploit left organizations wide open to remote code execution attacks.

It was hard to detect because it was typically pulled in as a dependency of a dependency.

customers who had completely mitigated Log4Shell from their environments saw it reenter their systems

 through a continuous integration (CI) process or the installation of a vulnerable third-party application.

Secure Supply Chain Consumption Framework

Attacks targeting OSS are on the rise because they work, and because so many software organizations aren’t taking adequate precautions.

OpenSSF, the Open Source Security Foundation

, unites OSS maintainers, industry leaders, governments, OSS consumers, and more to enhance OSS security for all.

Secure Supply Chain Consumption Framework (S2C2F)

 provides essential guidelines and best practices to bolster security when consuming OSS.

In our next blog, in our series on how to securely consume OSS, we'll delve into the S2C2 Framework, exploring how it can significantly mitigate the risk of OSS attacks.

Cloudsmith blog

Implementing Zero Trust Security With Cloudsmith in 5 Steps

The Dangers Lurking in Open Source Software