| Version | Supported |
|---|---|
| 2.1.x | ✅ Security fixes |
| 2.0.x | ✅ Security fixes (no new features) |
| < 2.0 | ❌ Not supported |
BioSentinel handles sensitive medical data. Security vulnerabilities must be reported privately to prevent exploitation before a patch is available.
Email: security@liveupx.com
Please include:
- Description of the vulnerability
- Steps to reproduce
- Potential impact assessment
- (Optional) Suggested fix
- Acknowledgement: Within 48 hours
- Initial Assessment: Within 5 business days
- Fix Timeline: Critical issues within 7 days; high within 30 days
- Public Disclosure: After patch release + 30 days (coordinated disclosure)
In-scope security concerns:
- SQL injection or NoSQL injection vulnerabilities
- Authentication / authorization bypasses
- Patient data leakage or unauthorized access
- Insecure default configurations exposing PHI
- Dependency vulnerabilities in production dependencies
- Cryptographic weaknesses in data-at-rest/in-transit encryption
Out of scope:
- Vulnerabilities in development/test environments only
- Social engineering attacks
- Denial of service (unless causing patient data exposure)
- Never expose BioSentinel API to the public internet without authentication
- Always use HTTPS (TLS 1.2+) in production
- Rotate API keys regularly
- Enable audit logging for all patient data access
- Keep all dependencies updated — run
pip auditregularly - Use strong database passwords and restrict DB network access
- Enable PostgreSQL row-level security for multi-tenant deployments
- Review HIPAA/GDPR compliance before ingesting real patient data
BioSentinel is designed with security by default:
- AES-256 encryption for data at rest (when enabled)
- TLS 1.3 for all API communications
- Patient IDs are UUIDs (non-sequential, non-guessable)
- Passwords hashed with bcrypt (cost factor 12+)
- JWT tokens with short expiry (15min access, 7d refresh)
- Audit log for all patient record access
BioSentinel follows responsible disclosure practices. Security researchers who responsibly report valid vulnerabilities will be credited in the release notes (with their permission).