Define what's in/out of scope vs. filtered about gsd-tools

[dbrumley]

Just to put in my $0.02 for the conversation, I think "security finding" would be a good term. Any "security finding" can be committed, and we have an extended "status" attribute such as whether "accepted", "wont fix", "resolved", "open", "in progress", and so on. Similar to when you file a bug report.

[joshbuker]

Agreed. Having as much data as possible, but all clearly labeled and filterable, is the intent of the project from my perspective; providing a centralized open-source place to discover, process/parse, and discuss security findings.

[kurtseifried]

Maybe even the more generic "security information" and then we commit to tagging that data, e.g. anything with a vendor advisory gets the "vulnerability" and "advisory" tags for example. Stuff that is confirmed as an incident but for which we don't yet have vulnerability details gets the "incident" tag (with the expectation it gets vulnerability information at some point).

[JonZeolla]

I use "finding" in this same way at my company, fairly successfully. I agree that having structured context which is easily parsable is important, allowing recipients of the information to interpret it however best fits their needs.

[kurtseifried]

One comment: once we start enriching the data we can also start tagging it, e.g.:

show me all GSD's with the tag "has_vendor_advisory" or "has_exploit_code"

and this would also allow us to better classify the data, e.g. anything acknowledged as a security vulnerability by a vendor, and/or anything with exploit code, well, that's a vulnerability. Entries without those could also be tagged as a vulnerability, with the reasoning given (e.g. the vendor may not acknowledge it, and exploit code may not be available, but there might be a clear flaw in the code or whatever).

The industry is changing, and it's not just classic vulns causing problems for us.