Hello,
We intend to have Grist installed on premise here and our head of IT security pointed out that he tested a tool called trivy on Grist’s source code (trivy image gristlabs/grist-oss:stable)
And it gave this result : Total: 114 (UNKNOWN: 0, LOW: 87, MEDIUM: 20, HIGH: 5, CRITICAL: 2)
Is this something we should be concerned about? What can I tell him to make him less worried about this scan result?
Thank you
G.
This is a ChatGPT answer. Always take it with a grain of salt
Trivy is a vulnerability and misconfiguration scanner created by Aqua Security.
It doesn’t “look inside” your app’s logic — it scans software dependencies and system packages for known CVEs (Common Vulnerabilities and Exposures).
When you run:
trivy image gristlabs/grist-oss:stable
it analyzes the Docker image used by Grist and checks:
the base OS packages (e.g. Debian, Alpine, etc.)
any system libraries included
optionally, application dependencies (Node, Python, etc.)
sometimes configuration files (permissions, hardcoded secrets, etc.)
It then compares those packages and versions against public CVE databases (like NVD, Debian Security Tracker, etc.) and reports matches.
What the Numbers MeanThe output:
Total: 114 (UNKNOWN: 0, LOW: 87, MEDIUM: 20, HIGH: 5, CRITICAL: 2)
doesn’t necessarily mean Grist itself is insecure.
It means that the image contains libraries or packages that have known issues, but:
Many may be in components never used by Grist’s code.
Some CVEs are false positives or already patched in later minor builds.
The “HIGH” and “CRITICAL” ones might refer to optional tools or background libraries.
Some are vulnerabilities in underlying Debian/Alpine packages that aren’t exploitable in typical Grist deployments.
How to Explain This to ITYou can tell your security team:
Trivy scans report potential vulnerabilities based on the image’s dependencies, not confirmed exploitable issues in Grist.
The reported items come from the OS base image and open-source packages bundled with it. Many of them are irrelevant to how Grist runs (for example, a vulnerable image-processing library that Grist never calls).
The Grist image is maintained by Grist Labs, and those dependency updates are regularly pulled when the base image is rebuilt.
As with any open-source service, the right mitigation is to run the latest “stable” tag, and if needed, rebuild from source using your own base image with updated packages.
Optional: What to Do if You Want to Be ThoroughYou can:
Run Trivy with --ignore-unfixed to see only issues that have official patches.
Run trivy image --severity HIGH,CRITICAL gristlabs/grist-oss:stable to focus on real risks.
Rebuild Grist yourself from the GitHub repo with a newer base image (for example node:18-alpine), if your company’s policy requires minimal CVE counts.
Hello Rogerio, thank you for the detailed answer.
Talking about “rebuilding” Grist with a newer base image, do you have any pointer to maybe a tutorial on that subject? (we were thinking about using a Docker image to install Grist but maybe you think there is a better way).
Hello Guillaume,
Grist images are rebuilt quite frequently: stable is from two weeks ago, latest is from today (but produces the same results). Careful with AI recommendations, e.g. node:18-alpine wouldn’t be newer, Grist uses node:22 now (see Dockerfile).
@Rogerio_Penna is right, these are all about dependencies that Grist relies on.
To be clear, there are no reported exploits of Grist for any of these. Most dependencies are not accessible to the user enough to attempt an exploit. We do, however, upgrade dependencies, to keep such scans clean.
In particular, it looks to me like it may be a good time to upgrade our images from using node:22-bookworm to node:22-trixie, which may clear up most of these reports. @paul-grist, wdyt? (Judging from the table in CVE-2025-7458, where bookworm is still vulnerable, though in Notes it says that in this version it’s a minor issue.)
Hello Dmitry, thanks for your answer. I’ll do my best to explain all of this to my IT security colleagues.
It’s so nice to see this good exchange between the community and Grist, especially about a sensitive subject. Kudos to everyone!
I wanted to share an update that gristlabs/grist-oss:latest (as well as gristlabs/grist:latest) are upgraded and their scans are now much cleaner. (The :stable tag will catch up a bit later.)
Thank you Dmitry 