Hi, I spoke with Sam, and he advised I should file a bug with what I reckon would be useful in the GLSAs that goes out. So here is my "list" * CVSS - separate field ideally (we parse from glsa-check -d). * Impact invariably states to refer to CVEs. This would be more useful to actually state something sensible. * Description - invariably states to refer to CVEs, would be much more useful if the CVE text could be made available here. * json dump (easier to auto-process than parsing glsa-check -d) I would recommend: * The CVE numbers become a separate field, eg: CVE Numbers: x, b, c Impact: flag1, flag2 * The description be grabbed from the associated CVEs. Although these generally are vague as can be in order to not reveal clues (Personally I say spill the beans so that the rest of us can make an assessment, and get those that think this is a joke a proper scare so that they too can start to realise that security updates are important). Looking at https://en.wikipedia.org/wiki/Common_Vulnerability_Scoring_System one could conveivably create a field for each individual metric and a flag for each setting which this can be at. But I suspect that may be overkill. This would make parsing and evaluation of whether we care about a specific vulnerability for a give system much more viable. For example, let's say there is a vulnerability in rsync that requires network access, but rsync isn't running as a service, I may decide to not care. I don't have this all nailed down yet, but the plan is to at a minimum use the CVSS scores (which I realise is only a guideline) to at least prioritise which servers/services needs to be upgraded/evaluated first. A more useful filter may be something that requires local access, I could decide to just completely ignore that, or de-prioritise to after anything that could be exploited remotely. Note that prioritising 200+ servers by hand is hard. So help from GLSA side to achieve this would be most helpful. We will likely map something like CVSS >= 8.0 straight to critical alert, whereas other vulns could conceivable be classed anything from high all the way down to low. And then handled in a more sensible ordering that first come first serve which we're currently (mostly) following. One do need to keep in mind that the CVSS are based on assumptions, which may or may not apply in specific environments, so anyone reading this: Security is more involved than a simple score. Use your discretion, which you can only do if you understand the vulnerabilities in question. CVSS is merely a guideline and helps you to infer what should likely take priority, and what can possibly wait a bit. In the end, a "local only" exploit could be the nail through which you get bitten remotely if compounded by another weakness that can be attacked remotely. Reproducible: Always
