What happens when a new vulnerability emerges for a package you already used in a build? If you don’t find out about that new vulnerability right away, then your production system is at risk until the next security scan runs. Scan results provide a point-in-time snapshot, but they’re only valid until the next CVE comes out. Currently, we’re seeing an average of 234 new CVEs daily. Continuous risk detection solves this problem using a near-real-time threat data feed to power a lightweight lookup rather than an in-depth scan, allowing it to run as new advisories emerge. If you scan daily, continuous risk detection can reduce a 24-hour risk window to as little as five minutes.
Scanning is a package-centric process. For every package in a repository, the scanner needs to schedule a scan, prepare the package to scan, perform the analysis, and then store the result. This is a resource-heavy process, making it expensive and time-consuming. Typically, that means packages get scanned once on upload and don’t get evaluated again until a daily or weekly scheduled scan occurs, or someone initiates a manual scan. In practical terms, this means that scan results go stale quickly because they are only relevant as of the time that the most recent scan occurred.
Because scanning is such a valuable tool, the natural reaction may be to run scans more frequently. There are several technical reasons that make scanning more often a challenge.
The first is a cardinality problem. Scan time scales with the product of the number of packages in a repository and the number of CVEs that have accumulated since the last scan. Enterprise-scale repositories are so large (e.g., tens of thousands of packages) and CVE lists are so long (e.g., hundreds or thousands, depending on the scan schedule) that a full rescan can take longer than the interval between new threat advisories.
Another issue is that scanning images increases the scanners’ workload. Each image contains a bundle of packages, e.g., the base image, installed dependencies, layers, and the scanner needs to unpack all those elements, identify them, and then scan each one. A base image package also gets scanned in every downstream image that includes it, which further compounds the cardinality issue.
Because scanning tools can’t run continuously, teams often use multiple different scanners at different development stages, e.g., at source, build, test, and runtime. Different tools often use different output formats and lack a common data store for scan results, so results from a source-stage SCA scan may not be able to share results with a build-stage SCA scanner. The result is a visibility gap that prevents teams from having a holistic view of their environment’s overall risk level.
Where scanning uses a package-centric approach, continuous risk detection uses matching, which is vulnerability-centric. Packages contain a unique package URL (PURL) that details the package name, ecosystem, and version. Threat advisories carry PURLs too, and continuous risk detection uses a lightweight database lookup to match the PURL in the threat advisory to packages entering or already in a repository. There’s no need to perform a complete in-depth scan, which means that the matching process can run continuously as new advisories get published.
Because matching is less resource intensive, it can run at the artifact registry layer. This is important because the artifact management platform plays a unique role in the software development lifecycle; it evaluates every package and dependency that enters the development environment, and interacts with every stage of the development process.
An artifact manager provides broad and consistent visibility across the entire development environment. It keeps a persistent set of metadata for every package in the repository over the lifespan of the package and knows every build that consumed a package. When a new CVE emerges, continuous risk detection can look at any package you’ve ever used and determine if there’s a match. Standalone security tooling lacks a persistent repository and can’t make the same determination.
Furthermore, because continuous risk detection is a native capability of the Cloudsmith platform, it’s able to trigger policy management security policies when it detects a CVE match. You can use that same persistent repo data in custom policy-as-code security policies, making the two features intrinsically connected in the platform. This is another reason to use Cloudsmith as the control plane for software development.
The main limiting factor to both scanning and matching is that they rely on known CVEs, so zero-day threats remain a concern for security teams. In Cloudsmith, you can augment continuous risk detection with another proactive security policy: a cooldown. Cooldown policies hold newly released packages for a set period of time (e.g., 3-7 days) to allow threat intelligence researchers to vet them, helps to bridge the zero-day gap, and contributes to a defense-in-depth security posture.
Continuous risk detection matches threat data to new packages at ingest and continuously thereafter when new threat intelligence lands. Powered by OSV.dev, the data feed for continuous risk detection provides near real-time threat evaluations for every package in your repository.
Chat with our team to learn more about continuous risk detection and how it can improve your security posture.
