Skip to content

chore: block newly committed .env credentials in CI - #2

Merged
ricky-raup merged 1 commit into
mainfrom
chore/committed-env-guard
Aug 18, 2026
Merged

chore: block newly committed .env credentials in CI#2
ricky-raup merged 1 commit into
mainfrom
chore/committed-env-guard

Conversation

@ricky-raup

Copy link
Copy Markdown

Summary

  • An org-wide read-only sweep on 12 Aug walked every commit in the org. This repo has 2 committed .env placement(s) but none of their values matched a provider credential pattern — so this is prevention, not remediation, and this PR does not claim a leak that isn't there. It still qualifies: a repo that commits .env files and its .gitignore (1781 B) does not cover every .env-shaped name is where the next real credential lands.
  • Adds .github/workflows/committed-env.yml — a 15th workflow alongside the 14 already here — plus bin/check-committed-env.py
    and a vendored bin/credscan.py, the same detector that produced the sweep's numbers.
  • Fires only on .env-shaped files a change adds or modifies, and only on a
    provider-matched value. Anything already committed here is untouched, so this lands
    green.
  • Measured in this repo: its .gitignore (1781 B) does not cover every .env-shaped name, and a plain git add -A stages .env.development, .env.local, .env.production today.
    Base branch is main.

What this does NOT do

  • It does not rotate, revoke, or touch any credential.
  • It does not delete anything already committed.
  • It does not block anything yet. This repo has no required-status-check ruleset — the
    only ruleset is "no force push" — so the check reports red and merges/pushes still
    succeed. Adding a required check is a repo-owner decision and is deliberately not in this
    PR.

Test plan

  • --selftest runs in CI before the check itself (18 assertions), so a detector that
    stopped matching cannot pass as "clean".
  • Proved against this repo's own .gitignore, fetched from main, in a
    throwaway repo: a commit adding a provider-shaped .env exits 1 and names the file;
    a commit editing only .env.example exits 0; the failure output never echoes the
    matched value
    . Every repo in this wave was proved separately because their ignore rules
    differ — five of them have no .gitignore at all.
  • Synthetic pattern-shaped values only — no real credential was written to disk.
  • Confirm the workflow run on this PR is green (it should be: nothing changed here is
    .env-shaped).

🤖 Generated with Claude Code

An org-wide read-only sweep on 12 Aug walked every commit in the AfterQuery org. This repo has committed .env-shaped files (2 placement(s)) but NONE of their values matched a provider credential pattern -- so this is prevention, not remediation, and the PR says so rather than implying a leak that is not there.

It still qualifies: a repo that already commits .env files and does not reliably ignore them is exactly where the next real credential lands.

Its .gitignore is 1781 bytes and does not cover every .env-shaped name. A plain `git add -A` in this repo stages `.env.development`, `.env.local`, `.env.production` today.

What it does: on every PR and every push to `main`, it checks the .env-shaped files a
change ADDS OR MODIFIES, and fails only on a provider-matched value. Anything already
committed here is untouched until someone edits it, so this lands green.

Honest limit: this repo has no required-status-check ruleset (the only rule is "no force
push"), so the check reports but does not block. It is detective until protection is
added -- deliberately left as a repo-owner decision rather than changed here.

bin/credscan.py is vendored rather than reimplemented, so this uses the SAME detector that
produced the sweep's published numbers. --selftest runs in CI ahead of the check, because a
detector that silently stopped matching would report "clean" forever.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Aug 13, 2026

Copy link
Copy Markdown

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 53 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: b207abc6-600f-466c-92d9-1f711529ca66

📥 Commits

Reviewing files that changed from the base of the PR and between a202ebe and 57fb16a.

📒 Files selected for processing (3)
  • .github/workflows/committed-env.yml
  • bin/check-committed-env.py
  • bin/credscan.py

Comment @coderabbitai help to get the list of available commands.

@ricky-raup
ricky-raup merged commit a8b1767 into main Aug 18, 2026
2 checks passed
@ricky-raup
ricky-raup deleted the chore/committed-env-guard branch August 18, 2026 14:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant