retry snyk docker scanning

[mcandre]

Tasks:

• [ ] Setup GitHub Actions to run docker scan --accept-license --severity medium <parent image> on a weekly basis.
• [ ] Ensure security scan alerts project owners, but does not block any build/release pipelines. Developers need to be able to continue pushing various fixes and improvements, in spite of any CVE's, not blocked indefinitely by the existence of CVE's.

Projects:

• [ ] tug
• [ ] snek

[mcandre]

docker scan --accept-license <image>

Docker's Snyk integration is still buggy and constrained. For best effect, focus on scanning the parent image. Use other scanning tools to check for any CVE's added by your application's OS packages and/or programming language packages.

To keep up with security alerts, both the docker scan process and the image build & publish process, must be rerun at regular intervals, such as once a week. That assumes a CI/CD pipeline, as well as a Docker-in-Docker setup with buildx support.

[mcandre]

Advised to omit low level CVE's: They're too numerous, and by the time the upstream OS distribution actually gets around to patching them, yet more crop up. Focus on medium/high/critical CVE's instead.

This is all a moot point until critical level CVE's get fixed in upstream, reasonably stable OS Docker images.

https://snyk.io/vuln/SNYK-DEBIANUNSTABLE-LIBARCHIVE-2434850

At this writing, the Alpine 3.15 image finally appears to feature no known CVE's, according to Snyk. We could try refactoring the non-musl toolchain images to use an Alpine build environment. Or Fedora. Or Gentoo (shudder) I think Debian historically has one of the least immature cross-platform toolchains, so we could just wait the problem out.

Fortunately, snek does not currently maintain a Docker image for snek itself, but rather transient toolchain images for various snek target build processes. The end user should not be impacted much beyond any faults in gcc/clang. The vast, unpatched list of CVE's for most Docker images spells doom for runtime applications. But here, we are simply offering developers what buildtime tools we can.

Furthermore, Docker's Snyk integration appears to have neglected to provide the fundamental Snyk ability to skip unactionable security reports. That means, any automated alerting or CI/CD usage of docker scan will result in 90% noise. Which promotes a lazy security posture of ignoring ALL security alerts.

Like a good linter, a good security scanner should emphasize specific, actionable steps to improve the application. Rather than generating useless noise. It's one thing for a department to file away a 0-day, unpatched problem. But we need a better balance of security and productivity.

Pending https://forums.docker.com/t/docker-scan-offer-option-to-skip-unactionable-results-like-the-ordinary-snyk-cli/123189