- README.md: Update tech stack versions, simplify content, add links to docs - CONTRIBUTING.md: Add commit guidelines, testing instructions, PR process - SECURITY.md: Add security measures, vulnerability reporting process - PULL_REQUEST_TEMPLATE.md: Add conventional commit types, breaking change section - Remove outdated plan documents (already implemented or superseded) - architecture.md: Already updated with comprehensive system documentation - release-engineering.md: Already updated with current pipeline status
128 lines
2.6 KiB
Markdown
128 lines
2.6 KiB
Markdown
# Security Policy
|
|
|
|
## Supported Versions
|
|
|
|
| Version | Supported |
|
|
| ------- | ------------------ |
|
|
| 1.x | :white_check_mark: |
|
|
| < 1.0 | :x: |
|
|
|
|
## Reporting a Vulnerability
|
|
|
|
We take security seriously. If you discover a security vulnerability, please follow responsible disclosure.
|
|
|
|
### How to Report
|
|
|
|
**Preferred Method**: Open a security advisory
|
|
|
|
1. Go to the repository
|
|
2. Click "Security" tab
|
|
3. Click "Report a vulnerability"
|
|
4. Fill out the advisory form
|
|
|
|
**Alternative**: Email the maintainer directly (if available in profile)
|
|
|
|
### What to Include
|
|
|
|
- Description of the vulnerability
|
|
- Steps to reproduce
|
|
- Affected versions
|
|
- Potential impact
|
|
- Suggested fix (if available)
|
|
|
|
### Response Timeline
|
|
|
|
| Action | Timeline |
|
|
|--------|----------|
|
|
| Initial response | Within 48 hours |
|
|
| Vulnerability assessment | Within 7 days |
|
|
| Fix timeline based on severity | See below |
|
|
|
|
### Fix Timeline by Severity
|
|
|
|
| Severity | Timeline |
|
|
|----------|----------|
|
|
| Critical | 24-72 hours |
|
|
| High | 1 week |
|
|
| Medium | Next release |
|
|
| Low | Next release |
|
|
|
|
## Security Measures
|
|
|
|
This project implements several security measures:
|
|
|
|
### Code Quality
|
|
|
|
- ESLint for code analysis
|
|
- Automated testing before merge
|
|
- Code review required for all changes
|
|
|
|
### Secret Management
|
|
|
|
- Gitleaks pre-commit hook prevents committing secrets
|
|
- Environment variables for sensitive configuration
|
|
- No secrets in version control
|
|
|
|
### Authentication
|
|
|
|
- JWT tokens with configurable expiration
|
|
- Password hashed in database
|
|
- Token-based API authentication
|
|
|
|
### Dependencies
|
|
|
|
- Regular dependency audits via `npm audit`
|
|
- Dependabot for automated updates (if enabled)
|
|
|
|
## Best Practices for Contributors
|
|
|
|
### Do Not Commit
|
|
|
|
- API keys or tokens
|
|
- Database credentials
|
|
- JWT secrets
|
|
- Password files
|
|
- Private keys or certificates
|
|
|
|
### Environment Variables
|
|
|
|
Store sensitive configuration in environment variables:
|
|
|
|
```bash
|
|
# Backend
|
|
PORT=3001
|
|
DB_PATH=./data/cv.db
|
|
AUTH_MODE=simple
|
|
JWT_SECRET=your-secret-here
|
|
|
|
# Keycloak (if used)
|
|
KEYCLOAK_URL=https://keycloak.example.com
|
|
KEYCLOAK_REALM=your-realm
|
|
KEYCLOAK_CLIENT_ID=cv-app
|
|
```
|
|
|
|
### Running Security Audit
|
|
|
|
```bash
|
|
# Check for vulnerable dependencies
|
|
npm audit
|
|
|
|
# Fix vulnerabilities
|
|
npm audit fix
|
|
|
|
# Check backend dependencies
|
|
cd backend && npm audit
|
|
```
|
|
|
|
## Disclosure Policy
|
|
|
|
- Please allow reasonable time for the fix before public disclosure
|
|
- Coordinated disclosure is appreciated
|
|
- Credit will be given in the fix commit (if desired)
|
|
|
|
## Contact
|
|
|
|
For security concerns, use the vulnerability reporting process above.
|
|
|
|
Thank you for helping keep this project secure!
|