Open Stack

On 8/5/15, 08:14, "McPeak, Travis" <travis.mcpeak at 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
>>
>>