Skip to content

English · 한국어

Security Policy

pqcota is a tool that observes and normalizes an enterprise intranet's crypto assets and generates migration artifacts. Because of the data it handles (endpoint and crypto-asset inventory) and the privileges it requires (packet observation by the collector, etc.), we take security reports seriously.

Supported versions

Security fixes land on main and the latest release. They are not backported to earlier tags — a solo project cannot maintain several branches, and pretending to would leave users believing they have a fix that never reached them.

Version Security fixes
main ✅
the latest release ✅ — it goes out in the next release; a defect that cannot sit there gets its own patch release
earlier tags ❌ — upgrade to the latest

Reporting a vulnerability

Do not open a public issue, PR, or discussion. Use one of these private channels:

  1. GitHub private report (preferred) — the repo's Security tab → "Report a vulnerability". This follows a coordinated-disclosure process.
  2. If that isn't possible, contact the maintainer directly — randyinthedev@gmail.com. Prefixing the subject with [security] helps it surface faster.

Including the following speeds up triage: affected component (collector/CLI/library), reproduction steps, impact (privilege escalation·information disclosure·integrity compromise, etc.), and a PoC if possible.

Anything that isn't a vulnerability belongs in a public issue. Bugs, questions, and proposals go to this repo's issues — there's nothing to hide, and an open discussion stays for the next person. Private reporting is only for things that could expose users to attack if known before a fix.

Response

As a solo project, response is best-effort — acknowledge receipt, reproduce and assess, then coordinate a fix plan with the reporter. There is no SLA, but a valid report goes ahead of other work.

Security scope (specific to this project)

The following in particular are treated as security issues:

  • Access-secret leakage — connection keys/accounts live only in a runtime-only file, and only endpoints are ingested into the inventory (Postgres); secrets are not persisted. If a secret leaks into a persistent store, logs, or artifacts, that is a vulnerability.
  • Signing·integrity — bypassing the ed25519 signature on a collection result (the collector signs it, and pqcota-ingest checks it when a verification key is configured) or on a plan approval (pqcota-approve signs it, and pqcota-provision checks it), or accepting forgery/tampering.
  • Collector privilege misuse — actions beyond the packet-observation (CAP_NET_RAW) and process-scan privileges, or collecting the observed target's plaintext payloads (the capture receives frames into memory and extracts only handshake fields; it does not decrypt or write packets).
  • Artifact injection — paths where observed or contract inputs flow malicious content into the generated Ansible playbooks/config.

What is out of scope is discussed together at report time (e.g., operational problems in the environment where the user runs the playbook themselves are the execution side's responsibility, not this tool's).

한국어