If you believe you've found a security vulnerability in RaftIQ, please report it privately rather than opening a public issue. Use GitHub's "Report a vulnerability" flow under the repository's Security tab, or contact the maintainer directly through the contact information on their GitHub profile (sanchar127).

Please include:

• A description of the vulnerability and its potential impact.
• Steps to reproduce it, including cluster topology/config if relevant.
• Whether it requires network access, disk access, or a malicious peer.

We'll acknowledge reports as promptly as we can and follow up with a fix timeline once the issue is understood. As a single-maintainer, early-stage open-source project, there is currently no formal SLA on response time.

RaftIQ does not yet have tagged releases with a formal support window. Security fixes are applied to the main branch. Once tagged releases exist, this section will be updated with a supported-version table.

• TLS/mTLS is implemented in internal/transport/tls.go (LoadTLSConfig, LoadTLSServerConfig, LoadTLSKVServerConfig, LoadTLSClientConfig, with SAN verification for Raft peers) and is mandatory in cmd/raftiq. The binary requires --tls-ca, --tls-cert, and --tls-key, and refuses to start without them — both the Raft gRPC server and the KV gRPC server run mutual TLS unconditionally. There is no plaintext mode.
• Raft peer connections are additionally checked against an expected certificate SAN (<peerID>.raftiq for each ID in --peers) — a certificate that doesn't match a configured peer ID is rejected even if it's signed by the trusted CA.
• The KV gRPC service does not restrict by client identity — any client presenting a certificate signed by the configured CA is accepted, regardless of which specific certificate it is. If you need to restrict which clients can reach the KV API, do it at the CA/issuance level.
• The Prometheus metrics endpoint (--metrics-addr) and the health/readiness endpoint (--health-addr) are plain HTTP, not TLS. Don't expose either beyond a trusted network without your own reverse proxy or network policy in front of them.
• There is no further authentication/authorization layer beyond TLS. Anyone with a CA-signed client certificate can read and write any key over the KV API. See docs/transport/security.md for the full implementation details, including how to generate development certificates.

• No built-in authentication/authorization for KV reads/writes beyond possession of a CA-signed client certificate.
• No rate limiting or request quotas on either gRPC service.
• No encryption at rest for the WAL (internal/storage writes plain binary records; anyone with filesystem access to --data-dir can read all committed state, including keys and values).
• The distributed-locking and job fencing mechanisms (internal/lock, internal/scheduler, internal/worker) protect against stale actors (partitioned/slow nodes acting on outdated leases), not against malicious ones — a compromised node with valid credentials can still submit arbitrary commands.
• Membership changes (AddMember/RemoveMember) have no RPC or CLI — this is an availability/operability gap, not a security one, but it means there's currently no way to remove a compromised node's voting rights except by embedding the Go API directly.

If you plan to run RaftIQ in production or across untrusted networks, treat the items above as required hardening work, not optional extras.