(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