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.
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.
-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
<mailto: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
<mailto: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
<mailto:opnfv-secur...@lists.opnfv.org>
https://lists.opnfv.org/mailman/listinfo/opnfv-security
<https://lists.opnfv.org/mailman/listinfo/opnfv-security>
--
Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat
e: lhi...@redhat.com <mailto: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
