In the mean time, we started to spread container security culture accross Dev & OPS teams, especially around
grype tooling (which is very easy to handle).
all the people who produce and release docker images have
grypeinstalled on their workstation... hence helps promote shiftleft culture
Next to that we wanted to automate, monitor and alert on security issues so we'll be able to run a proper maintenance pipeline by linking issues to code actions.
Finally we created the following scheduled workflows to monitor our
latest tags (the ones we deploy)... and be noticed when they fail according to
We wanted to be noticed and embed security concerns into our project planning : we needed to get alerts as issues :
Also, thanks to custom and shared labels accross our organization, it is possible to report these issues globally.
Now we get all the required details within the (self updating) issue so we can assign it, investigate, link it to other tasks, assign it to a SCRUM and so many other things.
For now, we have set the workflow to fail as soon as a
Critical level has been reached... and here is what we got on one of our projects :
These issues were affecting our core java image that was relying on :
Then here is what we got 😱 👇
So I started to count them :
grype openjdk:8-alpine | grep Critical | wc -l grype openjdk:8-alpine | grep High | wc -l
Then, with that methodology I could very quickly build the following benchmark :
👉 Finally we started to migrate our core java layer from
☝️ Be aware that if under certain circumstances vulnerabilities should be considered as acceptable, it is possible to create a configuration file to ignore certain matches :
Thanks to continuous scan and proper alerting we could seriously enhance our core Java runtime for legacy source code that only supports java 8 runtime,
we could switch from a runtime with 10
Criticalissues to a runtime with 21
It is possible to generate
SARIF vulnerability report so it can be displayed :
... delivered to other systems.
See more details about
SARIF support in
What would you like to be added:
I see https://github.com/anchore/scan-action supports a SARIF report.
However, instead of using the
grype --template option, it creates it in the code.
Is there any plan to create a template for use by grype?
Why is this needed:
Being able to create a SARIF report no mater how you use grype.
</div> <div class="gh-btn-container"><a class="gh-btn" href="https://github.com/anchore/grype/issues/304">View on GitHub</a></div>
- Anchore : Continuous security checks directly in container image registry : ready to play solution (native integration, monitor public & private repos, enforce policies, gain security insights, ready to use reporting)
- Snyk report for
- Uploading a SARIF file to GitHub
- SARIF support for code scanning on Github to display results from a third-party static analysis tool & CodeQL static analysis
- Managing container vulnerability risks: Tools and best practices
- The Role of SBOMs in Securing Software Supply Chains by Gartner
Finally many strategies are possible :
- Per-repo strategy : each repo is reponsible of its own monitoring with CI
- Per-org single repo strategy : within a single repo, monitor all published images with CI
- Global & ready-to-use Container Registry Scanning by
anchorefor policy enforcement, security insights
Each of these approaches has its pros and cons,... just pick (or create) your own solution to achieve this goal.
Find below some issues :
- Replacements for the inline scanning script
- grype can't detect spring4shell (CVE-2022-22965)
- Add support for cyclonedx 1.4 and VEX
- generate fig autocompletion
- False positive for alpine package
- Consistent sort order for grype output
- Add show-grype-output option to show vulnerabilities in console
- Can't see findings in console?