Re: [openstack-dev] [Security] Would people see a value in the cve-check-tool? (Reshetova, Elena)
> I guess it depends on whether the tool needs to read the entire database to perform its queries (in which case using AFS would be basically the same as downloading). I am including below the reply from Michael, cve-check-tool maintainer, and also including him in this conversation. " Right now we force-update the database every 4 hours as this is roughly how often the NVD DB is centrally updated with new/modified entries. This behaviour can be disabled, and cve-check-update can be run to manually update. We download all of the NVD XML feeds and convert them into a local sqlite3 database for faster usage. What you're proposing sounds more like making cve-check-tool run as a Security As A Service setup, which is feasible. Would they be hosting internal copies of the XML feeds or prefer a central remote DB to be used here?" -Original Message- From: Jeremy Stanley [mailto:fu...@yuggoth.org] Sent: Wednesday, August 5, 2015 10:16 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Security] Would people see a value in the cve-check-tool? (Reshetova, Elena) On 2015-08-05 09:54:52 -0700 (-0700), Clint Byrum wrote: > Doesn't this feel like a job for AFS? Maintain the db there, and let > the nodes access it as-needed? I guess it depends on whether the tool needs to read the entire database to perform its queries (in which case using AFS would be basically the same as downloading). -- Jeremy Stanley __ 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 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
Re: [openstack-dev] [Security] Would people see a value in the cve-check-tool? (Reshetova, Elena)
> 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
Re: [openstack-dev] Would people see a value in the cve-check-tool?
> Arguably also 3. lots of CVEs which aren't applicable for some reason, so we likely need a means to whitelist those and filter them from the report. cve-check-tool supports whitelisting and won't report the CVEs that have been marked as "ignore". The temporal faux format that I am filling in the python wrapper has a place to put such CVEs. So, only thing that would be needed from your side is to define how/where you want to store list of CVEs to be ignored for each package and I can process them in the wrapper similarly. Best Regards, Elena. 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
Re: [openstack-dev] Would people see a value in the cve-check-tool?
Hi Adam, Thank you for your suggestion! I will send also this proposal to openstack-security@. I have previously attached the wrapper python class to the email, but it seems that it didn’t reach people. Let me try again (now in a form of an archive) and see if it goes through this time. Best Regards, Elena. From: Adam Heczko [mailto:ahec...@mirantis.com] Sent: Monday, August 3, 2015 3:18 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Heath, Constanza M; Ding, Jian-feng; Demeter, Michael; Bhandaru, Malini K Subject: Re: [openstack-dev] Would people see a value in the cve-check-tool? Hi Elena, the tool looks very interesting. Maybe try to spread out this proposal also through openstack-security@ ML. BTW, I can't find the wrapper mentioned - am I missing something? Regards, Adam On Mon, Aug 3, 2015 at 11:08 PM, Reshetova, Elena mailto:elena.reshet...@intel.com> > wrote: Hi, We would like to ask opinions if people find it valuable to include a cve-check-tool into the OpenStack continuous integration process? A tool can be run against the package and module dependencies of OpenStack components and detect any CVEs (in future there are also plans to integrate more functionality to the tool, such as scanning of other vulnerability databases and etc.). It would not only provide fast detection of new vulnerabilities that are being released for existing dependencies, but also control that people are not introducing new vulnerable dependencies. The tool is located here: https://github.com/ikeydoherty/cve-check-tool I am attaching an example of a very simple Python wrapper for the tool, which is able to process formats like: http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt and an example of html output if you would be running it for the python module requests 2.2.1 version (which is vulnerable to 3 CVEs). Best Regards, Elena. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Adam Heczko Security Engineer @ Mirantis Inc. wrapper.zipx Description: Binary data 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
[openstack-dev] Would people see a value in the cve-check-tool?
Hi, We would like to ask opinions if people find it valuable to include a cve-check-tool into the OpenStack continuous integration process? A tool can be run against the package and module dependencies of OpenStack components and detect any CVEs (in future there are also plans to integrate more functionality to the tool, such as scanning of other vulnerability databases and etc.). It would not only provide fast detection of new vulnerabilities that are being released for existing dependencies, but also control that people are not introducing new vulnerable dependencies. The tool is located here: https://github.com/ikeydoherty/cve-check-tool I am attaching an example of a very simple Python wrapper for the tool, which is able to process formats like: http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints. txt and an example of html output if you would be running it for the python module requests 2.2.1 version (which is vulnerable to 3 CVEs). Best Regards, Elena. 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
