Note from Tom: I’ve just started a new blog on Substack called “Tom Alrich’s blog, too”. From now on, all my new posts will appear there; however, the posts having to do with NERC CIP (and other issues of primary interest to the electric power industry) will continue to appear in Energy Central.
A subscription to the Substack blog costs $30 per year (or $5 per month); anyone who can’t pay that should email me. Until August 11, I will continue to put up all posts in Energy Central. However, after that date you will need a paid subscription to continue reading my posts on topics other than NERC CIP, like vulnerability management and vulnerability databases. If you wish to continue receiving my non-NERC CIP posts after August 11 – which I hope you will! – please sign up for a paid subscription to the Substack blog at the link above.
I’ve written a lot about the travails of the CVE Program, which for about 24 hours in April looked like it might disappear from the face of the earth. However, I’m pleased to report that the future of the Program looks bright – although there’s a significant cloud on the horizon that needs to be addressed (more on that in one of my next posts).
The reason why I’m optimistic about the future of the CVE Program is the CVE Foundation, which was in the process of being formed before the crisis in April, but is now on the way to becoming a solid nonprofit organization (it’s now led by my friend Pete Allor, former Director of Product Security for Red Hat and still an active member of the CVE Board. Pete has been active in the CVE Program since the CVE concept was introduced in 1999). I will elaborate on this point in another near-term post.
The CVE Foundation recently announced the publication of a white paper called “Ensuring the Longevity of the CVE Program” by the Center for Cybersecurity Policy and Law. While the paper has some good background information, I didn’t find it particularly new or inspiring – although I must admit I believe that no large marine mammals were harmed in writing the paper.
However, there was one quasi-suggestion in the paper that I think is quite dangerous. If it were followed (which it won’t, I’m sure), that could cause serious long-term damage to the CVE Program. On page 8, in a section suggesting possible funding sources, there’s a bullet point that reads, “Private sector - Vendors worldwide use CVE as the standardized form of vulnerability management, so the private sector should be considered as a funding source. Questions around vendor funding to gain leverage in modifying the CVE priority agenda would need to be addressed.” (emphasis mine)
The last sentence seems to say two things:
1. Vendors will likely offer funding to the CVE Program on the condition that they “gain leverage” in helping the Program decide what should be its priorities in improving the program or the CVE Schema (which is at the heart of the CVE Program). I totally agree that vendors will request this. They wouldn’t be doing their jobs if they didn’t request it.
2. The CVE Program should consider how they will respond to those requests. I have a suggestion for how the program should respond: It should say no. I can’t think of a better way for the program to damage its reputation than for it to even consider accommodating these requests.
The CVE Program is always considering new projects. I doubt there’s any serious user of CVE data that couldn’t rattle off ten things the program should do[i]. When somebody’s pet project is put off for a year or two (or even longer than that), they have reason to be unhappy. However, if it becomes known that priority in the project queue is a commodity that’s now available to the highest bidder, that will make a lot of people very unhappy. And justifiably so.
If you would like to comment on what you have read here, I would love to hear from you. Please comment below or email me at [email protected].
[i] For almost a year, I’ve been pushing one project: adding purl as a second possible software identifier in CVE records, besides just CPE. Fortunately, it looks like that may happen - or at least start to happen - by the end of the year.