With the increased focus on software supply chain security, the question arises- what implications does that have for CI/CD processes and DevOps pipelines?

The Future is Continuous: Integration, Packaging and Delivery - DevOps Institute SKILup Day CI/CD

Join Dan McKinney, Developer Relations at Cloudsmith for an introduction to Continuous Packaging, and to discuss what it takes to secure build and deployment pipelines at The 2022 DevOps Institute SKILup Day CI/CD.

Check out the amazing graphic which summarizes Dan's talk!

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 

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?

. 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.

Everything You Wanted To Know About Securing The Software Supply Chain

Webinar: To NuGet and Beyond: NuGet Ecosystem & Upstream Support at Cloudsmith

Watch our To NuGet & Beyond webinar with Adil Leghari, Dan McKinney, Paddy Carey and Mikey Lombardi.

We break down the NuGet ecosystem in Cloudsmith's first ever hosted webinar! Read the video transcript below, and make sure to read our blog article: 

Good afternoon, good evening, depending on where you are in the world. We appreciate you taking the time out of your day to join us here and welcome to our webinar entitled To NuGet and Beyond. Now we here Cloudsmith know that as a package format, NuGet is a core technology for the Microsoft developer ecosystem, and we want to ensure that we're fully meeting the needs of our customers when it comes to NuGet packaging.

And we also want to make sure that we're treating our Windows users like First-Class citizens on our platform. So to that end, today we'll be talking about some exciting new improvements we've made to our NuGet repository platform, here at Cloudsmith, but also our new support for NuGet Upstreams. Sound good?

OK, so before we get ahead of ourselves, some introductions are in order. Firstly, who the heck are we? So, Dan, I'ma let you go first.

 Yeah, thanks very much, Adil. So yes, hi everybody. I'm Dan McKinney, I work in developer relations here at Cloudsmith. So it's my role to sort of educate and help and assist in any way that I can. So hoping to get some good questions today and to show you some of the sort of unique features of Cloudsmith and how we've brought those features to the NuGet community and the NuGet ecosystem in general.

Awesome, awesome. So I'm Adil Leghari, I'm a solutions architect, manager here at Cloudsmith. I'm assistant turned solution architect and turned manager, and I've spent the better part of two decades here wrangling windows boxes.

So over the past five or so years, I've gotten more active in the PowerShell & DevOps community. I'm a speaker and author and a blah blah blah blah blah, you know that sort of thing. But I think more important for today, I've also spent the past three years in the packaging management space, here Cloudsmith and also previously a Chocolaty; hello ChocoFam. So I guess you could say I know a thing or two about new packaging. Both of us are very pleased to have joining us today as our surprise guest speaker, my dear friend and colleague in the PowerShell Dev Community, Michael Lombardi, Mikey, over to you.

Hey, how's it going? So I have been in the PowerShell Windows Dev Ops space for around roughly a decade and spent a lot of time doing talks and trying to get people to write docs and script code a little bit more cleanly, elegantly.

And then in the last couple of years of my entire professional life, doing nothing but open source development and documentation, writing previously at Puppet, currently at Microsoft, a huge amount of fun to maintain Chocolaty packages and PowerShell modules. So packaging has stayed near and dear to me because it's the best way to get what I wrote or what other people wrote to any system. Everything else is just so much pain.

**Adil Leghari:**Yeah, no, for sure. By now, I think also you're doing some game dev stuff, right? Which you'll be looking at in the future for packaging?

Yeah, doing some interesting work in Golang to build some CLI apps and frameworks and tools. And I'm very excited actually to use Cloudsmith to deliver those things in a much less frustratingly, complex way. I don't want to figure out packaging from the ground up if I can help it. And the raw feeds seem like they're going to solve exactly my problem for me. So I'm very excited about that.

Awesome. We're excited to have you, Mikey. I just want to put a caveat upfront that your views and opinions do not reflect those of your employer.

But whereas Dan and I we are, we are speaking for our employers.

Now, for those of you who may not be familiar with Cloudsmith and what we do here, Dan, why don't you walk us through a quick overview?

