Almost all modern cloud-native applications are developed using open source components. And yet, security is not always the top priority for open source developers. While many vulnerabilities can be accidental (e.g., coding error) and have minimal impact, some of the largest breaches to date have relied on exploiting known vulnerabilities from open source components. Furthermore, there is also no standardization for open source security integrity. This makes vulnerability management more critical than ever.
Current Vulnerability Management is Flawed
Security vulnerabilities are flaws in software or code that cause issues developers did not intend, such as allowing an attacker to be exposed to sensitive data, escalate privileges or even to execute code remotely on a machine. To identify and distinguish between them, security teams use the Common Vulnerabilities and Exposures identifier (CVE ID)–essentially, it’s an always-updated repository of publicly disclosed computer security flaws that have been assigned a CVE, which includes a description of the flaw along with an ID number.
The problem with CVE ID is that it’s just a description. What it lacks is the metadata needed to understand what software components have been impacted and what version needs to be fixed, not to mention the severity of the flaw. Most of the time, there is no information about the prerequisites needed for the vulnerability to be exploited. In other words, the CVE lacks the context necessary to know what to do about it.
As we stated earlier, open source code is so widely used that it’s become part of the fabric of app development. The fact that open source code is both convenient and ubiquitous makes it easy to lose sight of the fact that it is still code and developers are still human. In other words, both are flawed.
Identifying the Three Types of Hidden Vulnerabilities
Many open source project maintainers are aware of security risks and seek to secure their code. This is not the standard behavior for all projects, though. Maintainers might not have the capacity or interest in remediating known vulnerabilities, let alone newly discovered ones. When finding a new vulnerability in their code, many project maintainers don’t want to go through the CVE filing process or don’t know how to go through the reporting process. This failure results in countless vulnerabilities that are known and don’t get a CVE ID. We call these hidden vulnerabilities.
Hidden vulnerabilities represent weaknesses in software design or code that can be maliciously exploited. They are public but have no documentation, so scanners won’t detect them. This makes them great leads for malicious actors when searching for widely-used packages to target in supply chain attacks.
Based on our research, we were able to categorize these into three main types:
- A visible vulnerability
The security flaw is clearly described in the GitHub commit/issue. For example, a commit in the OctoPrint project describes an XSS vulnerability and even lists the CVSS vector string.
- A vulnerability in disguise
The security flaw is described as a bug, so we don’t always have a clear indication of the security impact. For example, a commit in the Envoy project describes a bug fix but actually fixed a denial-of-service vulnerability.
- An enhancement
These vulnerabilities look like an enhancement or feature but are actually security issues. Without deep technical knowledge and expertise, the average user will find it difficult to notice some security vulnerabilities here. For example, a commit in the Listmonk project describes an enhancement that actually prevented a stored XSS vulnerability.
The increasing complexity and expanding attack surfaces of cloud computing and cloud-native application development are fueling a need for organizations to gain visibility into and mitigate vulnerabilities in the cloud.
The use of open source comes with many benefits. It allows easier and faster development of new technologies while using fewer resources. But without proper maintenance, open source is a liability.
3 Takeaways for Open Source Vulnerability Management
Shift-left Security (aka Developer-Friendly Security)
Security must be developer-friendly to be successful. After all, it’s far faster to fix a bug found in code than in production. With modern cloud development and deployment models, vulnerabilities need to be detected and remediated when software is being built and deployed.
Software Composition Analysis
To continuously identify vulnerabilities in registries and at runtime, effective software composition analysis (SCA) solutions must leverage the same intelligence stream used to identify vulnerabilities in repositories. Organizations should strive to use a scanner with an intelligence stream that is enriched with researchers’ data, which will help with detecting hidden vulnerabilities. SCA can also help with the prioritization of remediating risks.
Effective security needs to meet developers where they are (and where application code is written) and address security issues all the way to the runtime environment. Vulnerabilities should be caught early to avoid costly post-event analysis and remediation. Gartner recommends a consolidated platform-driven approach from development to operations.
Context-Aware Security From Code to Cloud
The best vulnerability management solutions provide context-specific vulnerability information tailored to your environment and not just generic risks. Only by enriching identified vulnerabilities with knowledge about attack vectors, network exposure, host configuration, and other details unique to every customer’s environment can security teams focus their resources on correcting the most impactful problems – from code repository through to production.
To hear more about cloud-native topics, join the Cloud Native Computing Foundation and the cloud-native community at KubeCon+CloudNativeCon North America 2022 – October 24-28, 2022