[TB] Fix Docker scan vulnerabilities

[aaronreed708]

Problem/Concern

Docker scanner currently reporting vulnerabilities. This issue is to resolve the vulnerabilities so that we can publish our Docker image.

Proposed Solution

Fix vulnerabilities.

[aaronreed708]

Fixed and merged.

Waiting on word from FINOS on how to handle Docker images with vulnerabilities deemed acceptable risk.

[aaronreed708]

Relevant replies from Mao at FINOS:

I have been getting Docker scan errors for a while. For example, here: https://github.com/finos/a11y-theme-builder/actions/runs/7412162132. Only one vulnerability has been addressed and I am just now updating the Dockerfile to pull a later base that fixes one of the scan errors. But there are 3 left that are only currently fixed in test versions of Debian Linux. What is the process for this in FINOS?

The "FINOS way" to deal with security vulnerabilities is described on https://community.finos.org/docs/governance/software-projects/cve-responsible-disclosure/ - it's a high level description of the process to follow in order to manage security vulnerabilities; however it does not specify how a project should secure its codebase; more on this below...

What is the prescribed way to notify potential Docker image users of these issues

This is something that should be dictated by the Docker image project (in this case Debian), not FINOS - https://www.debian.org/security/disclosure-policy ; the focus for the a11y theme builder team is to make sure that no CVEs are shipped within the released project artifacts.

and how do we tell the scanner to ignore these error for the time being?

Trivy seems to have this feature, see https://aquasecurity.github.io/trivy/v0.22.0/vulnerability/examples/filter/ ; unfortunately the GH Action that we're using does not allow that, and someone asked for this feature to be built, see https://github.com/crazy-max/ghaction-container-scan/issues/43

I'm pretty sure that there are alternative approaches we can explore to scan Docker images and ignore some known CVEs, but contributing to ghaction-container-scan is also an option.

None of the modules with the issues are used directly by us and we don’t believe that these are issues that will affect our users. Indeed, DockerHub’s scanner doesn’t even show these errors in the base image that we are using and reports no high or medium vulnerabilities in the base image. If you could please advise me on the process that I should follow, I would appreciate it.

In the short term, I'd suggest commenting out the docker scan action and run it manually/locally ahead of a release, while experimenting with a solution that allows the filtering of CVEs.

[aaronreed708]

From another exchange with Mao from FINOS:

My one concern is that, perhaps, a consumer of our Docker image may not feel the same about the vulnerabilities if they knew about them. With the current scanning they could always go to our Action page and see the current results (for good or bad) and make their own decisions. If we disable the scanning there will be nothing for them to refer to without doing their own scanning. Do you think we should post somewhere (the release notes? the issue/epic under which the release is managed?) the manual scan results for any release we do? I know that this may be slight overkill given the youth and modest user population of our project, but would like to establish good processes early on.

Good point. Yes, release notes are fine, however, I'd make sure that there's a mention in your README.md and/or website and/or any other place that you believe the consumer will definitely see.

Depending on the length of the "security notes", you may want to create a SECURITY.md file in the repo's root folder and link it across other pages.

[aaronreed708]

Closing issue as complete. #785 will address getting automated docker scanning working once whitelisting is supported.

[aaronreed708]

I added the securityscanning folder in the repo that contains the security scans run on Docker on the date of release. We'll continue to add for each subsequent release until #785 is addressed. Closing.