This week’s main results are all valid within a boundary.
A V2X signature can authenticate a sender without proving that a braking event happened. An SBOM can accurately describe a named source or build input without proving the complete contents of the deployed binary. An authenticated Ignition session can establish identity without granting Perspective Designer authority. The practical discipline is the same: write down the exact property demonstrated, the artifact and state to which it applies, the exclusions that remain, and the next accountable gate. That preserves useful evidence without letting one result close three different decisions.
The pattern this week
A valid result needs a scoped claim and a separate next gate.
FIELD GUIDE · WEEKLY BRIEF 14Where the proof stopsThree valid results. Three decisions that still need a test.
01 / V2X · MIRAGE
Signed warning
Evidence
Credentialed sender.
Limit
The road event is unconfirmed.
Next test
Check braking on genuine and forged warnings.
02 / SUPPLY CHAIN · SBOM
Inventory generated
Evidence
Components found in the declared inputs.
Limit
Deployed binary coverage is unproven.
Next test
Trace known components to the exact release artifact.
03 / OT · IGNITION
Authenticated session
Evidence
An authenticated Vision identity.
Limit
Designer authority and Gateway reach are separate.
Next test
Deny Vision-only access to Designer and verify Gateway rights.
Release rule Record what the test proved, where it applies and who owns the next decision.
Common gap: record the exact property, artifact or state, exclusions and accountable next gate. A useful result should not silently inherit a broader claim.
01
Automotive · V2X · Response Safety
MIRAGE: a valid sender is not a valid physical event.
MIRAGE evaluates forged emergency electronic brake-light messages sent by a credentialed V2X participant. The research separates three questions: whether the sender is enrolled, whether the reported event and later trajectory are plausible, and how much braking authority the receiving vehicle should exercise. The published F1, detection and braking-severity results come from two attack variants in single-lane, ideal-channel VASP simulations. They do not establish production-vehicle effectiveness, a field compromise or a homologated safety function. The release test therefore has to challenge both false acceptance and false rejection on the intended vehicle configuration. A genuine warning must not be suppressed merely because a detector is aggressive, and a signed false warning must not trigger an unbounded response before local evidence arrives.
DecisionBind any EEBL claim to the evaluated attacker model, detector operating point and physical response limit, then validate genuine and false events on the intended vehicle configuration.
SBOM: an inventory result needs an artifact contract.
Prado et al. compare cdxgen, Syft and Trivy across popular JavaScript and Rust source repositories using freshly derived lockfiles as the study baseline. The tools diverge on dependency scope, package identity, aliases, nested projects and metadata. Those differences matter, but they do not create a universal ranking. The sample is selected, the baseline is source and lockfile oriented, and dynamic or runtime-resolved dependencies are outside the evaluated scope. A supplier acceptance test should freeze a representative product input, name the generation stage, tool version, configuration and dependency classes, and trace known packages and exceptions. A zero match downstream is not enough unless the inventory can be connected to the exact release artifact and its declared exclusions.
DecisionAccept an SBOM-generation pipeline only against a representative frozen product, declared scope, reproducible discrepancy handling and a trace to the release artifact.
Ignition: authentication must not collapse into engineering authority.
CISA ICSA-26-286-01 and Inductive Automation describe CVE-2026-92817, where an authenticated user with Vision project access and a valid Vision session identifier can, under affected Perspective conditions, obtain Designer-level access and potentially execute code in the Gateway process. The vendor recommends Ignition 8.1.55 or 8.3.9 and later. The precondition matters: this is not an unauthenticated takeover. So does the deployment-specific consequence. The Gateway process may reach databases, devices or integration credentials, but that authority varies by site. After a controlled upgrade, test a representative Vision-only denial and an authorized Designer allowance, verify normal production functions and recovery, and record the Gateway process’s effective downstream rights.
DecisionClose the ticket only with the fixed installed version, cross-module negative and positive authorization tests, production-function evidence and a site-specific record of Gateway process authority.
What exactly does the result authorize you to decide?
Take one current control result and write four lines: the property demonstrated, the exact artifact or operating state, the exclusions that remain and the owner of the next production decision. Then run the negative test that would expose overreach. For a signed V2X warning, challenge a credible but false event and a genuine event. For an SBOM, inject known direct, transitive and aliased components into a frozen representative input. For an Ignition upgrade, deny a Vision-only session while allowing an authorized Designer and preserving normal plant function. If the result cannot survive that scoped test, it should not close the wider claim.
