Common Vulnerability Exposures (CVE)

What is CVE?

When a vulnerability is discovered in a software system, a CVE identification number is held for it in the National Institute of Standards and Technology (NIST) National Vulnerability Database (NVD). Each suspected vulnerability is reviewed by a CVE Numbering Authority (CNA) and, if it is found to contain a valid threat to the affected software, it is published under its unique identifier. These are composed of the prefix “CVE” followed by the ID number. This identifier is used to refer to the vulnerability in public databases, security advisories, and the ActiveState article library. Not all vulnerabilities are reported to a CNA as such some vulnerabilities do not have a CVE-ID.

To view your project’s CVEs go to the Configuration tab of your project page. Each CVE is associated with either a package or the language version contained in your project. Each vulnerability is listed along with the severity of the threat associated with it (“low”, “medium”, “high”, and “critical”). The severity of each threat is assessed using the Common Vulnerability Scoring System (CVSS). Note that the CVSS is NOT a risk assessment.

Why does a package have a CVE? / Why do they occur?

CVEs are most often the result of flaws or weaknesses in software that can be exploited to gain unauthorized access, steal data, or otherwise compromise the integrity of a system. In most cases this is not intentional. If you would like specific examples of causes OWASP maintains an annual top 10 causes of vulnerabilities in web applications .

Common reasons why CVEs occur include

1. Programming errors or oversights made when writing software. This can include errors in configuring software or implementing weak security measures.
2. Design flaws due to poor planning, inadequate testing, or lack of consideration for potential security risks.
3. Integrating third-party components can sometimes introduce vulnerabilities to the affected software if they are not kept up to date.
4. Lack of updates and maintenance to the underlying software. As software systems age, they may become more vulnerable to attack if they are not updated and maintained.

How do I see them?

To see all CVEs in your project using the State Tool.

1. Open a command terminal and enter state auth to authenticate with the Platform.
2. Activate your project using either state shell <orgname>/<projectname> or state use <orgname>/<projectname>.
3. To view all current vulnerabilities in your project, enter

state cve

Your project’s CVEs are also visible in the Configuration tab of your project page.

As seen above, the “PythonWindows” project shown has a total of four CVEs:

• Two related to the Python version of the project
• One related to a package in the project (Flask 0.12.2)
• One is a dependency related to the vulnerable package (Wheel 0.37.1, not shown in the image)

Creating a successful project containing everything you need may involve managing some risks, as not every vulnerability listed means your project is not secure. We encourage you to investigate these vulnerabilities to see if remediation is needed.

This is the beginning of the vulnerability management and triage process, which is

1. Assessing the vulnerabilities in your project.
2. Triaging the risk posed by each vulnerability.
3. Acknowledging the risk or taking steps to remediate each vulnerability.

What steps should I take to secure my project?

The first step is assessment, or viewing the CVEs in your current project. This should be done on a recurring basis (weekly, monthly, quarterly, etc.). Due to the evolving nature of software development, older packages may develop new vulnerabilities, even if no changes have been made. Once a vulnerability is reported and assigned a CVE-ID, the previously secure package will now have a listed vulnerability.

After assessing the vulnerability you will need to triage the risk. We recommend starting with the “Critical” severity vulnerabilities. Your triage group (or person) must read the CVE description. You can research each CVE by clicking the link and reviewing it on the NIST Vulnerability Database. After reading about the vulnerability you can decide if the severity is relevant enough to address. Relevancy has to do with applicability (for example, is this a Windows-only flaw and all your software only runs on macOS?) as well as taking into consideration any mitigations or remediations your company had put in place (such as a WEP, or input sanitization). After triaging the risk you can now make a more informed decision about the risk associated with this CVE and if it is worth remediating.

The next step is deciding whether to remediate or acknowledge the vulnerability. Acknowledgment means that the risk is low and can be accepted as a part of the project. As a result, no further steps will be taken.

If remediation is needed, there are a few different options. In the example “PythonWindows” project, you can update (to a previous version) the Python version with one that has fewer vulnerabilities. Do so by clicking the Change Version button in the “Language” section and selecting a version with no (or fewer) CVEs listed.

To remediate the CVEs related to the Flask package (and its dependencies), update the package to a more secure version by clicking the dropdown next to the package name and selecting a version with no (or fewer) CVEs listed. In this case Flask 2.2.3.

After making your selection and saving the changes, an updated version of the project will be available.

The new project build has reduced the total number of CVEs from 4 to 2. Due to the ever-changing open source environment, it may not be possible to completely remediate all known CVEs from your project while still containing all of the versions and packages you need.

If selecting a different version does not work, you can try removing the package by clicking the trash can icon next to the package name. This is particularly helpful if the package is not used or used for only one function and can be replaced by another similar package with fewer vulnerabilities.

If removing, replacing, or changing the version of a package does not work you will need to look into remediation within your own environment or software (such as input sanitization, etc.).

For Enterprise tier users

The ActiveState Platform can help you shorten the lengthy remediation process of investigating, rebuilding, retesting, and updating runtime environments. The Platform lets you find, fix, and automatically rebuild a secure version of your runtimes in minutes. Decreasing the Mean Time To Remediation (MTTR) from days to hours.

You can export your CVE report to see if any of the reported vulnerabilities have already been acknowledged or remediated by an existing security or triage team, leaving you with only the new findings to triage. In certain cases you may need to provide an accompanying SBOM with your report. After triaging them you will be able to quickly create a testing branch for developers to ensure that the proposed fixes work for your software.

To protect the integrity and settings of your existing project, we recommend creating a new branch of your existing project, making any remediations in the new branch, verifying a successful build (with vulnerabilities remediated), and then incorporating the new branch into your existing CI/CD pipeline.

To create a new branch of your project

1. On your Project Settings tab click Branches and Add Child.
2. Select a branch name and click Add to create a branch for your project.
3. In the Configuration tab, select your new branch from the Branch drop-down menu at the top of the page

To make changes to your new branch

1. On the Configuration tab of your new branch, scroll down to find an artifact that has a listed vulnerability and click the Edit button.
2. The drop-down associated with that artifact will show other versions that may have fewer, less severe, or no vulnerabilities listed.
3. Select a new version and wait for the builder to notify you that the dependency has been resolved.
4. Click Save Changes and Start Build (or in the case of an unresolved dependency Save Changes Anyway) to build your new branch.

It is recommended that you only proceed with resolved dependencies. Proceeding with unresolved dependencies may introduce unnecessary risks to the security of your project.

1. In your History tab, check to see if your updates have been included in your branch.

You can now run this new branch, complete with your remediated vulnerabilities, from the Download Builds tab of your project or against your current CI/CD pipeline using existing methods unique to your organization.