The following versions of Stellar-K8s currently receive security updates:-
| Version | Supported | End of Support |
|---|---|---|
| 0.1.x | ✅ | TBD |
Only the latest patch release within a supported minor version receives security fixes. Users are strongly encouraged to stay on the latest release.
Do not report security vulnerabilities through public GitHub issues, pull requests, or discussions.
Use GitHub's built-in private disclosure mechanism:
- Go to the Security Advisories tab of this repository
- Click "Report a vulnerability"
- Fill in the details and submit
This keeps the report confidential and allows coordinated disclosure.
Send an encrypted report to:
For encrypted communication, use our PGP public key:
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBGYXXXXBEAC... (placeholder — replace with actual project PGP key)
-----END PGP PUBLIC KEY BLOCK-----
Key fingerprint: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
Until a project PGP key is published, reporters may use GitHub's private advisory system (Option 1) or email samuelotowo@gmail.com directly.
Please provide as much of the following as possible:
- Type of vulnerability (e.g., privilege escalation, SSRF, RCE, information disclosure)
- Affected component(s) and version(s)
- Full path(s) of relevant source files
- Step-by-step reproduction instructions
- Proof-of-concept or exploit code (if available)
- Potential impact and attack scenario
- Any suggested mitigations
| Stage | Target SLA |
|---|---|
| Acknowledgment | 48 hours |
| Initial triage & severity | 5 business days |
| Fix development begins | Based on severity |
| Patch release (Critical/High) | 14 days |
| Patch release (Medium/Low) | 30–90 days |
| Public disclosure | After patch ships |
Severity is assessed using CVSS v3.1.
We follow coordinated vulnerability disclosure:
- Reporter submits vulnerability privately
- We validate, triage, and assign a CVE if warranted
- We develop and test a fix in a private fork
- A patched release is published
- A GitHub Security Advisory is made public
- Reporter is credited (unless they prefer anonymity)
We ask reporters to:
- Allow at least 90 days before public disclosure
- Avoid accessing or modifying data beyond what is needed to demonstrate the issue
- Not disrupt production systems or other users
Report received
│
▼
Acknowledgment (48h)
│
▼
Triage & CVSS scoring
│
├─ Invalid / Not a vulnerability ──► Close with explanation
│
▼
Private fix branch + draft advisory
│
▼
Patch release + CVE assignment
│
▼
Public advisory + reporter credit
- Use the latest stable release; pin image digests in production
- Scan images with Trivy or Grype before deployment
- Operator containers run as non-root by default — do not override this
- Follow least-privilege; review the generated RBAC manifests before applying
- Use dedicated service accounts per component
- Audit RBAC bindings regularly
- Enable mTLS for inter-component communication
- Apply Kubernetes NetworkPolicies to restrict operator traffic
- Protect the admission webhook endpoint with proper TLS certificates
- Use an external secrets manager (Vault, AWS Secrets Manager, etc.)
- Enable etcd encryption at rest
- Rotate secrets and TLS certificates regularly
- Enable audit logging on the API server
- Alert on unexpected RBAC changes or CRD modifications
- Monitor operator metrics via the Prometheus endpoint
Our pipeline runs the following on every commit:
| Tool | Purpose |
|---|---|
cargo audit |
Rust dependency advisory checks (RUSTSEC DB) |
| Trivy | Container image vulnerability scanning |
| Dependabot | Automated dependency update PRs |
| SBOM | Software Bill of Materials generation |
Results are uploaded to GitHub Security tab as SARIF reports.
The WASM-based admission webhook validates all StellarNode resources. Ensure:
- The webhook TLS certificate is valid and rotated before expiry
- WASM plugins are loaded only from trusted, integrity-verified sources (SHA-256 checked)
Webhook validation prevents invalid configurations, resource exhaustion, and privilege escalation attempts via the StellarNode spec.
The optional REST API should be protected by network policies and ingress authentication. Do not expose it publicly without authentication.
Our CI/CD pipeline includes comprehensive automated security testing:
- Trivy - Container/FS/dependency scanning (CRITICAL/HIGH alerts)
- Cargo Audit - Rust crates.io advisories
- SBOM Generation - CycloneDX supply chain transparency
- CodeQL - Semantic code analysis (GitHub Advanced Security)
- k6 - API load/penetration scenarios (DDoS, slowloris sim)
- OWASP ZAP - Baseline DAST for operator REST API
- Nuclei - Template-based vulnerability scanning
- kube-bench - CIS Kubernetes Benchmark automation
- Checkov - IaC scanning for Helm charts/manifests
- kube-score - K8s resource scoring
Run locally: make security-all
-
Prometheus + Grafana - Security metrics dashboard
-
Falco - Behavioral runtime security (planned integration)
-
Audit Logs - API/server audit trails
-
CVE Auto-remediation - Controller-based patching (src/controller/cve.rs)
| Channel | Address / Link |
|---|---|
| Security advisories | GitHub Security Tab |
| Security email | security@stellar-k8s.io |
| Maintainer contact | samuelotowo@gmail.com |
| General issues | GitHub Issues |
We are grateful to security researchers who responsibly disclose vulnerabilities. Reporters will be credited in the GitHub Security Advisory and CHANGELOG unless they request anonymity.