Yes, absolutely. Well, I would hope that we do have some Cloudsmith users, but for those that aren't yet Cloudsmith users, Cloudsmith is a global cloud native and universal package management as a service package management solution. And so what we really provide is the ability to sort of build a single source of truth for all your software, artifacts, images, packages.

And although this is a very NuGet-focused webinar, you know, we are fully universal. We support over 28 package formats in multi-format repositories as well, so we are a completely global distributed, web application. There's nothing to install. You don't have to patch anything or update anything. It's a managed platform. We have over 225 points of presence on our package delivery network, as we call it, so great for distributed teams or software distribution even.

An so just to clarify, if I were just a random user, a free user even, if I upload any package up into Cloudsmith, it is available in 225 different points of presence.

Yeah, exactly. You know, it's cached at the edge of the package delivery network. So, you know, performant global access. You don't have to worry about replication or clustering or high availability or anything like that. That's the whole managed platform for you.

Well, of course, we are heavy on security, lots of really, you know, granular access controls and permissions and the ability to restrict and allow access and a very fine-grained manner. And for private repositories, of course, you can have public and open source repositories as well. And yes, as I said, universal. So, you know, we love all package formats equally, but with a special focus on NuGet today.

So actually, Adil, I think this is a very good point now that I've just explained, yes?

For our first poll, so really, we'd like to know more about our users or people who are potentially considering using Cloudsmith. What is your need? What problem are you trying to solve in package management? What is your use case? So we have some options in our poll. You know, A to distribute software externally or B to manage growing complexity within an organization which is very popular now.

Actually, we see a lot of this or a very hot topic at the moment, software supply chain security to supply security or software supply chain. Or maybe you just want to centralize package management on one sort of platform. And for those of us, for those of you who have just joined the webinar and missed the previous slide, what is Cloudsmith? That's a perfectly legitimate answer in this case. So yes, and we'll leave that up just for a second and people can answer and we'll look at them at the end.

SSounds good, Dan, and I do want a plug because we have this here, and I think Alan, our CEO, I'm sure is watching, did remind us yesterday that we have all these great resources and we sometimes don't even plug them enough internally. So let's do that now. So I will mention that securing the software supply chain is one of those big SBOM buzzwords that are out there now. We did try and demystify this a little bit. We had a webinar last week with the Linux Foundation and Dan Lorenc over at Chainguard, who's of Sigstore and Cosign fame.

So feel free to go to our website and check that out as well. It's available under resources.

But yeah, generally, we talk a lot about software supply chain security, which is a very hot topic of conversation, right, Mikey?

Yeah, just a little bit of a nightmare to catch up to for everybody who pretended that it didn't matter forever.

So that's kind of like we talked to not talk specifically about everything you wanted to know about the supply chain, but we're afraid that so I'm plugging another webinar during this webinar. But hey, it's all good content, right? So just frames of reference for you for later.

OK, so let's talk you through a little bit of the agenda now that you know who we are and what Cloudsmith is just you know what you're getting yourself into today. So specifically, what I'll talk about, first of all, is what is NuGet, as a packaging format, as a technology, and how it enables folks on the .Net dev ecosystem.

And then we'll talk about specific NuGet flavors, so the communities and tooling around different use cases for the technology. So in NuGet, that's mainly three groups the C#/.NET folks using Visual Studio, the PowerShell dev community and of course, the Chocolaty dev community as well. So we'll highlight use cases, and I'll also focus a little bit on the differences because the packages are very discrete and different.

There's some complexity in there that we want to help and solve. So that's the next point. We will talk about how Cloudsmith helps solve and make simple some of these complexities for you in the NuGet ecosystem and some of the solutions we have around that. Then I will demo and show off a little bit of this actually live for you so you can understand some of the stuff that we've been working on here, especially to cater to .NET dev specifically. So I'll show off some of the easy stuff you can do with the package installs and stuff like that.

But I'll also touch on, you know, some of the work that we're doing with PowerShell modules, et cetera, making the Cloudsmit CLI available and in places like the Chocolaty Community Repository. So then after that, Dan is going to really dive into, but wait, there's more! All the additional platform features that you get, are just parts of being a Cloudsmith customer. So there's a lot more there that we can touch on, but we'll try and limit it to the time that we have here today, and then we'll leave it open for a Q&A at the end as well because I'm sure there'll be some questions. And will have Mikey chiming in with anything coming from a Cloudsmith customer or user perspective as well.

 Any time he sees fit as well, so sound good? Let's get into the meat of the talk show. So first of all, what is NuGet, right? NuGet is the official package management system the .NET development community, right? Those are NuGet packages. And so that includes a platform and tooling to help .NET developers create, publish and consume and share this reusable code. Why reinvent the wheel if you don't have to? A lot of NuGet devs will build,

let's say you write some code to essentially solve a problem, and then now you can have that library packaged as a NuGet package and other developers now, when they need to solve that same problem, they can just pull down your library, install that NuGet package and then they're ready to go with the tools available in that package to make their development and workflow a lot more efficient. So it encourages the reusability of code and the functionalization of those things. And so the smallest unit of that is a NuGet package.

So a little background for you. NuGet was created in 2010 under the name “NuPack”, I believe, according to Rob from Chocolatey, I believe it was “Nu” before that? He mentioned it once. So I think it was “Nu”, firstly, that it was talked about but referred to as “NuGet” or “NuPack” earliest and then also then moving to NuGet as a format by the Outercurve Foundation. The Outercurve Foundation is now very much a precursor to the .NET Foundation set up by Microsoft.

Some people, you know a thing or two about, Mikey. So of course, NuGet packages themselves, what do they contain? What is the NuGet package? So it's actually kind of very universal and multi-use format. So it can be very different depending on the type of package you have, and we'll highlight some of that here. But the main components sort of to boil it down, are a library sort of like a compiled piece of code, or a binary, that actually stores some of the functions and other features of the other that you're trying to use.

So in the case of .NET/C#, it can be a DLL in the case of a Chocolatey package that can be a binary itself, EXEs or MSIs. And along with that is related files so often describing how to use or install the package itself in the case of Chocolate Factory, this is actually a PowerShell script that does the actual installation upgrade or uninstall of the package. So that's part of related files there.

And then we have a manifest file, the Nuspec, if you will, right?

This is the metadata of about the package version title author information like good details to have there, including dependency format as well if you have any dependencies for that package are defined here in the nuspec. OK, so let's talk about NuGet flavors and communities. And again, I'm going to get into some of this stuff, and I just want to do a quick call out here that there's no quiz later, so you don't have to remember all of this. But a big part of what is NuGert, NuGet flavors and communities, tooling, we tackle a lot of this in a blog that I published last week.

So that blog will go and cover this in detail, too as well. If you don't want to remember all of it now, I'll do a quick summary for you, for the different communities,

 So let's summarize some of these use cases, right? So there are three big groups here, firstly, let's talk about the .NET developer community, now this is largely C# folks, but also F# to a small extent. The VB, you know, the hangers-on that are out there still running, VB. So the organization behind this is very much the .NET Foundation now as in 

, of course, and Microsoft that sponsor the .NET Foundation.

And so in addition to that, of course, the language of choice for this is largely C#, so C# devs that are working, you know, in Visual Studio, et cetera, but of course, some F# and VB too. The tool of choice is ubiquitous here, so Visual Studio is the tool that is used most popularly as an IDE an “integrated development environment”, so Visual Studio is what he was to write that code and has some integration built right in for NuGet packaging.

And of course, NuGet CLI as well. So NuGet.exe can be used by devs when they're looking to do something or preferring to do it from the command line or also when they need it in a pipeline. So it's not interactive.

The public repository of choice, of course, is the NuGet Gallery. The NuGet Gallery is probably the largest public repository of NuGet packages. It contains almost 300,000 NuGet packages. So for the sake of our discussion today, it is the largest. So that's a lot of packages that are up there.

And so these packages now have moved to NuGet format V3, just a heads up. So NuGet v3 is the newer format. 

 moved from V2 to V3, largely citing concerns around scaling and the availability of 

