> The only concern that I have is the requisite database. Downloading a 500MB + CVE database for the jobs could become painful. We could either keep the CVE database on each node in the test pool or download it at the start of each cve-check job. I¹d >be curious what the infra wizards have to say.
Actually the database is downloaded only once ( thefirst time) and then only database diffs are downloaded, which is much faster. I don't know enough about your node setup (do you fully clean up each node between the builds?) and etc., so the best way to test this would be if somebody can try it out and tell if it is a problem. If it is a problem, then we can discuss with the tool maintainer on how to address it. >I¹d also really like to see what the baseline results look like. If you run it against current global requirements does it find legitimate issues? Does it find false positives. In any case it seems worth exploring as vulnerabilities in upstream dependencies are a >key weakness in our current system. I have so far only run the tool against this file: http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints. txt and it didn't find any issues in it, given that the version there is taken as minimal supported version. I am myself not actually working in the OpenStack project (so please excuse my ignorance on some even basic matters), but I am actually a bit confused why this file for example called "upper-constraints"? The name would indicate an upper border, but that doesn't make that much sense with packaging systems. If you can point me to a full set of files that should be analyser with cve-check-tool, I can do the runs and post results here. Best Regards, Elena. -----Original Message----- From: McPeak, Travis [mailto:travis.mcp...@hp.com] Sent: Wednesday, August 5, 2015 6:15 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Security] Would people see a value in the cve-check-tool? (Reshetova, Elena) (Merging thread from security ML) Bandit probably isn¹t the correct integration point for this - cve-check has its own analysis procedures while Bandit uses Python AST. Also I see the use workflows being different. For Bandit a developer/gate wants to check a specific code snippet whereas for cve-check to be effective it really needs to examine the entire dependency chain. As Rob and I mentioned earlier a gate process on ³openstack-requirements² seems like an ideal target for this. The idea would be anytime a requirement is added (for example to enable a newer version or an entirely new library to be used) we could run a cve-check job that ensures the new library (or version) doesn¹t have any known CVE¹s against it. This way we can be covered across OpenStack (since OpenStack projects can¹t use Libraries that aren¹t in global requirements). The gate processing time is minimal since it doesn¹t have to run for each project. The only concern that I have is the requisite database. Downloading a 500MB + CVE database for the jobs could become painful. We could either keep the CVE database on each node in the test pool or download it at the start of each cve-check job. I¹d be curious what the infra wizards have to say. I¹d also really like to see what the baseline results look like. If you run it against current global requirements does it find legitimate issues? Does it find false positives. In any case it seems worth exploring as vulnerabilities in upstream dependencies are a key weakness in our current system. >Hi folks! > >Idea really looks good. > >I am attaching an example of a very simple Python wrapper for the tool > > >Looks like this wrapper is lightweight. But maybe try to integrate it >with Bandit and not to create a new tool? > >--? >Victor Ryzhenkin >freerunner on #freenode > >
smime.p7s
Description: S/MIME cryptographic signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev