@sbs2001 re:
time to review nexB/vulnerablecode#236 , it is based off nexB/vulnerablecode#231 which was just a refactor. nexB/vulnerablecode#236 has changed alot of things I think you should review it and ignore the old PR.
On my plate :+1:
VulnerableCode :)
@copernico @inksong @edoardolanzini , I want to write an importer for NVD. IMHO it desirable to avoid collecting of vulnerabilities whose impact is limited to closed source software or hardware and avoid the fluff. We just want NVD for the reference urls and scores.
My approach is to classify the vulnerabilities into closed source and open source via looking for keywords in the references as well as cpes. For instance if I see 'apple' in a cpe I can safely ignore that vulnerability, or if I see 'apache' in a cpe I can collect the vulnerability.
What other approaches are available to do this classification ?
5 replies
1 reply
- The line-length should be ~60 characters.
- The font-size should be decreased for such paragraphs.
- Most of the design spans over the device-width, rather, there should be appropriate margins on the sides, .container class should be used [Bootstrap]
- We can't delete any of our created vulnerabilities and packages.
- The same vulnerability can be added to the "Vulnerable To" as well as the "Safe To" section simultaneously.
I can even come with some quick wireframes to help make the platform aesthetically better by the next week if you are willing to iterate. Otherwise, the aforementioned points about correcting the margins would be great as well.
cc: @pombredanne @sbs2001
Thanks @nitin10s I understand most of your points, and they make perfect sense.
As for
what are packages
This was expected, we use purl(the pkg:type:name strings) to represent packages, you can check https://github.com/package-url/purl-spec for more info.
We can't delete any of our created vulnerabilities and packages.
That's true, infact we can't delete any vulnerability and packages. What we can do instead is delete/create relations between them. I'm not so sure about adding the delete functionality.
The same vulnerability can be added to the "Vulnerable To" as well as the "Safe To" section simultaneously.
This has a long story with it. You won't be able to do it once nexB/vulnerablecode#239 gets merged. That being said we should have a way of telling the user that they messed up.
Other than that I'm off to implementing your suggested changes for now and would ask for extra clarification if required. Thanks again for the detailed review, I really appreciate this.
refsource is supposed to mean in NVD's json feeds n [22]: xc['CVE_Items'][0]['cve']['references']
Out[22]:
{'reference_data': [{'url': 'https://source.android.com/security/bulletin/2020-01-01',
'name': 'https://source.android.com/security/bulletin/2020-01-01',
'refsource': 'CONFIRM',
'tags': ['Vendor Advisory']}]}In [27]: rsc = set()
In [28]: for it in xc['CVE_Items']:
...: for ref in it['cve']['references']['reference_data']:
...: rsc.add(ref['refsource'])
...:
In [29]: rsc
Out[29]:
{'BUGTRAQ',
'CERT',
'CERT-VN',
'CISCO',
'CONFIRM',
'DEBIAN',
'EXPLOIT-DB',
'FEDORA',
'FREEBSD',
'FULLDISC',
'GENTOO',
'HP',
'IBM',
'JVN',
'MISC',
'MLIST',
'N/A',
'REDHAT',
'SUSE',
'UBUNTU',
'XF',
'https://www.tenable.com/cve/CVE-2020-5756',
'https://www.tenable.com/cve/CVE-2020-5757',
'https://www.tenable.com/cve/CVE-2020-5758',
'https://www.tenable.com/cve/CVE-2020-5759'}CONFIRM supposed to mean
