We release patches for security vulnerabilities for the following versions:

DO NOT open a public GitHub issue for security vulnerabilities.

Please report security vulnerabilities by emailing:

security@firestoned.io

Include in your report:

• Description of the vulnerability
• Steps to reproduce the issue
• Potential impact
• Suggested fix (if any)

• Acknowledgment: Within 24 hours of report
• Initial Assessment: Within 72 hours
• Status Updates: Weekly until resolution
• Fix Timeline: Critical issues within 7 days, high priority within 30 days

• We practice coordinated disclosure
• Security advisories will be published after a fix is available
• We will credit reporters unless they prefer to remain anonymous

This section provides an overview of Bindy's security posture. For detailed information, refer to the following documents:

• Threat Model: STRIDE threat analysis, attack surface, threat scenarios
• Security Architecture: Trust boundaries, authentication, secrets management, network security
• Incident Response Playbooks: Step-by-step response procedures for security incidents
• Audit Log Retention Policy: 7-year retention, WORM storage, log integrity verification
• Secret Access Audit Trail: Kubernetes audit logs, pre-built compliance queries, alerting rules
• Build Reproducibility Verification: SLSA Level 3, deterministic builds, verification process
• Vulnerability Management Policy: Remediation SLAs, scanning process, exception handling
• RBAC Verification: Automated script to verify least privilege RBAC implementation

All commits MUST be cryptographically signed with GPG or SSH keys.

This requirement ensures:

• ✅ Cryptographic proof of code authorship
• ✅ Prevention of commit forgery
• ✅ Audit trail for compliance (SOX 404, PCI-DSS 6.4.6)
• ✅ Supply chain integrity (SLSA Level 2+)

Enforcement:

• Branch protection requires signed commits on main
• CI/CD verifies all commits are signed
• Unsigned commits will fail PR checks

Setup Instructions: See CONTRIBUTING.md

All code changes require:

• 2+ approving reviews from maintainers
• Cryptographically signed commits from all authors
• Passing CI/CD security checks:
  • Dependency vulnerability scanning (cargo audit)
  • Clippy linting with strict warnings
  • Automated tests (unit + integration)
  • SBOM generation for releases

No exceptions - even for hotfixes or urgent changes.

Security requirements for dependencies:

• All dependencies scanned with cargo audit
• Only use dependencies from crates.io or verified sources
• Dependencies MUST be actively maintained (commits in last 6 months)
• Security vulnerabilities remediated within defined SLAs (see below)

Automated Vulnerability Scanning:

• Rust Dependencies: cargo audit scans all dependencies in every PR, push to main, and release
• Container Images: Trivy scans all container images for OS and library vulnerabilities
• Scheduled Scans: Daily security scans run automatically at 00:00 UTC
• SARIF Upload: Results uploaded to GitHub Security tab for tracking
• Issue Creation: GitHub issues automatically created for new vulnerabilities

CI/CD checks:

• cargo audit --deny warnings runs on every PR and push to main
• CI FAILS on CRITICAL/HIGH vulnerabilities - must be remediated before merge
• Trivy scans containers with severity threshold: CRITICAL, HIGH
• Automated security reports uploaded as workflow artifacts
• Manual review required for major version updates

Remediation SLAs:

• 🔴 CRITICAL (CVSS 9.0-10.0): 24 hours
• 🟠 HIGH (CVSS 7.0-8.9): 7 days
• 🟡 MEDIUM (CVSS 4.0-6.9): 30 days
• 🔵 LOW (CVSS 0.1-3.9): 90 days

Policy: See docs/security/VULNERABILITY_MANAGEMENT.md for complete vulnerability management policy

Repository access:

• Read access: Public
• Write access: Requires GPG/SSH signed commits + 2FA
• Admin access: Limited to project maintainers
• Release access: Requires signed tags + manual approval

Branch protection on main:

• ✅ Require signed commits
• ✅ Require linear history (no merge commits)
• ✅ Require pull request reviews (2 approvers)
• ✅ Dismiss stale pull request approvals when new commits pushed
• ✅ Require status checks to pass (CI/CD verification)
• ✅ Require branches to be up to date before merging
• ❌ No direct pushes to main (even for admins)

Build provenance (SLSA Level 2+):

• All commits cryptographically signed
• SBOM (Software Bill of Materials) generated for all releases
• Docker images include SBOM and attestation
• Reproducible builds with pinned dependencies

Container security:

• Multi-stage builds minimize attack surface
• Non-root user for runtime
• No secrets in container images
• Regular base image updates for security patches

Release process:

• Signed Git tags for all releases
• Automated SBOM generation (CycloneDX format)
• Checksum verification (SHA256)
• Signed container images with provenance attestation

NEVER commit:

• ❌ API keys, tokens, or credentials
• ❌ Private keys or certificates
• ❌ Internal hostnames or IP addresses
• ❌ Customer or transaction data
• ❌ Encryption keys or secrets

Approved methods:

• GitHub Secrets for CI/CD
• Kubernetes Secrets for runtime
• Environment variables (never hardcoded)
• External secret managers (Vault, AWS Secrets Manager)

Detection:

• Pre-commit hooks to detect secrets
• GitHub Advanced Security secret scanning
• CI/CD fails if secrets detected

This project operates in a regulated banking environment and adheres to:

Change Management:

• All code changes require cryptographic signature verification
• Two-person approval required for all merges
• Audit trail maintained via Git history and signed commits
• Changes traceable to business/technical requirements

Access Controls:

• Least privilege access (write requires 2FA + signing)
• Regular access reviews (quarterly)
• Separation of duties (2+ reviewers required)

Evidence Collection:

• GitHub audit logs
• CI/CD workflow logs
• Commit signature verification logs

Requirement 6.4.6 - Code Review:

• Two-person review required (enforced via GitHub)
• Signed commits provide non-repudiation
• Automated security scanning (cargo audit)
• Change documentation (CHANGELOG.md)

Requirement 12.10.6 - Change Management:

• Documented approval process (PR + 2 reviews)
• Testing required before deployment (CI/CD)
• Rollback procedures documented
• Change tracking via Git history

SLSA Level 2 Requirements:

• ✅ Build provenance: Signed commits provide authorship proof
• ✅ Source integrity: GPG/SSH signatures verify source authenticity
• ✅ Build integrity: Reproducible builds with SBOM
• ✅ Availability: Public repository with immutable history

Evidence:

• Signed commits in Git history
• SBOM files in release artifacts
• Container image attestations
• CI/CD workflow logs

1. Sign all commits - See CONTRIBUTING.md
2. Keep dependencies updated - Run cargo update regularly
3. Run security audit - Run cargo audit before committing
4. Follow least privilege - Request only necessary permissions
5. Use 2FA - Enable two-factor authentication on GitHub

1. Review all code changes - Even for trusted contributors
2. Verify commit signatures - Check "Verified" badge on GitHub
3. Test security controls - Regularly verify branch protection works
4. Rotate keys regularly - GPG keys expire, plan rotation
5. Monitor dependencies - Review Dependabot PRs promptly
6. Audit access - Quarterly review of repository access

1. Verify signatures - Check Git tags and container signatures
2. Validate checksums - Verify SHA256 checksums for binaries
3. Scan containers - Run container security scanning before deployment
4. Use SBOM - Review SBOM for known vulnerabilities
5. Monitor runtime - Deploy with security monitoring enabled

For detailed incident response procedures, see Incident Response Playbooks.

• P1: Critical Vulnerability Detected - CVSS 9.0-10.0 vulnerability, 24-hour remediation SLA
• P2: Compromised Operator Pod - Unauthorized access, anomalous behavior
• P3: DNS Service Outage - All BIND9 pods down, queries failing
• P4: RNDC Key Compromise - Key leaked, unauthorized RNDC access
• P5: Unauthorized DNS Changes - Unexpected zone modifications
• P6: DDoS Attack - Query flood, resource exhaustion
• P7: Supply Chain Compromise - Malicious commit, compromised dependency

All incidents follow the NIST Incident Response Lifecycle:

1. Preparation: Playbooks, tools, team readiness
2. Detection & Analysis: Confirm incident, assess impact
3. Containment: Isolate affected systems, prevent escalation
4. Eradication: Remove threat, patch vulnerability
5. Recovery: Restore service, verify integrity
6. Post-Incident Activity: Document lessons learned, improve defenses

• Internal: Slack war room (#incident-[date]-[number]), status updates every 30 minutes
• Public: Coordinated disclosure after fix available
• Customers: Email notification for critical/high incidents
• Regulators: PCI-DSS (24h), SOX (quarterly), Basel III (risk committee)

• Security Team: security@firestoned.io
• Project Maintainers: See CODEOWNERS
• Compliance Officer: compliance@firestoned.io (for SOX/PCI-DSS issues)

We thank the security researchers and contributors who help keep Bindy secure:

• GitHub Security Best Practices
• SLSA Framework
• OWASP Kubernetes Security Cheat Sheet
• SOC 2 Type II Controls

Last Updated: 2025-12-18 Next Review: 2026-03-18 (Quarterly)