whitehat-security/intakes/intakes.md

Intake records

WHITEHAT-IN-0001 — Declaration requested: state this repository's layer in INTENT.md (security layer model §11)

id: WHITEHAT-IN-0001
kind: intake
title: 'Declaration requested: state this repository''s layer in INTENT.md (security
  layer model §11)'
status: closed
origin: cross-repo
origin_ref: net-kingdom security-layer-model_v0.4 §11
priority: low
owner: whitehat-security
requested_by: gate-house
proposed_layer: Staff
description: 'A conformance sweep on 2026-08-28 found this repository has no layer
  declaration of its own. It carries a layering review note gate-house wrote into
  the top of its INTENT.md on 2026-08-24, and that note names a layer — but the words
  are gate-house''s, sitting above a line admitting the body is unadapted. Section
  11 has since been amended to say so explicitly: a layer stated about a repository
  by another repository is not a declaration; only the repository''s own file, in
  its own voice, conforms. Seven of fifteen estate-authored repositories have declared;
  this is one of the eight that have not. REQUESTED: state the layer in INTENT.md
  in your own voice, or contest it. PROPOSED LAYER: Staff. Offensive validation. Beyond
  the label, one substantive item: gate-house authors the assurance specifications
  T-01 to T-10 in the Active Secrets Management Canon and you execute them, with findings
  returning through the conformance loop. That division — we specify, you attack and
  judge whether the control actually held — should be in your words rather than ours,
  and you should push back if specifying the tests from outside your repository is
  the wrong shape. Contesting is a real option and costs nothing — the three repositories
  that reviewed this model each returned a correction, two of which changed the standard.
  If the proposed layer is wrong for what this repository actually does, that is more
  useful to us than a label added to close a checkbox. Standard: net-kingdom/canon/standards/security-layer-model_v0.4.md.'
created: '2026-08-28T21:03:30.332146Z'
updated: '2026-09-01T19:00:23.889023Z'
quality_doc: DoC-Ok
quality_doc_at: '2026-09-01'
quality_doc_by: grok
notes:
- content: 'Declared Staff in INTENT.md in this repository''s own voice (v0.7 §11
    frontmatter, not the 2026-08-28 review note). Offensive validation is interactive
    and non-deterministic; live E3/P1/P2 sit at zero with no Tooling client (blocked-clean).
    Assent to the conformance loop with one correction: gate-house may specify the
    invariant, including T-01…T-10 as targets; it does not author our probes. A probe
    list written outside this repository is not our evidence.'
  author: whitehat-security
  created: '2026-09-01T18:50:00Z'
closed_at: '2026-09-01T19:00:23.889023Z'
outcome: absorbed
state_hub_intake_id: 01a05e52-d5ed-7ad5-8573-f7a857a90b3b

WHITEHAT-IN-0002 — Triage Gate House ASM T-01–T-10 executable targets

id: WHITEHAT-IN-0002
kind: intake
title: Triage Gate House ASM T-01–T-10 executable targets
status: closed
origin: cross-repo
origin_ref: gate-house GH-WP-0001-T06 / message 8229c9a4-862f-4d55-842c-5c95702f79d9
priority: high
owner: whitehat-security
requested_by: gate-house
source_message_id: 8229c9a4-862f-4d55-842c-5c95702f79d9
specification: asm-assurance-targets.v1
reporting_contract: conformance-reporting.v1
authorizes_probe: false
description: 'Gate House (GH-WP-0001-T06, commit 8cb7250) published executable ASM
  assurance targets T-01 through T-10 and the conformance-reporting.v1 return contract.
  Specs: gate-house/docs/assurance/asm-t01-t10-executable-targets.md, gate-house/docs/assurance/asm-targets.yaml,
  gate-house/docs/contracts/conformance-reporting.md. This fulfills their side of
  the T-01-T-10 split named in WHITEHAT-IN-0001: they specify the invariant; this
  repository owns attack design, execution, and the verdict. REQUESTED: triage each
  Canon test into this repository''s work structure — applicability, target surface,
  known-bad calibration, and result route — preserving the Canon test id. Current
  whitehat-target/v1 approval classes are E2, E3, and capacity, not ASM; mapping or
  extending that schema is this repository''s decision. Acceptance, revision, rejection,
  or split are all valid. This handoff authorizes no fixture, live probe, target,
  credential, or packet. Every run remains under the rules of engagement and a dated
  engagement. Outcomes return to gate-house under conformance-reporting.v1 with subject
  [GH-CONFORMANCE] <test> <outcome> <target>@<revision>; implementation findings still
  route through risk-nexus. Tests: T-01 Malicious Model; T-02 Credential Exfiltration;
  T-03 Human Disconnect; T-04 Policy Self-Modification; T-05 Confused Deputy; T-06
  Approval Replay; T-07 Circuit Breaker; T-08 Audit Reconstruction; T-09 Audit Failure;
  T-10 Revocation Closure.'
created: '2026-09-01T22:52:47.291284Z'
updated: '2026-09-01T23:11:26.350174Z'
state_hub_intake_id: 01a05f2d-d773-76c1-89ec-d5a934e0a207
routed_to: WHITEHAT-WP-0007
routed_at: '2026-09-01T23:11:24.530643Z'
closed_at: '2026-09-01T23:11:26.350174Z'
outcome: promoted

WHITEHAT-IN-0003 — Request: secret-aware release diff review (rendered vs. live, values redacted)

id: WHITEHAT-IN-0003
kind: intake
title: 'Request: secret-aware release diff review (rendered vs. live, values redacted)'
status: open
origin: cross-repo
origin_ref: the-custodian CUST-WP-0071 wave 1 (2026-10-21), railiance-forge FORGE-WP-0011
priority: medium
owner: whitehat-security
requested_by: the-custodian
description: 'Agents may not read Secret values (guard-secret-reads). Several deploy
  paths still compose Helm values from Secrets, for example railiance-apps
  make forgejo-deploy via tools/forgejo-helm-secrets.sh. Forgejo also has Helm drift:
  the last release revision is 9 (July) while the live Deployment is at revision 14
  after out-of-band rollouts. An agent therefore cannot verify that an upgrade changes
  only the reviewed fields, so the founder has to diff by hand. REQUESTED: a facility
  that renders the candidate release (with secret inputs resolved inside a trusted
  boundary), diffs it against live objects, and returns a redacted, reviewable report.
  The report shows structure and field paths for every change; Secret and secret-derived
  values appear only as changed/unchanged digests. It ends with a verdict on whether
  the change set equals the declared intent (e.g. resource requests only). The founder
  would review and accept the report instead of evaluating raw diffs. Natural consumers:
  the CUST-WP-0071 allocation waves and the planned release-registry drift check
  (RELREG-WP-0001).'
state_hub_intake_id: "01a17fd1-ef7e-709c-b81c-ebdd49038570"