amal66 gives Mike's security posture a proper front door

The fork makes it easier to report problems privately and harder for security mistakes to slip into the project unnoticed.

securityinfrastructure

amal66 has added the parts of a security programme that sit beyond routine dependency checks: a clear route for responsible disclosure, automated analysis of application code, checks for accidentally committed credentials, and a public measure of repository hygiene.

Private vulnerability reporting gives researchers a defined channel, scope and seven-day acknowledgement expectation, including for prompt-injection concerns.
Automated code analysis looks for security weaknesses across the product.
Credential scanning checks both new changes and the repository's history, blocking newly exposed secrets.
A weekly public security scorecard tracks the project's broader safeguards.

Some protections still require repository settings to be switched on, including server-side prevention before a credential reaches the history.

So what Legal teams assessing an AI product's operational maturity should care: this is a meaningful move from good intentions toward visible, repeatable security practice.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

2 commits from amal66/mike, oldest first. Source extracted verbatim from the harvested git log.

SHA	Subject	Author	Date
`f75914ca`	ci(security): SECURITY.md, CodeQL, gitleaks, OpenSSF Scorecard	Amalanand Muthukumaran	2026-07-25	↗ GitHub
commit body Public-repo security posture on top of PR #227's audit/eslint/dependabot gates: - SECURITY.md: private vulnerability reporting via the Security tab, 7-day acknowledgment (solo maintainer), self-hosted + LLM prompt-injection scope notes. main-only support (no release tags yet). - codeql.yml: javascript-typescript analysis with build-mode: none (interpreted TS, no build needed) on PRs, main, and a weekly cron. - gitleaks.yml: full-history secret scan using a sha256-verified pinned release binary instead of gitleaks-action (which needs a paid license for org repos). .gitleaks.toml allowlists hand-verified fake secrets (test fixtures, docs placeholders, the public supabase-demo anon key); a local run over all 551 commits is clean with this config. - scorecard.yml: OpenSSF Scorecard on main + weekly cron with publish_results: true. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
`a119e3e6`	fix(security-posture): pin actions to SHAs, allowlist exact secrets, correct policy scope	Amal	2026-08-02	↗ GitHub
commit body Addresses all four points from review on PR #246. WHY THIS MATTERS A security-posture PR has to hold itself to the standard it introduces. Each of the four fixes below closes a gap where the original version either overstated its guarantees (policy text) or quietly weakened them (scanner allowlists, mutable action refs). 1. SECURITY.MD SCOPE - THE HOSTED SERVICE EXISTS The policy claimed "there is no hosted service", but the official Mike website offers a cloud version at app.mikeoss.com. A researcher reading the old text would conclude the hosted service was out of scope and either not report or disclose publicly. The policy now explicitly takes hosted-service reports through the same private channel (with the usual safe-harbor expectations: own accounts only, non-destructive testing) and narrows the exclusion to what it was always meant to cover: independent third-party self-hosted deployments. 2. SUPPORTED VERSIONS - TAGS EXIST AND ARE UNSUPPORTED The repository has tags v0.1.0 through v0.4.0, so "there are no tagged releases" was simply wrong, and wrong in the dangerous direction: a user pinned to v0.4.0 might assume they were covered. The policy now lists the tags explicitly as unsupported historical snapshots - only the tip of main receives security fixes. 3. WORKFLOW ACTION PINNING - TAGS ARE MUTABLE, SHAS ARE NOT `uses: some/action@v4` re-resolves on every run: whoever controls that tag controls code that executes inside this repo's CI, which is exactly how the 2025 tj-actions/changed-files compromise spread. The risk is sharpest in the Scorecard job, which holds id-token: write (OIDC signing) and security-events: write. Every `uses:` now references a full commit SHA - the only immutable ref format GitHub offers - with the release version kept in a trailing comment, which is the convention Dependabot parses to keep proposing pinned updates: actions/checkout@11d5960a... # v4.4.0 github/codeql-action/*@a2983b8b... # v3.37.4 ossf/scorecard-action@4eaacf05... # v2.4.3 4. GITLEAKS - ALLOWLIST EXACT SECRETS, NEVER PATHS The old config allowlisted entire files ("this file contains a fake secret, ignore it"). gitleaks applies a global allowlist's `paths` as a whole-file skip, so a REAL credential later committed to any of those files would sail through the scan - the allowlist grew a permanent blind spot with every entry. Reproduced before fixing: planting a high-entropy secret in an allowlisted fixture file and scanning full history reported zero leaks under the old config. The new config allowlists exact secret VALUES instead - one anchored regex per hand-verified fake (the safeError test fixtures, the add-in e2e mock token, and Supabase's published local-dev demo JWTs, which are public by construction). A real secret can never equal a known fake, so the blind spot is gone; the same planted-secret experiment now fails the scan, and the full history of both this branch and current main still passes clean. This also surfaced two findings the old path list missed entirely (the demo JWTs in .env.example / docker-compose.yml history) - they are now consciously allowlisted by value rather than accidentally green. VERIFICATION - All three workflows parse as valid YAML. - gitleaks 8.30.1 (checksum-verified binary): full-history scan clean on this branch and on current origin/main with the new config. - Planted-secret experiment: old config 0 leaks (blind), new config 1 leak (caught) on an identical history. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-1319.md from inside the repo you want the changes in.

⬇ Download capture-thread-1319.md