whitehat-security/SCOPE.md

# Scope

## One-liner

`whitehat-security` is NetKingdom's authorization-bound harness for adversarial
evidence. It can calibrate probes offline. It can admit a live run only when
a complete engagement record already exists. No live target is authorized.

## What it can do

- Calibrate E2 differential probes in process, including an audit-core-shaped
  pack. `whitehat fixtures` fails a known-bad fixture before it trusts a
  known-good pass. It sends no packet.
- Calibrate E3 row-level-security outcomes in process, including the
  SQL-compromise case that stays `inconclusive`. `whitehat e3-fixtures` opens
  no database.
- Calibrate E4 credential confinement and R4 erasure recovery in process.
  `whitehat e4-fixtures` and `whitehat r4-fixtures` project no credential,
  open no store, and are not target assurance. No live E4 or R4 target is
  registered. Tenancy Posture §13 classifies the live E4 artifact as
  Mechanical. The fixture does not perform that demonstration.
- Judge a supplied V2, V3, or V4 observation in process.
  `whitehat v-fixtures` injects no failure and makes no cluster call. A pass
  is a complete observation shape. V1 stays inconclusive because it is a
  mechanical exercise of the declaring service.
- Calibrate P1/P2 capacity judgments from supplied samples.
  `whitehat capacity-fixture` generates no load.
- Calibrate Active Secrets Management Canon T-01 through T-10 in process.
  `whitehat asm-fixtures` sends no packet. The T-06 fixture counts simulated
  custody calls; it is not an OpenBao client.
- Validate engagement records, target registrations, and probe packs, and
  refuse plane admission unless the target is applicable, the approval class
  matches, the kill switch is clear, and the engagement is inside its window.
- Render a value-safe run message and queue it as a local outbox file.
  `whitehat deliver` does not file the message in `risk-nexus` and does not
  assign severity.
- Render a Gate House conformance envelope. `whitehat conformance-message`
  does not send it.
- Review a sealed Emergent knowledge package offline with
  `tools/offline_emergent_knowledge_review.py`. That tool does not call a
  provider and does not re-pin `informed-decision`.
- Keep an `audit-core` E2 runner that can send HTTP only from an admitted
  plane pod. The dated engagements that used it are terminal.

## What it cannot do

- Run on a schedule. `whitehat cadence` lists every family with
  `scheduled: false`. The E3 interval of 24 hours is a declared detection
  window, not an operating timer.
- Send a packet, open a database connection, generate load, or lease a live
  credential under the current records. `WHITEHAT-WP-0006` and
  `WHITEHAT-WP-0008` stay blocked on owner returns.
- Treat a fixture pass, or the terminal audit-core E2 pass, as proof that a
  boundary holds.
- File findings, grade severity, disclose them, or fix a target.
- Hold an OpenBao client, a database driver, or a cluster-mutation API.
- Produce E4 or R4 evidence about a real substrate. Those families stop at
  the in-process harness.
- Produce identity or authorization evidence. Tenancy Posture §13 classifies
  I2, I3, A2, A3, and A4 as Mechanical, and that evidence belongs in the
  declaring service's CI. This repository has no I or A probe.
- Inject a failure, or produce live V2, V3, or V4 evidence. The in-process
  judge only checks a supplied observation. A restart is not V2.
- Admit `tenant-engine` for E2 or `platform-pg` for E3. Both are
  `not_applicable`.

## Out of scope

- Fixing defects in target repositories.
- Assigning severity, disclosure policy, or remediation deadlines.
- Replacing mechanical checks owned by a target repository's CI.
- Defining the estate's security model or publishing permanent policy.
- Probing any target without the authorization and engagement records required
  by [the rules of engagement](docs/rules-of-engagement.md).
- Blocking build-mode delivery without a separately recorded decision.
- Turning the local outbox into a `risk-nexus` writer.

## Safety invariants

- The rules of engagement are accepted, but their acceptance authorizes no live
  target. Without a complete approved engagement record, only documentation
  and non-networked fixture design may proceed.
- No live target is authorized by this scope document.
- Every live run names its authorization, target, owner, window, technique,
  credential lane, rate ceiling, abort contact, and finding destination.
- A probe stops at the recorded boundary and never follows an adjacent system.
- Evidence records response shape and counts, never real tenant row values or
  credentials.
- Findings leave this repository; repairs do not enter it.
- A probe is trusted only after it has failed a known-bad fixture.

## Relevant when

- A service claims a Tenancy Posture evidence level that requires adversarial
  rather than mechanical evidence, and an engagement record for that service
  already exists or the work is an offline fixture.
- The estate needs the attacker model, the last dated run, and whether the
  harness has been shown to fail when the control is absent.

## Not relevant when

- A repository needs unit, schema, or provisioning tests for its own code.
- A finding needs triage, severity, or disclosure handling; use `risk-nexus`.
- Permanent policy needs publication; use `policy-nexus`.
- The desired activity is a live probe and no complete engagement exists.

## Current state

- Repository status: active.
- Layer: Staff (declared in `INTENT.md`, 2026-09-01). `conformance_state`
  stays `blocked-clean` in the dated
  [declaration migration evidence](docs/evidence/2026-10-11-layer-declaration-migration.md),
  outside declaration frontmatter under GH-DEC-2026-021 §5.
  `WHITEHAT-IN-0001` is closed.
- The capability statement above is the 2026-10-04 scope assessment. The
  comparison against `INTENT.md` is
  [`history/2026-10-04T0649Z-scope-against-intent.md`](history/2026-10-04T0649Z-scope-against-intent.md).
  `WHITEHAT-WP-0011` added the E4 and R4 calibrations and the cadence
  register. It authorizes no packet.
