Vulnerability Scans: Catch Vulnerabilities Before They Catch You!
In the previous post of the series, we discussed how creating an SBOM (Software Bill of Materials) lays the groundwork as a means to an end in securing software supply chains. Next, we need a way to make sense of the SBOM data and act. Here’s where vulnerability scanning comes in, a crucial step to risk management and remediation and the focus of this post. Let’s keep going.
Vulnerability Scanning Primer
The vulnerability scanning process identifies weak spots in software code and dependencies. Vulnerability scanners can identify infrastructure, networks, applications, or website vulnerabilities. These tools scan various target systems for security flaws that attackers could exploit.
The scanners use the information contained in the SBOM to identify vulnerabilities and potential security risks within software applications. Here are some ways in which vulnerability scanners use SBOM information:
- Identify vulnerable components: Software vulnerability scanners use the SBOM to identify a software application’s components. Then, they cross-reference this information with known vulnerabilities and security issues to identify vulnerable components within the software.
- Prioritize vulnerabilities: After the vulnerability scanner has identified all vulnerable components within the software application, it uses the SBOM to prioritize the vulnerabilities allowing security teams to focus on the most critical vulnerabilities.
- Identify supply chain risks: SBOMs provide visibility into the software supply chain, enabling vulnerability scanners to identify third-party or security risks. As a result, organizations can mitigate supply chain risks and reduce their overall security exposure.
- Track changes and updates: Software vulnerability scanners use SBOM information to determine whether software changes have introduced new vulnerabilities or security risks.
The SBOM is a critical tool for vulnerability scanners, providing the information needed to identify, prioritize, and mitigate security risks within software applications. In addition, scanners also rely on other types of inputs, as listed below.
Inputs To Vulnerability Scanning
Vulnerability scanners may require different inputs depending on the type of software or system they’re scanning. Typical inputs are:
- SBOM Documents (Key Input)
- Software code
- Third-party libraries
- OS and Network Configurations
- User-input
- Known vulnerabilities Database
Outputs From Vulnerability Scanning
A vulnerability scanner usually outputs:
- A list of vulnerabilities: A list of the vulnerabilities discovered, along with details about each vulnerability’s potential impact and severity.
- CVSS scores: Common Vulnerability Scoring System (CVSS) scores provide a way to quantify the severity of a vulnerability.
- CVE numbers: Common Vulnerabilities and Exposures (CVE) numbers are unique identifiers assigned to specific vulnerabilities.
- Remediation Guidance: Includes specific steps to patch the vulnerability or mitigate its impact.
- Vulnerability Report: Modern vulnerability scanners provide a report summarizing the scan’s findings, including the vulnerabilities discovered, their severity, and any remediation advice.
Vulnerability Scanning Architecture & Ecosystem
The scanning ecosystem comprises several key entities, like CNAs, CVEs, CVSS, and NVDs. Let’s review some of these terms and see how they all fit together.
CVE (Common Vulnerabilities and Exposures) is a list of publicly disclosed computer security flaws. CVEs are security flaws that are uniquely identified by a CVE ID.
CVSS (Common Vulnerability Scoring System) is a framework used to assess the severity of computer systems or software vulnerabilities. A very useful in-depth explanation of this system can be found in this CVSS Specification.
A CVSS calculator is a tool that helps to calculate the CVSS score for a given vulnerability based on various attributes, such as the vulnerability’s complexity, availability of exploit code, and ease of exploitation. These attributes generate a numerical score between 0 and 10, where 10 indicates the highest severity, and 0 indicates no impact. Here is some information if you want to understand the design to implement a calculator for your specific needs.
Security analysts, developers, and system administrators use the CVSS calculator to prioritize and manage vulnerabilities and allocate resources for patching and remediation activities. It is a widely used cybersecurity tool maintained by the Forum of Incident Response and Security Teams (FIRST).
CNA (CVE Numbering Authority) Organizations are responsible for regularly assigning CVE IDs to vulnerabilities and creating and publishing information about the Vulnerability in the associated CVE Record.
NVD (The National Vulnerability Database) is a database maintained by NIST fully synchronized with the MITRE CVE list.
Figure-2 below illustrates how a vulnerability-scanning architecture ecosystem works:
What To Scan
- Containers
- Applications
- Root File Systems
- Images
- Packages
In the context of modern cloud-native applications and shift-left security regimens, container vulnerability scanners take the front and center seat. Containers have become more popular for packaging and deploying apps, which makes them an attractive target for attackers looking for vulnerabilities. Typically, container vulnerability scanning is done during the container image build process or ongoing security monitoring. The task entails analyzing container images and identifying vulnerabilities in software packages and their dependencies.
Applications, Root File Systems, Images, Packages, Virtual Machines- your entire end-to-end software sub-system needs to be scanned to gain visibility against fix-worthy CVEs. The whole chain is susceptible when one part of the software supply chain is vulnerable. So, despite the temptation to look for shortcuts, it’s best not to do that. A repetitive and elaborate scanning can take time, but it’s worth it. There are advanced techniques for cherry-picking and fixing vulnerabilities by overlaying contextual data on vulnerability reports. Let’s save that topic for a future post.
When To Scan
- CI/CD
- On-Demand (manual)
- Runtime
It is excellent hygiene to automate and integrate the scanning processes with your CI/CD pipelines via APIs to derive the most value from these vulnerability scans. KubeClarity also offers a CLI to integrate these scanners into CI/CD pipelines via APIs to catch and mitigate vulnerabilities from source code development to container deployments.
Is it a dream come true for security operators and developers in shift-left environments to gain visibility and fix vulnerabilities early on? We can make this happen with automated, continuous CI/CD-integrated vulnerability scanning!
Choosing A Scanner
Scanners aren’t all the same, just like SBOM generators. Each has its input format and idiosyncrasies. What scanner to choose depends on your use case and deployment context. For example, some scanners only work with CyloneDX inputs, while others require SPDX. Certain supply chains may do better with a specific type of scanner, so deployments may have to use multiple scanners and normalize the results. An open-source scanner option, Grype, has been mentioned throughout the series.
Look for tools that do it out of the box. If you plan on doing it yourself, a word of caution running a single scanner generates a ton of output. Configuring and running multiple scanners and looking at vulnerabilities can be like searching for a needle in a haystack. KubeClarity has figured this out for you.
Filtering Noise vs. Signal
There can be an endless list of CVEs in software vulnerability reports that you can sit and fix all day yet leave your supply chains vulnerable. These steps will help you filter out noise from your software vulnerability scanning reports and focus on the most critical ones.
- Focus on the most critical vulnerabilities: Start by prioritizing vulnerabilities with the highest severity ratings, such as those with a CVSS score of 9 or 10. These vulnerabilities are most likely to be exploited and cause significant damage.
- Analyze the context of each vulnerability: A vulnerability in a component that is not in use or is not reachable from the internet may be less of a priority than one that is easily exploitable.
- Verify each vulnerability manually: Scanners can produce false positives, so it is essential to verify each vulnerability manually. Though it can be time-consuming, filtering out the noise to address only valid vulnerabilities is necessary.
The CVE list needs granular filtering options; tools like KubeClarity can also help with this.
KubeClarity Brings Clarity To Vulnerability Scanning
KubeClarity isn’t a vulnerability scanner but integrates with top opensource vulnerability scanners. It also helps with prioritization and bleeding risk management by allowing efficient visualization and filtering mechanisms to filter out noise. It is often necessary to prioritize CVEs because of the sheer volume of identified CVEs. With KubeClarity’s vulnerability trending dashboard and APIs, you can locate and double-click into a specific CVE in your application or infrastructure.
KubeClarity features a range of flexible and dynamic filters that help map CVEs down to an application->package->Image level. You can navigate vulnerabilities across all layers with a connected graph traversal experience. Additionally, it normalizes reports from multiple scanners and calculates missing CVSS scores. Isn’t that cool?
Using KubeClarity to track and remediate vulnerabilities is easy thanks to its user-friendly interface; as shown in Figure-3 below, aggregates of vulnerability trends and total fixable vulnerabilities can be very helpful.
Sometimes granular filter controls are as important as aggregates, and Figure-4 shows filter controls for digging deeper.
Dashboards help visualize vulnerabilities and check them manually. The most effective approach is a combination of manual and automated vulnerability scanning. Automatic scans can find common vulnerabilities quickly and efficiently, while manual scans can help verify automated scans and sometimes help identify more complex and less common vulnerabilities. Choosing the right approach also depends on the scope and criticality of the scanned system and the resources available.
We have reached the end of the foundational topics in the series; by now, I hope you’ve grasped the fundamentals of securing software supply chains and an understanding of KubeClarity’s offerings in these foundational areas. Well done! Thank you for sticking with me so far. It’s time to break open the shell and get inside KubeClarity next.
Conclusion
Putting it all together, a mental map of vulnerability scanning, as seen in Figure-5 below, summarizes what it is, what it is not, and where it is valuable.
Next Up
Starting the how-to series with an introduction to the internals of KubeClarity. The follow-up blogs will discuss installation, architecture deep dives, feature configurations, and more. As a recap, you can check out the complete series roadmap here.
———————————
Pallavi Kalapatapu is a Principal Engineer and open-source advocate in Cisco’s Emerging Technology & Incubation organization.
