Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Add `.env` and secret-scanning to CI to prevent credential commits

Open
  • Is something wrong?
#283 1 comment 0 reactions 0 assignees View on GitHub

@ranjeet150 is already working on this.

Since Oct 9, 2026.

Assessment

Difficulty
3/5
Estimated time
Half a day
Newbie friendliness
42/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
github-actions, nodejs
Domain
ci-cd, security

Research direction

Start with .github/workflows/build-check.yml to see the existing jobs, then package.json line 28 for security:check, scripts/generate-secrets.sh, .gitignore, and the README warning at line 107. Check the git history for any committed .env file before choosing the allowlist. Done means a secret-scan job runs on pull requests over full history, security:check runs it, a reviewed baseline exists, and the rotate-then-purge process is documented.

Written by the indexing model from the issue text.

Description

good first issue help wanted security tooling

Problem

There is no secret scanning in .github/workflows/build-check.yml, which runs only: install → codegen diff → tsc --noEmit → a narrow Jest subset → build, plus an OpenAPI/SDK job on pushes.

Meanwhile the repository is unusually exposed to credential leaks:

  • .env.example, .env.production.example, .env.secrets.template are all committed (correctly, as templates)
  • npm run security:generate-secrets runs a shell script (scripts/generate-secrets.sh) that creates secrets
  • security:check (package.json:28) runs npm audit, lint, and the KYC guard scan — but no secret scan, and it is not wired into CI
  • The README (line 107) warns "Never commit .env files"

Nothing enforces that warning.

Why it matters

A committed secret is permanent in git history even after a later commit removes it, and anyone cloning gets it. On a project handling wallet signing keys, JWT secrets, and provider API keys, a leaked JWT_SECRET allows forging tokens — including admin tokens, given RolesGuard is registered globally.

GitHub's own secret scanning is unavailable for public repos only in older plan configurations and does not cover everything; a repo-side check is a useful second layer and catches leaks before they are pushed rather than after.

Suggested Direction

  1. Add a secret scan to CI using a maintained tool — gitleaks or trufflehog — as a job in .github/workflows/build-check.yml that scans the full history, not just the working tree. Pin the action version and keep the config in-repo.
  2. Extend npm run security:check (package.json:28) to include the scan, so contributors can run the same checks locally that CI runs.
  3. Verify .gitignore actually excludes .env and that no .env file is present in history. This is the first thing to check — if a secret was already committed, remediation is: rotate it first, then purge history. Rotation is mandatory; history rewriting alone does not help.
  4. Add a baseline file so existing known-safe matches (for example placeholder values in .env.example) do not block every build. Tune the allowlist rather than disabling the scan.
  5. Document the process — what to do when the scan fires, and that rotation comes before history rewriting.

Constraints

  • A scan with no baseline will fail immediately on the existing templates; plan for a reviewed allowlist.
  • Do not paste a detected secret into a CI log or an issue. The scanner must redact the value it reports.
  • scripts/generate-secrets.sh must be reviewed to confirm it writes outside version control.
  • Pair this with the plaintext-refresh-token issue — a leaked database dump is the same class of problem.

Acceptance Criteria

  • A secret-scanning job runs in CI on pull requests and scans git history.
  • npm run security:check includes the scan.
  • .gitignore covers .env, confirmed by checking history for committed .env files.
  • A reviewed baseline allowlist exists so legitimate placeholder values do not fail the build.
  • Detected values are redacted from scanner output.
  • The response process (rotate first, then purge history) is documented.
Dominant language
TypeScript
Stars
7
Forks
55
Avg merge
1d 17h
Merged PRs (30d)
5

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from SourceXXL/alian_structure-api

All issues in SourceXXL/alian_structure-api

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.