By submitting this form, you agree to our 

Security scanning provides an opportunity to target, track, and trace vulnerabilities introduced to your packages as soon as Cloudsmith has received a complete package upload. However what happens when you want to intercept the results of a scan immediately. An early warning can make a difference when distributing vulnerable packages to hundreds, thousands, or even millions of developers, devices, or systems globally.

Previously you could have rolled a custom solution using our API and polled it across your entire organization, dozens of repositories, and numerous packages; however, you don't even need to put in that kind of effort!

This is where vulnerability webhooks come to the rescue!

Anytime a scan is completed, Cloudsmith will dispatch a corresponding vulnerability webhook to your source. A webhook event will identify a scanned package and a summary of the vulnerabilities found within the package. As a sanity check, this helps determine which completed images have vulnerabilities and the severity of those vulnerabilities.

If you are unfamiliar with everything that webhooks are useful for, check out our earlier post on 

Repository Webhooks: Notifications for DevOps

Good news, everybody! If you already have a webhook set up and you are using "

" for your Event Subscription, you are already receiving "

" events when a security scan completes. Simples! However, if you are using an event subscription with selected individual events, it's simple to add the "

". Once updated, your webhook will start receiving these events.

If you have never set up a webhook, you can check our comprehensive 

 on how to create, configure, and test a webhook.

Once configured, you can upload a new package that supports security scanning or rerun an existing security scan using "On-Demand Scanning", and when it completes the following event will be sent to your configured endpoint:

amd64

cloudsmith-docker-cli-example

It's that simple to configure and get started with Vulnerability webhooks. Create a 

Dan McKinney

Solutions Engineer

Intercept Security Scans with Vulnerability Webhooks

Cloudsmith provides a way for vendors to sell, license and distribute software as packages. To any customer, anywhere in the world, across a reliable and performant infrastructure, and handling all licensing and invoicing / billing challenges.

As most of the readership of this blog will know, a huge proportion of the software developed around the world is dependent upon the third-party packages and libraries we integrate into our projects.

And whilst a lot of that will be open-source, a surprisingly large amount will be distributed on a commercial basis. Plenty of organizations generate revenue by selling packages and libraries, almost always on a business-to-business (B2B) basis, to clients looking to speed up their own development processes and deliver better software, faster.

Just by way of example, consider the following common use cases:

The creator of fonts, icons or other similar libraries that may be integrated into web projects

Creators and/or distributors of core network libraries

Hardware companies needing to distribute drivers to customers

These organizations have a challenge. They need to sell and distribute the packages they create to customers all over the world, and they need to do so in a way that:

Is easy and inexpensive to support for themselves, and

The rest of this short piece will take a look at why that has been a challenge in the past, and how new approaches mean that distributing software packages on a commercial basis is now a piece of cake (clue: it involves Cloudsmith).

Commercial Package Distribution: A Short History Lesson

For the sake of everyone’s sanity let’s not talk about prehistory: when software was shared on floppy discs, compact discs and other physical media. Instead, let us save a little time and jump ahead to the digital days.

Until pretty recently the standard way to distribute any form of software, or resources that a software developer might use, has been to 

put it up on an FTP server and allow customers to download them from there

There’s only three problems with that. Unfortunately, between them they make the whole process painful for all concerned:

First, ‘dumb’ downloads are hard to integrate. Customers have to extract what they’ve bought and figure out how to get it into their own environment and tooling. That can require plenty of work, and things go wrong, which means calls to support and time and effort on all sides wasted.

Second, it leaves licensing and access control entirely in the hands of the vendor, which is a challenge. It requires figuring out the easiest way to give customers access to the packages they are entitled to (and only those packages), and for the amount of time they are entitled to them.

Last (and most certainly not least) it doesn’t support modern continuous integration and deployment processes that want to access up-to-date packages on demand rather than download once and use from an on-premises repository.

Faced with these challenges, many B2B software vendors took a new approach: 

distribute software and libraries as ‘packages’ from package repositories.

The good news: this involves sharing content, libraries etc as software packages in the specific package format that allows for easy, effectively automated integration into the developer environment.

So for example, if I am a frontend developer working in Javascript, an npm package ‘speaks my language’, integrates directly into my environment and tooling.

Even better, I can connect to package repositories in this way and access them on demand. In other words, whenever a person or process needs them, they can connect and integrate - rather than downloading once and then being responsible for maintaining and updating hundreds or even thousands of packages, dependencies and libraries on-site.

The problem with this approach, however, was equally simple.

 It requires the vendor building and setting up a private repository and sharing access to that repository with clients all over the world.

Modern development processes demand high levels of availability and performance, so that isn’t a trivial undertaking. It leads to significant amounts of resources just being put into managing and maintaining that infrastructure, resources that were hired to build software.

Oh, and you still have to handle all the complexities around licensing and managing granular access to specific packages and assets.

There is another way: let someone else handle the distribution and licensing of commercial software packages and libraries.

What would that service look like? Well, it has to solve the problems we’ve outlined above, so a checklist would look something like this:

Take responsibility for availability and scalability, or in other words ensure that packages are there when clients need them, and that the service scales to meet new requirements automatically.

Deliver high performance - to customers anywhere on the planet. As many packages are integrated into build processes directly from the repository, it is absolutely essential that this happens fast. And in an age of distributed teams and processes, 

not fast in one place, but fast in any place

Handle licensing and access controls. Whilst the repository is effectively private, the service will need to allow customers read-only access to the right packages and confirm license agreements without too much fuss.

Enable the vendor to share packages in multiple languages and formats as required by customers.

That, in four brief points, is what we have built at Cloudsmith to support vendors.

Cloudsmith is ultimately a platform supporting cloud-native, universal and secure public and private repositories. Of course we work with dozens of developer orgs who simply need a single source of truth for the software assets they use every day, and also need to share those assets across distributed teams.

But we also work with vendors sharing assets to clients outside their own organization.

For vendors, using Cloudsmith has a number of advantages, that largely correspond to the benefits of the approach already detailed above:

We already have in place a fast, reliable, content delivery infrastructure that is used to meet any challenge (so far!), and trusted by thousands of businesses all over the world.

We pay particularly close attention to performance. Again, as a tool used by distributed teams and processes: 

. To that end we have production instances in multiple locations around the globe and support configurable edge caching to ensure that a cloud-native distribution network means zero compromise when compared with storing packages on-premises.

We ensure that all needs around licensing and access control are met in an intuitive way for both customer and vendor. Cloudsmith supports entitlement tokens that deliver access to specific packages across specific time periods, for specific numbers of downloads or clients, all generated and shared automatically via the Cloudsmith API. And we give 

 to our clients. Their customers don’t have to become Cloudsmith customers just to access packages!

Lastly, Cloudsmith is universal. It doesn’t matter what you need to distribute in what format, we can almost certainly handle it. So there’s never any need to maintain more than one distribution network.

That isn’t everything of course. We are always working to ensure that our service gets faster, smarter, and more fully-featured. To give a few recent examples:

We provide comprehensive analytics that show who has downloaded what and when, and macro trends in terms of which packages are proving popular (or unpopular).

We integrate with Zapier to support no-code integration with leading payment platforms, automating order processing of assets stored on Cloudsmith.

We support custom domains. From your customer’s perspective, they are always dealing with your business, and connecting to a repository branded in your name.

If you’re a vendor struggling with some of the challenges discussed in this piece, we’d love to talk. We’re pretty sure we can help you!

Managing Commercial Package Distribution: A Better Way


With the introduction of the Package Activity API and accompanying CLI command, you can now quickly and easily check your entire repository for packages' activity status or even take a detailed approach and view packages individually (per day/per package).

You can save on your storage costs by eliminating inactive packages and retaining only the packages you or your users derive value from storing and distributing via Cloudsmith.

The excellent news is that once you identify those inactive packages, you can make use of Automated retention/lifetime rules (available on the Velocity plan and above). These rules allow you to automatically manage storage for packages by deleting or moving packages that fall outside of the defined retention rules.

Assets can be expired based on the number of packages (count), size of packages (bytes), or by the number of days (time); however, to first create these rules, you first need to understand how your users are interacting with your existing packages. However, understanding when to delete the packages was challenging, until now!

Every package has an aggregated count of the number of total downloads for a given package calculated daily. A package is considered active when there have been downloads for that package for a given range. If there are no downloads during a specified period, then it's deemed to be inactive.

The easiest way to get started exploring these metrics is to check out the metrics command within the Cloudsmith CLI. Alternatively, to get more fine-grained metrics, you can implement a programmatic solution using our API or one of the API binding libraries published in various languages.

For example, to check if a package has ever been "active" and received downloads, you can request the "packages" metric for an entire repository and use the --inactive=true flag to display a list of inactive packages to identify candidates that will help you create a retention rule to automate the removal in future.

Using the Cloudsmith CLI you can quickly and easily query the total number of active/inactive packages for your repository by running the following command with your organisation/repository.

If you want to specify a specific package, you can also supply one or more packages as a comma separated string.

cloudsmith metrics packages cloudsmith/example --packages=ZGCV58VqT8Sl

Querying between a range is easy using ISO 8601 formatted datetimes. Supplying a start and finish helps drilling down to answer specific questions like:

Has package activity increase or decreased since last month?

Has the number of inactive packages increased since last year?

How many active packages has been added this week?

cloudsmith metrics packages cloudsmith/example --start=2019-01-01T00:00:00Z --finish=2019-12-31T00:00:00Z

Although the summary overview provides a general feel for the increase/decrease of inactive/active packages, it can be useful to drill down into what those packages are by using the 

 flags to identify what's been added or what can potentially be removed.

cloudsmith metrics packages cloudsmith/example --active-packages=true

The package slug has been omitted from these screenshots but when running the command you can use the slug to identify the package uniquely.

cloudsmith metrics packages cloudsmith/example --inactive-packages=true

Manage costs with Cloudsmith's usage APIs

IoT is slowly, quietly taking over the world. A few years ago, self-ordering fridges, driverless cars, and fully automated homes seemed like the stuff of dreams. And while the technology exists, rollout and adoption is slower than anticipated, amidst security and privacy concerns. That said, IoT is the future, and growth is steady, as the challenges of building and maintaining hundreds of thousands of devices per vendor are getting solved.

Today, there are billions of devices online; with an ultra-wide and global dispersal pattern from the factories that built them. Each device runs firmware, or more commonly a light-weight embedded OS and software written in performant languages like C++ or Rust or more accessible languages like Java or Python.

A company building the latest smart TV, or Fridge, or Japanese-style automated toilet needs to ship their device, fully loaded with working software to control the device, connect to the internet to provide analytics back to HQ and get new versioned updates to introduce new features - or most importantly, to receive security patches.

Cloudsmith provides a distribution toolkit for IoT that helps to solve the issues with global rollout at scale.

If you need fast, reliable deployment infrastructure; look no further. Cloudsmith provides accelerated edge delivery of software to allow you to stay close to the sea of devices you want to manage. And what’s more, the caching of your packages and artifacts at the edge is configurable, because there is no one-size-fits-all solution. Your needs are bespoke, and Cloudsmith gives you the control to define a best-fit solution for your own needs.

Cloudsmith enables you to automate the rollout of software using a unique token to manage repository access for each device. Entitlement tokens are read-only access tokens for a Cloudsmith Repository and they can be created to nearly any secure standard.

You can attach metadata; allowing you to store additional information for the device. You can add restrictions to the token; such as a validity period, a specific allowable device IP address or a maximum number of downloads. Each token can be individually managed and filtered to provide tight control of your IP. All of which is accessible via the Cloudsmith first-class API.

