Do periodic license scanning on images and build artifacts

[killianmuldoon]

Following on from https://github.com/kubernetes-sigs/cluster-api/issues/9181 there may be a need in CAPI to find a good way to scan for forbidden licenses in our release artifacts - namely our controller images and the clusterctl binaries.

There are a few tools out there that can do such a scan:

Trivy

• Currently used for our code-level license scans on PRs.
• Can run and report without needing a token or integration with an external service.
• Same tooling as we currently use for PRs and for periodic security scans
• Currently detecting GPL licenses in our base image distroless:nonroot. These are not being picked up by the other scanners.

Snyk

• Used for a periodic scan for upstream Kubernetes. The current version of the scan ignores license information.
• Requires a Token, but we might be able to share the one used by Kubernetes or find out where they got theirs from.
• Can be used from CLI with report output to file

Fossa

• Seems to be the preferred tool for CNCF projects
• Requires a Token, but we might be able to get one from the CNCF.
• Requires access to the web service for license scanning and reporting.
• Seems easiest to run using a github action with the key

There's still ongoing conversation in the Kubernetes community about this.

My preference would be to defer the conversation for CAPI until we have some idea of the preferred direction from the community. None of the tools above seem to be a great fit for now. If someone has time to take this on though it could be really helpful for CAPI and the broader community.

[killianmuldoon]

/help

[k8s-ci-robot]

@killianmuldoon: This request has been marked as needing help from a contributor.

Guidelines

Please ensure that the issue body includes answers to the following questions:

• Why are we solving this issue?
• To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
• Does this issue have zero to low barrier of entry?
• How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed by commenting with the /remove-help command.

In response to [this](https://github.com/kubernetes-sigs/cluster-api/issues/9436): >/help > Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

[sbueringer]

Thx for all the research that went into this so far and writing up a very clear summary.

Did you mean controller & clusterctl images? I think the clusterctl binaries should be covered by the "code-level" scan.

I think if someone has time to take this on, it would be probably best invested in pushing the community discussion forward, so that Cluster API can eventually just share a solution with the wider community.

[killianmuldoon]

Did you mean controller & clusterctl images? I think the clusterctl binaries should be covered by the "code-level" scan.

I also mean the binary, though I basically agree it should be covered by the code level scan. It wouldn't hurt to find something that covers all of our release artifacts.

[fabriziopandini]

q: does this cover both binaries (clusterctl) and images?

[killianmuldoon]

does this cover both binaries (clusterctl) and images?

The issue does, but the tooling may or may not.

[fabriziopandini]

ACK, let's keep this in mind while we assess different tools

/triage accepted

[fabriziopandini]

/kind feature /priority important-soon

[k8s-triage-robot]

This issue is labeled with priority/important-soon but has not been updated in over 90 days, and should be re-triaged. Important-soon issues must be staffed and worked on either currently, or very soon, ideally in time for the next release.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Deprioritize it with /priority important-longterm or /priority backlog
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

[sbueringer]

/priority important-soon /triage accepted

[fabriziopandini]

Another option to consider https://github.com/google/go-licenses