ResQ takes the safety of its users and contributors seriously. This policy applies to every repository under resq-software.

For libraries and binaries cut via release-plz, only the latest minor release line receives patches. If you're running an older line, upgrade before reporting — the issue may already be resolved.

Do not open a public issue for a suspected vulnerability. Public disclosure before a fix is available puts users at risk.

Use one of the private channels below:

1. GitHub Security Advisories (preferred): open a draft advisory on the affected repo at https://github.com/resq-software/<repo>/security/advisories/new. If you're unsure which repo, file against resq-software/.github and we'll route internally.
2. Email: security@resq.software.

Please include:

• Affected repo + commit SHA or release tag
• A short description of the issue and its impact
• Steps to reproduce (a minimal proof-of-concept is ideal)
• Any suggested mitigation if you have one

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.

We credit reporters in advisory text unless they ask to remain anonymous.

• Code, configuration, and infrastructure manifests in any public resq-software repository.
• The resq CLI binary distributed via resq-software/crates GitHub Releases.
• The canonical git hooks shipped via resq-software/dev.

• Dependencies maintained by third parties — report upstream; we'll consume the fix when it lands. (That said, if an advisory affects us materially, we want to know.)
• Social engineering, physical access, denial-of-service via traffic volume.
• Self-XSS, missing security headers on non-sensitive marketing pages.

Every repo runs the reusable security-scan workflow on push + PR + weekly schedule. What actually runs is narrower than the job list, so it is written out rather than summarised:

Three further limits worth knowing before relying on a green tick:

• CodeQL findings cannot fail a build, but CodeQL can. Only the Analyze step carries continue-on-error, so a finding is reported and not enforced — yet Initialize CodeQL and Autobuild do not, and a failure in either fails the job and the required gate. Autobuild failure is the common case for the compiled languages the input advertises (c-cpp, csharp, go, java-kotlin, swift).
• zizmor findings cannot fail a build either. Both its scan step and its SARIF upload are continue-on-error, so the row above marking it "on, every repo" means it always runs, not that it can ever block a merge.
• Dependency Review fails rather than skips. On a private repo without GitHub Code Security the job runs and fails on every pull request, until the caller passes enable-dependency-review: false.

Findings are triaged by the maintainers listed in each repo's CODEOWNERS.