Open Stack

> 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.mcpeak at hp.com] 
Sent: Wednesday, August 5, 2015 6:15 AM
To: openstack-dev at 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
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7586 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150805/ad2621eb/attachment.bin>