How to Manage Your Vulnerability Workflows with Cloudsmith

A vulnerability is a flaw in your software product that an attacker can exploit. A critical and easily exploitable vulnerability, like Log4Shell, can facilitate Remote Code Execution (RCE), allowing an attacker to remotely execute malicious code on a computer. Sonatype’s 2021 state of the software supply chain found that supply chain attacks, which include attacks that target vulnerabilities in software, are up 650%.

But finding vulnerabilities is not a piece of cake- people are still searching for packages vulnerable to Log4Shell in their system.

Cloudsmith, as a hosted package management service, wants to help our users secure their software supply chain, and one component of that is extending its support for vulnerability scanning to include Docker, Ruby, Python, Composer, Maven, NuGet, Golang, Cargo and npm.

Cloudsmith will automatically scan supported package types for CVEs when a package is pushed to a Cloudsmith repository or fetched from a public repository. You can use the results of a Cloudsmith Security Scan to drive other actions such as quarantining a package, or as part of a package promotion workflow. We know that vulnerabilities can be found after you build your software, so Cloudsmith allows you to trigger rescans on demand via the API/UI.

This post will talk about:

• Cloudsmith's vulnerability scanner
• Symbiotic features that play nice with scanning, including webhooks, quarantining and upstreaming. These can be used together to create workflows and drive actions.
• A workflow to trigger a nightly scan and quarantine if vulnerabilities are found above a certain level.
• Future improvements to workflows on vulnerabilities

Vulnerability Scanning

Package vulnerability scanning is a key step in securing your software delivery pipeline and reducing the risk of releasing insecure software into production.

Cloudsmith makes it easy for your team to introduce vulnerability scanning by automatically scanning every supported package format pushed to a Cloudsmith repository or fetched from a caching-enabled upstream.

Cloudsmith's vulnerability scanning feature is available for the following package formats:

• Docker
• Ruby
• Python
• Composer
• Maven
• NuGet
• Golang
• Cargo
• npm

Cloudsmith's Security Scanning page shows a breakdown of the number of packages scanned/not scanned, the age of scans, the pass/fail count overall and the maximum severity of those found.

To dig into your exposure a bit deeper, you can view the individual vulnerabilities found on the "Scans" tab on any package detail page:

Symbiotic features

Vulnerability scanning on its own isn't enough - you need to couple it with other features to create workflows and drive actions. Let's talk about webhooks, quarantining images and setting up upstream so that all your 3rd party dependencies are also scanned.

Webhooks

Webhooks are one way that apps can send automated messages or information to other apps. Webhooks are great for integrating Cloudsmith with other systems in your build pipeline, by sending data or notifications to other tools in your stack and helping to enable automation across your workflows.

And we have webhooks for vulnerability scanning. Anytime a scan is completed, Cloudsmith can dispatch a corresponding vulnerability webhook to trigger some action like quarantining your package.

Quarantining

Package quarantine allows you to temporarily block any downloads of a package until you release the package from quarantine.

This is useful in any case where you wish to remove the ability to access a package that is present in your Cloudsmith repository, for example, in a case where a security vulnerability is discovered after you have published a package. Unlike deleting a package, you can restore access to the specified package at a later stage if required.

Upstreams

Cloudsmith's vulnerability scanner is most effective when combined with upstreams. Upstream proxying and caching allows you to upload and use the packages you own, while Cloudsmith fetches and caches your dependencies from public repositories e.g. Maven Central or NuGet.org.

This enables you to use Cloudsmith as a first-class cache and a central source of truth for packages, to protect you from outages of external services (which is especially important when running behind your firewall).

Any supported package fetched from a caching-enabled upstream will be automatically scanned for vulnerabilities.

Vulnerability Workflows with Cloudsmith

This is an example workflow to:

• Set up an upstream
• Push a package
• Set up a webhook for scan results
• Quarantine the package for scans with vulnerabilities
• Schedule a rescan

I'll assume that you have installed the Cloudsmith CLI for the examples below. The CLI interfaces with Cloudsmith's API and allows users, machines and other services to access and integrate smoothly with Cloudsmith without requiring explicit plugins or tools.

Set up an upstream

To kick off Cloudsmith's vulnerability scan on your 3rd party dependencies, set up an upstream to your public registries e.g. Maven Central or NuGet.org. Every time a dependency is fetched, it triggers a vulnerability scan just like it would for a package you push directly.

Click the green "Create Upstream" button, and then select the format you want to create an upstream for:

Push a package

A vulnerability is automatically triggered for supported packages every time they are pushed. If you set up an upstream, your 3rd party dependencies are also scanned for vulnerabilities.

Cloudsmith supports over 28 different types of packages. Uploading a package/binary/image to a Cloudsmith repository is simple:

• Upload via the package-specific native CLI / tools e.g. using Maven's mvn deploy, Node's npm publish, .NET's nuget push or Ruby's gem push.
• Upload via the API using tools/integrations (such as the official Cloudsmith CLI).
• Upload directly via the website.

To upload a package via the Cloudsmith CLI, use the cloudsmith push command:

cloudsmith push <format> OWNER/REPOSITORY <package_file>

Set up a webhook for scan results

Setting up webhooks so Cloudsmith can send automated messages to alert another system when a package had been scanned is great for setting up vulnerability workflows.

Set up a webhook for vulnerability scanning by clicking Webhooks in your repository and then create a new webhook. Then:

• Select the Create Webhook button.
• Populate the Target Endpoint URL with the tool you want to receive your webhook like Jenkins, Zapier, CircleCI, Github Actions or BuildKite.
• Selecting the Package Security Scan Completed checkbox
• You can test out the Webhook by selecting to Ping (test) this webhook.

Quarantine the package for scans with vulnerabilities

The webhook is triggered when the scan is finished and will have a payload in the HTTP req with information about the package and any vulnerabilities, including:

"slug_perm":"IB6FYhIvaoAy",
"max_severity":"Medium",
"num_vulnerabilities":140,"
"vulnerability_scan_results_url":"https://api-prd.cloudsmith.io/v1/vulnerabilities/demo/examples-repo/IB6FYhIvaoAy/"

This information can drive actions such as quarantining your Cloudsmith package based on the maximum severity reported.

To quarantine a package using the Cloudsmith CLI, use the command cloudsmith quarantine add as follows:

cloudsmith quarantine add OWNER/REPOSITORY/SPACKAGE

For example, using the data from the snippet above where IB6FYhIvaoAy is the package identifier or the package slug:

cloudsmith quarantine add demo/examples-repo/IB6FYhIvaoAy

Schedule a rescan

Many vulnerabilities are discovered after you build your software.
To find new vulnerabilities in previously clean packages, Cloudsmith allows you to trigger rescans on demand via the API/UI.

To schedule a rescan via the API, use the following:

curl --request POST \
     --url https://api.cloudsmith.io/v1/packages/owner/repo/identifier/scan/ \
     --header 'accept: */*'

Work to be done

Tools to support standards connected to vulnerability management and supply chain security, like Vulnerability-Exploitability eXchange (VEX) and Software Bill of Materials (SBOMs), are in the early stages.

Cloudsmith already integrates with sigstore tooling to support hosting SBOMs, but we are looking at ways to integrate our security scanner with our SBOM offering.

An integration with the new VEX standard would help our users remove noise and prioritize exploitable vulnerabilities.

Cloudsmith wants to embolden our users to be early adopters of these emerging standards with features that can easily be integrated into their existing build pipelines.

Conclusion

Finding and fixing vulnerabilities is becoming more of a priority for software teams as supply chain attacks are on the rise.

Cloudsmith's security scanning gives teams a way to find vulnerabilities as soon as packages are uploaded, and workflows to automatically quarantine vulnerable packages give developers an opportunity to fix them before they make an impact.

Liked this article? Don\'t be selfish (:-), share with others:   Tweet