Skip to content

Security: pb3ck/quarry

SECURITY.md

Security Policy

Quarry is a security tool used by people who handle sensitive evidence. We take vulnerabilities in Quarry itself seriously.

Reporting a vulnerability

Do not file a public GitHub issue for security matters.

Report vulnerabilities via one of:

  1. GitHub Security Advisories — preferred. Open a private advisory at https://github.com/pb3ck/quarry/security/advisories/new. This keeps the disclosure private until coordinated release.
  2. Email — TODO: maintainer security email. PGP key fingerprint: TODO. Encrypt sensitive details if possible.

Please include:

  • A description of the vulnerability and its impact.
  • Steps to reproduce, including version / commit SHA.
  • Your assessment of severity (CVSS v3.1 vector welcomed but not required).
  • Whether you intend to publish a write-up, and any timeline you have in mind.

What to expect

Step Target time
Acknowledgment of report 72 hours
Initial triage and severity assessment 7 days
Fix or mitigation timeline communicated 14 days
Coordinated disclosure window 90 days from acknowledgment, negotiable

These targets are commitments for a project at Quarry's current scale. They may tighten as the project matures.

Scope

In scope for this policy:

  • The Quarry CLI and any official binaries published from this repository.
  • Code in this repository, including ingestion adapters, the storage layer, the retrieval layer, and the LLM provider abstraction.
  • Documentation that, if followed, would lead to a security compromise.

Out of scope:

  • Vulnerabilities in third-party services Quarry calls (Anthropic, OpenAI, Ollama, NVD, OSV, etc.). Report those upstream.
  • Vulnerabilities in dependencies, unless Quarry's use of the dependency creates a vulnerability that wouldn't otherwise exist. (Report dependency vulnerabilities upstream first; we'll bump.)
  • Theoretical risks without a working proof of concept.
  • Issues that require a compromised local machine to exploit. Quarry trusts the machine it runs on.

Threat model

Quarry's threat model assumes:

  • The user controls the machine Quarry runs on. A compromised host is out of scope.
  • LLM API keys are sensitive. They live in OS-level secret storage where available, falling back to a config file with restricted permissions. Mishandling of keys is in scope.
  • Ingested artifacts are untrusted. Burp project files, JS bundles, scan output, and HTML responses can be hostile. Parsers must not be exploitable by malicious input. This is the largest attack surface and the most important class of bugs to find.
  • Network endpoints Quarry talks to are semi-trusted. We validate TLS, we don't pin certificates by default (CA-rotation is real), and we don't trust response bodies to be well-formed.
  • Quarry does not protect against an attacker with read access to the user's home directory. Encrypting the corpus at rest is on the roadmap but is not the threat model today.

Safe harbor

Good-faith security research on Quarry is welcome. We will not pursue legal action against researchers who:

  • Make a good-faith effort to avoid privacy violations, data destruction, and service disruption.
  • Report vulnerabilities through the channels above.
  • Give us reasonable time to fix issues before public disclosure.
  • Do not exploit vulnerabilities beyond what's necessary to confirm them.

This safe harbor applies to research on Quarry itself, not to Quarry's use against any third-party target. You are responsible for the legality of how you use the tool.

There aren't any published security advisories