We actively maintain security for the following versions:

If you discover a security vulnerability, we appreciate your help in disclosing it to us responsibly.

1. Do NOT create a public GitHub issue for security vulnerabilities
2. Send an email to [email protected] with:
   • Description of the vulnerability
   • Steps to reproduce the issue
   • Potential impact assessment
   • Any suggested fixes (optional)

• Acknowledgment: We will acknowledge receipt within 48 hours
• Assessment: Initial assessment within 5 business days
• Updates: Regular updates on our progress
• Resolution: We aim to resolve critical vulnerabilities within 30 days

Our Docker images implement several security best practices:

1. Non-root User: All containers run as non-root user mcp
2. Minimal Base Image: Using python:3.13-slim-bookworm for reduced attack surface
3. Multi-stage Builds: Separate build and runtime stages
4. Security Updates: Regular package updates and security patches
5. Vulnerability Scanning: Automated Trivy scans on every build
6. File Permissions: Restrictive permissions on application files

1. Automated Scanning: Using safety and pip-audit for Python dependencies
2. Dependabot: Automated dependency updates via GitHub Dependabot
3. Version Pinning: Explicit version pinning in requirements.txt
4. Regular Updates: Monthly security review of all dependencies

1. Secrets Detection: Automated scanning with TruffleHog
2. Static Analysis: Security-focused code analysis
3. Input Validation: Comprehensive input validation and sanitization
4. OAuth Security: Proper JWT token validation and OAuth flows

1. HTTPS Only: All communications over HTTPS
2. Environment Variables: Sensitive configuration via environment variables
3. Logging: Comprehensive security event logging
4. Monitoring: Automated security monitoring and alerting

We classify vulnerabilities according to the following severity levels:

• Critical: Immediate risk to confidentiality, integrity, or availability
• High: Significant risk requiring prompt attention
• Medium: Moderate risk to be addressed in regular updates
• Low: Minimal risk, addressed during maintenance cycles

Some vulnerabilities may not be applicable to our use case. We document these in .trivyignore with:

1. CVE Number: Specific vulnerability identifier
2. Rationale: Why it's not exploitable in our context
3. References: Links to upstream decisions or security analyses
4. Review Date: When the exception should be reviewed

Examples include:

• System-level vulnerabilities in containerized environments
• Vulnerabilities in unused libraries or features
• Issues marked as "will_not_fix" by upstream maintainers

1. Use Official Images: Only use official images from Docker Hub
2. Network Security: Deploy behind a reverse proxy with HTTPS
3. Environment Variables: Use secure methods for configuration
4. Regular Updates: Keep images updated with latest security patches

1. OAuth Configuration: Properly configure OAuth settings
2. Access Controls: Implement appropriate access controls
3. Monitoring: Enable security monitoring and logging
4. Backup Security: Secure backup and disaster recovery procedures

1. Authentication: Enable authentication on Schema Registry
2. Authorization: Use proper RBAC for schema management
3. Network Isolation: Isolate Schema Registry network access
4. Audit Logging: Enable comprehensive audit logging

We run automated security scans:

• Container Vulnerabilities: Trivy scans on every build
• Dependency Vulnerabilities: Python package security checks
• Secrets Detection: Source code secrets scanning
• Docker Security: Docker Bench Security compliance

Subscribe to security notifications:

1. GitHub Security Advisories: Watch repository for security updates
2. Release Notes: Review security sections in release notes
3. CVE Tracking: Monitor CVE databases for relevant vulnerabilities

Our security practices align with:

• OWASP Application Security: Following OWASP guidelines
• CIS Docker Benchmarks: Docker security best practices
• NIST Cybersecurity Framework: Security controls and processes
• SSDLC: Secure Software Development Lifecycle practices

For security-related questions:

• Security Issues: [email protected]
• General Security Questions: Create a GitHub Discussion
• Documentation: Check our security documentation in /docs

We appreciate the security research community and acknowledge responsible disclosure of vulnerabilities. Contributors who responsibly report security issues may be acknowledged in our security advisories (with their permission).

This security policy is licensed under the same terms as the project.