Add dependency license scanning linting

[dfarrell07]

What would you like to be added:

License scanning paralleling the CNCF periodic license scanning, to make sure that all of our code and dependencies use a CNCF-approved license.

Some CNCF scanning details are here, but need to dig for more details about our tooling options:

kubernetes/steering#57

Why is this needed:

To ease integration with other CNCF projects.

[dfarrell07]

This might be a good option: https://github.com/google/go-licenses

[stale]

This issue has been automatically marked as stale because it has not had activity for 60 days. It will be closed if no further activity occurs. Please make a comment if this issue/pr is still valid. Thank you for your contributions.

[dfarrell07]

Bump

[dfarrell07]

This was done by @skitt in a series of PRs like #1066.

[dfarrell07]

This was done by @skitt in a series of PRs like #1066.

NVM, this issue is actually about checking the licenses of dependencies, not Submariner. Still should look into google/go-license.

[dfarrell07]

The CNCF application process says we need to follow CNCF IP rules, which in turn say:

All projects evaluated for inclusion in the CNCF shall be completely licensed under an OSI-approved open source license. If the license for a project included in CNCF is not Apache License, Version 2.0, approval of the Governing Board shall be required.

I guess that means we need to be confident that all of our dependencies use OSI-approved licenses.

[skitt]

The CNCF application process says we need to follow CNCF IP rules, which in turn say:

All projects evaluated for inclusion in the CNCF shall be completely licensed under an OSI-approved open source license. If the license for a project included in CNCF is not Apache License, Version 2.0, approval of the Governing Board shall be required.

I guess that means we need to be confident that all of our dependencies use OSI-approved licenses.

A quick check through our vendor directories shows ASL 2, MPL 2, ISC, MIT, 2- or 3-clause BSD, and “unlicense”, which are all fine.

[skitt]

This is still relevant.

[skitt]

I’m looking into Snyk for this (see also https://twitter.com/snyksec/status/1387089315465998343).

[skitt]

So Snyk isn’t great; it looks at all transitive dependencies, including those which we don’t use (basically, it uses go mod graph when what we really care about is go list -deps -test). https://app.fossa.io/reports/dce31219-52a8-4d88-903d-3885f427bba6 suggests that FOSSA might be better, I’ll look into that next.

However, I think it would be good to make this part of our PR checks, so that variations in dependencies and their licenses are flagged at PR merge time and not in a periodic report. We should only care about adding dependencies on PRs, so I’m not suggesting we run security scans in PRs, but storing the known list of calculated dependencies and the licenses used by artifacts which end up in our binaries (see https://github.com/mitchellh/golicense) would be good — that way, if developers don’t realise they’re changing the dependency tree, the PR will fail, but they can fix it by updating the catalog (and tooling will be provided to do this). We did this successfully in OpenDaylight for the odlparent project.

[skitt]

https://app.snyk.io/org/skitt/project/88cc8844-35fa-4fdc-8e74-61bfa8231dd7 is a report on Submariner’s go.mod. It highlights some relevant issues (or rather, CVEs in dependencies we really do use, although the security issues themselves don’t affect us — I’ll fix those), but most of the report lists dependencies which we don’t actually use (etcd, miekg/dns, Docker...).

[skitt]

I’m also filing issues or submitting PRs for our dependencies as appropriate, e.g. onsi/gomega#441 and kubernetes-sigs/mcs-api#6.

[skitt]

FOSSA sign-up is failing for me currently.

[dfarrell07]

We talked about this on the automation sync today and will focus on https://github.com/mitchellh/golicense