What it isAlways-on coding rules. GitHub Copilot applies them to files matching **; the Claude Code version is a path-scoped rule generated from the same file. Why use instructions →
Install
This repository (recommended)
Adds .github/instructions/secure-coding.instructions.md — commit it so everyone's Copilot follows the same rules.
Nothing to invoke — edit a matching file and Copilot picks the rules up. Adjust applyTo if your repository layout differs.
This repository (recommended)
Adds .claude/rules/secure-coding.md — commit it. Claude loads it when it reads a matching file.
npx -y github:AGCO-Global/org-skills add instructions secure-coding --tool claude
Just for me, every repository
Save it in your user profile instead.
npx -y github:AGCO-Global/org-skills add instructions secure-coding --tool claude --user
Use it
Nothing to invoke. Adjust the paths globs if your repository layout differs.
Commands run in your repository folder and need Node.js 20+. They use your normal git sign-in to GitHub, so they work while the repository is private. Run npx -y github:AGCO-Global/org-skills list to see everything available.
Settings
name: "Secure coding"
description: "Always-on, stack-agnostic security rules for every file in the repository."
applyTo: "**"
Instructions Copilot follows
Secure coding rules
These rules apply to every language and file type. When a rule conflicts with a quick fix, keep the rule.
Secrets
Never write secrets, passwords, API keys, tokens, connection strings or private keys into code, config files, tests, samples or comments. Anything committed is permanently exposed.
Read secrets at runtime from Azure Key Vault or Azure DevOps pipeline secret variables (or variable groups linked to Key Vault).
Prefer managed identities or workload identity over stored credentials.
Use obvious placeholders in examples (<your-api-key>), and keep .env and local secret files in .gitignore.
If a secret was ever committed, treat it as leaked: rotate it first, then remove it from history.
Input and output
Treat all input as untrusted: request data, headers, files, queue messages, environment and third-party responses.
Validate at the boundary with allow-lists for type, length, range and format; reject unknown fields on sensitive objects.
Use parameterized queries or the ORM; never concatenate input into SQL, shell commands, LDAP, file paths or template expressions.
Encode output for its context (HTML, attribute, URL, JavaScript) and never render untrusted HTML without a sanitizer.
Fetch user-supplied URLs only against a host allow-list, blocking private and metadata IP ranges. Prevents SSRF.
Never deserialize untrusted data into arbitrary types.
Access control
Authenticate and authorize every endpoint, handler, job and admin path; deny by default.
Check object-level ownership (id plus user or tenant), not just the role. Prevents IDOR.
Enforce authorization on the server; client-side checks are for UX only.
Grant least privilege to service accounts, pipeline service connections, database users and cloud roles; no shared admin accounts.
Data and logging
Never log passwords, tokens, secrets, full card numbers or personal data (names, emails, addresses, IDs). Log opaque ids instead.
Return generic error messages to users with a correlation id; keep stack traces, SQL and internal paths in server logs only.
Encrypt data in transit (TLS) and use vetted crypto libraries; hash passwords with Argon2, bcrypt or scrypt. Never roll your own crypto.
Collect and keep only the personal data the feature needs.
Dependencies and builds
Add dependencies only when needed, from official registries, and pin versions with a committed lockfile.
Check new packages for maintenance, license and known vulnerabilities; fix high and critical findings before merging.
Do not disable security checks, TLS validation, linters or scanners to make a build pass.
Do not copy code from unknown sources without understanding what it does.
When to ask a human
Stop and ask a reviewer before changing authentication, authorization, cryptography, secret handling, payment flows, or personal data processing.
Ask before adding a new external service, widening network or firewall access, or granting new permissions.
Flag it clearly when you are unsure whether code is safe, or when a request would weaken an existing control.
Go deeper: for larger tasks use the backend-code-review, frontend-code-review and api-design skills, plus the stack-specific development skill for the code you are changing.
---
name: "Secure coding"
description: "Always-on, stack-agnostic security rules for every file in the repository."
applyTo: "**"
---
# Secure coding rules
These rules apply to every language and file type. When a rule conflicts with a quick fix, keep the rule.
## Secrets
- Never write secrets, passwords, API keys, tokens, connection strings or private keys into code, config files, tests, samples or comments. Anything committed is permanently exposed.
- Read secrets at runtime from Azure Key Vault or Azure DevOps pipeline secret variables (or variable groups linked to Key Vault).
- Prefer managed identities or workload identity over stored credentials.
- Use obvious placeholders in examples (`<your-api-key>`), and keep `.env` and local secret files in `.gitignore`.
- If a secret was ever committed, treat it as leaked: rotate it first, then remove it from history.
## Input and output
- Treat all input as untrusted: request data, headers, files, queue messages, environment and third-party responses.
- Validate at the boundary with allow-lists for type, length, range and format; reject unknown fields on sensitive objects.
- Use parameterized queries or the ORM; never concatenate input into SQL, shell commands, LDAP, file paths or template expressions.
- Encode output for its context (HTML, attribute, URL, JavaScript) and never render untrusted HTML without a sanitizer.
- Fetch user-supplied URLs only against a host allow-list, blocking private and metadata IP ranges. Prevents SSRF.
- Never deserialize untrusted data into arbitrary types.
## Access control
- Authenticate and authorize every endpoint, handler, job and admin path; deny by default.
- Check object-level ownership (`id` plus user or tenant), not just the role. Prevents IDOR.
- Enforce authorization on the server; client-side checks are for UX only.
- Grant least privilege to service accounts, pipeline service connections, database users and cloud roles; no shared admin accounts.
## Data and logging
- Never log passwords, tokens, secrets, full card numbers or personal data (names, emails, addresses, IDs). Log opaque ids instead.
- Return generic error messages to users with a correlation id; keep stack traces, SQL and internal paths in server logs only.
- Encrypt data in transit (TLS) and use vetted crypto libraries; hash passwords with Argon2, bcrypt or scrypt. Never roll your own crypto.
- Collect and keep only the personal data the feature needs.
## Dependencies and builds
- Add dependencies only when needed, from official registries, and pin versions with a committed lockfile.
- Check new packages for maintenance, license and known vulnerabilities; fix high and critical findings before merging.
- Do not disable security checks, TLS validation, linters or scanners to make a build pass.
- Do not copy code from unknown sources without understanding what it does.
## When to ask a human
- Stop and ask a reviewer before changing authentication, authorization, cryptography, secret handling, payment flows, or personal data processing.
- Ask before adding a new external service, widening network or firewall access, or granting new permissions.
- Flag it clearly when you are unsure whether code is safe, or when a request would weaken an existing control.
Go deeper: for larger tasks use the backend-code-review, frontend-code-review and api-design skills, plus the stack-specific development skill for the code you are changing.
<!-- Secure coding — generated from instructions/general/secure-coding.instructions.md for Claude Code. Edit that file, not this one. -->
# Secure coding rules
These rules apply to every language and file type. When a rule conflicts with a quick fix, keep the rule.
## Secrets
- Never write secrets, passwords, API keys, tokens, connection strings or private keys into code, config files, tests, samples or comments. Anything committed is permanently exposed.
- Read secrets at runtime from Azure Key Vault or Azure DevOps pipeline secret variables (or variable groups linked to Key Vault).
- Prefer managed identities or workload identity over stored credentials.
- Use obvious placeholders in examples (`<your-api-key>`), and keep `.env` and local secret files in `.gitignore`.
- If a secret was ever committed, treat it as leaked: rotate it first, then remove it from history.
## Input and output
- Treat all input as untrusted: request data, headers, files, queue messages, environment and third-party responses.
- Validate at the boundary with allow-lists for type, length, range and format; reject unknown fields on sensitive objects.
- Use parameterized queries or the ORM; never concatenate input into SQL, shell commands, LDAP, file paths or template expressions.
- Encode output for its context (HTML, attribute, URL, JavaScript) and never render untrusted HTML without a sanitizer.
- Fetch user-supplied URLs only against a host allow-list, blocking private and metadata IP ranges. Prevents SSRF.
- Never deserialize untrusted data into arbitrary types.
## Access control
- Authenticate and authorize every endpoint, handler, job and admin path; deny by default.
- Check object-level ownership (`id` plus user or tenant), not just the role. Prevents IDOR.
- Enforce authorization on the server; client-side checks are for UX only.
- Grant least privilege to service accounts, pipeline service connections, database users and cloud roles; no shared admin accounts.
## Data and logging
- Never log passwords, tokens, secrets, full card numbers or personal data (names, emails, addresses, IDs). Log opaque ids instead.
- Return generic error messages to users with a correlation id; keep stack traces, SQL and internal paths in server logs only.
- Encrypt data in transit (TLS) and use vetted crypto libraries; hash passwords with Argon2, bcrypt or scrypt. Never roll your own crypto.
- Collect and keep only the personal data the feature needs.
## Dependencies and builds
- Add dependencies only when needed, from official registries, and pin versions with a committed lockfile.
- Check new packages for maintenance, license and known vulnerabilities; fix high and critical findings before merging.
- Do not disable security checks, TLS validation, linters or scanners to make a build pass.
- Do not copy code from unknown sources without understanding what it does.
## When to ask a human
- Stop and ask a reviewer before changing authentication, authorization, cryptography, secret handling, payment flows, or personal data processing.
- Ask before adding a new external service, widening network or firewall access, or granting new permissions.
- Flag it clearly when you are unsure whether code is safe, or when a request would weaken an existing control.
Go deeper: for larger tasks use the backend-code-review, frontend-code-review and api-design skills, plus the stack-specific development skill for the code you are changing.