Cisco Logo


Have you ever watched a movie called “The Abyss?” Near the end of the movie there’s a scene that I think is particularly relevant to this post. Our hero has to go 17,000 feet under the sea to disarm a nuclear bomb (watch the movie and you’ll know how the bomb ended up there and why our hero has the unenviable task of disarming it). And when he gets to the bomb, he’s instructed to “cut the blue wire with a white stripe — not the black wire with a yellow stripe” in order to disable it.

Easy enough, right? The problem is that our hero is using a glow stick as a light source, and under its yellowish light he can’t accurately determine which wire is which; they both look exactly the same. So after a bit of indecision, preparing to cut one but changing his mind, he goes ahead and cuts a wire. Lucky for him, it was the right one.

While here at the Cisco PSIRT we do not have to deal with such explosive situations (well, maybe not in a physical sense), we do, however, think that making security decisions based on incomplete data is certainly not a good approach. And this is why our vulnerability disclosure process keeps evolving over time.

Here are some of the changes we have implemented over the years, in order to provide our customers with more data on which to base their security decisions:

Based on our own analysis of the current security landscape, and feedback from our customers and partners, we think there is the need for another change to our process: an evolution that will provide our customers with additional data on which to base their security decisions when it comes to Cisco products.

Starting on January 2011, any bug that has been reported to the Cisco PSIRT but will not be disclosed as part of a Cisco Security Advisory will include a “PSIRT Evaluation” section within its Release Note. The Release Note Evaluation (RNE) section will include, where appropriate and relevant, base and temporal CVSS scores and one or more CVE IDs. However, not all bugs will include a CVSS score or a CVE ID.

The inclusion of a CVSS score will assist our customers in performing their triage and risk assessment, allowing them to better identify mitigations and corrective actions, if and when needed. In addition, including CVE IDs allows for easier correlation with external databases and other network and security management tools.

But why is it that some bugs will not get a CVSS score or a CVE ID? There are cases in which something is reported to us for evaluation but it isn’t an actual vulnerability.  Such examples include (but are not limited to):

In these cases, we will still include a “PSIRT Evaluation” as part of this process change, but the bug will not be assigned a CVSS score or a CVE ID.

And last, but not least: I’m sorry but at this time we won’t provide wire cutters, glow sticks, diving gear or instructions on which wire to cut.

In an effort to keep conversations fresh, Cisco Blogs closes comments after 90 days. Please visit the Cisco Blogs hub page for the latest content.


  1. What about vulnerabilities stemming from misconfiguration, will Cisco be adopting the Common Configuration Scoring System (CCSS) for them?

    NIST released the final version of NIST IR 7502 Common Configuration Scoring System (CCSS); Metrics for Software Security Configuration Vulnerabilities today:


Trackbacks and Pingbacks:

  1. Return to Countries/Regions
  2. Return to Home
  1. All Security
  2. All Security
  3. Return to Home