docs: state the control test that separates hardening from a vulnerability - #1964
Merged
Merged
Conversation
…ility SECURITY.md already says an unbounded read is in scope and THREAT_MODEL §8.5 already says a control that fails to enforce its documented behaviour is a violation, but nothing states the rule that connects them: a control the framework claims and does not enforce is a vulnerability; the absence of a control the framework never claimed is hardening. Adding a control therefore moves the line, which is why the same input can be a hardening report before a limit exists and a vulnerability report once the limit can be bypassed. Adds that test to SECURITY.md with the public WW-5618 -> S2-072 sequence as the worked example, a `VALID: control-not-enforced` disposition to §13, and a §11a bullet so a repeat report is re-triaged against any control added since rather than closed as a duplicate. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
lukaszlenart
marked this pull request as ready for review
September 18, 2026 04:03
lukaszlenart
deleted the
docs/hardening-vs-vulnerability-control-test
branch
September 18, 2026 04:33
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
1 participant
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.
Summary
SECURITY.mdalready says an unbounded read is in scope, andTHREAT_MODEL.md§8.5 already says a control that fails to enforce its documented behaviour is a violation — but nothing states the rule that connects them. Recent triage kept applying it implicitly, and one reporter reasonably asked why the same symptom was handled as hardening one month and as a CVE later.The rule: a control the framework claims and does not enforce is a vulnerability; the absence of a control the framework never claimed (and documents as the operator's or the application's) is hardening. Adding a control therefore moves the line.
Changes
SECURITY.md— new subsection Hardening or vulnerability: the control test after the "linear cases" paragraph, with the public WW-5618 → S2-072 sequence as the worked example (limits added as hardening; the later bypass of one of them was CVE-2026-73633; two findings, credited separately).THREAT_MODEL.md§13 — new dispositionVALID: control-not-enforced, licensed by §8 (esp. §8.4, §8.5, §8.7), so the triager doesn't have to argue a default-config case when the control's own documentation is the claim being broken.THREAT_MODEL.md§11a — new bullet: "this was reported before and closed as hardening" is not a ground to close; check whether a control was added since and re-triage against it instead of closing asDUPLICATE.Everything cited is already public (WW-5618, S2-072, the bulletin).
Documentation-only change, no ticket.
🤖 Generated with Claude Code