-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[TB] Fix Docker scan vulnerabilities #742
Comments
…ally fix a vulnerability
#742: changing bookworm-slim version for Dock…
Fixed and merged. Waiting on word from FINOS on how to handle Docker images with vulnerabilities deemed acceptable risk. |
Relevant replies from Mao at 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...
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.
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.
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. |
From another exchange with Mao from FINOS:
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. |
… to test that is still working
…back to previous version that worked which is actually later than latest release version
Closing issue as complete. #785 will address getting automated docker scanning working once whitelisting is supported. |
#742: creating docker scan results
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. |
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.
The text was updated successfully, but these errors were encountered: