chore(security): CI hygiene & supply-chain pass — triage 5 gitleaks docs hits, add Dependabot

[MScottAdams]

Summary

A static, read-only security audit of this repo (osv-scanner + trivy + gitleaks + a dictionary scan) returned 5 findings, all in markdown proposal/history docs (no osv advisories, no trivy HIGH+CRITICAL, no unpinned actions). They look like example Authorization: Bearer … / generic-api-key strings inside code snippets, but each one still trips gitleaks every scan. Also no Dependabot config.

Scan baseline:

• osv-scanner vulnerabilities: 0
• trivy HIGH+CRITICAL: 0
• gitleaks findings: 5 (all in .md docs / history)
• Unpinned GitHub Actions refs: 0
• Dependabot configured: no

Problem(s)

1. gitleaks hits in 5 documentation files

• Location:
  • history/proposal-llms.txt-additions.md.20260121:465 — curl-auth-header
  • proposal--web--llms.txt-enhancements.md:1124 — curl-auth-header
  • proposal-cli--ai-help.md:590 — generic-api-key
  • history/proposal-cli--ai-help.md.20260121:415 — generic-api-key
  • history/proposal-web__ai_help.md.20260121:1389 — curl-auth-header
• Why it matters: These are documentation/proposal files. Most likely each shows an example curl -H "Authorization: Bearer …" or OPENAI_API_KEY=sk-… style snippet. If the values are placeholder strings, the right fix is to either rewrite them as obviously-fake (Bearer EXAMPLE_TOKEN, sk-EXAMPLE) or add .gitleaksignore entries so future scans return 0. If by accident one of them is a real key (the history/ mirrors of these docs make that worth checking), it must be rotated.
• Expected: Triage each of the 5 lines. Rewrite or suppress confirmed-fake examples; rotate any confirmed-real secret and remove from history.
• Fix: Edit each markdown file to use obviously-fake placeholders; add a .gitleaksignore referencing this issue for any remaining unavoidable hits.

2. No Dependabot config

• Location: missing .github/dependabot.yml.
• Why it matters: Same propagation argument as webinstaller#186. CVE advisories on already-pulled deps don't auto-open PRs without Dependabot.
• Expected: Add .github/dependabot.yml with the appropriate ecosystem block on weekly cadence and a security-updates group.
• Fix: Add the config file (example: https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file).

Acceptance criteria

• All 5 listed lines confirmed fake (or rotated if real); future gitleaks scans return 0 for this repo.
• .github/dependabot.yml exists with the relevant ecosystem block and a security-updates group; first Dependabot run schedules without error.

Out of scope

• Org-level controls (secret scanning, push protection) — repo settings change, not a code change in this issue.
• Restructuring the history/ proposal archive.

References

• Sibling hardening issue and template: deftai/webinstaller#186.
• gitleaks suppressions: https://github.com/gitleaks/gitleaks#configuration
• Dependabot config: https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file

[MScottAdams]

Re-scan update from the 2026-05-20 org-wide post-breach audit (deftai/section-31#18).

Scanners: static_scan.py + vscode_extensions_scan.py + osv-scanner 2.3.8 + trivy 0.70.0 + gitleaks 8.30.1. Hard-safety contract upheld — no package manager invoked inside the clone.

Re-scan tally

• 10 files in the repo (small).
• gitleaks: 5 raw hits → 0 effective P0 after re-classification.
• osv-scanner: 0. trivy: 0/0/0. VS Code extension surface: 0.

Re-classification of the 5 prior P0 gitleaks hits

All 5 are documentation / proposal-spec example tokens, not real leaks. Two were caught automatically by the expanded FP allowlist this cycle; three remained "raw" only because the file name carries a .20260121 timestamp suffix that bypassed the .md$ regex, but the content is the same class of finding.

File	Line	RuleID	FP class	Notes
proposal-cli--ai-help.md	590	generic-api-key	proposal-doc	TOOL_API_KEY="..." example in a feature-spec proposal
proposal--web--llms.txt-enhancements.md	1124	curl-auth-header	proposal-doc	curl -H "Authorization: Bearer ..." example
history/proposal-llms.txt-additions.md.20260121	465	curl-auth-header	history-snapshot	Timestamp-suffix snapshot of the proposal under history/
history/proposal-cli--ai-help.md.20260121	415	generic-api-key	history-snapshot	Same content as proposal-cli--ai-help.md, dated copy
history/proposal-web__ai_help.md.20260121	1389	curl-auth-header	history-snapshot	Same content as the root proposal, dated copy

The "history snapshots" appear to be timestamped copies of in-flight proposals — they would be re-generated each time a proposal is touched, hence appearing in the audit each cycle. Two ways to silence them durably (operator's call):

1. Move history/ into .gitignore if those files are not meant to be committed.
2. Switch the example tokens to ${REDACTED_FOR_DOCS} placeholders in the proposal source (then the history copies will inherit the placeholder shape and trip the existing env-placeholder FP rule).

Recommendation

This issue (#2) can be closed with not-planned once the operator agrees the 5 hits are documentation examples. Alternatively, apply option (2) above in a follow-up PR and we'll get a clean re-scan in the next cycle.

Notes on false positives (carry-forward + new for 2026-05-20)

• ${ENV_VAR} placeholders — env-placeholder
• Supabase anon JWT — supabase-anon
• Clerk pk_test_* / pk_live_* publishable keys — clerk-publishable (NEW)
• NEXT_PUBLIC_* / VITE_* / REACT_APP_* / PUBLIC_* / PUBLISHABLE_* env prefixes — public-env-prefix (NEW)
• *_test.{go,py,ts,tsx,js}, *.test.{ts,...}, tests/, __tests__/, fixtures/ — *-fixture
• .env.example|sample|template|dist|defaults — env-example
• docs/*.md, history/, proposals/, rfc/, root-level proposal*.md — doc-example / proposal-history-doc / proposal-doc (NEW)
• curl -H "Authorization: Bearer …" in *.md — curl-example-in-doc (NEW)

Raw log: security/audits/2026-05-20-org-wide-post-breach/logs/audit-poly/dashdash.gitleaks.json on the audit-poly shard branch.