Home Correction journal Vulnerability management: context from code to cloud

Vulnerability management: context from code to cloud


Almost all modern cloud native applications are developed using open source components. And yet, security isn’t always the top priority for open source developers. While many vulnerabilities can be accidental (eg, a coding error) and have minimal impact, some of the most significant breaches to date rely on the exploitation of known vulnerabilities from open source components. Additionally, 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 problems developers did not anticipate, such as allowing an attacker to be exposed to sensitive data, elevate privileges, or even execute remote code on a machine. To identify and distinguish them, security teams use the Common vulnerabilities and exposures identifier (CVE ID) – this is essentially an always-updated repository of publicly disclosed computer security vulnerabilities to which a CVE has been assigned, which includes a description of the vulnerabilities as well as an identification number.

The problem with CVE ID is that it is just a description. What it lacks is the metadata needed to understand which software components have been impacted and which version needs to be patched, 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 doesn’t have the necessary context to know what to do about it.

As we mentioned earlier, open source code is so widely used that it has become an integral part of application development. The fact that open source code is both convenient and ubiquitous makes it easy to lose sight of the fact that it’s still code and developers are still human. In other words, both are defective.

Identify the three types of hidden vulnerabilities

Many maintainers of open source projects are aware of the security risks and seek to secure their code. However, this is not the standard behavior for all projects. Maintainers may not have the ability or interest to patch known vulnerabilities, let alone newly discovered vulnerabilities. When discovering a new vulnerability in their code, many project managers 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 do not 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 will not detect them. This makes them excellent leads for malicious actors when looking for widely used packages to target in supply chain attacks.

Based on our research, we were able to categorize them into three main types:

The security flaw is clearly described in the GitHub commit/issue. For example, a get involved in the OctoPrint project describes a XSS vulnerability and even lists the CVSS vector string.

  • A Disguised Vulnerability

The security flaw is described as a bug, so we don’t always have a clear indication of the security impact. For example, a get involved in the Envoy project describes a bug fix but actually fixed a denial of service vulnerability.

These vulnerabilities look like an enhancement or feature, but are actually security issues. Without deep technical knowledge and expertise, the average user will have a hard time noticing certain security vulnerabilities here. For example, a validate in the Listmonk project describes an improvement that effectively prevented a stored XSS vulnerability.

The increasing complexity and expanding attack surfaces of cloud computing and cloud-native application development is fueling organizations’ need to gain visibility and mitigate vulnerabilities in the cloud.


Using open source has many advantages. 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 managing open source vulnerabilities

Shift-left Security (aka Developer-Friendly Security)

Security must be developer-friendly to be successful. After all, it is much faster to fix a bug found in code than in production. With modern cloud development and deployment models, vulnerabilities must be detected and patched when building and deploying software.

Analysis of software composition

To continuously identify vulnerabilities in registries and at runtime, effective software composition analysis (SCA) solutions must leverage the same flow of intelligence used to identify vulnerabilities in repositories. Organizations should strive to use a scanner with an intelligence feed enriched with data from researchers, which will help detect hidden vulnerabilities. SCA can also help prioritize remediation risks.

Continuous scanning

Effective security must meet developers where they are (and where application code is written) and resolve security issues down to the runtime environment. Vulnerabilities should be detected early to avoid costly post-event analysis and remediation. Gartner recommends a consolidated platform-centric approach from development to operations.

Contextual 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 augmenting identified vulnerabilities with knowledge of attack vectors, network exposure, host configuration, and other details unique to each customer’s environment can security teams security can focus their resources on fixing the most impactful issues, from the code repository to production.

To learn 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