-
Notifications
You must be signed in to change notification settings - Fork 38
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
Ensure security vulnerabilities are patched in MCR images #233
Ensure security vulnerabilities are patched in MCR images #233
Conversation
Signed-off-by: Tatsinnit <[email protected]>
This reverts commit 7f2965f.
Codecov Report
@@ Coverage Diff @@
## master #233 +/- ##
=======================================
Coverage 80.53% 80.53%
=======================================
Files 14 14
Lines 786 786
=======================================
Hits 633 633
Misses 94 94
Partials 59 59 |
…ion on public image
.github/workflows/build-publish.yml
Outdated
- name: Copa Action | ||
if: matrix.canpatch && steps.vulncount.outputs.vuln_count != '0' | ||
id: copa | ||
uses: project-copacetic/copa-action@1eb86b0907bce48225b66dc9488c7d329c2d48a0 # v1.0.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: need to upgrade to 1.0.1 which adds a curl retry when getting the latest copa version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated, but now waiting for the next release of copa which will include project-copacetic/copacetic#377
This includes changes for:
Example runs:
Notes on why we're making these particular changes:
Should we create a pipeline that runs on a schedule, or on demand? I think it makes more sense to run it on a schedule. Reason: any issues that we detect should be in our dependency tree, and will change when new vulnerabilities are discovered in those dependencies. We won't know when that happens, so nothing will prompt us to run the pipeline.
Should that pipeline scan the image built from the latest code in master, or the latest published images? The published images are the ones that actually matter, because they're being used, but it would still be useful to know if our code introduced a dependency with a vulnerability. For a pipeline that runs on a schedule, I think we should be checking the latest published images, because our code doesn't change on a regular schedule. (In theory we could patch older images too, but that would be more work and massively increase pipeline execution times, and we can add that in later if we really need it.)
Should the pipeline just create a report and send some notification if there are vulnerabilities, and let us know so we can manually run a pipeline to patch the images? Or just go ahead and patch them? I think it should go ahead and patch. Realistically, we're not going to analyze the report ourselves and have the knowledge to make good decisions. And even if there's a risk that the patch breaks our functionality, security is more important than functionality. We are keeping unpatched images available with the
'unpatched
tag suffix, just in case something gets broken.Can we test the patched images before publishing? We have no automated tests for images, and I don't think it'd be trivial to create them. But if we add the patching to the GHCR publishing pipeline, we can manually check the published images from VS Code, which we should probably be doing before publishing to MCR anyway.