All articles

What are software vulnerabilities and CVEs, and why do they matter?

The Chainguard Team
AppSec
Key Takeaways
  • A vulnerability is an exploitable weakness; MITRE's CVE Program has catalogued 200,000+ since 1999.

  • CVSS scores severity, CWE classifies weaknesses, and the NVD adds analysis and KEV exploitation flags.

  • Chainguard Containers minimize CVEs by shipping only what your app needs, rebuilt continuously.

A software vulnerability is a weakness in a program which, if left unaddressed, may be used by attackers to access, manipulate, or compromise a computer system. Vulnerabilities can be introduced at different stages of development and vary in their scope, criticality, and potential attack vector depending on their root cause. As a consequence, software developers spend time and resources triaging, remediating, and patching vulnerabilities to harden their software security and to prevent attackers from exploiting unintended program behavior.

With software supply chain attacks on the rise, it is essential that developers and other technology professionals become knowledgeable about software vulnerabilities. Staying on top of the latest threats helps protect against targeted cyber attacks, ensuring the safety of important information and computer systems.

Understanding software vulnerabilities is the first step in mitigating them in order to improve the security of the software you consume, develop, and release. In this article, you will be introduced to software vulnerabilities, examples of their causes and impacts, and learn how known vulnerabilities are documented through the CVE Program.

What makes a vulnerability?

Any party, process, or other input (like a dependency or package) involved in software production can introduce vulnerabilities into the final release. When third-party inputs used in development have software vulnerabilities, the resulting product may be impacted by them as well. Alternatively, developers writing their own code may unintentionally introduce vulnerabilities to a project through their programming, processes, or habits.

If left unresolved, software weaknesses can advance to become vulnerabilities if hackers are able to exploit them via an attack. For example, not conducting input validation in a program could allow unfiltered or malicious input to affect the program, creating an improper input validation vulnerability. A notorious example of this is the Log4Shell vulnerability, which widely impacted many systems that used the Log4j logging utility.

Attackers may target software vulnerabilities if they see an opportunity to compromise sensitive data or systems for their own benefit. They may choose to prioritize some vulnerabilities over others depending on how lucrative and accessible the opportunity is.

Malicious actors can approach a vulnerability from different attack vectors depending on the weakness type being targeted. In some cases, attack vectors are easier to reach, meaning less leverage is required to expose and exploit the software’s weaknesses.

The CVE program

Founded by the MITRE Corporation in 1999, the CVE Program was established with the goal to collect and document information surrounding known vulnerabilities in software products. Standing for Common Vulnerabilities and Exposures, CVEs are records of publicly disclosed software vulnerabilities. Over time, the program catalog has expanded to include over 200,000 software vulnerabilities, with more being added every day.

The CVE Program is supported by the U.S. Department of Homeland Security Cybersecurity and Infrastructure Security Agency (CISA). In addition, the CVE Program feeds the U.S. National Vulnerability Database (NVD), which provides additional information for each CVE entry.

What is a CVE?

A CVE entry represents a known weakness in a software product and contains information to help address any potential risks to the integrity of a system caused by the vulnerability. Each CVE is assigned a unique CVE ID and is recorded with a description of the vulnerability, a list of affected software releases, any relevant references, and other pertinent information.

CVE Numbering Authorities (CNAs) are the entities responsible for assigning CVE IDs. CNAs can be software vendors, research groups, open source sponsors, and similar organizations. When a new vulnerability is discovered and reported to a CNA, the CNA will request that a CVE ID is reserved for it. Once reserved, details are added to the CVE record and the entry is published to the database.

While the CVE Program database functions stand-alone to communicate known vulnerabilities with developers, a variety of related efforts provide additional information and context to support the database.

  • The Common Vulnerability Scoring System, or CVSS, is a metric which helps assess the severity of any given vulnerability and serves as a tool for developers who are determining which CVEs to address first.

  • Similar to the CVE Program, MITRE also supports the Common Weaknesses Enumeration, or CWE. The CWE catalogs product-unspecific types of software weaknesses which may produce vulnerabilities if present in a program.

  • The U.S. National Vulnerability Database (NVD) connects to the CVE database to provide further information regarding CVE entries. The NVD provides additional references and public advisories regarding each vulnerability. It also connects each CVE with a CVSS score, links a vulnerability’s associated CWE(s), and reports whether it is in the CISA’s Known Exploited Vulnerabilities (KEV) catalog.

Why care about software vulnerabilities?

Software products are prone to vulnerabilities which, if exploited by an attacker, may negatively impact the systems and consumers relying on them. Attacks against vulnerable software systems can result in the unintended exposure and misuse of sensitive data (like the theft of user account credentials). In other cases, these attacks could affect the provision of a service, or compromise critical infrastructure that relies on the software. Given the considerable threat that they can pose, it is important that developers spend time mitigating vulnerabilities to protect against hackers seeking to exploit them.

Addressing the vulnerabilities present in your software helps secure the systems you support, use, and maintain. In this article, you will explore why you should care about vulnerabilities as a software developer, and learn about federal regulations that draw importance to CVE management.

As a developer

Discovering and mitigating software vulnerabilities is a difficult – but necessary – task for developers to tackle. Development teams are ultimately the authorities who are able to remediate vulnerabilities at the source. Depending on the severity of a vulnerability, its exploitation could significantly impact the integrity of the software product. The trust, safety, and operations of the consumers who rely on the software may be affected as well.

Vulnerability triage is an important step developers must take to work toward reducing risks posed by vulnerabilities in their software. Using vulnerability scanners can give developers information about the number, type, and severity of CVEs present in their work. With this data, developers can prioritize critical CVEs, therefore ensuring that major security concerns are addressed first.

Federal regulations

With notable software supply chain security attacks occurring in recent years (such as the SolarWinds attack in 2020), the U.S. federal government has increased efforts to improve U.S. cybersecurity. These initiatives aim to strengthen software supply chain security by promoting safer development habits, such as frequent vulnerability scanning.

FedRAMP

The Federal Risk and Authorization Management Program (FedRAMP) is a security framework that must be adopted by cloud service providers (CSPs) before they service U.S. federal government agencies. The framework aims to promote the use of cloud services across agencies by standardizing security authorization practices. Based on the service being offered, FedRAMP sorts cloud services into low, moderate, and high impact levels, with increased security expectations for each level.

In order to achieve FedRAMP authorization, certain requirements need to be met as follows:

  • Container images used by CSPs must be hardened according to benchmarks laid out in the

    NIST SP 800-70. Our solution is Chainguard Containers, which offers hardened, minimal base images designed to help you meet FedRAMP compliance requirements.

  • Vulnerability scanners are expected to report information about discovered vulnerabilities, such as its CVE ID and CVSSv3 score.

Meeting FedRAMP container image and vulnerability scanning requirements allows your organization to expand and reinforce its offerings as a CSP. To learn how we can help you meet FedRAMP container image requirements, check out our blog post on how you can Fortify, comply and conquer FedRAMP with Chainguard Containers.

DHS software self attestation

The Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) released their Secure Software Attestation Form in response to Executive Order 14028. The attestation form identifies the secure software development practices that developers must verify to have met in order for their software to be utilized by federal agencies. Meeting the criteria laid out by the form is another critical step toward securing your software development processes.

Learn more

In this article, you were introduced to software vulnerabilities, learned about their characteristics, and how they are tracked in the CVE Program catalog. This understanding will help you to start triaging and addressing vulnerabilities present in the software you produce or consume to limit the potential for attackers to successfully exploit your systems.

To learn more about software vulnerabilities, you can visit the CVE Program website, explore the NVD, or take a look at the KEV Catalog.

You can also check out our articles on real-world CVE examples and how to prevent them and our guide to addressing vulnerabilities in your software.

In this article, we discussed reasons why you should care about software vulnerabilities from a development perspective. In addition, you were introduced to federal regulations that draw importance to vulnerability management and secure development practices. This knowledge will help you begin managing vulnerabilities present in the software you develop, improving your security profile and giving you a head start toward meeting regulations like FedRAMP.

To learn more about the importance of software vulnerability management and meeting federal regulations, you can explore the process of gaining FedRAMP authorization, or learn how Chainguard Containers can help reduce CVEs in your container images.

Share this article

Start building with Chainguard

Contact us