What Is
CVE Scanning?

The CVE (Common Vulnerabilities and Exposures) database is a public list of reported security vulnerabilities. The fact that it is continually growing (see Figure 1) sets back efforts to manage and maintain a secure development environment. Monitoring the increasing number of exploits, which includes identifying, categorizing, and assessing their severity on your Linux platform, is critical — but it is also a complex and time-consuming task.

Of course, not every registered CVE will affect the version of Linux you use in a given RYO — but how can you be sure? You still must do an assessment on a staggering number of exposures just to find those that do affect your release. You might recall several exploits — Spectre and Meltdown in 2018 and WannaCry in 2017 — that made a dramatic splash in the public consciousness. They were illustrative of the types of vulnerability and ransomware challenges facing developers.

As vulnerability reports have skyrocketed, two points have become clear: First, their frequency creates an endlessly moving target that many developers don’t have the resources to address, which exposes companies to significant business risk. Second, the nature of CVEs is not black and white, but many shades of gray.

There are 10 crucial elements of best-practice CVE scanning activities:

1. Develop a vulnerability management lifecycle: Development teams need to manage vulnerability detection as a lifecycle (see Figure 2) that includes constant assessment, effective prioritization, scanning and detection, and a method for growing the library of known vulnerabilities so detection can improve over time. Scanning is never a one-and-done activity.
2. Stay current: Vulnerability scanning is not enough. Staying up to date on changing CVEs is possible by using databases such as the CVE database provided by Wind River.
3. Focus: Not all of today’s rapidly increasing threats are relevant for the embedded developer. A key step in effective vulnerability management is paring down the world of CVEs to a curated database of those vulnerabilities that have the most impact on embedded development teams.
4. Use automated vulnerability identification: A structured approach that Wind River recommends is to take advantage of automation to help with vulnerability detection. Software bills of materials (SBOMs), which use the software package data exchange (SPDX) format, include not only descriptor information but also version, name, license, manufacturer, and other metadata associated with a given software package. Using this information, developers can create a powerful inventory of the software that comprises their Linux OS and/or application. This then becomes the foundation for intelligent vulnerability scanning that is tailored to the software in use.
5. Triage efficiently: Initial scans can produce overwhelming results. The Common Vulnerabilities Scoring System (CVSS), however, provides a severity score for every CVE tracked. The Wind River vulnerability scanner can use this score to deliver a prioritized list of CVEs that have the highest impact on the code, helping developers zero in on the vulnerabilities that pose the greatest risk to their solutions.
6. Use automated license and IP compliance identification: Running IP and license scans can be time-consuming if they are not automated. Fortunately, standardizing on a format such as SPDX for package descriptions and maintaining a disciplined SBOM enables developers to implement automated scans for license use and compliance.
7. Integrate DevOps into development: By implementing automated vulnerability and CVE scanning early in the build process, developers become responsible for fixing known security risks early in the development phase. This, in turn, delivers benefits for the product lifecycle in general, including a higher security posture and a more agile model for responding to identified security issues. DevOps provides the needed shift-left tactic to achieve this strategy, which also drastically reduces time and cost.
8. Use dashboards and health monitors: While search engines and vulnerability databases are helpful, development teams and engineering leadership need a consolidated, streamlined view of their platform and application status rather than having to hunt for and collect information from different sources. Dashboards provide a high-level view of status, must be understandable at a glance, and enable drill-down and detailed reporting where necessary. They should also be automatically updated to remain relevant and current at all times.
9. Engage in reporting: Customers have an expectation that suppliers are validating their system components against known vulnerabilities, because those customers are in turn expected to prove that the devices they offer are secure. Development teams often find it necessary to invest in automation that shows CVE detection and resolution times. They may be also required to show the criticality of found CVEs, particularly for high-impact packages within the system.
10. Ensure security and privacy: There are three characteristics to keep in mind when evaluating a secure solution for CVE scanning:

• Access control: The tool should provide strict access controls to prevent unauthorized access to sensitive information.
• Manifest protection: The tool provider must protect the assets that are being scanned for CVEs — usually source code and/or software packages. These manifests must be protected to ensure that your SBOM and other sensitive information about the components of the Linux platform or application don’t fall into the hands of bad actors.
• Customer privacy and protection: The tool should not compromise the relationship between the supplier and customer. This relationship should remain private thanks to various mechanisms, such as encryption, access controls, or other means of obfuscation.