Re: tracking security issues without CVEs
On Tue, Mar 22, 2016 at 10:06 PM, Antoine Beaupré wrote:
> Well, the friction is one thing, but we need to adopt *one* system for
> the future, if CVEs are going the wayside (or even as a complementary
> approach).
I agree with this post from oss-security:
https://marc.info/?l=oss-security&m=145764213513572&w=2
Fracturing of the security identifier space is inevitable and already
happening to some extent even before the CVE policy changes and before
OVE/OVI/DWF/etc started; many projects have their own identifiers and
some of those don't use CVEs (notably node-security and drupal
AFAICS). Here are some examples of project-specific identifiers:
https://anonscm.debian.org/viewvc/secure-testing/check-external/sources.ini?view=markup
I think Debian needs to go towards the approach of VRDX-SIG and do
identifier cross-referencing instead of settling on *one* system for
referring to security vulnerabilities. Internally, we would continue
to use CVEs and CVE-2016-XXXX for issues without CVEs and then map all
the external identifiers onto those.
> DWF seems interesting because it incorporates CVE IDs
> directly and it also allocates CVE ranges to various projects.
> Debian could be one of those:
>
> https://github.com/distributedweaknessfiling/DNA-Registry/blob/master/DNA-Registry.csv
>
> ... and manage its own allocations.
ETOOMUCHGITHUB :)
> I am not sure I like the CSVs, however... and it doesn't seem to have
> much adoption yet:
>
> https://github.com/distributedweaknessfiling/DWF-Database/blob/master/DWF-Database-2016.csv
More available here:
https://github.com/distributedweaknessfiling/DWF-Database/blob/master/DWF-Database-2015.csv
Wow, both of those really aren't useful at all; no external references
or actionable useful information.
Either way we need to support it since it is already being used. I
have a local branch of the security tracker that has a data/DWF/list
file containing the following. Ultimately though, I think that is the
wrong approach. Instead, data/CVE/list should continue to contain all
the data and we just add {DWF-2016-89999 DRUPAL-SA-37134} to the
beginning of the entry like we do for DSA/DLA. Then the tracker needs
to grow support for extra security issue identifiers and we need a
script reading sources.ini and automatically pulling down each kind of
identifier and adding it to data/CVE/list, as we do for CVEs
themselves.
https://wiki.debian.org/SummerOfCode2015/ProjectProposals/SecurityTrackerCheckExternal
https://anonscm.debian.org/viewvc/secure-testing/check-external/sources.ini?view=markup
DWF-2016-89000 Fedora captcha system weakness
NOT-FOR-US
NOTE: https://patrick.uiterwijk.org/2016/03/09/fedora-spam-dwf-2016-89000/
DWF-2016-89001 [Shotwell does not validate TLS certificates]
- shotwell 0.22.0-3 (bug #807110)
NOTE: https://bugzilla.gnome.org/show_bug.cgi?id=754488
> Centralisation certainly doesn't scale here...
I think using debbugs or similar for CVE numbers could easily scale,
if a few features were added to it, but I doubt that will happen.
https://marc.info/?l=oss-security&m=145766818820035&w=2
--
bye,
pabs
https://wiki.debian.org/PaulWise
Reply to: