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.
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
To see all CVEs in your project using the State Tool.
state auth to authenticate with the Platform.
state shell <orgname>/<projectname> or
state use <orgname>/<projectname>.
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:
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
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.).
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
To make changes to 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.
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.