Gold Packs
Gold Check Packs deepen a selected catalog hypothesis with a threat model, detection layers, false-positive filters, refutation tests, and regression fixtures. They cannot mark themselves verified.
What a pack is
A Gold Check Pack is a provenance-bound, reusable investigation plan for a selected catalog hypothesis. It deepens an existing slot in the 546-item coverage model; it does not create a second catalog and it does not add to the count.
The purpose is repeatability. A specialist who has verified an object-authorization failure once should be able to hand the next reviewer the threat model, the detection layers, the false-positive filters, the refutation tests, and the regression fixtures rather than the memory of how it went.
What a pack records
- Threat model
- Actor, asset, trust boundary, failure mode, and impact.
- Applicability
- Capability tags, the selection rule, and the required evidence.
- Framework fingerprints
- Signals that point at a framework or pattern. They are investigation leads, never proof of reachability or impact.
- Boundary and sinks
- The subject, object, action, and invariant, plus the sink classes it can fail through.
- Detection layers
- What to look for statically, at the contract level, and in local runtime.
- Validation
- The default mode, whether destructive actions or production mutation are permitted, and the safe steps.
- False-positive filters
- The documented reasons a candidate in this class is commonly wrong.
- Verification
- Whether independence is required, the required evidence, and the refutation tests.
- Root causes and remediation
- The canonical invariant and the repair patterns that enforce it.
- Variant strategy
- Anchor fields, variant dimensions, and the result contract.
- Regression
- Fixture IDs and the assertions that must hold before and after the fix.
- Calibration
- Measurement status and sample size.
- Limitations
- What the pack explicitly does not establish.
The shipped packs
Eighteen packs ship publicly, all at lifecycle REFERENCE and all with calibration NOT_MEASURED at sample size zero. None of them claims measured performance.
| Pack | Class |
|---|---|
| SEC-AI-MCP-AUTHORITY-001 | Tool authority for agents that consume untrusted content |
| SEC-API-SURFACE-001 | API surface breadth: generic entry points, field writes, and batch amplification |
| SEC-AUTHZ-IDOR-001 | Object authorization and missing subject boundary |
| SEC-BROWSER-DOM-001 | Browser trust boundaries across DOM sinks, origins, and framing |
| SEC-FILE-PARSER-001 | File names, archive members, and decoders acting on untrusted bytes |
| SEC-IDENTITY-ATO-001 | Account takeover through identity proofing and recovery flows |
| SEC-INJECTION-DATAFLOW-001 | Untrusted data reaching an interpreter as syntax rather than value |
| SEC-MONEY-INVARIANT-001 | Cumulative money invariants and partial-success accounting |
| SEC-RACE-IDEMPOTENCY-001 | Single-use state transitions under concurrency and replay |
| SEC-SESSION-TOKEN-001 | Session and token authority across issuance, verification, and revocation |
| SEC-SSRF-FETCH-001 | Server-side fetch destination control across resolution and redirects |
| SEC-TENANT-RLS-001 | Tenant isolation at the database boundary and the policies it depends on |
| SEC-DJANGO-ORM-CONFIG-001 | Django: queryset construction, deployment settings, and the signing key |
| SEC-EXPRESS-NODE-001 | Express and Node: middleware order, request shape, and what reaches the filesystem |
| SEC-LARAVEL-ELOQUENT-001 | Laravel: model attribute control, policy coverage, and deployed configuration |
| SEC-NEXTJS-BOUNDARY-001 | Next.js App Router: the server boundary and the checks it does not carry |
| SEC-SPRING-METHOD-001 | Spring Boot: URL rules, proxied method security, and management surface |
| SEC-SUPABASE-RLS-001 | Supabase and PostgREST: the policy is the only server-side check |
The authorization pack is documented below as a worked example: SEC-AUTHZ-IDOR-001.
| Field | Value |
|---|---|
| Failure mode | A lookup or list operation omits the effective subject or ownership constraint. |
| Boundary | OBJECT_AUTHORIZATION — effective caller identity to owner- or tenant-scoped resource. |
| Invariant | Every protected object access is constrained by the effective subject at a canonical enforcement boundary. |
| Sinks | OBJECT_LOOKUP · LIST_QUERY · BULK_OPERATION |
| Default validation mode | LOCAL, with destructive actions and production mutation both forbidden. |
| Catalog hypothesis | SHX-AUTHZ-L02 |
| Mappings | CWE-862 · OWASP-ASVS:V4 · OWASP-API1:2023 |
| Calibration | NOT_MEASURED, sample size 0 |
What a pack cannot do
- It cannot bypass applicability. The pack still has to be applicable to the target architecture.
- It cannot bypass verification. Independence is required for this class, declared in the pack itself.
- It cannot mark its own results verified.
- It cannot claim benchmark performance. Calibration status stays NOT_MEASURED until a reproducible run exists.
- Its source IDs must exist in the rights-aware source registry, its catalog IDs must exist in the canonical catalog, and its regression fixture IDs must resolve locally.
The v1 contract requires non-destructive defaults, forbids production mutation, and requires independent verification. Those are schema-level constraints, not conventions.
Validating a pack
python scripts/validate_gold_packs.pypython -m unittest tests.test_gold_packs -vValidation covers provenance, safety, and calibration. A pack that declares a source ID missing from the registry, or a calibration claim without a run behind it, fails.