thoth-station
Security confidence addition to the images for more clear traceability and security
Is your feature request related to a problem? Please describe.
The plan is to have a process in place to add score/confidence based on the base image and package security into the image during the build time. we would focus on the provenance of the package and the base image source confidence. The aggregation would be provided in the image for the details for the user to view and verify that the built image is of good quality.
This is not the same as the vulnerability of the installed binary, but it would be similar to it in the context of the base image and packages installed. The goal is have a process:
- [ ] phase 1. To accumulate the score/confidence based on the base image and package (for example: thamos advise security score, base image source confidence based on if it is official or not)
- [ ] phase 2. To determine the method to include them in a format into the image.
- [ ] phase 3 . Introduce an open policy to check back on what this information signifies.
References opa: https://www.openpolicyagent.org/ sigstore: signature for the package https://sigstore.dev/what_is_sigstore/ stackrox: https://www.stackrox.com/use-cases/vulnerability-management/
is this still valid @pacospace
Yes, we do not collect scorecards yet: https://github.com/thoth-station/core/issues/289
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
/lifecycle rotten
There was an issue in the lifecycle commenter, it should not mark as rotten directly. Flagging it as stale instead.
/remove-lifecycle rotten /lifecycle stale
Looking into this issue, it might be better to have security information on the backend side linked to the container image SHA (and let clients ask for it). If you take a look at how the vulnerabilities or issues are discovered - they are discovered not during the build time but rather as the container image is used. A solution that would link container image SHA to known issues or vulnerabilities would scale long term and would provide the flexibility to add observations after the container image is built based on its use (ex. exposed as an API endpoint). Moreover, we could also aggregate queries stats (that can provide insights on the container image use by users).
Discussed this in today's backlog meeting, decided to move to core repo but otherwise leave for further decisions on priority.
/kind feature /triage needs-informafion /priority backlog
@codificat: The label(s) triage/needs-informafion cannot be applied, because the repository doesn't have them.
In response to this:
Discussed this in today's backlog meeting, decided to move to core repo but otherwise leave for further decisions on priority.
/kind feature /triage needs-informafion /priority backlog
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
oh, I had a typo: /triage needs-information
and while we are at it: leaving the needs-information label because it was unclear during today's review how important/relevant this is at the moment, considering that #289 was replaced by a different approach (thoth-station/prescriptions-refresh-job#14) and that this type of metadata probably should not stay into the container image anyway.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
/lifecycle rotten