Pimp My IDE / garage dispatchBack to the garage
October 11, 2026 / vulnerability triage / conditional evidence

A suppression needs a trip wire.

A package match can raise an alert. It cannot tell you whether the vulnerable path exists on this machine. Tie every "not affected" decision to the condition that keeps it true.

When the condition changes, the exception should blow.
SCANNER INPUTTRIAGE OUTPUT
MATCHcomponent foundCHECKpath testedDECIDEreview owned

The scanner found a component.

Fabian Kammel ran an SBOM scanner against a small Debian image with OpenSSH and reported 284 matches. He then narrowed one old OpenSSH issue by inspecting the effective daemon settings and PAM modules. In his example, PAM was enabled, keyboard-interactive authentication was disabled, and no OPIE module was configured.[1]

The finding was real inventory data. The exploit path depended on configuration that was not present. That difference is where triage starts.

A dependency match is a question. Suppression is an answer that needs its own evidence.

Reachability cuts noise, not responsibility.

The Go vulnerability system records affected packages and symbols. Its govulncheck tool analyzes a program's call graph and reports known vulnerabilities whose functions the program can reach transitively.[2] That is stronger than stopping at a module version.

Operating systems make the same question harder. A vulnerable route can depend on a service setting, a loaded module, an imperative change, or the running machine drifting away from its declaration. Source reachability and system configuration are different witnesses.

Make the exception conditional.

Kammel's NixOS example turns the triage reasoning into a condition. The generated VEX statement remains only while the package and service configuration satisfy that condition. He reports 272 scanner matches for the sample system. Applying one conditional statement moved one match into the ignored count.[1]

OpenVEX defines a small JSON-LD document for a vulnerability, one or more products, a status, and supporting metadata. The project calls its specification a draft. It also says VEX complements an SBOM by recording whether a finding applies to a product.[3]

The useful part is not the word not_affected. It is the machine-checkable reason and the route that removes the statement when that reason stops holding.

Do not confuse declared state with running state.

The nixos-vex repository makes this limit explicit. Its conditions inspect the NixOS configuration, not the running system. A service started by hand or a kernel module loaded outside that configuration can escape the check. The project also says its goal is zero untriaged findings, not zero vulnerabilities.[4]

That warning belongs in the interface. A triage card should show the component identity, vulnerable route, configuration condition, runtime probe, source date, reviewer, and invalidation rule. A green scanner badge cannot replace them.

The load bank below drafts that card. It does not inspect a host, generate a valid VEX document, or decide whether a vulnerability applies. Use it to expose missing evidence before a scanner exception enters policy.

Interactive makeover / severity badge replaced with a conditional decision card

Load the evidence.

This combines native condition switches, a connected check bus, a verdict, and a copyable review card. It shows what the reviewer selected. It does not verify a machine.

FindingConditionRuntimeReview

Condition switches

Select each section the review packet will require. The final state means the template is complete, not that the vulnerability is absent.

Required evidence sections
Decision route / template only

VEX review card

IDENTITYOPEN
PATHOPEN
RUNTIMEOPEN
INVALIDATEOPEN
0 sections selectedThe review structure is incomplete. No VEX status is supported.
Sources read / October 11, 2026

Source log

Open the evidence boundary
  1. Fabian Kammel, "The Unreasonable Effectiveness of VEX in NixOS", published and read October 11, 2026. The post supplies the Debian and NixOS scanner counts, OpenSSH configuration example, conditional Nix expression, and warning against treating the project as a high-trust data source.
  2. Go Vulnerability Management, read October 11, 2026. The Go project documents its curated database and says govulncheck uses transitive calls to vulnerable functions to narrow findings.
  3. OpenVEX specification repository, read October 11, 2026. The project describes its draft JSON-LD format, its relationship to SBOM findings, and the role of VEX status statements.
  4. nixos-vex repository at revision 6c6bbba, read October 11, 2026. The README describes conditional and unconditional statements, configuration evaluation, the reference-system limit, and the gap between declared configuration and running state.
  5. Hacker News item 50046864, verified through the Hacker News API and read October 11, 2026. This was the discovery trail. At read time the thread contained no comments, so it does not support the technical claims above.

Evidence boundary: this page read the post, official Go documentation, OpenVEX material, and the project README. It did not install nixos-vex, generate an SBOM, inspect a NixOS host, run govulncheck, or validate a VEX document. The interactive load bank produces a review template only.