This document describes how security is handled in this project, how to report vulnerabilities, and what conventions contributors must follow.
Template note: Replace all
<ORG>,<PROJECT_NAME>, and<security@stoopid.email>placeholders before publishing. Remove this note once instantiated.
Do not open a public issue for security vulnerabilities.
Report vulnerabilities by emailing security@stoopid.email.
Include the following when possible:
- A description of the issue and its potential impact
- Steps to reproduce, or proof-of-concept code
- The affected version, commit SHA, or deployment environment
- Your suggested remediation, if any
| Stage | Target |
|---|---|
| Initial acknowledgment | Within 2 business days |
| Triage and severity | Within 5 business days |
| Status updates | At least every 7 days until resolution |
| Fix or mitigation | Severity-dependent (see below) |
| Severity | Examples | Target fix |
|---|---|---|
| Critical | RCE, auth bypass, data exfiltration | 7 days |
| High | Privilege escalation, sensitive data exposure | 30 days |
| Medium | DoS, info disclosure with limited impact | 90 days |
| Low | Hardening issues, defense-in-depth gaps | Best effort |
We do not run a formal bug bounty program. We will work with external researchers in good faith on a case-by-case basis. Coordinated disclosure is expected; please give us reasonable time to remediate before publishing.
This project follows semantic versioning. Security fixes are applied to:
- The current major version (latest)
- The previous major version, for 6 months after a new major release
Older versions are not supported. Operators are expected to upgrade.
In-scope concerns for this repository:
- Application-layer vulnerabilities in the code maintained here
- Secret handling in code, CI, and deployment artifacts
- Dependency vulnerabilities introduced by this project
- Misuse or misconfiguration of public APIs and interfaces this project exposes
Out of scope (handled elsewhere):
- Infrastructure hardening (host OS, container runtime, cluster control plane)
- Identity provider configuration
- Physical and corporate security
- Vulnerabilities in unmodified upstream dependencies (report those upstream; we will track and update)
No secrets are ever stored in this repository. This includes but is not limited to: API keys, tokens, passwords, private keys, certificates, database credentials, and signing keys.
| Type | Location |
|---|---|
| Production / staging secrets | External secret store (Vault, AWS Secrets Manager, 1Password, etc.) |
| Local development defaults | .env.example (committed, non-sensitive placeholders only) |
| Developer-specific overrides | .env (gitignored, never committed) |
| CI / CD secrets | GitHub Actions secrets, scoped to the minimum required workflows |
| Runtime secrets | Mounted from external secret stores at runtime; never baked into build artifacts |
.env.exampleMUST contain only placeholder values (e.g.DATABASE_URL=postgres://localhost/dev). It MUST NOT contain real credentials, even for shared dev environments.- Real secrets MUST be retrieved from the external secret store at runtime — never read from committed files.
- Secret values MUST NOT appear in logs, traces, error messages, or telemetry. Sensitive fields should be redacted at the logging layer.
- CI workflows MUST use scoped GitHub Actions secrets and MUST NOT echo secret values to logs.
- Any commit containing a real secret requires immediate rotation of the secret and a follow-up to purge it from history.
- Rotate the secret immediately. Do not wait for cleanup. Treat any committed secret as compromised.
- Notify security@stoopid.email.
- Open an incident (see Incident Response below).
- Coordinate with security to scrub history if required. Note that scrubbing alone is insufficient — rotation is the primary control.
Code in this project is expected to follow the principle of least privilege:
- Services and processes run with the minimum permissions required
- Service accounts, IAM roles, and database users are scoped per-component, not shared
- Tokens, credentials, and session data are short-lived where possible
- Authentication of incoming and outgoing calls is the responsibility of the project; specific mechanisms (mTLS, JWT, OAuth, API keys, etc.) are documented in the project's own design documentation
This repository enforces the following via CI:
- Dependabot — automated dependency update PRs for all supported ecosystems (npm, pip, cargo, terraform, github-actions, docker)
- Secret scanning — GitHub native secret scanning with push protection enabled
- CodeQL — static analysis for supported languages, run on every PR and on a weekly schedule
- Do not disable, bypass, or weaken any of the above checks without security review
- Address Dependabot PRs promptly. Critical and high-severity advisories should be merged or have a documented mitigation within the timelines above
- Do not introduce dependencies from untrusted sources. Prefer well-maintained, audited packages with active security postures
- Pin dependencies to specific versions; lockfiles MUST be committed
- New container base images MUST be from approved sources and SHOULD be digest-pinned where practical
Contributors are expected to:
- Follow the conventions in
CONTRIBUTING.mdfor code review, branching, and CI checks - Treat all input as untrusted and validate at trust boundaries
- Use parameterized queries; never construct SQL by string concatenation
- Avoid logging raw request bodies, headers, tokens, or user-supplied data without sanitization
- Avoid introducing new cryptographic primitives. Use vetted libraries from language standard libraries or well-known, maintained packages
- Run pre-commit hooks locally; do not push code that fails them
This section provides the high-level flow. Detailed procedures, when they exist, are documented separately per project.
Escalate immediately if any of the following are observed or suspected:
- Confirmed or suspected unauthorized access to production systems or data
- Exposure of secrets, credentials, or PII
- Active exploitation of a vulnerability
- Ransomware, data destruction, or cryptojacking activity
- Compromise of CI/CD pipelines or signing infrastructure
- Notify security@stoopid.email with subject prefix
[INCIDENT]. Page on-call if the issue is active or affects production. - Preserve evidence. Do not delete logs, terminate suspicious workloads, or rotate credentials before security has captured forensic data — unless continued operation poses ongoing risk.
- Contain. Isolate affected components (revoke tokens, scale to zero, network-isolate, etc.) per project conventions.
- Communicate. Use the designated incident channel. Avoid speculation in public or shared channels.
- Document. Maintain a timeline of actions taken, decisions made, and their rationale. This becomes the basis for the post-incident review.
Every incident requires a blameless post-mortem documenting: timeline, root cause, contributing factors, remediation, and follow-up action items with owners.
Logs, audit trails, and evidence relevant to compliance obligations are
retained per <ORG> policy. Contributors should not alter or delete audit
data without explicit security approval.
Security questions that are not vulnerabilities can be directed to security@stoopid.email.