Repository navigation
Emit the canary map, and assert what the chain depends on - #185
Merged
Merged
Conversation
The cross-repo canary is one vertical slice through the whole product claim — a reviewed recipe in hub, a verdict and generated rule in the platform, and this engine blocking the exploit — proved as a chain rather than as three sets of green unit tests. CVE-2017-5941 is the slice: `node-serialize`'s `unserialize` executes an embedded function expression, so a request body reaching it is remote code execution, and it is public, so the app, the rule and the requests can all live in the open while the review rationale and detector recipe stay private in hub. The platform vendors the map, which makes the map an artifact of this package. The ladder fixtures established the pattern and its one weakness: nothing downstream can detect a fixture going stale, because no job over there runs this extractor. So this adds the two things that help. An emitter, run the same way as the ladder one: PS_CANARY_EMIT_DIR=/path/to/back/tests/Fixtures/Canary npx vitest run tests/map/canary-emit and a provenance file naming the commit that produced the artifact — the ladder maps carry that as a hand-maintained line in a README, which is only as fresh as whoever last remembered. The assertions do NOT skip when the emit directory is absent. They run on every suite run, so a change to the app or the extractor that would invalidate a vendored copy fails HERE, with a message about the map, rather than three repositories away as a rule that quietly stopped being generated. They pin the endpoint, the coordinate, the sink, and the flow's tier, role, family and generatability — plus that `recognizedSinkKinds` is non-empty, since an empty list means "no model of this API" and the recipe's gate is `dataflow`, which would make the whole canary a needs-review case. The app is the simplest one that carries the vulnerability, and that is load-bearing rather than lazy: a wrapper, a validation step or a rename would move the flow off `exact-local`, and the canary would then be proving that a review-grade flow generates a rule — a different and weaker claim. `canary-case.ts` holds the app as data because two things consume it and must not drift: the assertions here and the emitter, generated from one definition. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Well-structured, thorough canary tests with detailed documentation and clear assertions. 🎯 Quality: 100% Elite · 📦 Size: Medium 📈 This month: Your 144th PR — above team average · Averaging Excellent |
Contributor
Author
|
/review |
mariojgt
approved these changes
Aug 27, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Produces the map artifact the platform vendors for the cross-repo canary — one vertical slice through the product claim for CVE-2017-5941 (
node-serialize'sunserializeexecutes an embedded function expression, so a request body reaching it is remote code execution).Public CVE, so the app, the rule and the request controls can all live in the open; the review rationale and detector recipe stay private in hub.
Why this belongs here
The platform commits the map and grades it into a verdict and a rule, which makes the map an artifact of this package. The ladder maps established the pattern and its one weakness, in their own README:
So this adds the two things that help:
The platform's integration job then regenerates from this emitter and compares bytes, which turns that documented gap into an actual check.
The assertions do not skip
They run on every suite run, not only when emitting. A change to the app or the extractor that would invalidate a vendored copy fails here, with a message about the map — rather than three repositories away, as a rule that quietly stopped being generated.
Pinned: the endpoint, the coordinate (
post.state), the sink (eval/node-serialize/unserialize), and the flow's tier, role, family and generatability. Plus thatrecognizedSinkKindsis non-empty — an empty list means "no model of this API", and the recipe's gate isdataflow, so an empty list would silently turn the whole canary into a needs-review case.The app is minimal on purpose
A wrapper, a validation step or a rename would move the flow off
exact-local— the one auto-promotable tier — and the canary would then be proving that a review-grade flow generates a rule. That is a different and weaker claim than the one it advertises.canary-case.tsholds the app as data because two things consume it and must not drift: these assertions and the emitter, generated from one definition.Full suite: 1665 passed, 7 skipped.
🤖 Generated with Claude Code