On 8/5/15, 08:14, "McPeak, Travis" <travis.mcp...@hp.com> wrote:
>(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. One point of clarification. Not every project has to opt into global-requirements so this isn't necessarily true. Also with the merging of the stackforge and openstack namespaces, it'll be harder to distinguish when a project is or isn't using g-r since in the past it was fairly safe to assume that stackforge/ projects were more likely to not use g-r. > >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 >> >> __________________________________________________________________________ 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