🛡️ 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 :

❇️ 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 21 Low 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

jeff-cook posted on Apr 19, 2021

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

See global solution below :

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?