feat(security,ecosystem): outbound disclosure policy + OSS repo manifest#15
Merged
stackbilt-admin merged 1 commit intomainfrom Apr 10, 2026
Merged
Conversation
Adds the missing "outbound" side of the security policy — rules for when
Stackbilt itself (operators and internal agents) files findings against
its own public repositories. The existing policy covered inbound reports
only; this closes the gap.
What's new:
1. security.md — new "Outbound Disclosure" section:
- Severity/channel routing matrix for public vs private repos
- Neutral-filer rule (no internal agent branding on public issues)
- Reference framing rules (cite RFCs/OWASP, not internal docs)
- Scrub list of identifier classes that must not appear publicly
- Cross-repo chain rule (never describe private-chain findings publicly)
- Approval gate for agent-filed public issues
- Disclosure audit log requirement
- Policy Authoring Rule: the policy itself must pass its own scrub
filter during revisions (includes a case study of the near-miss
that produced this section)
- Primary reporting email flipped to admin@stackbilt.dev
- GHSA added as per-repo preferred channel
2. ecosystem.md — two new sections:
- Open Source Libraries table listing 14 OSS repos under Stackbilt-dev
with one-line purposes and repo links
- OSS Core / Commercial Extension pattern documentation with aegis-oss
as the concrete example; commercial extensions described abstractly
without naming
- Service Map AEGIS row updated to point at aegis-oss (removes the
"Internal cognitive agent" phrasing that contradicted the new OSS
libraries section)
3. public/ecosystem/repo-visibility.json — new machine-readable manifest:
- Public allowlist only (16 repos) with ecosystem_role, disclosure
channel, and fallback channel per entry
- default_policy stanza: anything not listed is private, must not be
referenced publicly
- Routing matrix for severity -> channel decisions
- Reference framing allowlist / prohibition list
- agent_consumers section documenting pre-flight lookup behavior
- Contains NO private repo names. Private-name scrub lists are
generated dynamically by agents at session start via the
authenticated GitHub API, never persisted to a public-visible
location.
4. public/ecosystem/SECURITY.md.template — canonical per-repo SECURITY.md
template. Placeholder {{REPO_NAME}} replaced at rollout time. Points
at admin@stackbilt.dev and the canonical policy URL.
Known pre-existing scrub gaps in ecosystem.md that are NOT addressed in
this PR and will be tracked in a follow-up issue:
- Service Map line 29: tarotscript-worker service binding identifier
- Service Map line 30: img-forge-gateway service binding identifier
- Authentication section lines 123, 129: edge-auth named by private
repo name
These were present before this PR and are editorial decisions about how
the deployed auth and service-binding architecture is described. Fixing
them requires broader rewriting of those sections and is out of scope
for this policy introduction.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
stackbilt-admin
pushed a commit
to Stackbilt-dev/cc-taskrunner
that referenced
this pull request
Apr 10, 2026
Adds the standardized Stackbilt-dev security reporting template to this repository. The template is the canonical per-repo security file rolled out across the entire Stackbilt-dev organization as part of the outbound disclosure policy (Stackbilt-dev/docs#15). Key points: - Primary reporting channel: admin@stackbilt.dev - GitHub Security Advisory link scoped to this repo - Response target matrix (critical 24h ack / 7d fix, high 48h / 14d) - Full policy link at https://docs.stackbilt.dev/security/ - Explicit "do not open public GH issues for vulns" rule This replaces the implicit policy that existed via the Stackbilt-dev organization profile with an explicit per-repo file, so the GitHub security tab surfaces it and external researchers have a clear reporting path. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
4 tasks
stackbilt-admin
added a commit
to Stackbilt-dev/cc-taskrunner
that referenced
this pull request
Apr 10, 2026
Adds the standardized Stackbilt-dev security reporting template to this repository. The template is the canonical per-repo security file rolled out across the entire Stackbilt-dev organization as part of the outbound disclosure policy (Stackbilt-dev/docs#15). Key points: - Primary reporting channel: admin@stackbilt.dev - GitHub Security Advisory link scoped to this repo - Response target matrix (critical 24h ack / 7d fix, high 48h / 14d) - Full policy link at https://docs.stackbilt.dev/security/ - Explicit "do not open public GH issues for vulns" rule This replaces the implicit policy that existed via the Stackbilt-dev organization profile with an explicit per-repo file, so the GitHub security tab surfaces it and external researchers have a clear reporting path. Co-authored-by: Codebeast <codebeast@stackbilt.dev> Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
stackbilt-admin
pushed a commit
to Stackbilt-dev/stackbilt-mcp-gateway
that referenced
this pull request
Apr 10, 2026
Adopts the canonical SECURITY.md template published in Stackbilt-dev/docs#15 and served at https://docs.stackbilt.dev/ecosystem/SECURITY.md.template. Points disclosure traffic at admin@stackbilt.dev and this repo's GitHub Security Advisory endpoint, matching the policy's channel routing matrix for public Stackbilt-dev repositories. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
stackbilt-admin
added a commit
to Stackbilt-dev/cc-taskrunner
that referenced
this pull request
Apr 16, 2026
* chore: add canonical SECURITY.md Adds the standardized Stackbilt-dev security reporting template to this repository. The template is the canonical per-repo security file rolled out across the entire Stackbilt-dev organization as part of the outbound disclosure policy (Stackbilt-dev/docs#15). Key points: - Primary reporting channel: admin@stackbilt.dev - GitHub Security Advisory link scoped to this repo - Response target matrix (critical 24h ack / 7d fix, high 48h / 14d) - Full policy link at https://docs.stackbilt.dev/security/ - Explicit "do not open public GH issues for vulns" rule This replaces the implicit policy that existed via the Stackbilt-dev organization profile with an explicit per-repo file, so the GitHub security tab surfaces it and external researchers have a clear reporting path. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * feat(taskrunner): ratchet mode — measure-before-after validation Closes #16. Adds an opt-in guard that captures a baseline snapshot of typecheck + test state on main BEFORE the task branch is created, re-runs the same checks on the branch AFTER the task commits, and automatically reverts the branch (delete locally, skip push/PR, mark failed) when any check transitioned pass→fail. Opt-in paths - Per-task: `"ratchet": true` in the task JSON - Category default: `refactor` and `bugfix` tasks ratchet automatically - Environment: `CC_RATCHET=1` force-enables for every task Never ratcheted - `docs`, `tests`, `research`, `deploy` categories (no regression surface or outcomes aren't code-level) Decision rule Only pass→fail transitions revert. fail→fail (unchanged broken surface) and skip→fail (first-time check on a pre-existing breakage) are both `keep`. fail→pass is `keep`. The goal is to gate regressions, not punish tasks for inheriting broken state. Snapshot surface - `npm run typecheck` exit code → pass/fail/skip - `npm test` exit code → pass/fail/skip - Each check is independent and degrades to `skip` when the repo has no corresponding script in `package.json`. Zero new dependencies. Integration points - Baseline captured right after `git pull --ff-only`, before the task branch is checked out (so we measure true main state). - Post-validation runs after commits but BEFORE push, so a regressed branch never reaches origin and never opens a PR. - Ratchet state is local to each execute_task() call — initialized up front so operator-authority tasks (which skip branch creation) don't trip unbound-variable errors under set -u. Applied symmetrically to taskrunner.sh and plugin/taskrunner.sh. Smoke-tested ratchet_decision() against 5 transition cases: - skip→skip: keep ✓ - pass→pass: keep ✓ - pass→fail: revert (rc=1) ✓ - fail→fail: keep (no regression) ✓ - skip→fail: keep (first-time surface) ✓ Env knobs - CC_RATCHET=1|0 force-enable/disable, overrides task fields - CC_RATCHET_TIMEOUT=<seconds> per-check timeout (default: 180) - CC_DISABLE_RATCHET=1 legacy alias for CC_RATCHET=0 Closes #16 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * docs(changelog): 1.6.0 ratchet mode entry Should've been in the prior commit but Edit bailed on an unread file. Squash candidate on merge. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: use .git/info/exclude instead of .gitignore for worktree protection (#25) The worktree-protection pattern (C:* glob for Windows-path pollution, added in #6) was being appended to .gitignore and staged, causing every auto-generated PR to include unsolicited .gitignore modifications. Move the exclusion to .git/info/exclude, which provides identical git ignore behavior but is local to the repository and never committed. Closes #25 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * docs(readme): add Claude Code Routines comparison section Anthropic shipped Claude Code Routines (research preview) in April 2026 — saved Claude Code configurations that run on Anthropic's cloud on a schedule, via API trigger, or on GitHub repository events. Routines and cc-taskrunner solve overlapping problems differently. New users evaluating the taskrunner deserve to know the alternative exists and when each substrate is the right fit. New "cc-taskrunner vs. Claude Code Routines" section between "Why This Exists" and "Quick Start" includes: - 12-row capability comparison table (where it runs, cost model, trigger types, cadence floor, local FS access, runs-while-laptop-closed, queue management, branch isolation, safety hooks, blast radius, GitHub event triggers, setup overhead) - Explicit "when cc-taskrunner is right" decision rubric (queue management, local FS access, sub-hour cadence, blast-radius enforcement, hook-level safety) - Explicit "when Claude Code Routines are right" decision rubric (single repeatable task, GitHub-event-driven, runs while laptop off, MCP-only mutations) - Honest disclosure that Stackbilt itself runs the taskrunner in paused mode and uses Routines for several scheduled workloads — complementary not competitive Framing throughout: pick the substrate that fits the work, neither obsoletes the other in a real ecosystem. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Codebeast <codebeast@stackbilt.dev> Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds the outbound side of the security policy — rules for when Stackbilt itself (operators and internal agents) files findings against our own public repositories. The existing policy only covered inbound reports from external researchers; this closes the gap.
This PR introduces the full framework: policy text, a machine-readable public repo manifest, a canonical per-repo SECURITY.md template, and an updated ecosystem doc that documents the OSS Core / Commercial Extension pattern without leaking private repo names.
What's in this PR
1.
src/content/docs/security.md— new "Outbound Disclosure" sectionsecurity@toadmin@stackbilt.dev2.
src/content/docs/ecosystem.md— two new sectionsaegis-oss) has commercial productization built on top. Names only the OSS core; describes commercial extensions abstractly without naming them. Enforces the moat-protecting convention that public discussion always references the OSS repo.aegis-oss(removes the "Internal cognitive agent" phrasing that directly contradicted the new OSS Libraries section)3.
public/ecosystem/repo-visibility.json— new machine-readable manifestServed at
docs.stackbilt.dev/ecosystem/repo-visibility.jsonfor agent pre-flight lookups.ecosystem_role,disclosure_channel, andfallback_channeldefault_policystanza — any Stackbilt-dev repository not listed here is treated as private by default; unlisted repos must not be referenced in publicagent_consumerssection documenting how internal automation consumes this file at pre-flight4.
public/ecosystem/SECURITY.md.template— canonical per-repo SECURITY.mdOne-file-fits-all template for per-repository SECURITY.md files across the entire Stackbilt-dev organization. Placeholder `{{REPO_NAME}}` is replaced at rollout time. Points at `admin@stackbilt.dev` and the canonical policy URL.
This unblocks a follow-up rollout that will apply the template to every repo (public and private) so every repo has a standardized security reporting entry point.
The Meta-Finding — why this PR has a "Policy Authoring Rule" section
The first draft of this policy would have shipped the exact leak it was designed to prevent.
The initial
repo-visibility.jsonI wrote listed every Stackbilt-dev repository by name — public AND private — because the natural instinct when documenting a visibility manifest is to be thorough. Publishing that file atdocs.stackbilt.dev/ecosystem/repo-visibility.jsonwould have converted "private repos exist but are not externally enumerable" into "here is the complete roster of every internal Stackbilt project." Private repo names are not currently discoverable via unauthenticated `gh api` calls, so the manifest would have been a pure reconnaissance gift.The initial ecosystem.md dual-repo section also named private commercial extensions directly in a table alongside their OSS cores. Same class of leak, narrower scope.
Both were caught in a pre-commit review pass before anything was pushed. No disclosure occurred. But the near-miss validates the rule: policy documents must be authored with the policy's own scrub rules applied from the start, not written thoroughly and scrubbed after. The highest-risk context for accidental disclosure is the policy authoring context itself, because the author has the most private context loaded at exactly the moment they're writing public-facing text.
This is codified in the new Policy Authoring Rule section with the above near-miss as the case study.
Known pre-existing scrub gaps NOT addressed in this PR
These were present in ecosystem.md before this PR and are editorial decisions about how the deployed auth and service-binding architecture is described. Fixing them requires broader rewriting of those sections and is out of scope for this policy introduction. Tracked as a follow-up issue:
A follow-up issue on this repo will track the scrub pass and propose the replacement wording.
Test plan
Follow-up work unlocked by this PR
🤖 Generated with Claude Code