CVE Blog

The purpose of this blog is to establish a dialogue and get your input on issues and topics important to CVE. We encourage you to use Medium, LinkedIn, or Twitter to comment on, share, or like a post. Right-click and copy here to share this article from the CVE website.


Our CVE Story: CVE IDs for Simplifying Vulnerability Communications

Share or comment Medium Twitter LinkedIn

Guest author Chandan Nandakumaraiah of Palo Alto Networks is Co-chair of the CVE Quality Working Group, and Palo Alto Networks is a CNA.

Most organizations that publish security alerts to warn their consumers need unique identifiers to use as a reference. The identifier may be used during meetings, included in emails, discussed over the telephone, cited in chat rooms, displayed in slide presentations, sent in text messages, or tweeted to help identify an individual security alert. They also help people distinguish between issues and ensure people are on the same page when discussing a security problem. Until recently, Palo Alto Networks always used an identifier scheme of PAN-SA-- to identify our advisories, which typically provide the information specific to a security vulnerability also identified by a CVE ID.

We upgraded our security advisory site at the beginning of 2020. In that process, I gave a hard look at our numbering scheme and asked if we really needed to create our own advisory identifiers when each entry likely has a CVE ID associated with it. When someone uses a CVE ID instead of an advisory ID, one needs to connect the dots and find the corresponding advisory ID. If there was a piece of information quoting the advisory ID somewhere on the Interwebs—such as discussion forums, wikis, chat rooms—someone seeking that information can miss it if they only search by the CVE ID.

The acronym “CVE” in the IT industry is synonymous with security holes and has instant name recognition. “Pay attention: There is a PAN-SA!” doesn’t convey the message as much as saying, “Pay attention: There is a CVE!” CVE IDs have become the de facto primary keys that our customers use to refer to security issues.

In the new site, we decided to stop using PAN-SA numbers in favor of using CVE IDs as the primary key. There are, however, some corner cases where we cannot use a CVE ID to identify a security advisory. When we need to publish an issue that does not meet the criteria for assigning a CVE ID, or we need to publish an advisory, grouping together several CVE IDs, we still have the flexibility to crank out a custom PAN-SA identifier. For the majority of issues, however, it is a one-to-one relationship between an advisory and a CVE ID, and this change eliminates a redundant identifier from usage altogether.

The switchover of the primary key has largely been transparent to our consumers, and no one has complained that they miss the old PAN-SA identifiers. It wasn't hard to set up URL redirection for older existing advisory IDs to corresponding pages identified by CVE IDs.

As a CVE Numbering Authority (CNA), we have automated the syncing of our CVE information with the official CVE corpus hosted on the public CVE website. Whether someone is looking at the CVE website or our corporate site, they see a consistent description, which further eliminates the need to keep our own identifier namespace for vulnerabilities.

The use of CVE IDs during the flurry of activities around an advisory publication has greatly helped us streamline communication, avoid confusion, help people get to the right information right away, and stay secure.

- Chandan Nandakumaraiah
  Sr. Director, Product Security Assurance and Vulnerability Remediation
  Palo Alto Networks
  October 21, 2020

Comments or Questions?

If you have any questions about this article, please comment on the CVE Blog on Medium or use the CVE Request Web Form and select “Other” from the dropdown menu to contact the CVE Program. We look forward to hearing from you!



Recent Posts

Back to top
Page Last Updated or Reviewed: October 22, 2020