Add Anchore go dependency security scanning, investigate others

[dfarrell07]

What would you like to be added:

Scanning for known vulnerabilities in the container images we publish, and a feedback loop from that scanning to highlight the problem and encourage a fix. Some scanning already happens on Quay, but we don't do anything with that information.

For example: https://github.com/marketplace/actions/anchore-container-scan.

As a different type of scanning, we may also want to look into: https://github.com/octarinesec/kube-scan

Why is this needed:

More security more better.

[skitt]

Here’s a test of the Anchore container scan: https://github.com/submariner-io/submariner/pull/797

Uploading the SCARIF results involves participating in the security scanning beta, I’m in the queue for my fork of Submariner.

[skitt]

Additional thoughts: our containers are designed to be as up-to-date as possible based on their base image, except for non-packaged dependencies. The only image which could have undiagnosed, actionable security problems is our base Dapper image; our production images are all based on software which is already tracked by the security teams of the distributions we use.

So ultimately, as long as we regularly rebuild our container images, it’s all about our Go dependencies, and dependencybot is already supposed to track that.

If we ever start supporting multiple streams, with long-term releases, this will become harder to deal with, but until we’re there, we’re in pretty good shape.

[dfarrell07]

Collecting a few more maybe-useful tool options:

https://github.blog/2020-09-30-code-scanning-is-now-available/ https://docs.github.com/en/free-pro-team@latest/github/finding-security-vulnerabilities-and-errors-in-your-code/enabling-code-scanning-for-a-repository https://lgtm.com/

[stale[bot]]

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.

[skitt]

This is still relevant.

[stale[bot]]

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.

[tpantelis]

bump

[stale[bot]]

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.

[tpantelis]

bump

[stale[bot]]

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]

The CNCF has some partnerships we might be able to leverage here.

[dfarrell07]

@Jaanki mentioned there's a tool Polaris that might be useful here. Something like: https://github.com/devsecops-test/polaris-action

[stale[bot]]

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.

[maayanf24]

This has been discussed on the issue scrub meeting and decided to close for now. If this will become a priority it can be reopened

[dfarrell07]

Looking at this more, it seems like this would have caught the current Lighthouse text lib CVE before downstream scanning caught it, which would be much lower cost to fix than waiting for it to be in a release downstream.

Also discussed on the scrub, re-opening and will handle as a part of that fix.

[dfarrell07]

This looks interesting, but not ready for use yet:

https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck

[dfarrell07]

This also looks interesting, but we'd need a Snyk account.

https://marketplace.visualstudio.com/items?itemName=redhat.fabric8-analytics

[dfarrell07]

I did this for Lighthouse with:

• https://github.com/submariner-io/lighthouse/pull/798
• https://github.com/submariner-io/lighthouse/pull/819
• https://github.com/submariner-io/lighthouse/pull/820

[dfarrell07]

It would be interesting to check if CodeQL identifies anything not found by other tools.

https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning-with-codeql https://codeql.github.com/

[dfarrell07]

For the main repo:

• https://github.com/submariner-io/submariner/pull/1961
• https://github.com/submariner-io/submariner/pull/1968

[dfarrell07]

And the rest of them:

• https://github.com/submariner-io/submariner-operator/pull/2181
• https://github.com/submariner-io/subctl/pull/217
• https://github.com/submariner-io/admiral/pull/400
• https://github.com/submariner-io/cloud-prepare/pull/357
• https://github.com/submariner-io/coastguard/pull/73
• https://github.com/submariner-io/shipyard/pull/920

[dfarrell07]

It would be interesting to check if CodeQL identifies anything not found by other tools.

https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning-with-codeql https://codeql.github.com/

Evaluating CodeQL vuln variant analysis here: https://github.com/dfarrell07/lighthouse/pull/6

The Go security rules are here (I don't see better docs): https://github.com/github/codeql/tree/main/go/ql/src/Security

[dfarrell07]

I used LGTM.com to run CodeQL against all the submariner-io repos. The test I did in Lighthouse was just unlucky to not see any new issues, there are other (minor from what I see so far) issues in other repos.

[dfarrell07]

[dfarrell07]

This is done. :heavy_check_mark: