Runtimes

Last updated: Aug 19, 2026

---

Runtime CVE detection is different from package manager dependency scanning: instead of reporting a vulnerability in one of your project's declared dependencies, it reports a vulnerability in the language or runtime itself (for example, a CVE in the Go toolchain or in the Ruby interpreter). Because of this difference, only a small subset of the ecosystems Fluid Attacks scans for dependencies also get runtime CVE reports.

The criterion

To safely report a runtime CVE, Fluid Attacks needs proof that the version it detects is the version actually running in production, not just a version the project's manifest says it is compatible with. Most manifest fields only declare compatibility, a range the code is expected to work with. They do not guarantee what gets deployed, so treating them as a runtime CVE signal would misreport vulnerabilities that may not apply.

Only two cases currently clear that bar:

• Go: Go compiles to a static binary that embeds its own runtime. The Go version declared in go.mod is baked into the built artifact itself, so it is a genuine deployment-bound fact, not a guess.
• Ruby on Heroku: Heroku's buildpack reads the Gemfile's ruby directive at build time and installs exactly that version. This is only true under Heroku's build flow, so Fluid Attacks gates it on a Procfile being present in the repository, the signal that a project actually deploys that way. Without a Procfile, the same directive is just a compatibility declaration, the same as every other ecosystem below.

Runtime CVE support by ecosystem