Charon/SECURITY.md

Security Policy

Supported Versions

We release security updates for the following versions:

Version	Supported
1.0.x	✅
< 1.0	❌

Reporting a Vulnerability

To report a security issue, use GitHub Private Security Advisories or open a GitHub Issue for non-sensitive disclosures.

Please include a description, reproduction steps, impact assessment, and a non-destructive proof of concept where possible.

We will acknowledge your report within 48 hours and provide a remediation timeline within 7 days. Reporters are credited in release notes with their consent. We do not pursue legal action against good-faith security researchers. Please allow 90 days from initial report before public disclosure.

---

Known Vulnerabilities

[HIGH] CHARON-2026-001 · Debian Base Image CVE Cluster

Field	Value
ID	CHARON-2026-001 (aliases: CVE-2026-0861, CVE-2025-15281, CVE-2026-0915, CVE-2025-13151, and 2 libtiff HIGH CVEs)
Severity	High · 8.4 (highest per CVSS v3.1, preliminary)
Status	Fix In Progress

What Seven HIGH-severity CVEs in Debian Trixie base image system libraries (glibc, libtasn1-6, libtiff). These vulnerabilities reside in the container's OS-level packages. No fixes are available from the Debian Security Team. The project migrated from Alpine to Debian to avoid CVE-2025-60876 (busybox heap overflow); now that Alpine has patched that CVE, migration back to Alpine is underway to eliminate this cluster entirely.

Who

• Discovered by: Automated scan (Trivy)
• Reported: 2026-02-04
• Affects: Container runtime environment; no known direct exploitation path through Charon's application interface

Where

• Component: Debian Trixie base image (libc6, libc-bin, libtasn1-6, libtiff)
• Versions affected: All Charon container images built on Debian Trixie base

When

• Discovered: 2026-02-04
• Disclosed (if public): 2026-02-04 (internal advisory)
• Target fix: 2026-03-05 (Alpine base image migration)

How The affected packages are OS-level shared libraries bundled in the container base image. Exploitation would require local access to the container or a prior application-level compromise to reach the vulnerable library code. Caddy reverse proxy ingress filtering and container isolation significantly reduce the effective attack surface.

Planned Remediation Revert to Alpine Linux base image (CVE-2025-60876 is now patched upstream). Expected outcome is 100% CVE reduction (7 HIGH → 0).

• Spec: docs/plans/alpine_migration_spec.md
• Advisory: docs/security/advisory_2026-02-04_debian_cves_temporary.md
• Risk Assessment: docs/security/VULNERABILITY_ACCEPTANCE.md

---

[HIGH] CHARON-2025-001 · CrowdSec Bundled Binaries — Go Stdlib CVEs

Field	Value
ID	CHARON-2025-001 (aliases: CVE-2025-58183, CVE-2025-58186, CVE-2025-58187, CVE-2025-61729)
Severity	High · (preliminary, CVSS scores pending upstream confirmation)
Status	Awaiting Upstream

What Four HIGH-severity CVEs in Go standard library packages (HTTP/2 handling, TLS certificate validation, archive parsing) present in CrowdSec binaries bundled with Charon. These vulnerabilities exist because CrowdSec's distributed binaries were compiled against Go 1.25.1. Charon's own application code is unaffected.

Who

• Discovered by: Automated scan (Trivy)
• Reported: 2025-12-01
• Affects: CrowdSec Agent component within the container; not directly exposed through Charon's primary application interface

Where

• Component: CrowdSec Agent (bundled cscli and crowdsec binaries)
• Versions affected: All Charon versions shipping CrowdSec binaries compiled against Go < 1.26.0

When

• Discovered: 2025-12-01
• Disclosed (if public): Not yet publicly disclosed
• Target fix: Dependent on CrowdSec upstream release timeline

How The CVEs reside entirely within CrowdSec's compiled binaries and cover HTTP/2, TLS, and archive processing paths that are not invoked by Charon's core application logic. The relevant network interfaces are not externally exposed via Charon's API surface.

Planned Remediation Monitor CrowdSec releases for binaries built with Go 1.26.0+. Upgrade CrowdSec in Charon's build pipeline as soon as a patched release is available.

---

Patched Vulnerabilities

✅ [HIGH] CVE-2025-68156 · expr-lang/expr ReDoS

Field	Value
ID	CVE-2025-68156
Severity	High · 7.5
Patched	2026-01-11

What Regular Expression Denial of Service (ReDoS) vulnerability in the expr-lang/expr library used by CrowdSec for expression evaluation. Malicious regular expressions in CrowdSec scenarios or parsers could cause CPU exhaustion and service degradation through exponential backtracking.

