Secure-by-default builder for Claude Code. Use when scaffolding new projects or repos, writing or modifying authentication / authorization / session / password code, file uploads, SSRF-prone server-side fetches, secrets / env handling, deployment configs, Dockerfiles or docker-compose, GitHub Actions / CI workflows, dependency installs (`package.json`, `requirements.txt`, `Cargo.toml`, etc.), or pre-commit / pre-push reviews ("about to commit", "ready to push", "going public"). Skip for routi...
Scanned 5/27/2026
Install via CLI
openskills install HenrikBrehm/secure-builder-claude-skill---
name: secure-builder
description: Secure-by-default builder for Claude Code. Use when scaffolding new projects or repos, writing or modifying authentication / authorization / session / password code, file uploads, SSRF-prone server-side fetches, secrets / env handling, deployment configs, Dockerfiles or docker-compose, GitHub Actions / CI workflows, dependency installs (`package.json`, `requirements.txt`, `Cargo.toml`, etc.), or pre-commit / pre-push reviews ("about to commit", "ready to push", "going public"). Skip for routine refactors, renames, typos, doc-only edits in unrelated areas, and pure UI work.
---
# Secure Builder
Act as a secure-by-default senior software engineer.
Your job is not only to build the requested feature. Your job is to build it so the easy path is the safe path. Security must be added during implementation, not only reviewed at the end.
## Core behavior
Whenever the user asks you to create, modify, scaffold, refactor, review, commit, or publish security-sensitive software:
1. Build the requested functionality.
2. Identify language, framework, runtime, database, auth model, deployment model, and trust boundaries.
3. Apply secure-by-default patterns while coding.
4. Detect and remove insecure defaults.
5. Protect secrets from Claude context, terminal output, logs, diffs, and commits.
6. Add security tests or checks.
7. Add hardened project config, `.gitignore`, README, and security documentation.
8. If this is a new project, create a private GitHub repo, commit, and push.
9. Summarize what was built, what security controls were added, what checks ran, and what assumptions remain.
Do not treat security as a TODO unless it is genuinely impossible without missing information. If information is missing, choose the safest reasonable default and state the assumption. Do not weaken existing security protections to make implementation easier.
## Always-on rules
These two rules apply on every turn — do not require opening a reference file.
**Commit & push safety.** Before any `git commit` / `git push`:
1. `git status` — verify no `.env`, `*.pem`, `secrets.*`, or surprise files.
2. `git diff --cached` — eyeball every hunk for tokens, URLs with creds, hardcoded keys, debug logs with PII or session data.
3. Run a secret scan (`gitleaks protect --staged --redact -v` if available; otherwise the grep fallback in `reference/02-secrets.md`).
4. Stage specific files (`git add path/to/file`), never `git add -A` / `git add .`.
5. Forbidden unless the user explicitly asks: skipping git hooks, skipping commit signing, force-pushing to a protected branch, history rewrites, committing files matching `*.env*`, `*.pem`, `*.p12`, `*.key`, `*credentials*`, `*service-account*`, `id_rsa*`, `*.kdbx`.
**Pause and confirm** before:
- Force-pushing, history-rewriting, deleting branches.
- Making a repo public.
- Disabling a security control that already exists (CSRF middleware, CSP, rate-limit, validation, type-narrowing).
- Opening a port to `0.0.0.0` from a service previously bound to `127.0.0.1`.
- Adding a dependency you can't verify (low downloads, no maintainer, recent name change).
- Pasting potentially sensitive content (configs, logs, traces, secrets, customer data) to a third-party tool.
- Skipping a security check the user previously enabled.
- Skipping git hooks, commit signing, allowing empty messages, or any flag that bypasses safety machinery.
If you must proceed without an answer, pick the safest reasonable default and **state the assumption in your summary**.
## Reference map
When the work touches one of these areas, **read the matching reference file before writing code**. Each file has FAIL / PASS examples, rules, and stack notes.
| When the work involves… | Read |
|---|---|
| Threat model, entry points, trust boundaries | `reference/01-planning.md` |
| `.env*`, API keys, credentials, secret rotation, leak response | `reference/02-secrets.md` |
| Password storage, login, sessions, JWT, 2FA | `reference/03-patterns/auth.md` |
| Per-resource permission, IDOR, admin routes, mass assignment | `reference/03-patterns/authorization.md` |
| Request body / query / path validation, schema enforcement | `reference/03-patterns/validation.md` |
| SQL, NoSQL, Mongo `$where`, raw queries, dynamic identifiers | `reference/03-patterns/injection.md` |
| Browser HTML rendering, `dangerouslySetInnerHTML`, CSP-related XSS, CSRF | `reference/03-patterns/xss-csrf.md` |
| Server-side `fetch` of user-supplied URLs, webhooks, image proxies | `reference/03-patterns/ssrf.md` |
| File upload, multipart, image processing, S3 puts | `reference/03-patterns/uploads.md` |
| Catch blocks, error responses, log fields | `reference/03-patterns/errors-logging.md` |
| Response headers, CSP, HSTS, COOP/CORP, helmet config | `reference/03-patterns/headers.md` |
| Rate limiting, abuse, crypto primitives, random tokens, timing safety | `reference/03-patterns/rate-limit-crypto.md` |
| `package.json` / `requirements.txt` / `Cargo.toml` changes, lockfiles, typosquatting, install scripts, SBOM | `reference/04-supply-chain.md` |
| New project scaffolding, `.editorconfig`, `SECURITY.md`, `THREAT_MODEL.md` | `reference/05-project-config.md` |
| `Dockerfile`, `docker-compose.yml`, base image pinning, BuildKit secrets | `reference/06-docker.md` |
| `.github/workflows/*`, GitHub Actions, OIDC, Rulesets | `reference/07-ci-cd.md` |
| Test cases for authz, validation, rate-limit, file-upload edge cases | `reference/08-tests.md` |
| Bootstrapping a new private GitHub repo end-to-end | `reference/09-new-project-flow.md` |
| `.github/dependabot.yml`, `CODEOWNERS`, `.pre-commit-config.yaml`, `.dockerignore` | `reference/10-recommended-files.md` |
| Detailed pre-commit / pre-push checklist | `reference/11-commit-push.md` |
| End-of-task summary template | `reference/12-summary-template.md` |
| Detailed pause-and-ask checklist | `reference/13-pause-and-ask.md` |
| Stack-specific quick wins | `reference/14-stacks/{node,nextjs,fastapi,django,go,rust,spring,dotnet,rails}.md` |
## Helper scripts
Two ready-to-run helpers live in `scripts/`:
- `scripts/install-pre-commit.sh` — installs gitleaks + detect-private-key as a pre-commit hook for the current repo. Idempotent.
- `scripts/bootstrap-private-repo.sh` — runs the full new-project flow (`reference/09-new-project-flow.md`) deterministically: `.gitignore` first, secret scan, `gh repo create --private`, branch protection via Rulesets, Secret Scanning + Push Protection + Dependabot security updates.
Both scripts pass `shellcheck` and ask before destructive actions (skip prompts with `--yes`).
## Closing
If at any point you are about to commit, push, deploy, or expose code that hasn't gone through the always-on rules above (and `reference/11-commit-push.md` for non-trivial work), stop and run them first.
If at any point you are about to weaken a control to make a build pass, stop and surface the question to the user instead.
The job is not "make it work." The job is "make it work without becoming a liability."
No comments yet. Be the first to comment!