Software programs today can be likened to a complex stew, with multiple ingredients sourced from disparate places. In software, open-source tools are a major ingredient. According to the 

2020 Open Source Security and Risk Analysis (OSSRA) report

 produced by the Synopsys Cybersecurity Research Center, 99 percent of the codebases contain at least one open source component, with open source comprising 70 percent of the code overall.

A critical component of DevSecOps is maintaining and monitoring the growing number of third-party components (open source and proprietary) that make up modern software. Increasingly, engineering teams are using a software bill of materials (SBOM) to help them with this work.

Although the concept of a Software Bill of Materials (SBOM) is not new, it has recently come into prominence due to several key events. First, a number of attacks on companies’ software supply chains including 

 revealed the importance of having full visibility into a software’s supply chain. This year has also seen an 

 on public repositories (e.g., NPM registry and PyPi).

Next, is the May, 2021 U.S. Presidential 

Executive Order on Improving the Nation’s Cybersecurity

. The order contains a provision that requires software vendors to the U.S. federal government to provide SBOMs. The Solarwinds hack was one of the cited reasons for the SBOM provision in the executive order.

The importance of SBOMs in package management

What is a software bill of materials (SBOM)?

So, exactly what is an SBOM? In brief, an SBOM is a list that contains all of the components and dependencies in a piece of software. The Nation Telecommunications and Information Administration (NTIA), the U.S. government agency tasked with developing federal standards from SBOMs, 

 them as, “a formal, machine-readable inventory of software components and dependencies, information about those components, and their hierarchical relationships.”

SBOMs should include open source and proprietary software and should explicitly state if there are any missing elements to the inventory.

Watch our very own Dan McKinney discuss what SBOMs are in depth, and what SBOMs should looks like for your applications in our webinar with Security Weekly.

A Standardized Approach to SBOM - Dan McKinney - ASW 173

Following the release of the executive order, NTIA published the following 

 of an SBOM. Note, that these guidelines currently only apply to vendors of the U.S. federal government, but they are a helpful reference for any organization interested in developing an SBOM.

Read on for a list of the minimum elements of SBOMs:

Data fields contain baseline component information about each element of the software that should be tracked and maintained. This information includes:

This section of the minimum requirements document stresses the need for tooling that “allows the ability to scale across the software ecosystem, particularly across organizational boundaries.” The federal government requires vendors to use one of the following formats to generate SBOMs:

Note, these are not the only formats to create SBOMs. We will go into more detail about these and others in a later section.

The following “practices and processes” outline how and when updated SBOMs should be delivered:

- A new SBOM must be created to reflect a new build or release of a software component.

 - An SBOM should include all primary components with their dependencies listed.

 - The SBOM author should explicitly state when the presence of dependencies is unknown and differentiate that from a component that has no dependencies.

 - SBOMs should be made available to those who need them in a timely fashion.

 If an organization chooses to keep an SBOM private, it must specify terms of access control and accommodate integrating SBOM data into a user’s security tools.

 - Consumers of SBOMs are advised to be tolerant of mistakes and errors, as this standardization process is still new.

SBOM formats, specifications, and delivery

As mentioned previously, there are currently three SBOM formats approved by the federal government to deliver SBOMs:

Processes and integrations are also emerging as a result of increased adoption of SBOM, and a 

 of tools both open source and commercial are being developed and used.

Any organization that produces, purchases, or operates software will benefit from an SBOM. Common use cases include:

 In addition to the U.S. federal government, heavily regulated industries like healthcare and financial services require software vendors with secure products. Many may require an SBOM as a part of the purchasing process.

 - An acquisition target can use an SBOM to demonstrate sound architecture and technical proficiency. This can also help the buyer better understand the software of their target.

 - Engineers can use SBOMs to monitor vulnerabilities across their company’s software. Upon receiving a notification about a vulnerability, a developer can then use the SBOM to find all instances of the affected software and patch the problem.

what SBOMs look like for an organization’s applications

One new or unfamiliar to the concept of SBOMs might be justifiably concerned that SBOMs might be an avenue for hackers to see into their infrastructure. On the surface, an SBOM may seem like a public-facing document that tells unwanted parties everything they need to know about your tools and software components.

These are both common misconceptions. First, nefarious actors do not require SBOMs to stage attacks. For example, botnets used to stage DDoS attacks are broad and take advantage of the probability that some IoT devices will be unsecured or lack up-to-date firmware. The SBOM is really a defensive document that gives you the ability to counter attacks and correct vulnerabilities as quickly as possible. Secondly, an SBOM does not need to be made available to the general public. You may need to provide an SBOM to a customer, but this can be done directly, avoiding the exposure of a public website.

While an obvious benefit of creating and using an SBOM is reducing the chance of a supply chain attack like the 

, there are some additional benefits of creating an SBOM including:

Generating customer loyalty by providing increased visibility into the tools that you use.

Better license management; more visibility into the software reduces risk of using non-compliant software.

Reducing business disruption during audits.

More easily identifying redundant or excessive coding, reducing code bloat.

Reducing operational costs by preventing developers from manually searching for vulnerabilities.

Package managers in and of themselves are not SBOMs. However, they do contain a large amount of information including third-party applications and some dependencies that will eventually be in the SBOM. The CycloneDX SBOM specification (mentioned earlier) has tools to enable engineers to 

generate SBOMs from package manager manifests

Cloudsmith is also an important tool for engineering teams 

 and staying in compliance with an increasing number of regulations. As a single source of truth for all your software assets, Cloudsmith is the only cloud-native, universal package management solution, allowing your organization to create, store and share packages in any format, to any place, with total confidence.

If you or your organization are looking for a cloud-native, universal package repository solution, 

 at Cloudsmith and we’d be more than happy to help.

If you’d rather try out the Cloudsmith platform for yourself first, we offer a 

Alan Carson

Co-founder and Chief Strategy Officer

Understanding and Implementing a Software Bill of Materials

You know you need to secure your software supply chain. Everyone’s telling you that these days - your executives, your vendors, even 

. Your organization has an initiative to do so, or maybe they’ve brought in an expert to help you achieve this goal. But hold on a minute - do we have a shared understanding of what a software supply chain is, and what exactly makes it secure?

Hopefully, you were able to join the Linux Foundation webinar Cloudsmith hosted last week with 

. The focus was getting back to the basics of what a software supply chain is, and why it needs to be secure. If you weren’t able to attend, or if you want reference material to share with others, here’s our recap.

The webinar addressed the following topics:

What does a secure software supply chain look like?

What are Cloudsmith and Chainguard doing to help solve this problem?

In the most basic terms, what is a software supply chain?

Simply put, a software supply chain includes 

 everything that contributes to making your product - the source code, dependencies, systems, tooling, environments, processes, and even the users who contribute along the way.

, Developer Relations at Cloudsmith, said that a good analogy for understanding the software supply chain is to look at another industry that also deals with supply chains - manufacturing. The manufacturing industry has a standardized way - a Bill of Materials - to detail all of the inputs into their final product. They need that because they need to ensure they have the materials required to build the physical product and that they have met safety and security standards along the way.

The software industry doesn’t have the same regulatory controls as manufacturing, though. There is no centralized authority ensuring provenance and traceability are enforced (though we may see this in the future). This gap has made space for the rise of many interesting projects designed to help make safety and security so easy, it becomes the default. Projects like Sigstore, The Update Framework, in-toto, and SLSA are just a few examples. We’ll touch more on these projects later in this post.


Why are we securing our supply chains now?

As Dan Lorenc said in the webinar, there have been voices advocating for securing software supply chains for years now. But a handful of events in the last 24 months have caused organizations to wonder why they’ve waited so long to get started.


In the spring of 2020, SolarWinds unknowingly started to send out software updates that contained hacked code. This is the event that really got everyone talking about “software supply chains”.

SolarWinds is an IT management tools company that helps businesses manage their networks, systems, and infrastructure. In early 2020, threat actors found a way into the build system at SolarWinds and managed to add malicious code into one of its products, a performance monitoring platform called Orion. Subsequently, when Orion customers updated their installations, the malicious code was included in the update, giving the threat actors a backdoor they could use to install additional malicious software, exfiltrate sensitive data, or spy on the companies themselves.

Big organizations found themselves impacted - Microsoft and Intel for example. Overnight, everyone was talking about software supply chains and what needed to be done to secure them.


In February 2021, security researcher Alex Birsan 

 were found to be vulnerable to the injection of malicious packages, via public sources, into their software supply chains.

, and it relies on package management software to download the malicious version of a package being used as a dependency. The key is to create an external library with the same name as a private internal library that a particular company uses in its development pipeline. There are then several ways that a package manager can end up accessing the malicious external version of the library.

This incident shows why it is so important to make security so easy, it happens by default. It only takes one developer with a poorly configured system for the malicious library to gain entry to the organization.

On May 12, 2021, President Joe Biden issued an executive order to begin creating federal standards for security of the software supply chain. 

The Executive Order on Improving the Nation’s Cybersecurity

 orders the Department of Commerce and the National Telecommunications and Information Administration to publish minimum requirements for a 

 (SBOM). The SBOM is a record of the components and packages used in building software, whether open-source or commercial, intended to help software end-users to analyze vulnerabilities or issues with the licenses.


In February 2022, The National Institute of Standards and Technology released Special Publication (SP) 800-218, 

Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities

. At the start of 2022, the White House brought together government employees, private sector stakeholders, and members of the open-source community to discuss how to improve the security of open-source software and software supply chains. This publication is the result of those discussions, and it recommends a core set of high-level secure software development practices called the SSDF that can be integrated into each SDLC implementation.

Why is this a hard problem for organizations to solve?

One challenge is that open-source software is foundational to software development, and so for an organization to secure their supply chain, they will need all open-source software they use to also be secure. Realistically, open-source code is in every supply chain. Now, it’s important to note that the way to solve this problem 

 to remove open-source software from your supply chain. In fact, open-source software can often be more secure than proprietary software as its widespread use means it’s usually well tested. The challenge is in how to make adhering to security best practices so easy, they are not burdensome for the open-source community to adopt.

Along the same lines, for one organization’s software supply chain to be secure, the supply chain of any vendor they use also needs to be secure. You need provenance from top to bottom. To quote Paddy Carey, Senior Staff Engineer, Cloudsmith, “

.” And if no one is requiring you to adopt secure software development practices, and it’s overly burdensome to do so, what’s your motivation? So again, designing standards, tools, and solutions that make it easy to be secure will be key to the widespread adoption of secure software development practices.

As Dan Lorenc said, it will be slow until the first person adopts these practices, but then we’ll see it ripple across the industry.


First, it’s important to acknowledge that there is no one thing you can do to secure your supply chain. There are many best practices that come together to create a secure software supply chain. But it’s also important not to let that overwhelm you.

One project that is designed to help organizations understand what makes a supply chain secure and provide guidance on how to get started is 

. It’s a security framework, a checklist of standards and controls to secure packages and infrastructure in your organization. And there are SLSA levels - Level 1 is designed to be easy to achieve to help motivate folks to start the process of securing their supply chain.

NIST organizes the Secure Software Development Framework practices into four groups:

: Ensure that the organization’s people, processes, and technology are prepared to perform secure software development.

: Protect all components of the software from tampering and unauthorized access.

: Produce well-secured software with minimal security vulnerabilities in its releases.

: Identify residual vulnerabilities in software releases and respond appropriately to address those vulnerabilities and prevent similar vulnerabilities from occurring in the future.

Both the SLSA framework and NIST’s SSDF are good starting points for organizations on the journey to a secure software supply chain. And if you want the tl;dr on NIST’s SSDF, 

Dan Lorenc read NIST 800-218 so you don’t have to

Chainguard was founded in 2021 with the mission to 

make the software supply chains secure by default

. The team is working on this goal with a strong commitment to open-source projects and communities, and a willingness to take on large-scale industry-wide changes. Some key projects they are involved in:

As mentioned earlier, SLSA is a checklist of standards and controls to secure packages and infrastructure within an organization. SLSA levels are a common language to talk about how secure software, supply chains, and their components really are. From source to system, the levels blend together best practices to create four compliance levels of increasing assurance.

A new standard for signing, verifying, and protecting software, sigstore automates how you digitally sign and check components, for a safer chain of custody tracing software back to the source, removing the effort, time, and risk of error this usually comes with this.

As Dan McKinney said, Cloudsmith is excited that securing the software supply chain is now at the forefront of people’s minds, as it’s been close to our hearts for a while now. We believe that 

 - the strategy of ensuring all packages produced or consumed are scanned, verified and isolated from untrusted sources - improves security through isolation, automation, and universal hosting. Our platform enables organizations to add continuous packaging to their modern software development workflow.

Provide a single source of truth of software assets

 with support for over 28 formats, allowing organizations to manage packages across languages and formats in one place. This centralized source of truth provides visibility, control and management consistently for all packages produced or consumed by the build process, and gives organizations a single checkpoint that all packages pass through.

The goal of provenance is an unbroken chain of traceability, all the way back to the host machine that built the package. And we want to meet our users where they are when it comes to provenance. We will implement support for the signatures and attestations that our customers are adopting across all the formats we support, including but not limited to sigstore, cosign, in-toto, The Update Framework and more.

users can cache their open-source packages

 away from public upstreams. By caching packages from public upstream repositories and other external sources, you can protect yourself from issues with package availability, license changes, and emerging vulnerabilities.

First and foremost, we must acknowledge that we are a chain in our customers’ software supply chains. We are taking steps to ensure that we employ high-level secure software development practices, and exposing that information to our customers to prove to them that we are secure. Customers need to be able to trust, and verify, that their providers are securing their software supply chains, too.

Hopefully, that helps demystify software supply chains and why securing them is paramount to the software industry as a whole, and why the time to do so is now.

We’d also like to thank Dan Lorenc, the founder and CEO of Chainguard for joining us for the webinar.

Dan McKinney

Solutions Engineer

Everything You Wanted To Know About Securing The Software Supply Chain

If you’ve spent any amount of time in the .NET / Microsoft developer ecosystem, you’ve probably heard the term “NuGet” in reference to code packages, package managers, software libraries, and even software installers. Understandably, this can cause a lot of confusion around what NuGet actually is.

Common use cases and tooling for NuGet packages

NuGet is the official package management system for .NET development. This includes a platform and tooling to help .NET developers create, publish, consume, and share reusable code. The format in which the code is bundled is called a NuGet package, which is simply a shareable unit of code.

NuGet was created in 2010 (under the name “NuPack”) by the 

, a non-profit founded by Microsoft. The goal of this foundation was to "enable the exchange of code and understanding among software companies and open source communities." The Outercurve Foundation was a precursor to the current 

 and contributed projects like NuGet to this group.

 a NuGet package? Well, the short answer is it’s just a fancy zip file that uses the “.nupkg” extension. This archive can contain:

Compiled code in the form of libraries (DLL’s), or in some cases binaries (EXE’s and MSI’s)

Additional files related to the code (often describing how to use/install it)

A manifest file (“.nuspec”) detailing metadata about the package (version, author, etc.)

Developers wanting to store or share this code with their team or others can simply publish their NuGet packages to a Public or 

. This also encourages developers to write code that is more reusable among teams, with libraries and dependencies that are well-defined. Why reinvent the wheel if you don’t have to?

Several distinct communities in the .NET ecosystem utilize the NuGet package format. Each of these communities has its own unique use case and tooling, along with its own “flavors” of NuGet package.

The .Net Developer Community largely uses C# as their programming language of choice (though F# and VB definitely have a presence here as well). With the move to .NET Core as a fully cross-platform and open-source framework, the community has garnered wider adoption and support on desktop, mobile, Cloud, and IoT operating systems.

This Community largely interacts with .NET via 

, the most popular IDE (Integrated Developer Environment) in this tech stack. Visual Studio offers .Net developers the ability to interact with their NuGet repositories via its graphical interface. In fact, the 

) already comes pre-configured as a package source. As of writing, the NuGet Gallery hosts almost 

 unique NuGet packages! Developers can add NuGet packages directly within their C# project and are then immediately given the ability to reference the libraries from that package in their code (with IntelliSense auto-suggestion).

How to install a NuGet package in Visual Studio

Watch the video below on how to install and use a NuGet Package with Visual Studio; courtesy of Microsoft:

Install and Use a NuGet Package with Visual Studio | NuGet 101 [2 of5]

Developers that prefer to create their own NuGet packages often choose to use the 

 (command-line interface; a.k.a. nuget.exe). The NuGet CLI allows users to install, create, publish, and manage packages without leaving their console. This also affords users the ability to interact programmatically with NuGet packages in their pipelines.

: PowerShell (pwsh), Windows PowerShell (powershell.exe)

PowerShell is a programming language, a scripting language, and a command-line shell all rolled into one! It has gained a great deal of popularity as a “glue language,” being a tool of choice in DevOps & Automation pipelines. All three major cloud vendors (AWS, Azure, GCP) support interaction with their platform via PowerShell modules and even include them in their SDK (Software Development Kit). Windows PowerShell comes installed by default on all Microsoft Windows operating systems. PowerShell (7+; a.k.a. pwsh.exe) is also available as a cross-platform open-source binary.

PowerShell developers utilize PowerShell modules as their unit of shareable and reusable code. PowerShell Modules contain functions and cmdlets (pronounced “commandlets”) that abstract away the need to do string manipulation.

For users interested in sharing and reusing code publicly, Microsoft hosts the 

, with over 9,500 unique modules. In effect, PowerShell uses “nuget.exe” under the hood of its cmdlets that interact with NuGet repositories to create, upload, and download PowerShell modules wrapped in NuGet packages. The modules themselves are not kept in NuGet format once installed or imported; the NuGet packages are simply used as a conveyance mechanism.

Chocolatey is a Windows software management solution that was created by 

 in 2011. It is a CLI tool (“choco.exe”) that allows users to package and install 

 kind of Windows software into a Chocolatey NuGet package. Chocolatey packages are a slightly different “flavor” of NuGet. They usually include binaries (EXE’s and MSI’s), along with instructions on how to install, upgrade, and uninstall these applications in the form of PowerShell scripts. The fact that users can bundle pretty much any kind of installer or PowerShell scripting in a reusable package format has solidified Chocolatey as one of the most versatile and ubiquitous choices for installing and managing software on Windows endpoints.

 hosts over 9,000 community packages in the Chocolatey NuGet format, containing simple, scriptable, and silent installation methods for most popular Windows applications (e.g., 7Zip, Notepad++, Firefox, Chrome). Many of these packages are for open-source software as well, and almost all of them are contributed by community maintainers. This gives a System Administrator a quick and easy way to provision and patch a set of base applications on all their Windows endpoints. In addition, Chocolatey Software also offers 

 with a more advanced feature set for creating, updating, and monitoring the status of Chocolatey NuGet packages in an organization.

NuGet packages don’t always play nice together

As you can probably see from the above examples, NuGet packages can come in many “flavors,” with notably different compositions. Thus, it should come as no surprise that mixing and matching different formats is not supported or recommended.

, the testing framework for PowerShell, exists as a package on the 

. However, you can’t “choco install” the NuGet Gallery package or use “Install-Module” in PowerShell to begin using it. The lack of interoperability between repositories and NuGet formats can often be the source of confusion.

To add another wrinkle, the NuGet Team deprecated NuGet V2 in favor of V3 on the 

 (citing performance and scalability issues of NuGet V2 OData feeds and queries). This works fine as long as you’re only using Visual Studio or the NuGet CLI. However, both PowerShell and Chocolatey communities currently only support the NuGet V2 format for their NuGet package management.

Hopefully, this article has helped clear up some confusion on what NuGet is as a package format and how developers use NuGet packages in their .Net, C#, PowerShell, and Chocolatey code workflows.

If you or your organization are looking for a global, secure, cloud-native, and universal package repository solution to 

 along with 26+ other formats (including Docker containers), 

 here at Cloudsmith, and we’d love to understand your use case, and show how we can help.

If you’d rather try Cloudsmith for yourself first, we also offer a 

If you're intrigued to learn more about specific package formats, delve into our series below:

Here is a quick roundup of the common NuGet questions we’ve come across.

C# is the most popular programming language used by developers building software with the .NET Framework. NuGet is used to improve C# developer productivity since reusable units of code can be packaged in a NuGet format and shared among teams and the OSS community. Developers can add NuGet packages directly within their C# project and are then immediately given the ability to reference the libraries from that package in their code.

Should you be worried about the safety of NuGet packages? We live and breathe security here at Cloudsmith, and you should always be in control of your software supply chain. Real talk: you should be careful about any kind of package you download from public repositories, as detailed in our article discussing what developers and organizations want from a package repository. But a NuGet package is as secure as any other package format; you just need to do your due diligence to vet the sources of these packages appropriately.

NuGet repositories (also known as NuGet feeds) are where you can upload and store your NuGet packages. At Cloudsmith, our package repositories are multi-format friendly, meaning you can store NuGet packages alongside other popular formats in the same repo, such as Docker images, Maven packages, and 24+ other formats too!

Lee Skillen

Chief Technology Officer

What is NuGet?

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.

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.

Cloudsmith blog

Understanding and Implementing a Software Bill of Materials

Everything You Wanted To Know About Securing The Software Supply Chain

What is NuGet?

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