Security fixes are shipped on the latest release line only. Support follows a rolling two-minor-version window (current + one prior minor).

If you discover a security vulnerability in sockguard, please report it responsibly.

Do not open a public GitHub issue for security vulnerabilities.

Instead, use GitHub's private vulnerability reporting or email security@getsockguard.com. GitHub private reports are preferred because they keep report details private and tie disclosure to the advisory and fix workflow.

For non-security contact, email hello@getsockguard.com.

You can expect:

• Acknowledgement within 48 hours
• Status update within 7 days
• Fix or mitigation as soon as feasible, depending on severity

We appreciate responsible disclosure and will credit reporters in the release notes unless you prefer to stay anonymous.

In scope

• The Go proxy at app/ — filter engine, ownership middleware, client ACLs, hijack/upgrade handling, access log, /health endpoint, config parsing, CLI flags.
• The published container image at ghcr.io/codeswhat/sockguard:<tag>, including its SBOM, build provenance, and cosign signatures.
• Any compiled binary distributed via a GitHub release tagged v0.x.x or v1.x.x or later.

Out of scope

• The marketing website under website/ and anything served from getsockguard.com. Report bugs here via a regular GitHub issue.
• The docs site under docs/ and served at getsockguard.com/docs. Same — regular issues.
• Third-party deployments of sockguard. If you find a misconfigured compose file in the wild, contact that operator directly. We can help triage but we can't ship a fix for it.
• Denial-of-service via CPU/memory exhaustion from an allowlisted client that already has full Docker-socket access. Sockguard's trust boundary is the client CIDR; a client inside the trust boundary is assumed to be cooperating in good faith.

Sockguard runs as UID 65532 (Chainguard nonroot) inside the published container image. On typical Linux hosts /var/run/docker.sock is 0660 root:docker, so deployments may need group_add with the socket's numeric group ID, or an explicit user: / supplemental group override, before the proxy can open the upstream socket.

That non-root default is useful hardening, but it is not the primary security boundary. In the threat model that matters for a Docker socket proxy, an attacker who can coerce sockguard into sending arbitrary Docker API requests can ask the daemon to create a privileged container, mount /, or otherwise pivot onto the host regardless of whether the proxy process reports UID 0 or UID 65532.

The controls that materially harden this class of tool are:

• Policy correctness — deny dangerous Docker API methods, paths, and request bodies unless they are explicitly required.
• Read-only root filesystem — set read_only: true so a compromised process cannot persist inside the container filesystem.
• Dropped Linux capabilities — set cap_drop: [ALL]; sockguard does not need ambient capabilities.
• No new privileges + seccomp — set security_opt: ["no-new-privileges:true"] and keep Docker's default seccomp profile or replace it with a stricter custom one.
• AppArmor/SELinux confinement — keep your runtime's default profile or apply a stricter host policy.
• Rootless Docker on the host — reduce the daemon's authority at the actual trust boundary.

See the Compose examples in README.md and the docs site's getting started guide for concrete read_only, cap_drop, and security_opt examples.

If you're unsure whether something is in scope, err on the side of reporting — we'd rather deduplicate than miss a real bug.

A good report makes triage fast and reduces the risk we misread the severity. Please include as much of the following as you can:

• Sockguard version and image digest — sockguard version and the digest of the image you tested (docker image inspect).
• Reproducer — the minimal config, rules, and request(s) that demonstrate the issue. If the repro needs a specific Docker daemon version, mention which one.
• Observed behavior — what sockguard did, including any relevant access-log lines and exit codes. Redact hostnames, IPs, or container names if you prefer — we don't need them to understand the bug.
• Expected behavior — what you believe sockguard should have done instead, and why (policy intent, Docker API semantics, etc.).
• Impact assessment — your read on severity, who it affects, and whether it requires authentication, a compromised client, or physical access.
• Disclosure timeline — when you found it, whether you've told anyone else, and whether a specific embargo date suits you.

If the bug involves a supply-chain concern (a tampered image, a cosign verification failure, a compromised dependency), also include the exact cosign verify command you ran and its full output. See the image verification guide for the canonical invocation.