π‘οΈ Context : security π³
We recently started to put grype
and Anchore Container Scan in our (GH based) CI pipeline.
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).
Now ...
all the people who produce and release docker images have
grype
installed 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.
π€οΈ Action
Finally we created the following scheduled workflows to monitor our stable
and latest
tags (the ones we deploy)... and be noticed when they fail according to
π Issue management & kanban
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.
π¨ Then the real world came to us
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 : openjdk:8-alpine
.
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 :
Image | Critical | High | Medium | Low | Negligible |
---|---|---|---|---|---|
openjdk:8-alpine | 10 | 55 | 110 | 142 | 0 |
openjdk:8u102 | 6 | 234 | 685 | 140 | 232 |
adoptopenjdk/openjdk8 | 0 | 0 | 8 | 21 | 7 |
adoptopenjdk/openjdk8:alpine-jre | 0 | 0 | 0 | 0 | 0 |
βοΈ Jaw dropping adoptopenjdk/openjdk8:alpine-jre
π Finally we started to migrate our core java layer from openjdk:8-alpine
to adoptopenjdk/openjdk8:alpine-jre
βοΈ 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 :
βοΈ Conclusion
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
Critical
issues to a runtime with 21Low
security issues.
It is possible to generate SARIF
vulnerability report so it can be displayed :
... delivered to other systems.
See more details about SARIF
support in grype
:
Add SARIF report output #304
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.
Additional context:
</div>
<div class="gh-btn-container"><a class="gh-btn" href="https://github.com/anchore/grype/issues/304">View on GitHub</a></div>
π Further
- 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
openjdk:8-jdk-alpine
- 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
π Organisation wide strategy
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
anchore
for policy enforcement, security insights
Each of these approaches has its pros and cons,... just pick (or create) your own solution to achieve this goal.
π Remarkable grype issues
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?
Top comments (3)