- `WHITEHAT-WP-0012` records that I and A evidence is mechanical and adds
  the offline V observation judge. Live E4, live R4, and a live V2–V4
  exercise stay `wait` on an owner or operator this repository cannot name.
  The plan stays `blocked`. It does not add a `risk-nexus` writer and it
  does not change `conformance_state`. It authorizes no packet and no
  failure injection.
- Finished: `WHITEHAT-WP-0001` through `WHITEHAT-WP-0005`,
  `WHITEHAT-WP-0007`, `WHITEHAT-WP-0009`, `WHITEHAT-WP-0010`, and
  `WHITEHAT-WP-0011`.
- Residual live Tenancy Posture evidence is `WHITEHAT-WP-0006`. Residual
  live ASM is `WHITEHAT-WP-0008`. Both stay `blocked` after the 2026-10-04
  owner returns. T01 now has the file grant from `rapp-postgres` `8d4106f`
  and still waits on an authorized promotion, a `railiance-platform` runtime
  `LOGIN` receipt, and a complete engagement. T02 still waits on an operator
  substrate window. T03 still waits
  on `access-engine` or a new `audit-core` engagement ID. Live ASM still
  waits on a surface owner, with T-06 on `approval-engine` and a consuming
  PEP. No packet is authorized.
- `WHITEHAT-WP-0007` triaged Gate House ASM T-01…T-10. Live `asm-tNN`
  registrations remain `pending`. In-process `fixture-asm-t01`…`t10`
  calibrations exist. That work authorized no live probe.
- `WHITEHAT-WP-0001` T01–T08 are complete for every applicable target.
  `audit-core` has dated E2 pass `WH-ENG-20260822-AUDIT-E2-03`.
  `tenant-engine` E2 and `platform-pg` E3 stay `not_applicable`. `flex-auth`
  E2 and `shared-substrate` P1/P2 stay `pending`. Offline E2, E3, E4, R4, and
  P1/P2 harnesses fail known-bad and pass known-good in process.
- `-01`, `-02`, and `-03` are terminal. A later live run needs a new
  engagement ID, plane admission, and the approvals required by the rules of
  engagement. `WHITEHAT-WP-0006` owns that work and authorizes no packet.
- `WHITEHAT-WP-0009` is finished. The 0.2.1 record shows WH-KNOW-001 and
  WH-KNOW-002. A local 0.2.3 retest did not reproduce them. `risk-nexus`
  holds open RISK-F-0013, RISK-F-0014, and RISK-F-0015. `emergent-security`
  commit `19e7feb` accepts the scoped review and the two library
  remediations, and leaves provider evidence and the `informed-decision`
  pin reconciliation in blocked EMERGENT-WP-0002. This plan authorizes no
  packet.
- `WHITEHAT-WP-0010` is finished. It dispositions sealed knowledge 0.2.6,
  digest `8d1d6a9d`, commit `f65d0e64`, from offline probes and the recorded
  28-case corpus. It finds no unsafe effect and both named RISK-F-0015
  routes on the fixture tokens. It does not close that finding, accept
  EMERGENT-WP-0002-T07, or re-pin `informed-decision`. On 2026-10-04
  `emergent-security` commit `9f4530b` accepted only that bounded review
  gate, and `risk-nexus` commit `e1f006b` recorded the observation.
  RISK-F-0015 stays open. It authorizes no packet.

## Relationships

- Owner and security canon: `net-kingdom`.
- Finding intake, severity, and disclosure: `risk-nexus`.
- Permanent publication: `policy-nexus`.
- Initial proposed target owners: `tenant-engine`, `audit-core`, and
  `flex-auth`.

## Getting oriented

1. Read [`INTENT.md`](INTENT.md) for the durable purpose and ownership model.
2. Read [the rules of engagement](docs/rules-of-engagement.md) before any probe
   design or execution.
3. Read [`history/2026-10-04T0649Z-scope-against-intent.md`](history/2026-10-04T0649Z-scope-against-intent.md)
   for the capability gaps against that intent.
4. Read [`WHITEHAT-WP-0001`](workplans/WHITEHAT-WP-0001-cross-tenant-evidence.md)
   for the finished applicable-target artifacts,
   [`WHITEHAT-WP-0006`](workplans/WHITEHAT-WP-0006-authorized-live-residuals.md)
   for unauthorized live Tenancy Posture residuals,
   [`WHITEHAT-WP-0007`](workplans/WHITEHAT-WP-0007-asm-t01-t10-triage.md)
   for finished ASM T-01…T-10 triage,
   [`WHITEHAT-WP-0008`](workplans/WHITEHAT-WP-0008-live-asm-residuals.md)
   for unauthorized live ASM residuals, and
   [`WHITEHAT-WP-0011`](workplans/WHITEHAT-WP-0011-scope-capability-gaps.md)
   for the offline E4, R4, and cadence work, and
   [`WHITEHAT-WP-0012`](workplans/WHITEHAT-WP-0012-ia-classification-and-v-observations.md)
   for the I/A classification, the offline V judge, and the blocked live
   E4, R4, and V requirements.

## Generated work-record index

This repository opts into staged-source WORK-RECORDS.md generation through
`.generated-work-records.json` and the isolated `.generated-work-records.mk`
recipe. `make generated-work-records` reuses the State Hub renderer through
the Custodian adapter; `make generated-work-records-check` verifies byte-exact
agreement with staged Markdown. The pre-commit hook uses the isolated recipe,
preserves unstaged index edits by refusing them, and retains the generated-only
commit guard. It does not contact the hub, alter workplan statuses, or grant
deployment authority. This consumes shared tooling; it does not make this
repository the provider of the generator capability.