Re: pulling in other vulnerability databases
On Thu, Jan 25, 2018 at 1:12 AM, Antoine Beaupré wrote:
> Okay, so this is a broader, recurring problem we have with the security
> tracker right now... From my perspective, I've always and only used CVEs
> as unique identifiers for vulnerabilities in my work in the security
> tracker. When that was not possible, say because a CVE wasn't issued
> yet, CVE-YYYY-XXXX templates were used, which leads to ugly TMP-FOO
> markers in the web interface.
That is how things are supposed to work indeed.
> Are you saying there are ways, right now, in the security tracker, to
> use non-CVE identifiers as unique markers in a meaningful way?
Not AFAIK. I think that having non-CVE identifiers on hand is a useful
but secondary goal. Achieving the primary goal also makes it easier to
achieve this too.
I'm mainly pointing out we need better automated ingestion of
vulnerability data for multiple reasons:
Mitre is *very* slow at unrestricting CVE information after a project
has published advisories, just look in CVE/list for things that are
still RESERVED but we have data for.
There are more vulnerability databases than just CVEs and this problem
is not going to go away. Some of these may (partially) overlap with
the CVE database.
The manual ingestion of vulnerability information into the security
tracker currently falls mainly on just one person (carnil). Having
just one person do all of that work isn't fair on them and does not
scale. If we automate more ingestion then there will be less latency
and he will have less work to do and be able to focus more on other
things like vulnerability feeds that aren't automatable (like mailing
lists).
> we discussed using BTS bug numbers in the past, but right now
> those are, as far as I know, bound to entries in data/CVE/list only.
Correct.
> Where should we start to implement the above? Any pointers to where a
> Python dev might look in the security-tracker source to actually work on
> this? It seems this would also affect the DSA/DLA release process - i
> think it *is* possible to actually release a CVE-less DSA right now, but
> I wonder if the process would stall in other places...
First we should decide if we want non-CVE identifiers and define how
we want to represent non-CVE identifiers in data/CVE/list. I would go
for yes and something like this:
CVE-2017-17565 (An issue was discovered in Xen through ...)
...
ID: XSA-251
Next the database would need an additional identifier mapping table.
The CVE page could then also list XSA-251 in the Name field, linked to
the canonical location for XSAs.
The search field could be used to lookup XSAs and redirect to the
right CVE page, just like we do for BTS entries.
After that I'm not sure, but I think I would look at how the
'automatic updates' commits happen and then extend that process to
include other types of data feeds than just the CVE one. I started a
list of possible feeds in check-external/sources.ini
I think the GSoC or Outreachy would be an ideal way to achieve this
and wrote a proposal a couple of years ago, but couldn't find anyone
interested in mentoring it. ISTR last time I brought up this idea it
was dismissed as a bad idea.
https://wiki.debian.org/SummerOfCode2015/ProjectProposals/SecurityTrackerCheckExternal
> And are we admitting here that we should just give up on the CVE process
> in those cases? Or should we make an effort (say like we do in reporting
> bugs against packages in teh BTS) to actively seek CVE identifiers for
> vulnerabilities that lack them, like I did for the jquery issues?
I don't think it is a good idea to give up on the CVE process and I
think doing so would be a violation of the Debian Social Contract. In
my opinion it would be a good idea (modulo workload issues) to seek
CVE identifiers for vulnerabilities reported in all vulnerability
databases, just like is done for the BTS (tag=security is kind of a
vuln db) and other locations.
> Sorry to bring so many questions and so few answers, but I figured it is
> useful to actually scope out the problem better before starting an
> implementation. :)
Quite.
--
bye,
pabs
https://wiki.debian.org/PaulWise
Reply to: