|
| 1 | +# Security Policy |
| 2 | + |
| 3 | +## Supported Versions |
| 4 | + |
| 5 | +We actively maintain and provide security updates for the following versions of `go-githubauth`: |
| 6 | + |
| 7 | +| Version | Supported | |
| 8 | +| ------- | ------------------ | |
| 9 | +| 1.4.x | :white_check_mark: | |
| 10 | +| < 1.3 | :x: | |
| 11 | + |
| 12 | +Please ensure you are using a supported version to receive security updates. |
| 13 | + |
| 14 | +## Reporting a Vulnerability |
| 15 | + |
| 16 | +We take security vulnerabilities seriously. If you discover a security vulnerability in `go-githubauth`, please report it responsibly. |
| 17 | + |
| 18 | +### How to Report |
| 19 | + |
| 20 | +1. **Email**: Send details to the maintainer via GitHub's private vulnerability reporting feature or create a [security advisory](https://github.com/jferrl/go-githubauth/security/advisories/new) |
| 21 | +2. **Do NOT** create a public GitHub issue for security vulnerabilities |
| 22 | +3. **Do NOT** discuss the vulnerability publicly until it has been addressed |
| 23 | + |
| 24 | +### What to Include |
| 25 | + |
| 26 | +When reporting a vulnerability, please include: |
| 27 | + |
| 28 | +- A clear description of the vulnerability |
| 29 | +- Steps to reproduce the issue |
| 30 | +- Affected versions |
| 31 | +- Any potential impact assessment |
| 32 | +- Suggested fixes (if available) |
| 33 | + |
| 34 | +### Response Timeline |
| 35 | + |
| 36 | +- **Initial Response**: Within 48 hours of receiving the report |
| 37 | +- **Initial Assessment**: Within 5 business days |
| 38 | +- **Fix Timeline**: Varies based on complexity, but we aim for resolution within 30 days |
| 39 | +- **Disclosure**: Coordinated disclosure after fix is available |
| 40 | + |
| 41 | +## Security Considerations |
| 42 | + |
| 43 | +### For Users of This Library |
| 44 | + |
| 45 | +When using `go-githubauth`, please consider the following security best practices: |
| 46 | + |
| 47 | +#### Token Security |
| 48 | + |
| 49 | +- **Never commit tokens to version control** - Use environment variables or secure credential management |
| 50 | +- **Rotate tokens regularly** - Especially personal access tokens |
| 51 | +- **Use minimal required permissions** - Follow the principle of least privilege |
| 52 | +- **Monitor token usage** - Regularly audit GitHub App installations and token access |
| 53 | + |
| 54 | +#### Application Security |
| 55 | + |
| 56 | +```go |
| 57 | +// ✅ Good - Using environment variables |
| 58 | +privateKey := []byte(os.Getenv("GITHUB_APP_PRIVATE_KEY")) |
| 59 | +clientID := os.Getenv("GITHUB_APP_CLIENT_ID") |
| 60 | + |
| 61 | +// ❌ Bad - Hardcoded secrets |
| 62 | +privateKey := []byte("-----BEGIN PRIVATE KEY-----\nMIIE...") |
| 63 | +``` |
| 64 | + |
| 65 | +#### Transport Security |
| 66 | + |
| 67 | +- Always use HTTPS endpoints (default in this library) |
| 68 | +- Validate SSL certificates (default behavior) |
| 69 | +- Use appropriate timeout values to prevent resource exhaustion |
| 70 | + |
| 71 | +#### Error Handling |
| 72 | + |
| 73 | +- Avoid logging sensitive token information |
| 74 | +- Handle authentication failures gracefully |
| 75 | +- Implement proper retry logic with exponential backoff |
| 76 | + |
| 77 | +### Library-Specific Considerations |
| 78 | + |
| 79 | +- **Token Caching**: This library caches tokens for performance. Ensure your application handles cached token invalidation appropriately |
| 80 | +- **Private Keys**: RSA private keys are stored in memory during operation. Ensure your application follows secure memory management practices |
| 81 | +- **HTTP Clients**: The library uses pooled HTTP clients. In containerized environments, ensure proper resource cleanup |
| 82 | + |
| 83 | +## Security Updates |
| 84 | + |
| 85 | +Security updates will be: |
| 86 | + |
| 87 | +- Released as patch versions (e.g., 1.4.1) |
| 88 | +- Documented in the [CHANGELOG.md](./CHANGELOG.md) |
| 89 | +- Announced in GitHub releases with security labels |
| 90 | +- Published to GitHub Security Advisories when applicable |
| 91 | + |
| 92 | +## Dependencies |
| 93 | + |
| 94 | +We regularly audit our dependencies for known vulnerabilities: |
| 95 | + |
| 96 | +- Direct dependencies are kept minimal and up-to-date |
| 97 | +- We use `dependabot` and automated security scanning |
| 98 | +- Critical security updates to dependencies trigger immediate releases |
| 99 | + |
| 100 | +## Responsible Disclosure |
| 101 | + |
| 102 | +We are committed to working with security researchers and the community to verify and address security vulnerabilities. Researchers who report valid security issues will be: |
| 103 | + |
| 104 | +- Acknowledged in security advisories (unless they prefer to remain anonymous) |
| 105 | +- Given credit in release notes |
| 106 | +- Provided with updates on the fix timeline |
| 107 | + |
| 108 | +## Security Resources |
| 109 | + |
| 110 | +- [GitHub Security Best Practices](https://docs.github.com/en/code-security) |
| 111 | +- [OWASP API Security Top 10](https://owasp.org/www-project-api-security/) |
| 112 | +- [Go Security Checklist](https://github.com/Checkmarx/Go-SCP) |
| 113 | + |
| 114 | +## Contact |
| 115 | + |
| 116 | +For security-related questions that don't involve reporting vulnerabilities, you can: |
| 117 | + |
| 118 | +- Create a regular [GitHub Issue](https://github.com/jferrl/go-githubauth/issues) (for non-sensitive matters) |
0 commit comments