Update README.md to provide a comprehensive overview of The Order monorepo, including repository structure, quickstart guide, development workflow, and contribution guidelines.
This commit is contained in:
105
docs/governance/SECURITY.md
Normal file
105
docs/governance/SECURITY.md
Normal file
@@ -0,0 +1,105 @@
|
||||
# Security Policy
|
||||
|
||||
## Supported Versions
|
||||
|
||||
We currently support the following versions with security updates:
|
||||
|
||||
| Version | Supported |
|
||||
| ------- | ------------------ |
|
||||
| 1.0.x | :white_check_mark: |
|
||||
| < 1.0 | :x: |
|
||||
|
||||
## Reporting a Vulnerability
|
||||
|
||||
We take security vulnerabilities seriously. If you discover a security vulnerability, please follow these steps:
|
||||
|
||||
1. **Do NOT** open a public GitHub issue
|
||||
2. Email security details to: security@the-order.org (or your security contact)
|
||||
3. Include:
|
||||
- Description of the vulnerability
|
||||
- Steps to reproduce
|
||||
- Potential impact
|
||||
- Suggested fix (if any)
|
||||
|
||||
### Response Timeline
|
||||
|
||||
- **Initial Response**: Within 48 hours
|
||||
- **Status Update**: Within 7 days
|
||||
- **Fix Timeline**: Depends on severity (see below)
|
||||
|
||||
### Severity Levels
|
||||
|
||||
- **Critical**: Remote code execution, authentication bypass, data breach
|
||||
- Fix timeline: 24-48 hours
|
||||
- **High**: Privilege escalation, sensitive data exposure
|
||||
- Fix timeline: 7 days
|
||||
- **Medium**: Information disclosure, denial of service
|
||||
- Fix timeline: 30 days
|
||||
- **Low**: Best practices, defense in depth
|
||||
- Fix timeline: Next release cycle
|
||||
|
||||
## Security Practices
|
||||
|
||||
### Secrets Management
|
||||
|
||||
- All secrets must be encrypted using SOPS
|
||||
- Never commit plaintext secrets
|
||||
- Use environment variables for configuration
|
||||
- Rotate secrets regularly
|
||||
- Use short-lived tokens via OIDC
|
||||
|
||||
### Code Security
|
||||
|
||||
- All code must pass security linting (ESLint security plugins)
|
||||
- Dependencies are scanned for vulnerabilities (Grype)
|
||||
- Container images are signed (Cosign)
|
||||
- SBOM generation for all artifacts (Syft)
|
||||
|
||||
### Infrastructure Security
|
||||
|
||||
- Immutable infrastructure via Terraform
|
||||
- Secrets stored in KMS/HSM
|
||||
- Network policies enforced via Kubernetes
|
||||
- API gateway with WAF rules
|
||||
- Regular security audits and penetration testing
|
||||
|
||||
### Access Control
|
||||
|
||||
- Least privilege principle
|
||||
- Quarterly access reviews
|
||||
- MFA required for all production access
|
||||
- Audit logs for all sensitive operations
|
||||
|
||||
### Compliance
|
||||
|
||||
- eIDAS compliance for identity services
|
||||
- Data retention policies per jurisdiction
|
||||
- WORM storage for legal documents
|
||||
- Audit trails for all financial transactions
|
||||
|
||||
## Security Updates
|
||||
|
||||
Security updates are released as:
|
||||
- **Hotfixes**: For critical vulnerabilities
|
||||
- **Patch releases**: For high/medium severity issues
|
||||
- **Regular releases**: For low severity and general improvements
|
||||
|
||||
## Disclosure Policy
|
||||
|
||||
- Vulnerabilities are disclosed after a fix is available
|
||||
- Coordinated disclosure with responsible parties
|
||||
- CVE assignment for eligible vulnerabilities
|
||||
- Security advisories published in `docs/governance/security-advisories/`
|
||||
|
||||
## Contact
|
||||
|
||||
- **Security Email**: security@the-order.org
|
||||
- **PGP Key**: [Link to public key]
|
||||
- **Security Team**: @the-order/security-team
|
||||
|
||||
## Additional Resources
|
||||
|
||||
- [Threat Models](docs/architecture/threat-models/)
|
||||
- [Incident Response Runbook](docs/governance/runbooks/incident-response.md)
|
||||
- [Security Checklist](docs/governance/security-checklist.md)
|
||||
|
||||
Reference in New Issue
Block a user