I'm curious about what the values in the bug id represent. For example. All bug ids start with CSC followed by two letters and a series of numbers. Do the two letters represent anything beyond random unique values? I was hoping that by looking at the release notes for a new code release, that I could easily identify what type of bugs were fixed. More specifically in my case, I want to easily identify if security vulnerabilities were fixed in a particular code release without having to maintain a comprehensive list of all the security bugs.
Short answer: No special meaning, just a sequential counting identifier.
DDTS (Distributed Defect Tracking System from Rational Software was the original bug tracking system that Cisco installed in the early 1990s for the software that would eventually come to be known as Cisco IOS. The bugid format enforced by the software at the time was XXXxxNNNNN. Remember, 1990 was pre-web - this was all 80x24 terminal screen and character based. Pre-Y2K bugs. A long time ago in a galaxy far, far away.
At the time the lettering was selected:
CSC was for "Cisco Systems Corporation"
di was for "Defect Identifier"
and then the number was just a sequential defect number.
So the earliest bugs were of the form CSCdi12345.
This went well until the 100,000th bug!
At that time, it was decided to increment the letter, to dj, dk, dl, etc etc. as it it were just a counting digit. CSCekXXXXX is the highest set I see in the 12.4 release notes.
Don't be alarmed that the number is so high - defect identifiers are assigned for ALL defects and also a lot of administrative testing events, including ones in internal testing and very early development. A small fraction of identifiers apply to released code.
At some point, the IOS "S" family of releases picked new two-letter baseline for some classes of bugs. "sa" formed the baseline defect identifier for a revised code base, and I see bug identifiers in the CSCtcXXXXXX range at this point. It seems that the 15.0 release now uses that "sa-and-higher" counting index, as does the ASA. I'm not sure what event moved people to start using the "sa" baseline.
I think some other Business Units may have picked other baselines, but it is most appropriate to think of the two-letters-and-five-numbers at the end of a bugid as just a 7 digit number with base-26 as the high order bits.
There is no specific signifigance to the lettering, just a lot of history.
Athough DDTS was replaced some time ago, so many tools orbiting the system expect the CSCxxXXXXX bugid form that its use persists to this day.
I'm not aware of any way to easily accomplish what you'd like. Here are the options I can think of:
Bug ToolKit (Known affected Version)
Release note for the SW version (OPEN / Closed Caveats)
Security Advisory itself.
Not much can be gleaned from the bug id itself.