You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During a CodeBeast audit + remediation of stackbilt-engine (a scaffold code factory), we ran charter bootstrap --preset worker as part of post-hardening governance onboarding. The bootstrap succeeded cleanly (doctor PASS, 12/12), but the experience surfaced a gap: charter's presets don't differentiate repos by security posture.
stackbilt-engine is an EGRESS-class repo — it generates code that ships into every downstream project. A timing attack in its templates (=== on HMAC digests) becomes a hereditary vulnerability. The bootstrap treated it identically to any other worker repo.
Proposal
Add a --security-sensitive flag (or a security preset modifier) to charter bootstrap that:
Generates a SECURITY.md from a template (responsible disclosure contact, supported versions table, vulnerability reporting process). This is already tracked as a separate rollout across Stackbilt repos, but charter is the natural place to automate it.
Seeds a .charter/patterns/security-deny.json with deny patterns for the drift scanner:
=== signature / === expected (timing attacks)
?.get() / ?.put() on security-critical bindings (silent bypass)
// TODO in auth/session/token paths
c.json({ access_token (token exposure)
These would be consumed by charter drift as hard failures, not warnings.
Adds an L4 security gate to verify:adf — a post-bootstrap check that the repo has at least one test file matching **/security* or **/l4*. Emits a warning (not a block) if absent, nudging the team to add security regression tests.
Why charter, not CodeBeast
CodeBeast runs adversarial audits on existing code. Charter governs the development process before code is written. The deny patterns belong in charter's drift scanner because they should prevent regressions at commit time, not catch them after deployment. The two tools are complementary — CodeBeast finds the disease, charter vaccinates against reinfection.
Context
During a CodeBeast audit + remediation of
stackbilt-engine(a scaffold code factory), we rancharter bootstrap --preset workeras part of post-hardening governance onboarding. The bootstrap succeeded cleanly (doctor PASS, 12/12), but the experience surfaced a gap: charter's presets don't differentiate repos by security posture.stackbilt-engine is an EGRESS-class repo — it generates code that ships into every downstream project. A timing attack in its templates (
===on HMAC digests) becomes a hereditary vulnerability. The bootstrap treated it identically to any other worker repo.Proposal
Add a
--security-sensitiveflag (or asecuritypreset modifier) tocharter bootstrapthat:Generates a
SECURITY.mdfrom a template (responsible disclosure contact, supported versions table, vulnerability reporting process). This is already tracked as a separate rollout across Stackbilt repos, but charter is the natural place to automate it.Seeds a
.charter/patterns/security-deny.jsonwith deny patterns for the drift scanner:=== signature/=== expected(timing attacks)?.get()/?.put()on security-critical bindings (silent bypass)// TODOin auth/session/token pathsc.json({ access_token(token exposure)These would be consumed by
charter driftas hard failures, not warnings.Adds an L4 security gate to
verify:adf— a post-bootstrap check that the repo has at least one test file matching**/security*or**/l4*. Emits a warning (not a block) if absent, nudging the team to add security regression tests.Why charter, not CodeBeast
CodeBeast runs adversarial audits on existing code. Charter governs the development process before code is written. The deny patterns belong in charter's drift scanner because they should prevent regressions at commit time, not catch them after deployment. The two tools are complementary — CodeBeast finds the disease, charter vaccinates against reinfection.
Evidence
tests/security-l4.test.ts, 53 tests) is exactly what the bootstrap security gate would check forAcceptance
charter bootstrap --preset worker --security-sensitivegenerates SECURITY.md.charter/patterns/security-deny.jsonseeded with deny patternscharter drifttreats security-deny matches as errors, not warningscharter doctorchecks for security test presence (warning-level)