Does this fix actually run on my runtime?
weak-crypto tells a Hono user to
import { randomBytes } from 'node:crypto'. On Cloudflare Workers
there is no node:crypto to import. The advice is not merely less
good on that runtime - it does not run.
A fix that throws at import time is not a fix. It is a catalogue cell that satisfies a test.
Five rules change with the runtime. Twenty do not.
| Rule | What changes |
|---|---|
weak-crypto | node:crypto vs Web Crypto; scrypt unavailable on edge |
insecure-cookie | Set-Cookie construction differs between the Node and fetch-API adapters |
security-headers-missing | headers set in edge middleware, not in a Node config block |
hardcoded-secret | process.env vs c.env vs Deno.env.get |
ssrf | fetch redirect semantics and the availability of redirect: 'error' |
Making runtime a second dimension would turn a 25 × 16 matrix into 25 × 16 × 4
- about 1 600 cells, most of them identical, because
sql-injection does not care whether the process is Bun or Node.
Instead a rule may declare a delta that patches the framework fix only
where the runtime genuinely changes it. Roughly 60 informative cells instead of
1 200 empty ones.
The absence of a delta is a positive claim
The naive version of this design lets a rule silently claim its base fix works everywhere. The build does not allow that: for every framework × runtime pair a profile declares, a rule either has a delta, or its base fix is checked against that runtime's available APIs - and CI installs Bun and Deno and names them, so a green build means the grid ran rather than quietly skipped three of four.
A delta that reintroduces the API it exists to avoid - a Workers fix still
saying process.env because it was copied from the Node one and
edited in one place - fails the build too.
The summary line says what it inferred
◉ᴥ◉ 41 files / next / node (detected) / quick / 0.3s
Runtime detection is inference, and inference is sometimes wrong. A fix chosen
from an inferred runtime should say what it inferred, so the word is
detected when there was evidence - a wrangler.toml, a
deno.json, a Nitro preset, an adapter in the config - and
defaulted when it came from the framework's default. It is
resolved per file, because a Next application with three edge routes
is normal.
Every rule's page shows the fix for your framework, and the delta where the runtime changes it: the rule catalogue. The axis that decides which of those fixes to apply first is exposure.
Keep reading
- owlwarden turnWhich of these did I just do?
- RulesTrigger, confidence, and framework-specific fix.
- Agent configHooks, MCP servers, instructions, and editor tasks.
- owlwarden vetCheck a repository before you open it.
- owlwarden sealNotice when your agent's execution surface moves.
- ExposureWhich of these findings do I fix first?
- RuntimesDoes this fix run on Bun, Deno, or Workers?
- CoverageMapped rules and categories static analysis cannot cover.