-
Notifications
You must be signed in to change notification settings - Fork 14
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
feat(security-scanning): image for scanning #87
Conversation
Temporary measure to bypass credential setting on new repo. Right now does not do any updates, will log data to job
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.
It's a bit hard to follow all of the files (the letters helped), but they will make the future steps easier and provide verbose details of each step!
Seems like you have covered every detail I could think of, looks good!
I'd be interested to see some output of the log when it matches a critical CVE at this stage if you have something.
Yeah I agree it's a bit hard to follow, its a lot easier when you look at the outputs of each step. There is some example output here https://github.com/Jose-Matsuda/artifactory-cleanup/tree/main/2022/z-Example-outputs (though it might not match completely anymore, this was the general idea). At this point the the outputs would just be the affected images, or images not found. |
{ | ||
"filters": { | ||
"min_severity": "Critical", | ||
"watch_name": "watch-k8s-acr" |
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.
Will this watch build up over time with a large number of items in the list or is it flushed out periodically? Alternatively is there a time component to the filter that could be used if necessary to limit to recent scans?
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.
fair play, yeah we could use a created_from
field to ensure that we only grab 'new' violations that are generated with a specific pull, that could be included in a later update to the Dockerfile as this isn't fully complete of course, just the initial implementation is here
Those are really helpful and interesting, thanks! One thing from the example that I am wondering about, any concerns when it picks up an artifact using the 'latest' tag? Could we get into a scenario where the vulnerability report 'latest' is not the same as the one in a notebook? Not sure if its a valid concern or not possible in an actual notebook. |
Very Valid concern. So after the discussion we had with StatCan/aaw#961, we did decide to eventually move to a pattern that will actually have a long lived tag (similar to latest). And using that tag, we will also have say weekly updates to the everyone's notebook images to get on the With the long lived tag (say a v1) when we push say For our current implementation it is not a problem, but when we do move towards that we will need to consider pulling by the digest and not the tag |
Temporary measure to bypass credential setting on new repo.
Does not do any updates, will just print data to console.
Dependent on StatCan/aaw#960 as step
b
will not actually pull the image in it's entirety, it will just be a.marker
file, and will thus not be scanned by XRAY.