Adoption of the EU Cyber Resilience Act is coming in 2024. This means that if you make software or hardware that’s sold in the EU and don’t fall within one of Act’s four product exemption categories, you’ll soon be legally required to comply with the Act’s requirements or risk penalties.

If you’re not using a modern package management system as part of your CI/CD process, you may find it harder and more time-consuming than others to meet the compliance requirements—particularly the requirements to minimize vulnerabilities and be transparent with consumers about the cybersecurity aspects of your products. (Read our post 

How To Comply With the EU Cyber Resilience Act

 for full details on compliance requirements.)

For instance, dated, legacy systems often:

offer limited visibility, which could make it challenging to identify and address vulnerabilities in the timeframes required by the CRA;

may not include automatic scanning tools for identifying vulnerabilities in dependencies, leaving teams to handle this manually—which is a time drain and introduces human error;

can struggle to manage track, and analyze the complex dependencies that are characteristic of modern software development; and

lack robust logging, audits, and reporting, making it harder and more time-consuming to assess, prioritize, and respond to software security issues.

In contrast, modern cloud-native artifact management systems, like 

, are built by design to secure software development across the entire software lifecycle—from pull-down to distribution—streamlining your team’s CRA compliance efforts through the benefit of:

Specifically, we can help you achieve the standards set out by the new CRA with our 

We’ll continue to create features in Cloudsmith that support our customers as the Regulation’s requirements evolve.

Want to know more about how Cloudsmith can support your CRA compliance efforts? Start your free trial now or talk to sales today.

Ciara Carey

Solutions Engineer

Simplify CRA Compliance With Modern Tooling

This week, the European Union (EU) reached an agreement on the 

Set for adoption in 2024, the CRA aims to protect consumers from insecure digital products, introducing mandatory cybersecurity measures such as vulnerability disclosure, Software Bill of Materials (SBOMs), and security updates throughout the product life cycle.

The CRA covers a wide range of digital products, from operating systems to baby monitors. Companies affected by this Act have 36 months to comply, facing penalties of up to €15 million or 2.5% of global turnover for non-compliance.

While most digital products may self-regulate, some, like Firewalls, Operating Systems, or Smart Meters, face more stringent cybersecurity requirements.

Despite the welcome, the CRA sparked concerns, especially in the Open Source Software (OSS) community, fearing inadequate exemptions and burdensome vulnerability reporting. The final version addressed some worries by extending exemptions to non-profit OSS organizations. Additional criticisms focus on potential disadvantages for EU businesses and uncertainties regarding auditing and funding.

The CRA introduces the following requirements for digital products sold in the EU:

Manufacturers must provide consumers with timely security updates for several years after purchase. The support period is designed to align with the expected lifespan of the products.

Manufacturers must disclose and patch vulnerabilities promptly and without charge. Manufacturers that discover a vulnerability in an OSS dependency will be required to notify the maintainer.

Manufacturers must report actively exploited vulnerabilities within 24 hours to both the competent Computer Security Incident Response Team (CSIRT) and The European Union Agency for Cybersecurity (ENISA) through a unified reporting platform. There are some narrow conditions where ENISA does not need to be informed, but they must receive adequate information to monitor systemic risks.

Manufacturers must include a SBOM in a common format, detailing at least top-level dependencies. Manufacturers must provide the SBOM to both ENISA and market surveillance authorities.

Member States will designate market surveillance authorities to enforce the EU Cyber Resilience Act. If a product is non-compliant, these authorities can:

Manufacturers can face fines of up to €15 million or 2.5% of their total worldwide annual turnover for non-compliance with essential cybersecurity requirements under the Cyber Resilience Act. For other obligations, fines can reach €10 million or 2% of the total annual turnover.

Products meeting the CRA’s essential requirements will receive the 

, signifying compliance with the Act's cybersecurity standards.

This marking is necessary to place your product on the market within the European Union.

The Regulation applies “all products with digital elements whose intended and reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.”
That’s a lot of products!

Most products are likely to self-regulate and apply the CE mark. However, the CRA specifies two categories of ‘critical products’ that are subject to more stringent requirements due to their higher perceived risk. These are divided into class I and class II, with class II products representing a greater risk. Manufacturers of class II products must involve a third party in their compliance assessment process.

These products are vital to the functioning of critical services and entities. Examples of Class I products include:

firewalls, intrusion detection/prevention systems;

industrial automation and control systems (IACS);

security information and event management (SIEM) systems; and

Class II are considered by the CRA to have a somewhat higher level of criticality compared to Class I. Examples of Class II products include:

operating systems for servers, desktops, and mobile devices;

hypervisors and container runtime systems;

public key infrastructure and digital certificate issuers;

secure elements, hardware security modules (HSMs);

smartcards, smartcard readers, and tokens;

robot sensing and actuator components; and

Not every digital product must comply with the new Regulation. Here are the exceptions.

The EU Cyber Resilience Act does not apply to Software-as-a-Service (SaaS) products.

Earlier drafts of the Act had an exemption for OSS individuals, but there was a gray area. It was unclear whether OSS organizations and contributions that could be deemed commercial would be exempt.

The final draft of the CRA now exempts free and open-source software developed or supplied without commercial intent. Notably, non-profit organizations selling OSS but reinvesting revenues in non-profit activities are also excluded. This exclusion protects the open-source community from unnecessary regulatory burdens.

The proposed Regulation won't cover products with digital elements already regulated by specific laws, such as:

medical devices (Regulation EU 2017/745 and EU 2017/746)

products certified under aviation safety (Regulation 2018/1139)

motor vehicle products (Regulation EU 2019/2144).

Products developed or modified exclusively for national security or defense purposes are excluded from the scope of the regulation.

The EU Cyber Resilience Act represents a significant stride in strengthening digital security across the EU.

By setting clear standards for cybersecurity, the EU aims to empower consumers, build trust in digital products, and establish itself as a global leader in cyber resilience.

Will the CRA get the balance right between security and innovation? Will it suppress the use of OSS? Will it be overly burdensome for businesses, especially SMEs? Only when the Act is being implemented will we see the true impact on cybersecurity, innovation, and the broader digital landscape.

Simplify CRA compliance with the help of modern tooling

How to comply with the EU Cyber Resilience Act

? The act is an EU regulation that aims to tackle low cyber security levels and make it easier for consumers to identify and choose secure digital products. First announced in the 2020 EU Cybersecurity Strategy, it’s the cyber security equivalent of GDPR and complements other cyber security legislation, like the NIS2 Directive.

The Act (also referred to as the CRA) applies to the vast majority of digital products sold in the EU—from operating systems to baby monitors—and when it comes into force in 2024, affected companies will have 36 months to adapt to the new requirements and become compliant.

At the minute, many digital products lack robust security measures and it’s often impossible for ordinary consumers to assess the security of those products. The CRA addresses this by introducing:

mandatory cyber security requirements for hardware and software products; and

 on products to signify they’re compliant.

Requirements include vulnerability handling, security updates, 

, and reporting actively exploited vulnerabilities within 24 hours of becoming aware of them. By mandating these measures throughout the product lifecycle, the Act aims to:

 Products entering the EU market must not have significant vulnerabilities that can be hacked.

 Manufacturers must provide clear and transparent information to consumers on the cyber security of their products. This includes secure default configurations, protection mechanisms against unauthorized access, and encryption of sensitive data.

 A key aspect of the CRA is the legal requirement for manufacturers to provide security updates for a defined period after purchase, reflecting the expected product lifespan.

The majority of digital products are likely to be self-regulated, but some products—like firewalls, SIEMs, operating systems, and smart meters—are held to more stringent cyber security requirements, including a third-party audit.

The open-source community has raised concerns about the Act, fearing its vulnerability reporting burdens. However, its final version does extend exemptions to non-profit OSS organizations. Other criticisms include potential disadvantages for EU businesses and uncertainties surrounding auditing and funding.

Will your product be affected by the CRA? If so, find out 

how to comply with the EU Cyber Resilience Act

Need to get a jump on CRA? Find out how to 

simplify CRA compliance with the help of modern tooling

What is the EU Cyber Resilience Act?

This week, we announced that Cloudsmith has taken an impressive $11M in additional funding, hot on the heels of our $15M Series A two years ago. That's not just serious cash for a startup; it's a game-changer! The natural questions are: why did we take it, and what's our big-picture plan?

Here's the why: Cloudsmith isn't just a proven, enterprise-class artifact management platform; we're a market disruptor. We've consistently outperformed and replaced legacy products like JFrog's Artifactory and Sonatype's Nexus, becoming the go-to choice for large organizations with hundreds of developers. We're not just playing in the big leagues; we're setting the pace.

I've seen this movie before. A SaaS upstart challenges a market burdened by outdated, on-premise software. And SaaS inevitably wins out. It's not a matter of if but when. Companies don't switch off systems like JFrog on a whim, but when they realize it's time to refresh, they will look for something authentic, fresh, and modern. That's Cloudsmith.

We're driven by a sense of urgency to ensure Cloudsmith not just competes but dominates these market takeovers. This means offering a comprehensive, unmatched feature set and amplifying our presence with bold sales and marketing. We're not just waiting to be noticed; we're making sure we're the obvious choice, especially for customers upgrading from JFrog or Sonatype.

And here's the plan: we did a leadership exercise to craft a strategy to turbocharge our growth. It's about scaling up significantly in a few critical areas.

A powerhouse engineering team to enhance package format support, innovate, and develop next-gen products and features.

An aggressive marketing campaign to tell developers, DevOps teams, and CISOs why we're the superior choice over JFrog and Sonatype. We're not just part of the conversation; we're leading it.

An expanded customer success organization with tools for seamless migration and integration, reinforcing our commitment to our users and helping them to make the change.

We further cement our global footprint by expanding our tools, teams, and technologies in North America, Europe, and Asia.

Here at Cloudsmith, we've built something extraordinary. Our calling is to simplify the lives of software developers. We're passionate about making our customers' work and lives easier, more productive, and, frankly, more enjoyable with our platform. We're proud of our product; we're revolutionizing software artifact management and distribution.

We're immensely grateful for our investors' faith in us, especially in a challenging VC funding environment. Like our customers, they don't just believe in Cloudsmith; they're betting on our vision to redefine the industry. For everyone who's reading, I invite you to join us on this journey; share your ideas at 

Glenn Weinstein

You Took HOW Much Money?!?

Attacks targeting open source software (OSS) are on the rise, making the security of your software supply chain a top priority. What do you have to do, exactly, to secure your software supply chain?

This is the third blog in a Cloudsmith series about software supply chain security. The first blog gave an overview of the

Secure Supply Chain Consumption Framework (S2C2F)

, which is designed to mitigate against these attacks.

Level 1 of S2C2F is the bare minimum organizations should do to securely consume OSS. Today's blog focuses on the actionable steps and essential tools required to attain Level 1.

Level 1 primarily centers on the ingestion of OSS and requires the following:

Use an artifact repository (like Cloudsmith!) to cache OSS

Maintain an automated OSS inventory, such as a software bill of materials (SBOM)

Scan OSS for known vulnerabilities and licenses

Update your vulnerabilities (manually is okay at this level)

A major step in Level 1 is the adoption of an artifact repository like Cloudsmith as a central location for all OSS packages. This facilitates applying security controls for your OSS, and guarantees the availability of OSS package dependencies and protects you from incidents like the

Let's refresh on the eight principles of S2C2F:

— Consume your OSS from one location controlled by your organization, like Cloudsmith.

 — Create a list of all your OSS dependencies.

 — Update known vulnerabilities in a timely manner.

 — Force developers to adopt secure practices.

 — Audit that developers are consuming through the approved ingest method, and validate the integrity of the OSS that you are consuming.

 — Scan for malware and vulnerabilities using automation where possible.

 — Rebuild OSS on trusted infrastructure.

 — Have the ability to fork and fix code, when necessary, for a temporary fix.

Level 1 of the S2C2F concentrates on the Ingestion, Inventory, Scan and Update principles. The following initiatives are required:

Before you start implementing changes in your organization to align with S2C2F it is advised that you 

 of the organization's degree of maturity in software developer OSS management, security, and consumption processes.

Use a package manager to consume OSS packages. A package manager keeps track of what software is installed on your computer, and allows you to easily install new software, upgrade software to newer versions, or remove software that you previously installed. Scroll to the table below for a list of commonly used languages and their respective package format, registry, etc.

 to host all of your software packages and OSS packages. To set up Cloudsmith to cache your upstream OSS, do the following:

Update your software’s configuration file to point to your artifact repository (see the table below for the settings file for popular languages).

Start hosting your OSS packages on Cloudsmith by 

caching your public repositories or upstreams

. If the upstream repository you depend on goes down or is otherwise unavailable, your team can still access your cached versions stored in Cloudsmith. Cloudsmith will scan all the OSS packages for malware and vulnerabilities and also extract their licenses. This setup empowers our users to apply customized policies for enhanced security and management.

Level 1 of S2C2F requires organizations to maintain an automated inventory of all OSS used in development. There are a number of ways to take an inventory of your OSS

The gold standard for inventorying your OSS is to 

generate a Software Bill of Materials (SBOM)

 at build time. An SBOM is an ingredient list of all the dependencies in your software in a standardized format. SBOMs are needed for more advanced levels of this framework. OSS tools to generate SBOMs that can be integrated into your CI/CD include 

If you cache and proxy all the public registries that your organization uses on Cloudsmith, you can 

