By submitting this form, you agree to our 

Getting Started with Go and Cloudsmith

A short demo of how to get started with Go modules and Cloudsmith, including pushing a Go module to a private Cloudsmith repository and then pulling the module as a dependency in a Go project.

Dan McKinney

Solutions Engineer

Docker Security Scanning

A walkthrough of Docker Security Scanning with Cloudsmith.

Get Started with Cloudsmith's Docker Security Scanning

 is an awesome tool, created by Hashicorp, with a vibrant community of open source modules for multiple cloud providers. It’s not hard to understand why it’s a favourite amongst developers; especially when it's often faster at supporting new features than some of the cloud providers!

Terraform enables its users to manage components in their architecture, ranging from the configuration of the services used in their chosen cloud provider (such as 

Amazon Web Services, Google Cloud Platform, or Microsoft Azure

), to software run on those services (like 

). Terraform even supports configuring some SaaS services you may interact with (for example, 

Using Terraform to define your desired configuration means that not only will you offload the work of creating the components you need, but also make the creation of these instances reproducible, allowing you to create, update and destroy components of your architecture as needed, all with one command (and a review of the changes before executing them!).


To make modules created by the Terraform providers available to all Terraform users, Hashicorp runs the 

 which allows users to upload modules, making them publicly available to all Terraform users.

Cloudsmith's private module registry fully supports the 

, allowing users to access both private modules available via Cloudsmith and public modules via the public registry.

Cloudsmith's private module registry also enables developers to:

Share custom modules for managing infrastructure among their team

Utilize private modules in your organization without the overhead of managing their storage

Distribute private modules as a commercial offering

Make modifications to public packages while having control of how you publish them (publicly accessible, private to your organization or open-source)

Capture the exact state of modules you depend on at a particular version

Control (allow list/deny list) at an organization, repository, and module level

Getting started with Cloudsmith and Terraform only takes a few steps. First, you need to create a Cloudsmith account and a repository to which you can upload your modules (a terraform provider for doing just this coming soon!).

If you need to install Terraform, you can find a getting started guide on the 

.

Cloudsmith's private module registry should work with all supported versions of Terraform, however, we recommend using version 

. You can check the version you have installed by running:

For this example, we'll create a module which prints out "Hello, world!".

First, we need to create the directory which will contain the module:

 file, this is the entry point for your module and will contain the code required to generate our message. To generate this message we must add the following to the 

Now that we have the code necessary for our module, we need to package and upload it to Cloudsmith. To achieve that we need to make use of the *nix tool 

To ensure we don't upload some unnecessary files, we exclude your terraform state file(s) along with 

 which can contain authentication credentials.

The name of the terraform module is critical here, as the 

terraform registry API requires this specific format

, along with several other requirements that you should review when creating modules.

To upload the module to Cloudsmith, you can use either the application's UI, or the Cloudsmith CLI. For this example, we'll be using the CLI, which has steps for installation available 

With the CLI installed and configured to authenticate successfully with Cloudsmith, we can upload our module by running:

Once uploaded, you can view your module in Cloudsmith.

Cloudsmith provides fully featured Terraform module repositories on all plans, flexible enough for use whether you’re hosting public packages for a public or open-source project, or private packages for your company’s internal needs. We're extremely proud to be able to support the Terraform ecosystem with this tooling.

You can find further, context-specific information, including detailed setup and integration instructions inside each Cloudsmith repository.

Lee Skillen

Chief Technology Officer

Announcing Private Terraform Registry Support in Cloudsmith

The movement away from on-premise and towards the Cloud is unstoppable. Even the 

 government is on board with their plans to “accelerate movement to secure cloud services, including Software as a Service (SaaS), Infrastructure as a Service (IaaS), and Platform as a Service (PaaS).”

There's many types of infrastructure to consider when selecting software. We aim to uncover the true difference of the key two, being on-premise software and cloud-native software below.

Cloud-native software and technologies are an approach to architecting, building, and managing workloads built in the cloud. This means that cloud-native software has the Cloud inherently built into its DNA, taking full advantage of all the technology that Cloud provider platforms offer. This results in the ability to scale for global performance.

On-premises (or on-prem) software uses IT infrastructure hardware and software applications that are hosted on-site, and relies on constant maintenance and upkeep from dedicated resources. On-prem is quickly becoming the legacy approach in artifct, as organizations are realizing the power of the Cloud.

What exactly is the difference between on-premise and cloud-native?

On-premise (on-prem) software is deployed, hosted, and maintained by your organization. While you can host your on-prem software in the cloud to remove some infrastructure and maintenance costs, you really need cloud-native software to take full advantage of the Cloud.

Cloud-native software is designed, developed, and deployed to take advantage of modern cloud computing, using techniques like micro-services, modularity, containerization, continuous integration, and continuous deployment.

When you access your software over the cloud, that usually means using the SaaS licensing and delivery model. You access your software over a browser or via an API, and you pay for what you use, like a utility bill.

Cloud-native software using SaaS licensing empowers you to focus on growing your business while only paying for the services you use.

Advantages of Cloud-Native Software over On-Premise Software

Many new companies today are choosing to offload the overhead of maintaining the tools and infrastructure they rely on to cloud-native services. The use of on-prem software is mainly due to legacy or regulatory reasons.

For example, the innovation coming out of Cloud-first FinTech companies compared to the risk-averse old-school banking industry shows what you can do when unshackled from your on-prem mindset. Now you see older banks like 

 accelerating their use of the cloud to remain competitive.

There are many advantages of cloud-native over on-premise software:

Cloud software is hosted for you. You don’t have to worry about maintaining your “on-prem” software or infrastructure- No updates, no security patches, no replacing obsolete hardware. Cloud-native technologies allow businesses to reduce the total cost of ownership for businesses, especially when you factor in the staff costs of maintaining “on-prem,” never mind just the licensing fees.

Scalability is another area where the cloud excels. Cloud-native software can quickly re-adjust its resources to meet demand. A company experiencing rapid growth can use the cloud to expand its infrastructure and computing power. In contrast, the same company using on-prem infrastructure would have to quickly invest in more hardware, software, and Engineers to keep up with rapid growth. On-prem software cannot compete with Cloud-native software in terms of scalability and flexibility.

“On-prem” software solutions tend to be faster the closer you are to the infrastructure. It’s no longer acceptable for everyone near the company headquarters to have a responsive low latency experience, while other geographically distributed teams have to put up with significant replication lag. This lag stifles collaboration and productivity.

Cloud software can use techniques like content delivery networks (CDN) and edge caching to provide better performance for distributed teams without requiring you to implement complex global replication or maintain globally distributed infrastructure.

A secure system needs a secure building, training, constant security updates, high availability, monitoring, and disaster recovery infrastructure. Although many companies that host their software on-prem take security very seriously, it is expensive and consumes many working hours.

Cloud providers are driven to focus on security as their business and reputation depend on providing a robust and secure service. As a result, cloud providers use highly sophisticated security tools and resources beyond the reach of most in-house teams.

 projects that from 2019 to 2029, there will be a 22% increase in the number of jobs available to Software Developers. It’s already hard to find Software Engineers, and the best ones want to work with the latest technologies. We need to embrace tooling that takes advantage of the automation and scalability of cloud-native technologies- freeing up your engineering and server resources to build your products.

When moving from “on-prem,” it’s crucial to select cloud-native tools, like 

Some vendors offer their on-prem software on Cloud platforms. However, these legacy offerings were not designed to run on a Cloud platform or architected to take advantage of the paradigm shift that cloud computing enables. You are left with effectively paying on the double for the same on-prem software, just running in a virtual machine in the Cloud. These Frankenstein hybrid software solutions inherit the same scale and distribution problems as their on-prem alternatives.

Cloud-native software works in tandem with Cloud Infrastructure- secure, fully distributed workloads, fault tolerance, and thanks to containers, it can move from cloud to cloud with ease and scale in or out rapidly.

Cloudsmith- your very own Cloud-Native packaging tool

Package management is an example of a tool that would benefit from being Cloud Native. Package management tools develop, deploy and distribute software packages.

Cloudsmith is a Cloud-native package management tool that makes life simpler for your engineers. Don’t worry about infrastructure, patching, upgrades, replications, or scaling. Our cloud-native architecture enabled us to develop a smart CDN for software packages- or our Package Delivery Network (PDN). The PDN is optimized to ensure lightning-fast delivery for deploying or shipping licensed software to your customers.

We believe that the elasticity, flexibility, security, and scalability of the Cloud allow us to support infrastructure and service beyond the capability of traditionally provided “on-prem” tools.

Shift to the cloud away from on-prem software by choosing Cloud-native software to empower innovation, stay secure, reduce costs, and scale as your business needs change.

Ciara Carey

Go Cloud-Native or Go Home

In early 2020, threat actors breached the build systems of SolarWinds and used this access to add malicious code into one of SolarWinds products. The product, called “Orion”, is very widely used and deployed by tens of thousands of companies, including many Fortune 500 companies.

Then, from around March 2020, when SolarWinds’ customers updated their installations of Orion, the malicious code embedded gave the threat actors a backdoor which they could then use to install additional malware, spy on, and exfiltrate data.

By now, this is a very well-known, maybe even the most famous, example of a software supply chain attack.

In short – a lot! Unfortunately, the SolarWinds’ incident was not the last time a software supply chain was breached. Software supply chain attacks have been continuing and could be accelerating.

In February, it was discovered by security researchers that many public package repositories and registries could be used to implement a 

, which allowed the insertion of malicious code or packages into several major companies’ build and development processes, including Apple and Tesla.

threat actors had breached a very commonly used development tool, CodeCov

. And just a few days ago, it was revealed that the primary public registry for Winget, Microsoft’s new Windows 10 package manager, was being filled with 

corrupt, duplicate, or possibly malicious

Despite the amount of news that these incidents have generated recently, unfortunately, software supply chain attacks are not new.

 development environment was distributed, which, when used to develop software for iOS, inserted malicious code into dozens of iPhone apps. And in 2019, the same thing happened to Microsoft’s Visual Studio, which resulted in 

In 2017, another software supply chain breach launched the 

. The software updates for a Ukrainian accounting product were compromised and caused an estimated $10 billion of damages.

And also, in 2018, a group of threat actors compromised software updates from the manufacturer ASUS and the computer cleanup tool CCleaner. These particular attacks are believed to be 

 successful supply chain attacks perpetrated by this group.

Overall, these attacks have affected thousands, if not hundreds of thousands, of users and systems. And often, the difficult part is determining exactly how large the blast radius is.

There are a few reasons why we see an increase in software supply chain attacks, so let’s just touch on a couple of the most important ones.

The first reason is that software security is not new. For years now, we have been conditioning users to “not click links in unsolicited emails”, “Check that the site you are using is genuine and secure”, “protect username/password/credentials”, etc. As users, we have started to implement better opsec; we are more aware of threats and how to combat them.

So, as a result, the threat actors have had to move up the chain. Rather than target individual users and systems, they target the very processes by which users obtain their software. After all, who wouldn’t trust a software update that has been delivered from a software vendor's distribution platform and signed by the said vendor? Everything we have been conditioned to question and check passes in this case.

The second reason is that the blast radius is potentially so much greater. Rather than targeting thousands of users or systems and compromising just a few, an attack like that on Solarwinds results in a single compromise expanding to many thousands of compromised systems and networks.

The threat actors can leverage the distribution networks of a software vendor to do the dirty work for them. To let thousands of Trojan horses out into the wild and run wild. The payoff is just so much greater for a successful supply chain attack, that it represents a significantly larger return on investment to an attacker.

At Cloudsmith, we believe that the solution comes in the form of Continuous Packaging.

Continuous Packaging is a development methodology that offers the observability and control to ensure that software is always verified, packaged, and ready to deliver.

We have talked about this before, and you can watch our talks on continuous packaging on 

. We think that continuous packaging is the missing link between continuous integration and continuous deployment – The cornerstones of a modern DevOps software development process.

It really comes down to using new best-in-class tools to help you have visibility and management over all packages and code used in your environments—providing trust, isolation, and performance.

· Minimise trust. Scan at source, during build and at packaging.

· Implement and own a single source of truth for packages.

· Be a curator of software packages, not just a consumer.

· Draw a thread from build to deployment.

We will dig a bit deeper into continuous packaging in an upcoming blog, so check back soon and watch this space.

 have recently announced efforts to improve the security of software supply chains. These efforts should result in guidelines for best practices and minimum standards that vendors should meet.

At its core, this is what Cloudsmith does. Cloudsmith provides a single source of truth for all packages and containers you consume as part of your development process. It enables you to isolate yourself from public upstream package sources and take back control over your software supply chain.

It’s time for a change. It’s time for an overhaul of how we securely develop software, and it’s time to get ready.

SolarWinds and the Secure Software Supply Chain

Getting Started with Unity and Cloudsmith

A short demo of how to get started with Unity packages and Cloudsmith, including pushing a package to a private Cloudsmith repository and then adding a package to a Unity project.

It’s official: regulations by the US and UK governments are coming down the track to secure the software supply chain.


Earlier this month, President Biden signed an 

 (EO) to increase cybersecurity defences across the U.S, with an emphasis on enhancing the security of the software supply chain. Now, the 

 is following suit, having announced their own call for advice on defending against software supply-chain attacks. The supply chain attacks at SolarWinds and 

 have shaken governments. The EO targets the software industry when it says, “Too much of our software, including critical software, is shipped with significant vulnerabilities that our adversaries exploit.” The US wants to know what is in the software they rely on and how securely it is built.

How could this affect your DevOps and Software Engineering teams?


Within 60 days of the EO, the US government will publish the following:

Minimum elements for a Software Bill of Materials (SBOM).

Guidelines recommending minimum standards for vendors’ testing of their software source code, including identifying recommended types of manual or automated testing (such as code review tools, static and dynamic analysis, software composition tools, and penetration testing).


The SBOM is a critical element of the EO, essentially a record of all of the components and dependencies used in building software. Most software contains libraries and packages sourced from the open-source community or commercial software. The end-user can use the SBOM to perform vulnerability or license analysis, both of which can evaluate risk in a product.

The EO specifically calls out actions to prove the security and provenance of open-source software (OSS). There is a fear that the OSS supply chain is a potential avenue of attack for hackers. Most modern software relies on many OSS packages, which will only increase moving forward as software becomes more and more complex. The EO indicates that OSS packages used in software will need to be checked for:

The EO may force Software developers and DevOps Engineers to change their practices and update their CI/CD pipelines to increase the visibility of the software composition, increase automation and attest to their security practices.

The EO's 10 steps to securing your software supply chain

Secure software development environments using administratively separate build environments, controlling access, 2-factor authentication and by monitoring operations on the build environments.

Provide proof that your software was developed in a secure software development environment when requested by a purchaser.

Use automation to maintain trusted source code supply chains, thereby ensuring the integrity of the code.

Automation tools checking for known and potential vulnerabilities and fixes shall operate regularly.

The Purchaser may request proof of Automation and a summary report of risks and mitigations.

Maintain accurate and up-to-date data, provenance (i.e., origin) of software code or components, and controls on internal and third-party software components, tools, and services present in software development processes, and regularly perform audits and enforcement of these controls.

Participate in a vulnerability disclosure program that includes a reporting and disclosure process.

Attest to conformity with secure software development practices.

Attest to the integrity and provenance of OSS used within any portion of a product.

Cloudsmith is uniquely positioned to help Engineers secure their supply chain and meet the new requirements the US and UK government will be introducing. Cloudsmith provides an entirely managed cloud-native ‘single source of truth’ for all software and its dependencies, isolating and protecting you and your customers from supply chain attacks. Using continuous packaging (CP), we offer the observability and control to ensure that your software is always verified, packaged and ready to deliver.

Build and ship your software with Cloudsmith to secure your supply chain and comply with future regulations.

United in Security: US and UK Vow to Improve Software Supply Chains

At Cloudsmith, we believe that packaging should be at the centre of any modern build and deployment process. In fact, we think that Continuous Packaging is the glue that ties Continuous Integration and Continuous Deployment or Delivery together.

So with that in mind, in this blog, we will take a walk through how easy it is to integrate Cloudsmith with a Semaphore CI workflow and push the artifacts and packages that you build to a private repository.

 – It’s super easy. You just need to add a block to a pipeline in a Semaphore CI workflow that installs the 

, and then uses the CLI to push your package. We will step through how you do that!

Semaphore CI is a Continuous Integration and Continuous Deployment or Delivery platform. It’s cloud-native, fast, easy to get started with and supports any platform or language. You can create your workflow and pipelines by writing the YAML configuration files directly, committing them along with your source code, or using the intuitive Visual Builder that Semaphore includes.

Building a workflow from scratch is beyond the scope of this blog, but we have created a straightforward example workflow that we can walk through to see where Cloudsmith fits in and how to set things up.

When you first log into Semaphore, you can authorise it to connect to your GitHub account and then choose which repository you want to use to create a Semaphore Project. Once you do this, Semaphore automatically installs the required hooks in your source repo so that new pushes can trigger your workflows on all or specific branches, or even for pull requests:

The next thing that we need to set up is to add our Cloudsmith API Key as a secret for this Semaphore project, as the Cloudsmith CLI requires the API Key to authenticate to Cloudsmith to push a package. It’s easy to add a secret to a Semaphore project and then use it as an environment variable in a pipeline:

Remember ALWAYS to store secrets used in your build or deployment processes in a secrets manager (here were are using the built-in Semaphore secrets store) or encrypted in some form. Never, ever add secrets or credentials to your configuration files as plain text, or commit any in your source.

OK, that’s the basics of our project settings configured. Now let’s take a look at the centrepiece of a Semaphore build and deployment process – the Workflow.

At this point, it’s probably worth running over a few of the terms we will come across when describing this workflow and what they mean.

First, you have the workflow itself, which may consist of multiple pipelines, perhaps one to run tests and another for deployment. Pipelines then consist of one or more blocks. Blocks run on an agent, which defines the execution environment, and they also specify which Jobs need to run. Jobs themselves then specify the commands that you want to execute.

In our example workflow here, we just have two blocks – A “Build Package” block and a “Push Package” block:

This is how things look in the Semaphore Visual Builder, and we can also drill down into individual blocks here to see the jobs within them. For example, this is what the “Checkout and Build” Job from the “Build Package” block looks like:

As previously mentioned though, all configuration in Semaphore is specified in YAML files. The initial pipeline is sourced from .semaphore/semaphore.yml. So let’s go and take a look at that now and see what it contains.

The semaphore.yml file starts by declaring a name for the pipeline and the agent that defines the hardware and software environment that the blocks will use:

Next we declare our blocks. The first block we declare is the “Build Package” block:

There are a few things to note here. First, is that any commands listed in the prologue are executed before each job, and here we use these to install the required tooling that we need to for our project (in this case, the rubygem “fpm”, which we will use to create a Debian package once our source is built)

Then, the commands in our “Checkout and Build” job will run. Going through these one at a time, the first command clears the Semaphore cache, so any artifacts from previous runs of this pipeline will be removed. Next, we check out our project source and run “make” to build our source. We then use “fpm” to package the results of our build into a Debian package, and finally, we store the built package in the Semaphore cache with the cache key “package”.

We need to use the Semaphore cache to pass files between blocks and jobs as each job runs in a separate, isolated machine that starts with a clean environment.

The second block that we declare is our “Push Package” block:

Things to note here are that we use the prologue to install the required tooling for the Block, namely the Cloudsmith CLI. We also use the secret that we added to the project here, which sets up our Cloudsmith API Key as an Environment Variable when the job runs.

In the “Push” job, we simply restore the package from the Semaphore cache. Then we use the “cloudsmith push” command with the Cloudsmith account called “demo”, our repository called “examples-repo”, and we are using “Debian” and “Buster” as the distribution and version for this package.

So putting that all together, our complete semaphore.yml file looks like this:

That’s all we need for this job to push the package to our private Cloudsmith repository.

Now, because Semaphore configured our Github repository automatically when we initially set up the project, all that is left for us to do is make a change to our source, add and commit the change, and then “git push”:

This push then triggers the Semaphore workflow to start:

Our pipeline is now running, and we can see that the “Build Package” block is executing the “Checkout and Build” Job:

We can view a live tail of the logs from this block, and we can watch for the output of each command in the job:

The job completed all commands successfully, and now the “Push Package” block starts and executes the “Push” job:

Again, we can view the logs from this block, and we can see that the “cloudsmith push” command succeeded and pushed our package to our private Cloudsmith repository:

That’s everything complete. Our Semaphore workflow ran successfully, and the package we created in our build process was uploaded to Cloudsmith. We can take a look now at our Cloudsmith repository and see our new package:

It is easy to add a private Cloudsmith repository to a workflow that you have in Semaphore CI. You don’t need to make sweeping changes to your build process. Cloudsmith and its universal package support means that, in reality, you are just a “cloudsmith push” away from adding your own central, single source of truth for your package management needs. In doing so, you are one step closer down the path of Continuous Packaging.

Continuous Integration, Continuous Packaging, Continuous Deployment / Delivery. The modern DevOps workflow, helping you secure and control your software supply chain.

Integrating a Cloudsmith repository with a Semaphore CI workflow

Using Semaphore CI to Push packages to Cloudsmith

A short demo of how you can set up a Semaphore CI workflow to push a package to a private Cloudsmith repository.

At Cloudsmith, our mission is to make it as easy and straightforward as possible to get your packages into our system from where you can manage and distribute them to your heart's content.

To this end, we recently spent some time with Atlassian's Bitbucket team at 

 that makes it simple for Bitbucket users to easily turn their source code into distributable packages and deploy to Cloudsmith in just a few lines of YAML.

Pipes build on top of Bitbucket's excellent 

 functionality which allows users to automate their build and deploy processes, whatever form they may take.

Bitbucket Pipes are, at their simplest, the combination of a Docker container and some YAML-formatted configuration. Pipes are designed to remove what would otherwise be repeated or verbose configuration from a user's pipeline. Pipes can be shared across repositories or organisations and make many common tasks almost trivial.

The Cloudsmith pipe is included in Bitbucket's collection of officially maintained pipes and is available by default for any user that wishes to include it in their pipeline.

To use the pipe you'll first need an application or library that can be packaged into one of the formats that Cloudsmith support. You can see examples of Python and Javascript libraries in 

For the purposes of this example we'll assume you're using the Python example from the link above.

First, ensure that you can package your code using a Bitbucket pipeline by editing 

 in your repository. You can do so either via Bitbucket's web UI or using your normal editor and Git workflow.

For the example library, a basic pipeline that builds a package when a new tag is created looks like so:

This pipeline will build a new package each time you push an appropriate tag you your Bitbucket repository. The built package is then discarded as we have not yet added further instructions to tell Bitbucket what to do with it.

Next we'll add publish the package to Cloudsmith using our official pipe. We'll need to provide an API Key that the pipe can use to authenticate with Cloudsmith. You can find the official documentation for pipeline variables in the 

The API Key should be added as a "secure" variable (so it doesn't leak into logs) with the name 

Once authentication is configured, you can add the pipe configuration to your pipeline.

If using the web UI to configure your pipeline, you can select the Cloudsmith pipe right from your browser, from within the list of supported pipes as in the image below:

If using your local editor, you can follow the instructions in the 

Once added, your pipeline YAML should look something like so:

This configuration instructs the pipe to push artifacts to the 

 repository, with the API key we stored earlier. We're uploading a 

And that's it! Your pipe is now configured and ready to run. You should be able to push a new tag to Bitbucket and see your pipe run.

Bitbucket's pipeline UI provides a great overview of the status of your jobs:

Once pushed, you should see your shiny new package in the Cloudsmith UI, ready for download and install using your preferred tools:

Cloudsmith's Bitbucket pipe provides the easiest and simplest way for Bitbucket users to push their assets to Cloudsmith. Our official pipe is maintained by the Cloudsmith team and you can be sure it'll be kept up to date with all changes and features as we release them.

As always, if you have any questions about the pipe (or anything else), we're available at support@cloudsmith.io.

Cloudsmith Blog