Sensitive-boundary code-health study

Research state: Needs refresh

Summary

Credential, control-boundary, workflow, and supply-chain risks concentrate enough authority to require a dedicated code-health track.

The boundary analysis remains useful, but tool capabilities require revalidation before adoption.

Question

Should security-sensitive code-health work share the routine refactoring and linting program, or remain an independently reviewable track with its own context and verification?

Findings

• Broad model safeguards can route ambiguous defensive coding and debugging work differently from routine engineering. Isolating this track keeps the work legible and prevents unrelated code-health execution from loading sensitive examples.
• Workflow security linting, secret scanning, dependency audit records, auditable binaries, redaction policy, and control-boundary tests form one coherent enforcement surface. They should share a roadmap item even when implementation lands in separate changes.
• The implementation plan should remain narrow: select tools from current evidence, keep protected examples in the separate security-review corpus, and require each new gate to prove signal quality before becoming mandatory.

Prior art

• Claude Fable 5 and Claude Mythos 5 and Redeploying Fable 5 document broad cybersecurity safeguards and benign false-positive trade-offs.
• zizmor analyzes GitHub Actions workflows.
• gitleaks scans repositories and commits for secrets.
• cargo-vet records dependency audits with shared imports.
• cargo-auditable embeds dependency information in release binaries.

Roadmap outcome

Sensitive-boundary code health owns implementation and completion status.