We take security issues seriously. If you discover a security vulnerability in this project, please report it responsibly.

Do NOT open a public GitHub issue for security vulnerabilities.

Instead, please report vulnerabilities by emailing:

📧 [email protected]

Include the following in your report:

1. Description — A clear description of the vulnerability
2. Reproduction Steps — Step-by-step instructions to reproduce the issue
3. Impact — What an attacker could achieve by exploiting this vulnerability
4. Affected Component — Which component is affected (Controller, Webhook, Governance API)
5. Environment — Kubernetes/OpenShift version, Go/Node.js version, and any relevant configuration
6. Suggested Fix — If you have a recommendation (optional)

• We follow coordinated vulnerability disclosure.
• We will work with you to understand and resolve the issue before any public disclosure.
• We request a 90-day disclosure window from the initial report.
• Credit will be given to reporters in the security advisory (unless anonymity is requested).

When deploying the SCC Orchestration System, follow these recommendations:

• Always use TLS for webhook communication — generate certificates using scripts/generate-certs.sh
• Rotate TLS certificates regularly
• Never commit certificates or private keys to version control

• Apply the principle of least privilege for all service accounts
• Use the provided RBAC manifests in deploy/base/controller/ and deploy/base/webhook/
• Restrict access to the Governance API to authorized namespaces only

• All provided Dockerfiles run as non-root users (distroless/static:nonroot for Go, USER node for Node.js)
• Do not override the USER directive in production
• Use read-only root filesystems where possible
• Scan container images regularly for known CVEs

• Enable authentication on the Governance API in production environments
• Configure RBAC policies to restrict who can approve migration plans
• Audit logs are immutable — ensure persistent storage is configured

• Restrict network access between components using Kubernetes NetworkPolicies
• The Admission Webhook should only be reachable from the Kubernetes API server
• The Governance API should only be reachable from the Controller and Webhook

• SCC Privilege Gap: The risk engine evaluates privilege escalation risk between source and target SCCs. High-risk migrations (e.g., restricted → privileged) require explicit governance approval.
• Webhook Bypass: If the webhook becomes unavailable, Kubernetes failurePolicy: Fail ensures pods are not admitted without SCC validation. Verify this setting in deploy/base/webhook/webhook-config.yaml.
• Governance API Isolation: The governance plane runs as a separate service to prevent compromise of the policy engine from affecting cluster operations.