Who

• Discovered by: Automated scan (Trivy)
• Reported: 2026-01-11

Where

• Component: CrowdSec (via expr-lang/expr dependency)
• Versions affected: CrowdSec versions using expr-lang/expr < v1.17.7

When

• Discovered: 2026-01-11
• Patched: 2026-01-11
• Time to patch: 0 days

How Maliciously crafted regular expressions in CrowdSec scenario or parser rules could trigger exponential backtracking in expr-lang/expr's evaluation engine, causing CPU exhaustion and denial of service. The vulnerability is in the upstream expression evaluation library, not in Charon's own code.

Resolution Upgraded CrowdSec to build from source with the patched expr-lang/expr v1.17.7. Verification confirmed via go version -m ./cscli showing the patched library version in compiled artifacts. Post-patch Trivy scan reports 0 HIGH/CRITICAL vulnerabilities in application code.

• Technical details: docs/plans/crowdsec_source_build.md

Credit Internal remediation; no external reporter.

---

Security Features

Server-Side Request Forgery (SSRF) Protection

Charon implements industry-leading 5-layer defense-in-depth SSRF protection to prevent attackers from using the application to access internal resources or cloud metadata.

Protected Against

• Private network access (RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
• Cloud provider metadata endpoints (AWS, Azure, GCP: 169.254.169.254)
• Localhost and loopback addresses (127.0.0.0/8, ::1/128)
• Link-local addresses (169.254.0.0/16, fe80::/10)
• IPv6-mapped IPv4 bypass attempts (::ffff:127.0.0.1)
• Protocol bypass attacks (file://, ftp://, gopher://, data:)

Defense Layers

1. URL Format Validation: Scheme, syntax, and structure checks
2. DNS Resolution: Hostname resolution with timeout protection
3. IP Range Validation: ALL resolved IPs checked against 13+ CIDR blocks
4. Connection-Time Validation: Re-validation at TCP dial (prevents DNS rebinding)
5. Redirect Validation: Each redirect target validated before following

Protected Features

• Security notification webhooks
• Custom webhook notifications
• CrowdSec hub synchronization
• External URL connectivity testing (admin-only)

Learn More

• SSRF Protection Guide
• Manual Test Plan
• QA Audit Report

---

Authentication & Authorization

• JWT-based authentication: Secure token-based sessions
• Role-based access control: Admin vs. user permissions
• Session management: Automatic expiration and renewal
• Secure cookie attributes: HttpOnly, Secure (HTTPS), SameSite

Data Protection

• Database encryption: Sensitive data encrypted at rest
• Secure credential storage: Hashed passwords, encrypted API keys
• Input validation: All user inputs sanitized and validated
• Output encoding: XSS protection via proper encoding

Infrastructure Security

• Non-root by default: Charon runs as an unprivileged user (charon, uid 1000) inside the container. Docker socket access is granted via a minimal supplemental group matching the host socket's GID — never by running as root. If the socket GID is 0 (root group), Charon requires explicit opt-in before granting access.
• Container isolation: Docker-based deployment
• Minimal attack surface: Alpine Linux base image
• Dependency scanning: Regular Trivy and govulncheck scans
• No unnecessary services: Single-purpose container design

Web Application Firewall (WAF)

• Coraza WAF integration: OWASP Core Rule Set support
• Rate limiting: Protection against brute-force and DoS
• IP allowlisting/blocklisting: Network access control
• CrowdSec integration: Collaborative threat intelligence

---

Supply Chain Security

Charon implements comprehensive supply chain security measures to ensure the integrity and authenticity of releases. Every release includes cryptographic signatures, SLSA provenance attestation, and a Software Bill of Materials (SBOM).

Verification Commands

Verify Container Image Signature

All official Charon images are signed with Sigstore Cosign:

cosign verify \
  --certificate-identity-regexp='https://github.com/Wikid82/charon' \
  --certificate-oidc-issuer='https://token.actions.githubusercontent.com' \
  ghcr.io/wikid82/charon:latest

Successful verification confirms the image was built by GitHub Actions from the official repository and has not been tampered with since signing.

Verify SLSA Provenance

# Download provenance from release assets
curl -LO https://github.com/Wikid82/charon/releases/latest/download/provenance.json

slsa-verifier verify-artifact \
  --provenance-path provenance.json \
  --source-uri github.com/Wikid82/charon \
  ./backend/charon-binary

Inspect the SBOM

# Download SBOM from release assets
curl -LO https://github.com/Wikid82/charon/releases/latest/download/sbom.spdx.json

# Scan for known vulnerabilities
grype sbom:sbom.spdx.json

Transparency Log (Rekor)

All signatures are recorded in the public Sigstore Rekor transparency log: https://search.sigstore.dev/

Digest Pinning Policy

Scope (Required):

• CI workflows: .github/workflows/*.yml
• CI compose files: .docker/compose/*.yml
• CI helper actions with container refs: .github/actions/**/*.yml

CI workflows and CI compose files MUST use digest-pinned images for third-party services. Tag+digest pairs are preferred for human-readable references with immutable resolution. Self-built images MUST propagate digests to downstream jobs and tests.

Local Development Exceptions:

Local-only overrides (e.g., CHARON_E2E_IMAGE, CHARON_IMAGE, CHARON_DEV_IMAGE) MAY use tags for developer iteration. Tag-only overrides MUST NOT be used in CI contexts.

Documented Exceptions & Compensating Controls:

1. Go toolchain shim (golang.org/dl/goX.Y.Z@latest) — Uses @latest to install the shim; compensated by the target toolchain version being pinned in go.work with Renovate tracking.
2. Unpinnable dependencies — Require documented justification; prefer vendor checksums or signed releases; keep SBOM/vulnerability scans in CI.

Learn More

• User Guide
• Developer Guide
• Sigstore Documentation
• SLSA Framework

---

Security Audits & Scanning

Automated Scanning

Tool	Purpose
Trivy	Container image vulnerability scanning
CodeQL	Static analysis for Go and JavaScript
govulncheck	Go module vulnerability scanning
golangci-lint (gosec)	Go code linting
npm audit	Frontend dependency scanning

Scanning Workflows

Docker Build & Scan (.github/workflows/docker-build.yml) — runs on every commit to main, development, and feature/beta-release, and on all PRs targeting those branches. Performs Trivy scanning, generates an SBOM, creates SBOM attestations, and uploads SARIF results to the GitHub Security tab.

Supply Chain Verification (.github/workflows/supply-chain-verify.yml) — triggers automatically via workflow_run after a successful docker-build. Runs SBOM completeness checks, Grype vulnerability scans, and (on releases) Cosign signature and SLSA provenance validation.

Weekly Security Rebuild (.github/workflows/security-weekly-rebuild.yml) — runs every Sunday at 02:00 UTC. Performs a full no-cache rebuild, scans for all severity levels, and retains JSON artifacts for 90 days.

PR-Specific Scanning — extracts and scans only the Charon application binary on each pull request. Fails the PR if CRITICAL or HIGH vulnerabilities are found in application code.

Manual Reviews

• Security code reviews for all major features
• Peer review of security-sensitive changes
• Third-party security audits (planned)

---

Security Best Practices

Deployment Recommendations

1. Use HTTPS: Always deploy behind a reverse proxy with TLS
2. Restrict Admin Access: Limit admin panel to trusted IPs
3. Regular Updates: Keep Charon and dependencies up to date
4. Secure Webhooks: Only use trusted webhook endpoints
5. Strong Passwords: Enforce password complexity policies
6. Backup Encryption: Encrypt backup files before storage

Configuration Hardening

services:
  charon:
    image: ghcr.io/wikid82/charon:latest
    restart: unless-stopped
    environment:
      - CHARON_ENV=production
      - LOG_LEVEL=info
    volumes:
      - ./charon-data:/app/data:rw
      - /var/run/docker.sock:/var/run/docker.sock:ro
    networks:
      - charon-internal
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
    security_opt:
      - no-new-privileges:true
    read_only: true
    tmpfs:
      - /tmp:noexec,nosuid,nodev

Gotify Token Hygiene

Gotify application tokens are secrets and must be handled with strict confidentiality.

• Never echo, print, log, or return token values in API responses or errors.
• Never expose tokenized endpoint query strings (e.g., ...?token=...) in logs, diagnostics, examples, screenshots, tickets, or reports.
• Always redact query parameters in diagnostics and examples before display or storage.
• Use write-only token inputs in operator workflows and UI forms.
• Store tokens only in environment variables or a dedicated secret manager.
• Validate Gotify endpoints over HTTPS only.
• Rotate tokens immediately on suspected exposure.

Network Security

• Firewall Rules: Only expose necessary ports (80, 443, 8080)
• VPN Access: Use VPN for admin access in production
• Fail2Ban: Consider fail2ban for brute-force protection
• Intrusion Detection: Enable CrowdSec for threat detection

---

Security Hall of Fame

We recognize security researchers who help improve Charon:

• Your name could be here!

---

Last Updated: 2026-03-20