docs: audit STPA + compliance honesty (#96)

Closes 3 findings from the 2026-04-30 audit:
  L-3 — soften phantom DO-178C/26262 trace claims; clarify what IS traced
  L-4 — add implementation-status field; populate sample of design-only SC/CCs
  L-6 — note Dockerfile.bytehound is outside the flake hermeticity guarantee

Trace: skip

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: avrabe

AGENTS.md

@@ -329,3 +329,8 @@ bazel build //src/cli:wasmsign_cli
 - `wasm-signing.yml` - End-to-end signing demonstration
 - `fuzz.yml` - Fuzz testing
 - `memory.yml` - Memory profiling
+
+> **Memory profiling reproducibility note:** Memory profiling via
+> `Dockerfile.bytehound` is **not in the hermetic build path**. The
+> bytehound image clones upstream and builds with `cargo +nightly`, so
+> reproducibility is best-effort, not bit-exact (unlike the Nix flake).

Dockerfile.bytehound

@@ -1,3 +1,19 @@
+# =============================================================================
+# NOTE: This image is intentionally OUTSIDE the Nix flake's hermeticity
+# guarantee. It uses `cargo +nightly` and clones bytehound from upstream
+# (a moving HEAD), and pulls a debian:bookworm rust toolchain image whose
+# apt-package set is not pinned. Reproducibility is best-effort, not
+# bit-exact.
+#
+# This is acceptable because the image is used only for memory profiling
+# (developer-facing diagnostics), never for producing release artifacts
+# or signing material. Anything that ships to users goes through the
+# `flake.nix` hermetic build path.
+#
+# If you need a reproducible memory-profiling environment, pin both the
+# base image digest and the bytehound git revision below.
+# =============================================================================
+
 FROM rust:1.90-bookworm
 
 # Install dependencies

SECURITY.md

@@ -656,6 +656,31 @@ For automotive (ISO/SAE 21434) and industrial IoT (IEC 62443) deployments, see:
 - [docs/KEY_LIFECYCLE.md](docs/KEY_LIFECYCLE.md) - Key management procedures (covers [[CD-1]] through [[CD-9]])
 - [docs/INCIDENT_RESPONSE.md](docs/INCIDENT_RESPONSE.md) - Security incident runbook
 
+### Scope of Compliance Mapping
+
+The following compliance frames **ARE** modelled in the artifact graph
+(under `artifacts/cybersecurity/` and `artifacts/stpa/`) with traceable
+links from threats to goals to requirements to designs and verifications:
+
+- **ISO/SAE 21434** (Road vehicle cybersecurity engineering) — TARA, CAL ratings, Annex H attack-feasibility scoring.
+- **IEC 62443** (Industrial automation and control systems security) — referenced for SL3+ gaps in HSM integration and OCSP/CRL revocation.
+- **EU Cyber Resilience Act (CRA)** and **UNECE R155 / R156** (vehicle type-approval cybersecurity / software updates) — see [docs/automotive-regulatory-compliance.md](docs/automotive-regulatory-compliance.md).
+
+The following compliance frames are **RELEVANT TARGETS** for sigil's
+roadmap but are **NOT YET modelled** in the artifact graph — no
+artifact carries a `do-178c-objective:` or `iso-26262-table:` field, and
+no traceability rule cross-references their objective tables:
+
+- **DO-178C** (Software considerations in airborne systems and equipment certification, civil aviation).
+- **ISO 26262** (Road vehicles — functional safety).
+
+These two standards are mentioned in passing in design discussions
+(see `artifacts/dev/features.yaml` for the Lean4/Coq proof-pipeline
+roadmap) but **do not yet have artifact-graph trace coverage**. Adding
+that mapping is tracked as a follow-up; until then, any claim of
+DO-178C / ISO 26262 alignment in this repository should be read as
+"potential mapping; not yet modelled in `artifacts/`."
+
 ---
 
 ## Reporting Security Issues

artifacts/cybersecurity/goals-and-requirements.yaml

@@ -1466,6 +1466,10 @@ artifacts:
       verification-criteria: >
         Verification rejects modules with only classical or only PQC
         signature when hybrid mode is configured.
+      # Honesty marker: Phase 3 PQC roadmap; hybrid Ed25519+SLH-DSA
+      # verification pipeline (CD-24) is still in draft. No hybrid
+      # verifier code path exists in src/lib yet.
+      implementation-status: design-only
     links:
       - type: derives-from
         target: CG-1
@@ -1484,6 +1488,11 @@ artifacts:
       verification-criteria: >
         Cache lookup returns miss for entries whose signing key has been
         revoked; revocation triggers immediate cache invalidation.
+      # Honesty marker: revocation-aware proof cache is design-only.
+      # No code exists today that wires key-revocation events to the
+      # proof cache; CR-20 has neither cybersecurity-design nor
+      # cybersecurity-verification linked.
+      implementation-status: design-only
     links:
       - type: derives-from
         target: CG-8
@@ -1502,6 +1511,10 @@ artifacts:
       verification-criteria: >
         Verification rejects Fulcio certificates missing SCTs or containing
         SCTs from untrusted CT logs.
+      # Honesty marker: paired with SC-26. Cryptographic verification of
+      # SCT signatures against trusted CT log keys is design-only — see
+      # the SC-26 entry in artifacts/stpa/losses-and-hazards.yaml.
+      implementation-status: design-only
     links:
       - type: derives-from
         target: CG-7
@@ -1520,6 +1533,9 @@ artifacts:
       verification-criteria: >
         Checkpoint writes are atomic; partial writes do not corrupt existing
         checkpoints; integrity check detects tampered checkpoints on load.
+      # Honesty marker: atomic checkpoint store (SC-28) is design-only.
+      # No write-then-rename checkpoint persistence exists in code today.
+      implementation-status: design-only
     links:
       - type: derives-from
         target: CG-8
@@ -1556,6 +1572,11 @@ artifacts:
       verification-criteria: >
         Verification enforces configured threshold; rejects envelopes with
         fewer valid signatures than the threshold requires.
+      # Honesty marker: configurable N-of-M threshold policy is design-only.
+      # `src/lib/src/dsse.rs` exists but does not yet expose a runtime
+      # threshold-policy configuration surface; CR-24 has no
+      # cybersecurity-design or cybersecurity-verification artifact yet.
+      implementation-status: design-only
     links:
       - type: derives-from
         target: CG-1

artifacts/stpa/losses-and-hazards.yaml

@@ -958,6 +958,12 @@ artifacts:
       Signed Certificate Timestamp signatures MUST be verified against
       a trusted set of CT log public keys, rejecting SCTs signed by
       unknown or untrusted logs.
+    fields:
+      # Honesty marker (see schemas/stpa-sec.yaml note on implementation-status):
+      # SC-26 is named in the 2026-04-30 audit as the canonical example of
+      # an approved-design constraint that has not yet landed in code.
+      # The cryptographic SCT-against-trusted-log-keys check is design-only.
+      implementation-status: design-only
     links:
       - type: prevents
         target: H-27

artifacts/stpa/ucas.yaml

@@ -496,6 +496,10 @@ artifacts:
       expected provider before requesting identity tokens.
     fields:
       constraint: "Pipeline signing workflows must validate OIDC issuer URL matches expected provider before requesting identity tokens"
+      # Honesty marker: status `approved` covers the design intent only.
+      # The CI workflow does not yet inspect the OIDC issuer URL before
+      # requesting tokens; CTRL-7 (CI pipeline) implementation is design-only.
+      implementation-status: design-only
     links:
       - type: constrains-controller
         target: CTRL-7

schemas/stpa-sec.yaml

@@ -43,6 +43,29 @@ schema:
     Adds data flows, threat agents, security properties, and attack
     scenarios to the base STPA control structure model.
 
+# ──────────────────────────────────────────────────────────────────────────
+# Convention: optional `implementation-status` field on constraints/reqs
+# ──────────────────────────────────────────────────────────────────────────
+#
+# Across system-constraint, controller-constraint, and cybersecurity-req
+# artifacts, an optional `implementation-status` field MAY be set under
+# `fields:` to disambiguate `status: approved` (design vetted) from actual
+# code-landing state.  Allowed values:
+#
+#   design-only   The constraint is approved as design but no code,
+#                 test, or other implementation evidence exists yet.
+#   in-progress   Implementation has begun (a PR or branch exists)
+#                 but is not merged or not feature-complete.
+#   implemented   Code lands on main and is exercised; verification
+#                 evidence may or may not yet exist.
+#   verified      Implementation lands AND a verification artifact
+#                 (test, fuzz target, formal proof) demonstrates it.
+#
+# This field is informational only — rivet does not enforce its values.
+# It exists to surface the audit-honesty distinction the bare `status:`
+# field cannot make.  Untagged entries should be assumed `unknown`; do
+# not infer `implemented` from their absence of the marker.
+
 # ──────────────────────────────────────────────────────────────────────────
 # Artifact types
 # ──────────────────────────────────────────────────────────────────────────