The org-wide policy in resq-software/.github governs this repository. It covers supported versions, what to include in a report, and the disclosure timeline. Read that first.

Do not open a public issue for a suspected vulnerability.

1. GitHub Security Advisories (preferred) — open a draft advisory.
2. Email — security@resq.software.

Where the EU Cyber Resilience Act (Regulation (EU) 2024/2847) applies to a product in this repository, ResQ reports through ENISA's Single Reporting Platform, to the CSIRT designated as coordinator and to ENISA:

• Actively exploited vulnerabilities: an early warning within 24 hours of becoming aware of one, a notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available.
• Severe incidents affecting the security of the product: an early warning within 24 hours, a notification within 72 hours, and a final report within one month of the notification.

We inform affected users as the Act requires. Reporting to us through the private channels above never requires you to contact ENISA yourself. You may also report to a national CSIRT under its coordinated vulnerability disclosure policy.

If you make a good-faith effort to follow this policy while researching a vulnerability, we will:

• treat your research as authorised, and not pursue or support legal action against you for it;
• work with you to understand and fix the issue quickly; and
• credit you, unless you ask us not to.

Good faith means that you:

• test only against your own accounts, data and installations;
• stop and report as soon as you find a vulnerability;
• access, change or keep no one else's data beyond what's needed to show the issue;
• don't degrade our services or anyone else's; and
• give us reasonable time to fix the issue before you disclose it.

This safe harbour covers ResQ's own claims only; it cannot bind third parties.

Two layers, deliberately split, because each catches what the other cannot.

In CI. GitHub secret scanning and push protection are enabled repo-wide; push protection blocks a known provider credential before it ever lands. On top of that, .github/workflows/security.yml calls the org's reusable scan — CodeQL for javascript-typescript and actions, plus Semgrep — and .github/workflows/ci.yml gates merges on its result through the Security scan gate job.

Gitleaks is deliberately off. It needs a GITLEAKS_LICENSE even for public org repos, and it would duplicate the native scanning already running here. The switch lives in the reusable workflow if that trade-off ever changes.

Before CI. When the resq CLI is installed, the pre-commit hook delegates staged-change checks to resq. If the CLI is unavailable, the hook warns and skips these local checks. That scanner is local-only and reads .secretsignore, which is its allowlist — not CI's, and not GitHub's. The two exclusion mechanisms are separate by design: GitHub's live in .github/secret_scanning.yml, which this repo does not define, so nothing is excluded from GitHub's scanning or push protection.

Note what .secretsignore does and does not buy. It excludes packages/security/tests/fixtures/corpora.ts by path, so the local scanner does not read that file at all. The credential-shaped strings in it are the vendors' published placeholders, which is what makes the exclusion safe to grant — but nothing inspects them, and a real credential committed to that path would pass the local scan unnoticed. GitHub's secret scanning and push protection still cover it, and they are what to rely on there.

.secretsignore therefore holds paths, not fingerprints, and is not interchangeable with a .gitleaksignore.