. So they had to solve some problems there, and so they upgraded to NuGet V3. And so that's really a re-artifacting of the whole format. So, very much not compatible with the other ones in that sense.

So in addition to that, largely the composition of these are our libraries, so compiled code that other developers can use so they can quickly import that individual studio and then it's ready to go for them. They can just start using that from the repository and start using the IntelliSense and the functions right from that code built into Visual Studio.

The second group is a group we know very well, right, Mikey? So the PowerShell developer community, right?

So this is not a “formal group”, per se. I mean, of course, PowerShell team shout out to Mike Greene and Steve Lee over at Microsoft do work over there and do push the technology. But largely it's the community of folks here in the PowerShell community, and we show up a lot on Slack and Discord and places like that. And of course, Microsoft is behind this technology. The “Shell Father” himself, Jeffrey Snover, who wrote it back in the day or who invented the format.

It's worth calling out that the language is open source and has been for half a decade now. It's Microsoft, but it is all developed out in the open and has been open source for a while. Which is great because people like me and you get to go and bother them with our stuff all the time.

Yeah, we can happily submit our suggestions and we get a response back, say we await your PR, right?

I will call that out a little bit here in the tools of choice too. Obviously, the language is PowerShell, but but largely here, you know, there's two main ways that folks interact in the PowerShell format. One, is powershell.exe. So the original Windows PowerShell does come bundled in, and for a lot of sysadmins, of course, they know on every Windows OS, right? So it's in the Windows ecosystem, it comes built into the box, so it's easy to use.

But largely Mikey, like you called out PowerShell, the pwsh.exe is now cross-platform and open source. So this has made it almost ubiquitous. Now it's across all technologies and a lot of OSS adoption has increased, once it was open source there.

The open source version of Microsoft PowerShell is the very popular format now and ever growing and where a lot of the code now, the functionality lands, right? According to Microsoft, I believe Windows PowerShell is a feature complete, right? It’s just more bug fixes and security updates. So all this new development is occurring on PowerShell cross-platform.

What are we referring to is as now? Should we call it Microsoft PowerShell officially?

Yeah. Okay, let's let's stick with that. And so, that's obviously increased for PowerShell devs, the availability and the accessibility of the code. Right now, of course, the big, big public repository is the PowerShell Gallery. The PS Gallery hosts a lot of the packages, over 9600 unique packages.

The great thing about it is that it's an easy format to be able to push up there. Once you do have your manifest and other things you find, you can push any PowerShell module up there. Now we know, Mikey, you and I, that sometimes what will have to end up happening, at no fault of the team, is the fact that availability can sometimes be an issue, right? Which is where it's helpful to have your own internal or private repositories, which we can get into.

Yes, totally, and running services is hard, and calling out to public services from every server is maybe not your favorite thing in the World. Certainly, not your security team's favorite thing.

Exactly. And it helps to have that level of vetting and internal verification, which an internal repository affords. So we'll touch on tha int a little bit. Now, just a quick point here, so PowerShell modules themselves, they are just files, scripts and manifests in a folder essentially once they get on to the box in the endpoint.

So NuGet here, is actually used as a delivery mechanism, so it's what's used to package the actual module itself. So when it's uploaded into a NuGet repository and when it's pulled down from a NuGet repository is when nuget.exe is used. So NuGet actually does under the hood pack and unpack that package for you into a PowerShell module. So it's a delivery mechanism, so it doesn't actually live in that format. And importantly, this NuGet V2 not NuGet V3.

It's also great for dependency management. That’s really hard to figure out on your own. And version pinning and all that stuff. So you get that for free just by using the NuGet package format.

Exactly, that version pining and dependency is one of the great features of NuGet for sure.

So great segway, here to the Chocolatey Dev Community.

This is a community, Mikey, also near and dear to our hearts, fellow choco-fam from back in the day. So it's definitely alive and well. And a lot of sysadmins now use Chocolatey as an easy way to be able to install any package under the sun on all your endpoints. I know, Stevie is probably in the chat right now, he is a Senior SA and Manager over at Chocolatey. He's helped me a lot with the PS Cloudsmith module, so shout out to Stevie, I appreciate all you do. For sure he is very active with this and he's a big, big advocate for it.

To NuGet and Beyond Webinar [On-demand Session]

Everything You Wanted to Know About Securing the Software Supply Chain but Were Afraid to Ask

From the history of supply chain security threats to security development and deployment we've covered everything you’ve always wanted to know about the software supply chain but were afraid to ask. Dan Lorenc, Founder/CEO, 

, Paddy Carey, Senior Staff Engineer, Cloudsmith, Adil Leghari, Solutions Architect Manager, Cloudsmith and Dan McKinney, Developer Relations, Cloudsmith, gathered for a fireside chat to cover your most burning questions:

 Types of attacks – availability, dependencies, development tools, and more.

Software supply chain challenges and considerations

A look at OSS projects and initiatives that were born out of the SSC security need.

 What have Cloudsmith & ChainGuard been working on to make these issues easier to tackle, and what you and your organization can do to help.


Read the transcript of the full webinar below:


Hello, everyone. Good morning, afternoon, good evening. Depending on where you are in the world, on behalf of my colleagues here at Cloudsmith and Guard, I want to welcome you to our discussion entitled “Everything You Wanted to Know about Securing the Software Supply Chain, But Were Afraid to Ask”. So this is going to be an open discussion or conversation, so feel free to hop in, you know, with questions if you want to. We do have a Q&A section specifically in Zoom for that, so it helps if you throw your questions in there because it will.

Definitely, everybody will get the benefit of the answer if we answer it on the call. In addition to that, of course, like, you know, we're all here and I want to welcome you. But I think over the last few years, software supply chain security specifically has become top of mind as one of these concerns for almost every organization, right, that's producing and consuming software. So we are the tech community have to try and understand this. But if we're going to wrap our heads around it, we really need to have conversations like these, you know, to improve our collective understanding of where we came from and sort of where we're going. So hopefully, by the end of this talk, we'll leave with not just a bunch of fear, but hopefully a little hope as well about the future of supply chain security and software.

So let's go through the agenda real quick here. I will first off just do a quick little speaker introduction for all of us. Everybody will do their own introduction and then we'll give you a little background on what we do with our organizations, with Cloudsmith and Chainguard as well. And then we'll get into the sort of the meat of the torque where we're talking about, you know, some of the things that we want to bring up today. As and again, this will be open, sort of like a fireside chat. We're just discussing stuff. And so feel free to ask questions as well and help my fellow speakers feel free to hop in at any point.

We'll be touching on points like what got us here, specifically when we talk about previous tipping point events, sort of attacks, and other things that precipitated our big concern about the software supply chain. And then we'll touch on why this is such a hard problem to solve because there are definitely some challenges there. Each attacking each different compromise or issue that comes up really has different origins and different techniques and methods. So it can be quite tricky, sort of a moving target.

And then we'll talk about specifically what's being done where we highlight a few open-source projects in the space, specifically around the efforts that Dan Lorenc has done over at Chainguard and also at his time at Google and with open source. So thanks for being here with us, Dan. And then also we'll specifically talk a little bit about at the end about what are we doing at organizations like Cloudsmith and Chainguard, and also how you as an organization can help and contribute to the same efforts? Sound good?

OK, well, without further ado, let's introduce ourselves a little bit. So I'm Adil Leghari, I'm a solution architect manager here at Cloudsmith. I'm a sys admin turned solution architect turned manager. I spent the better part of two decades here wrangling Windows boxes and Linux boxes. So over the past five years, I've become an active member of the PowerShell and the devops automation community, and I'm a speaker and author and super passionate about PowerShell, dev ops and automation, yada yada yada over to you, Paddy.

Webinar: The Future is Continuous: Integration, Packaging and Delivery

More articles

Understanding and Implementing a Software Bill of Materials

Everything You Wanted To Know About Securing The Software Supply Chain

To NuGet and Beyond Webinar [On-demand Session]

Securing The Software Supply Chain Linux Foundation Webinar [On-demand Session]

What is NuGet?

Continuous Software Pipelines: Why Enterprises Are Going Cloud-Native Dev Week Enterprise Open Talk