Hi Luke, there are several kind of projects in Open NFV space, and I am happy that your proposal covers not only python projects. Having security job templates which we can be re-used in gates with an extensive description of how to use them is very important and helpful. My only ask would be to pay attention to how exceptions will be specified for each gate check - security, as well as lint checks have very high number of false-positive results.
Once this initiative will be ready for beta-testing I will be glad to help you do this beta-testing on Fuel. P.S. there is an interesting project in OpenStack community, called Bandit [1], which allows to run security lint for Python source code, utilizing the ast module from the Python standard library. Seems interesting to have this checks on some of the projects. References: [1] https://wiki.openstack.org/wiki/Security/Projects/Bandit On Mon, Dec 19, 2016 at 6:49 AM, Luke Hinds <lhi...@redhat.com> wrote: > > > On Mon, Dec 19, 2016 at 2:30 PM, Tapio Tallgren <tapio.tallg...@nokia.com> > wrote: >> >> Luke, >> >> Since you are checking for binary files (point 2), will you also check all >> checkouts from version control systems (like git)? I would like all of these >> to pull in explicit versions (as opposed to main), since otherwise you will >> have no idea what you are building. > > > Is this a case of opnfv code / scripts that clone in an external repo? If > you could give me an example case to help understand.. > >> >> >> We also have a similar problem with external repositories: if you install >> Linux packages from an external repository, you again have a risk that there >> are random changes to what is installed. This is fortunately mostly relevant >> for installers. > > > Understood, there is not much I believe we can do here in respect of this > work item. > >> >> -Tapio >> >> >> >> >> On 12/19/2016 03:28 PM, Luke Hinds wrote: >> >> Hi Yujun, >> >> I would need Fatih to comment as I am not that up to speed on CI. The >> following is an albeit incomplete example of how we will wire this in: >> >> >> https://gerrit.opnfv.org/gerrit/gitweb?p=releng.git;hb=refs%2Fchanges%2F71%2F25971%2F1;f=jjb%2Fsecurityscanning%2Fopnfv-security-scan.yml >> >> Regards, >> >> Luke >> >> On Mon, Dec 19, 2016 at 1:12 PM, Yujun Zhang <zhangyujun+...@gmail.com> >> wrote: >>> >>> Luke, >>> >>> I remember that Fatih once mentioned that there are no gates in OPNFV CI >>> yet. So you are talking about some additional verification jobs enforced on >>> each commit. Or it is something like the current daily/weekly job. >>> >>> Could you help to clarify it? >>> >>> On Mon, Dec 19, 2016 at 7:39 PM Luke Hinds <lhi...@redhat.com> wrote: >>>> >>>> Hi, >>>> >>>> Myself and Ash with help from Fatih are currently prototyping some new >>>> gates we plan to phase in overtime. >>>> >>>> The idea is that each commit made to an OPNFV repo will perform some >>>> checks. >>>> >>>> 1. Search for any strings containing passwords, ssh / tls certs and >>>> other stuff we don't want sitting around in repos to then be scooped up for >>>> a release. >>>> >>>> 2. Search out any binaries. We need to be very strict over what compiled >>>> binaries are packaged in release (if any at all), as a binary could be >>>> compromised (without the knowledge of the project itself). >>>> >>>> 3. Security lint checks. Code will be searched for patterns such as >>>> shell executions, xss flaws etc and reports linked within the gate. >>>> >>>> The plan is to have 1,2 as voting (-1 / +1) and 3 initially as a guide >>>> for projects, with the support of the security group, if needed. >>>> >>>> For both 1,2 we will maintain a waiver / exception list. This means that >>>> if no threat is shown to be present, an ignore entry can be made for a >>>> single project. The gate will then allow the said string, file etc to pass >>>> with no vote. >>>> >>>> Initially we are working with a sandbox project, so expect no >>>> interruptions at all. From there we will start to bring projects over, so >>>> they will be aware ahead of any changes implemented that will affect them. >>>> >>>> Cheers, >>>> >>>> Luke >>>> _______________________________________________ >>>> opnfv-security mailing list >>>> opnfv-secur...@lists.opnfv.org >>>> https://lists.opnfv.org/mailman/listinfo/opnfv-security >> >> >> >> >> -- >> Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat >> e: lhi...@redhat.com | irc: lhinds @freenode | m: +44 77 45 63 98 84 | t: >> +44 12 52 36 2483 >> >> >> _______________________________________________ >> opnfv-tech-discuss mailing list >> opnfv-tech-discuss@lists.opnfv.org >> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss >> >> >> >> _______________________________________________ >> opnfv-tech-discuss mailing list >> opnfv-tech-discuss@lists.opnfv.org >> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss >> > > > > -- > Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat > e: lhi...@redhat.com | irc: lhinds @freenode | m: +44 77 45 63 98 84 | t: > +44 12 52 36 2483 > > _______________________________________________ > opnfv-tech-discuss mailing list > opnfv-tech-discuss@lists.opnfv.org > https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss > -- Serg Melikyan, Development Manager at Mirantis, Inc. http://mirantis.com | smelik...@mirantis.com | +1 (650) 440-8979 _______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