Track and monitor which devices have received the latest update. You can attribute each download from Cloudsmith to the specific Entitlement Token used, and you can see when and from where it was used. You can also export this data for further ingest into your own big data or analytics platform of choice, giving you an unparalleled view over the status of your IoT fleet and their package/updates status.

Cloudsmith repositories are fully multi-tenant for package formats. This means you can store all of the package types that we support in one repository, and this repository still works as a native repo with all of the client-side tooling for each format. No more managing multiple repositories if your IoT devices need 

 and even more. Simplify your package management, and gain more control.

Cloudsmith provides a “low-gravity” launchpad for IoT software updates at scale. Let us worry about performance, delivery and scalability while you concentrate on building secure software your customers will love.

The Internet of Things - Why Cloudsmith Plays a Crucial Role

You must secure your software supply chain. Now, more than ever, it is vital.

For a long time, a primary concern in security was malicious actors exploiting inherent weaknesses in software. Privilege escalations, SQL injections, race conditions etc. These are, of course, still a concern and should be afforded the attention that they deserve. But now, there is another worry, one that is arguably even more important – A Supply Chain Attack.

Rather than discover an existing flaw in a piece of software, a supply chain attack is designed to allow a malicious actor to target a specific piece of software, and insert a weakness of their choosing during the build process.

One recent example was the SolarWinds breach, where a build process itself (or rather, a build host) was compromised and was modified to insert malicious source code into a build of one of SolarWinds most popular products. This product was then distributed to SolarWinds customers, and as it came direct from the vendor none of the customers was aware they were running a vulnerable build of the product.

That’s scary enough, but it did involve the penetration of an internal network and the build host first (using various existing exploits), in order to achieve the malicious actor’s goal of inserting their malware into a SolarWinds product. But now, another approach has been demonstrated that can achieve the same outcome, with a lot less effort.

, Alex Birsan, that over 35 major companies were found to be vulnerable to the injection of malicious packages, via public sources, into their software supply chains.

It’s been dubbed the Dependency Confusion Attack or Package Namesquatting Attack, and the exploit process goes like this:

Identify the names of private internal packages used in software builds – primarily through leaked information in javascript files and other packages.

Upload a malicious package with the same name as one of these private internal packages to one of the public repositories. Note: Anyone can upload and there is very little or no checks performed.

Wait for a build process or individual developer at a victim organization to try to pull the private internal package, alongside public packages that the build or developer relies upon.

The malicious package gets pulled from the public upstream instead of the private internal package.

By the time it’s been pulled, and an attempt made to install the package, remote code execution has been achieved thanks to things like package pre-install scripts. And in an automated CI environment, where there is likely no one actively monitoring builds, this failure could go unnoticed for a while.

Let’s also consider for a moment that the malicious package implements the functionality from the original package as well as its own malicious code. Given that there have been major leaks of internal source code in the past, it’s not impossible that a malicious package could do this. In this case, the build using this malicious package would succeed. This then results in something akin to the SolarWinds breach, with a product or package now compromised - except it wasn’t necessary to penetrate a network or attack a build host or other infrastructure to achieve the same outcome.

So, how do you defend against this type of attack?

One way to mitigate this attack is simply to not make use of any public upstreams at all and to manually verify all packages that are used, but given the large number of open-source public packages that most modern software relies upon (and increasingly so as we move forward) - this is a difficult task, and certainly, one that will not scale.

But, using a package management service like Cloudsmith, another approach could look like this:

Two private repositories - one “unsafe” with upstream proxying and caching from a public repository enabled, and the other one “vetted” with public upstreams proxying/caching disabled.

Packages are pulled from upstreams into the “unsafe” repo, automation uses a private repository management API to pull package checksums and signatures, and run vulnerability scans.

If all checks are clear, and nothing untoward is discovered, the packages can then be promoted to the “vetted” repo, ready for use by development teams and build / deployment processes.

Importantly, internal build processes and developers never connect directly to a public upstream – this is the most likely attack vector, and it offers an almost unlimited attack surface. By pulling packages into a private repository, scanning/checking and then promoting based on the results, you have taken back control. Control over your software supply chain, control of the “single source of truth” for all your packages and dependencies.

You’ve closed the door. And cut off the previously exposed entry point into your supply chain.

Supply chain attacks are here, and they are here to stay. In addition, npm and PyPi (for example) are 

 security PoC packages that are being used to test for this vulnerability, so external testing for this is becoming increasingly difficult. The answer is to take back control. Control covers a lot of things, but in essence:

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

Isolate from third parties. Control the single source of truth.

Restrict publishers. Be a curator, not just a consumer.

Pin dependencies. Prefer repeatable builds.

Dependency Confusion Attacks

At Cloudsmith, you will often hear us refer to our mantra of “Automate Everything”. It's a quest that we never deviate from, and we believe that anything that can be automated, should be automated.

With that in mind, we would like to show you how simple it is to integrate a Cloudsmith repository with your Buildkite pipeline, and automate the pushing of your build artifacts into your own private repository for further CI/CD steps or even as a source for your global distribution needs.

Buildkite is a platform for running fast, secure, and scalable continuous integration pipelines on your own infrastructure. That means you can use Buildkite to orchestrate and manage your own fleet of build hosts, and these can be anything from containers, to cloud instances, to bare metal servers.

Why would I want to integrate Cloudsmith with Buildkite?

Well, in short, a continuous integration pipeline is going to have an output, and you are going to need and want to put that output somewhere that is secure, controlled and integrates with all the other tooling that will form the next parts of your DevOps workflow - whether that is continuous deployment to production, distribution to an end user or customer, or even consumption by another internal team as part of their development process.

This is where Cloudsmith fits in, and this is another phrase you might hear us use quite a bit - Cloudsmith offers a central source of truth for your packages and build artifacts. We provide a global platform that gives you the performance, scalability, security and visibility that you need to control and manage your software assets.

Using Buildkite and Cloudsmith – An Example:

So, you’re let’s assume that you’re new to Buildkite, how do you get started?

The first thing that you need to do is install the buildkite-agent so that you have a machine (remember, this can be a container, a VM, or even a real server) that will act as your build host. Buildkite provides install instructions for all major platforms and operating systems:

Once you have installed the agent, you will see a new build host in the Buildkite UI:

For this example, I have installed the buildkite-agent on a Debian instance.

The next thing you need to do is create your pipeline. A Buildkite pipeline is a series of steps that your build host(s) will execute in order to build your assets/artifacts. For this example, we will create a pipeline that will compile a simple C source program, package it into a deb package and then push that deb package to a Cloudsmith repository.

To get started, you give your pipeline a name, and then you specify a source repository for the pipeline. In this case, it is a GitHub repository (although Buildkite will also work with many other platforms as a source):

If using a private GitHub repository, you also need to remember to add an SSH key to your GitHub profile so that the host you have installed the buildkite-agent on can access the source repository.

Pipeline steps are where you specify the commands or scripts that you need to run in order to build your source / project / application. In Buildkite, you can define these steps via the Buildkite UI or as a pipeline.yaml file. To keep things simple, we will define two steps via the Buildkite UI.

In this step, we install the tools we need to build our source and package it into a deb package. We also install the Cloudsmith CLI:

In this step, we use `make` to compile our source and then we use `fpm` to build the deb package. Finally, we use the `cloudsmith push` command to push the package to our Cloudsmith repository:

The equivalent pipeline.yaml file for these steps would look like:

For more complex build pipelines, you’ll likely have a lot more steps and the advantage of using a pipeline.yaml file is that you can version it and check it in right alongside your source.

One thing to note is that pipeline steps in Buildkite are stateless. As a result, if you have a fleet of agents then each step is not guaranteed to run on the same agent. This means that if a subsequent step need / relies on the output from a previous step, the output from one step will need to be stored and then retrieved. Buildkite provides temporary artifact storage that you can use for this purpose (see 

 for more details), but to keep things simple in this example we performed the build and push in a single step.

We want this pipeline to start when we push a new commit of our source to our GitHub repository and for that, we can configure a GitHub Webhook. Conveniently, Buildkite provide a webhook URL that we just need to copy and paste into our GitHub webhook configuration, and then select the event type we wish to fire this webhook on (in this case, all pushes):

That’s it, our pipeline is now built and will be ready to run.

Buildkite supports several types of hooks that can run on a build host during a pipeline run and a final piece of configuration that we need to do is use an environment hook to configure our environment.

As we are using the Cloudsmith CLI to push the package to our Cloudsmith repository, we need to set up our Cloudsmith API Key as an environment variable. We do this because we don’t want to store a sensitive secret like an API-Key in our pipeline source, or within a build step as a plain text environment variable where it could be exposed in logs. There are other alternative methods of managing secrets in Buildkite, see 

Sets the CLOUDSMITH_API_KEY environment variable

Adds the location that the Cloudsmith CLI is installed to our PATH

Additionally, it only runs when executed by a pipeline with the name “cloudsmith-buildkite-demo”

OK, at this stage our pipeline is built and ready, and the environment on our build host will be set up when the pipeline executes. It’s time to test it out.

Step 4 – Push a change to our source repository.

Now if we make a change our source, commit it and then push the change to our GitHub repository, our build will start:

And once the BuildAndPushPackage step has completed, we can view the output in the logs:

We can see that our deb package was successfully built and pushed to our Cloudsmith repository.

If we now go to the repository on the Cloudsmith website, we can see the built package:

Buildkite is a very powerful and flexible CI management platform, and integrating your Cloudsmith repositories with your Buildkite pipelines is as simple as installing the Cloudsmith CLI and then using the Cloudsmith push command in your build steps. We would really encourage you to give it a go yourself, our trial is fully-featured and we are here to help you get started. No question is too big or too small.

Integrating a Cloudsmith Repository and a Buildkite pipeline

At Cloudsmith, helping fledgling startups grow from a single person operation to enterprise-level organisations is a constant joy! In those early stages, startups need all the help they can get to survive, and even veteran organisations experience similar challenges when scaling up rapidly.

Cloudsmith can help with our self-service approach to managing and defining storage and bandwidth limits to keep costs under control while allowing you to scale when needed. After all, no one wants to be caught between an unexpected bill for overages or any interruption to their business, no matter how minor.

The fantastic news is that now you have a new tool in your arsenal, as you can track your bandwidth and storage programmatically via the Quota API. It's easy to miss an email when your busy or a prompt within the Cloudsmith UI (if you haven't needed to log in recently); but you will always want to know if you're near/over a limit or even if you're over-provisioned.

Now you can automate a solution that works for you using either our API or CLI to always stay on top of your storage and bandwidth limits.

Using the Cloudsmith CLI, you can quickly and easily view the usage, limits, and maximum allocation of bandwidth and storage for your plan.

cloudsmith quota limits your-organisation

Alternatively, if you want to view the entire history for your organisation:

Finally, to view the OSS usage for an organisation, you can add the 

 flag to any command to view only OSS limits and history.

If you identify a limit that is over-provisioned or quickly approaching a threshold, then you can quickly and easily adjust your limits at anytime within the Cloudsmith UI.

Additionally, if you wish to automate a solution, you can also check out the 

 or the Cloudsmith API Bindings (available in multiple languages) and connect it to your favourite CI/CD or monitoring service to alert internally within your organisation.

Track your Bandwidth & Storage limits with our Quota API

Webhooks, so what are they good for? Well, quite a lot as it turns out! Webhooks are great for integrating Cloudsmith with other systems that you use, by sending data or notifications to other tools in your stack and helping to enable automation across your workflows.

I know what you’re thinking, this sounds a lot like an API right? Well, not quite. Webhooks are almost like a sibling of an API call. So, what’s the real difference?

A webhook is what you would use to notify another system (i.e, not the same system that performed the API Call) that such an event had taken place.

When you make an API call to retrieve some information or perform an action, the API will typically check that you are authorised and then if so, perform the action or return the information you requested. A webhook, on the other hand, is a message that is pushed in response to a change or an event on a system.

So, if you used the Cloudsmith API to upload a package, if you were authenticated you’d then get a response from the API confirming your action was successful.

Cloudsmith webhooks can trigger on events that occur for packages in a repository, so for example, when a package has been uploaded, is synchronizing, has synchronised or has failed.

Here are some great examples on what you can do with webhooks to help automate different workflows.

You could use a webhook to notify your CI/CD pipeline when a new package has arrived at a Cloudsmith repository. So, for example, if you had a repository that you used for packages destined for a production environment, you could combine a webhook with repository access controls to control who was able to promote packages to production, and then use the webhook to automate the deployment process itself.

You can use a webhook to push a notification to a chat application such as Slack or Microsoft teams when any of the supported events occur. You can customise the message to include details about the package or provide a link to it. In this way you and your teams can stay fully notified about activity on your Cloudsmith repositories without having to manually log in and check.

You can use a webhook to push notifications to your monitoring and alerting platforms. You could, for example, then get notified and alerted if a specific package was deleted, and trigger further automated processes in response to your monitoring. In this way, your monitoring platform is “aware” of activity on your Cloudsmith repository, and can take action.

distribute your packages to your own customers

, you could create a webhook that notifies your mail system or CRM system that a new package has been uploaded to your repository. You can then automate the process of informing your customers that a new or updated package is available for them to download.

But really, all this is just scratching the surface. If a component of your stack is capable of receiving HTTP POST requests and can handle a JSON or Handlebars template payload, then you can receive and process a webhook. A lot of platforms offer out-of-the-box functionality for accepting incoming webhooks, but even if yours doesn’t, you can be confident that you can put something together quickly in most cases.

For more information, including details of the webhook payloads and a worked example, see our 

We've also written up another handy guide on 

how to configure Webhooks with Cloudsmith

And if you make something awesome that you’d love to show off, please do let us know – we just love to see what our users can create with Cloudsmith.

Level up your DevOps, expand your integrations, and have fun building great processes with our webhooks.

Lock your sights on the black box hiding untold vulnerabilities in your repository and shine a light inside to find out what monster's lurk within. Yes, I'm talking about running on-demand security scans against supported packages within your repository. If you are a velocity or ultra customer, you can start making use of security scanning today!

Not only can you run security scans, but you can track which packages are vulnerable across your repository, alongside trace when vulnerabilities were introduced by looking up the vulnerability scan results for a specific package version via our API.

With Cloudsmith's security scanning, you can uncover packages that have become vulnerable over time. The version's that introduced insecurities are visible within our repository view and our new security scanning insights view, leaving those pesky vulnerabilities nowhere left to hide!

All newly uploaded packages and images get scanned for vulnerabilities as soon as they reach Cloudsmith; however, if for any reason you wish to rerun a security scan, you can do so at any time. Don't worry; we still keep all historic security scan results to track and trace when vulnerabilities get discovered, and they are always accessible via our API should you need them.

You can run security scans daily, weekly, monthly, or using the best cadence for you and your organization. Our daily updated vulnerabilities database is updated 365 days a year, allowing you to scan every image up to a maximum of once a day, every day, to combat emerging threats.

Cloudsmith Blog

Intercept Security Scans with Vulnerability Webhooks

Managing Commercial Package Distribution: A Better Way

Manage costs with Cloudsmith's usage APIs

The Internet of Things - Why Cloudsmith Plays a Crucial Role

Dependency Confusion Attacks

Integrating a Cloudsmith Repository and a Buildkite pipeline

Track your Bandwidth & Storage limits with our Quota API

Repository Webhooks: Notifications for DevOps

Target, Track and Trace your Vulnerabilities

Multi Format Repositories

Using Puppet to deploy packages from Cloudsmith

Modern Tech Stacks need Multi-Format Repositories