search for all packages that originated from an upstream

 via the UI or API by searching for tag:upstream (or even tag:maven-central if that's what you named the upstream when setting it up etc).

You can use your software’s dependency file (e.g. requirements.txt for Python builds) to see what dependencies your software is pulling in. This file may not include your software’s transitive dependencies (your dependencies’ dependencies).

Scan OSS for known vulnerabilities (i.e. CVEs, GitHub Advisories, etc.). Here are a few ways to do this:

Ideally you are integrating scanning tools early in your software development process using free tools like grype or paid tools like snyk.

Cloudsmith scans cached OSS for malware and vulnerabilities

. You can set a policy so that all packages must be above a certain vulnerability level and you can rescan a package for vulnerabilities.

Scan all the OSS in your organization for licenses.

for all cached OSS packages. Cloudsmith’s license policies allow you to define which package licenses are allowed within your organization.

Update vulnerable OSS manually using the results of your scanners, Level 1 S2C2F requires you to update vulnerable OSS manually. The framework advises that every organization should aspire to patch vulnerable OSS packages in under 72 hours. More advanced levels of S2C2F require you to use tools like 

By prioritizing ingestion, inventory management, and scanning, you'll bolster your software supply chain's resilience against potential threats. Leveraging package managers, artifact repositories like Cloudsmith, and automated inventory tools enhances security and guarantees availability when consuming OSS.

What’s next from Cloudsmith? In future blogs, we’ll discuss how you can achieve the advanced S2C2F framework levels, offering actionable steps to further enhance your OSS consumption practices and fortify your software ecosystem. 

Secure Open Source Consumption: Level 1 of S2C2F

Back when I was a C++ developer in the late 2000s, I didn’t use open source. The only external libraries I used were some proprietary libraries and we only released our software about once a quarter.

modern software embraces continuous releases and DevOps practices.

Meanwhile, C++ developers and DevOps Engineers look over the fence at Python, JavaScript and Rust and envy how easy it is for them to consume open source.

To navigate the complexities of versioning, dependency management and to easily consume open source software, a 

, also known as a package manager, is indispensable.

The adoption of package managers in C and C++ projects is on the rise- however, a recent 

 underscores that there is still considerable progress needed before package managers can outpace traditional approaches like copying and pasting code or downloading prebuilt binaries.

How C and C++ projects consume external libraries without a package manager.

The most popular C and C++ package managers- Conan and vcpkg.

Unlike languages such as Python, Java, or JavaScript, the C and C++ ecosystem has operated without the use of a standard package manager as part of its standard library or toolset.

The lack of a standardized package manager results in various methods for consuming external libraries. For instance:

, Developers can consume open source libraries using the ExternalProject_Add or FetchContent commands.

This absence of a standardized package manager in the C++ ecosystem can lead to several challenges and issues:

 Developers often resort to manual tracking of dependencies, which is prone to human error and leads to potential oversights, version conflicts, and security vulnerabilities.

 Managing different versions of libraries and ensuring compatibility across projects becomes a complex, time-consuming, and error-prone task.

 Identifying and addressing security vulnerabilities in dependencies requires manual effort, leaving projects susceptible to risks.

 The lack of a package manager makes it harder to share and reuse code.

: Package managers automate the process of 

, reducing the risk of using outdated or vulnerable components.

: Centralized package management ensures version consistency across projects, mitigating versioning conflicts and enhancing compatibility.

: Many package managers come equipped with tools for automated security auditing, enabling developers to identify and address vulnerabilities proactively.

: Package managers provide a standardized way to share and reproduce development environments, fostering collaboration and streamlining workflows.

In the C++ community, there are presently two front-runners for package management: Conan and vcpkg.

These open source tools feature an active community of contributors and a healthy package registry, simplifying the process of managing, consuming, and distributing C and C++ libraries.

 is an open source project that started in 2016 and aimed to empower C and C++ teams to adopt DevOps practices. Conan is a package manager for C and C++ programming languages that works on all platforms and with all build systems and compilers. You can consume over 1500 packages from the 

 is an open source package manager for C and C++ libraries on Windows, Linux, and macOS. It provides precompiled binaries to simplify the installation of dependencies. You can browse over 2000 packages in 

Both Conan and vcpkg are great additions to add to the developer toolkit for consuming external libraries.

In the world of C and C++ development, using package managers is now essential. Ready to upgrade your workflow? Get your public and 

 hosting at Cloudsmith now, or explore our 

Why Developers Need a C++ Package Manager

Welcome to our 2nd blog in our series on how to securely consume Open Source Software (OSS).

Attacks targeting OSS are on the rise, making the security of your software supply chain a top priority. The 1st blog gave an 

overview of some of the most common types of attacks

 that can help you mitigate against these attacks.

In 2019, Microsoft launched an internal initiative to secure its own development practices around the consumption and management of OSS. They donated the resulting framework, originally called the Open Source Software-Secure Supply Chain (OSS-SSC) framework, in 2022 to the Open Source Security Foundation (OpenSSF). Renamed S2C2F, the framework now has 

S2C2F consists of eight core principles and four maturity levels, providing a comprehensive strategy for organizations to incrementally improve their security posture when consuming OSS.

The framework is not revolutionary: it's a practical guide to knowing what OSS you are using, preventing the consumption of vulnerable packages, and efficient patch management.

By using Cloudsmith, you can get a big head start on implementing S2C2F principles, and improving your team’s S2C2F maturity level. Specifically, you can use Cloudsmith to -

Ensure comprehensive package and container scanning

Create rules for vulnerability mitigation

Automate workflows for a wide variety of package formats, CI/CD integrations, CLI, APIs, and webhooks

In this article, we will explore the fundamental principles and ascending maturity levels of the Framework, providing examples of real-world threats it can effectively counter. Additionally, we will illustrate how Cloudsmith assists in implementing these principles, helping you achieve your desired level of maturity.

The framework consists of the following 8 principles. By implementing practices for each, you can create a robust and secure supply chain:

Consume your OSS from 1 location controlled by your organization, like Cloudsmith.

Create a list of all your OSS dependencies.

Update known vulnerabilities in a timely manner.

Force developers to adopt secure practices.

Audit that developers are consuming through the approved ingest method, Validate the integrity of the OSS that you are consuming.

Scan for malware and vulnerabilities using automation where possible.

Have the ability to fork and fix code when necessary for a temporary fix.

The Framework applies these 8 principles across 4 maturity levels to enhance open-source security. Levels 1 and 2 provide the basics for a solid OSS governance program. Levels 3 and 4 get into proactive measures and more sophisticated types of controls.

Let’s have a look at the 4 maturity levels in more detail.

How you ingest your OSS is the most important thing to focus on when getting started with implementing this framework, says Adrian Diglio, Principal PM Manager of Secure Software Supply Chain (S3C), Microsoft at his RSA 2023 talk 

Introducing the Secure Supply Chain Consumption Framework

S2C2F strongly advocates the adoption of an artifact repository like Cloudsmith as a central location for all OSS packages. It's a single point to initiate policy enforcement, conduct scans, and implement stringent security controls for your OSS.

This approach guarantees the availability of OSS package dependencies and acts as a safeguard against potential upstream disruptions like the infamous NPM 

, where a package Maintainer withdrew a popular package from its public repository.

Inventory OSS, hopefully in a standard format like Software Bill Of Materials (SBOM)

Level 2: Secure Consumption and Improved MTTR

Level 2 requires organizations to focus on identifying known vulnerabilities in the OSS they use. This includes using Software Composition Analysis (SCA) tools to scan and detect security issues and automatically update OSS.

Audit that consumption is through the approved ingestion method

Level 3: Malware Defense and Zero Day Detection

In Level 3, the emphasis turns to mirroring external OSS internally. This safeguards organizations with local, controlled package copies, reducing vulnerabilities like the previously mentioned left-pad incident. It also encourages proactive security, including fuzzing, static analysis, and other methods to uncover potential code vulnerabilities.

Proactive security reviews for yet to be discovered vulnerabilities

Verifying the provenance of all open source components to make the binaries match the purported source code

This level is considered aspirational in most cases as it is difficult to implement at scale. It involves rebuilding OSS on Trusted Infrastructure. Also in extreme cases, when a critical vulnerability is discovered, organizations may implement private fixes as a temporary risk reduction measure. This would involve forking the code, implementing the fix and then releasing this version on a temporary basis with the intent of pushing this fix to the main branch as soon as possible.

Cloudsmith Blog

Simplify CRA Compliance With Modern Tooling

How to comply with the EU Cyber Resilience Act

What is the EU Cyber Resilience Act?

You Took HOW Much Money?!?

Secure Open Source Consumption: Level 1 of S2C2F

Why Developers Need a C++ Package Manager

Mastering Open Source Security: Your Guide to S2C2F

The Dangers Lurking in Open Source Software

Securely Connect Cloudsmith to your CI/CD using OIDC Authentication

Re-Imagining Cloudsmith.io

Hi. I'm the new CEO :)

Welcoming new leadership at Cloudsmith - a note from Alan Carson