<p dir="ltr">Joshua,</p>
<p dir="ltr">On Sep 23, 2014 5:14 PM, "Joshua Kinard" <<a href="mailto:kumba@gentoo.org">kumba@gentoo.org</a>> wrote:<br>
><br>
> On 09/22/2014 16:38, Gustavo Zacarias wrote:<br>
> > On 09/22/2014 05:21 PM, Matthew Weber wrote:<br>
> ><br>
> >> I was curious if anyone has done a script similar to the "make<br>
> >> legal-info" that takes a package list and checks it against a CVE<br>
> >> database?  We're looking at doing some automated tracking of<br>
> >> vulnerabilities with our nightly builds and were at a point of putting<br>
> >> something together.<br>
> >><br>
> >> It might also be an interesting feature to expose on the Buildroot<br>
> >> website.... maybe listing the current vulnerabilities of the last<br>
> >> release and the current tip?<br>
> ><br>
> > Hi.<br>
> > I usually track CVEs and bump/fix when appropiate.<br>
> > It's mostly a mix of personal scripts, nothing too fancy that i'd like<br>
> > normal people to see in the current state :)<br>
> > The problem with actively pursuing security fixes is that it needs some<br>
> > regular manpower in patching and testing, and that's without considering<br>
> > backports (though the package infra is quite stable lately).<br>
> > There are outstanding packages that have some severe vulnerabilities<br>
> > like cups where i did a call for volunteers to bump/fix without much<br>
> > success, and i can only do so much in my free time, with cups being<br>
> > somewhat complicated to test because of varying combinations.<br>
> > It's not a task that can really be fully automated either because you<br>
> > can get a CVE for say PHP that fixes a vulnerability that only affects<br>
> > windows operating systems - there must be some context analysis as well.<br>
> > I normally try to maintain some format for my security bumps/fixes but<br>
> > that's completely informal, like:<br>
> ><br>
> > Subject: Security bump PACKAGE to version x.y<br>
> > Fixes:<br>
> > CVE-yyyy-nnnn - short description<br>
> ><br>
> > But then some other people might catch the bump before myself and there<br>
> > goes that.<br>
> ><br>
> > Something nicer would probably be like the .hash files for packages<br>
> > where we could describe the bumps that affect security and the relevant<br>
> > CVEs.<br>
><br>
> I don't know if these two sites have a formal API that's queryable, but you can<br>
> generate RSS feeds based on criteria, so maybe something programmatic can be setup:<br>
><br>
> <a href="http://www.cvedetails.com/">http://www.cvedetails.com/</a><br>
> <a href="http://www.itsecdb.com/oval/">http://www.itsecdb.com/oval/</a><br>
></p>
<p dir="ltr">Yeah, I was also looking at the cve-search tool (offline database with scheduled updates from those sites).  Where if we create buildroot scripts that query that tool.... it would lessen the access to the public sites but it would put a requirement on setting that database and apps up if you want that buildroot feature.</p>
<p dir="ltr">><br>
> Also, these deal more with cyber-threat information, but has ties into<br>
> vulnerability research and are both developed by the MITRE corporation (who<br>
> manages the CVE database):<br>
><br>
> <a href="https://stix.mitre.org/">https://stix.mitre.org/</a><br>
> <a href="http://taxii.mitre.org/">http://taxii.mitre.org/</a><br>
><br>
> --<br>
> Joshua Kinard<br>
> Gentoo/MIPS<br>
> <a href="mailto:kumba@gentoo.org">kumba@gentoo.org</a><br>
> 4096R/D25D95E3 2011-03-28<br>
><br>
> "The past tempts us, the present confuses us, the future frightens us.  And our<br>
> lives slip away, moment by moment, lost in that vast, terrible in-between."<br>
><br>
> --Emperor Turhan, Centauri Republic<br>
> _______________________________________________<br>
> buildroot mailing list<br>
> <a href="mailto:buildroot@busybox.net">buildroot@busybox.net</a><br>
> <a href="http://lists.busybox.net/mailman/listinfo/buildroot">http://lists.busybox.net/mailman/listinfo/buildroot</a><br>
</p>