We release patches for security vulnerabilities only in the latest version:
| Version | Supported |
|---|---|
| Latest | β |
| Older | β |
Please do not report security vulnerabilities through public GitHub issues.
If you discover a security vulnerability in Envilder, please report it privately to help us address it before public disclosure.
- Email: Send details to mac.albert@gmail.com
- Subject:
[SECURITY] Envilder - [Brief Description] - Include:
- Description of the vulnerability
- Steps to reproduce the issue
- Potential impact
- Suggested fix (if available)
- Your contact information for follow-up
- Acknowledgment: I will acknowledge your email as soon as possible
- Initial Assessment: I'll provide an initial assessment and prioritize based on severity
- Updates: I'll keep you informed about the progress
- Resolution: I'll work to release a fix as soon as feasible (timeline depends on severity and complexity)
- Credit: You'll be credited in the security advisory (unless you prefer to remain anonymous)
Note: This is a solo open-source project maintained in my spare time. While I take security seriously, response times may vary based on availability.
When using Envilder, follow these security guidelines:
DO:
- β Use IAM roles with OIDC for GitHub Actions (setup guide)
- β Use temporary credentials when possible
- β Follow the principle of least privilege
DON'T:
- β Store AWS access keys in code or environment variables
- β Share AWS credentials via Slack, email, or chat
Envilder requires these AWS permissions:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::123456123456:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:octo-org/octo-repo:*"
},
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
}
}
}
]
}Recommendations:
- Scope permissions to specific parameter paths (e.g.,
/myapp/prod/*) - Use separate IAM roles for different environments (dev, staging, prod)
- Enable CloudTrail logging for audit trails
DO:
- β
Add
.envto.gitignore - β
Use
.env.examplefor documentation (without real values) - β Rotate secrets regularly
DON'T:
- β Commit
.envfiles to version control - β Share
.envfiles via email or chat
When using Envilder GitHub Action:
DO:
- β Use OIDC authentication instead of static credentials (OIDC setup guide)
- β
Pin action versions (e.g.,
@v1.0.0instead of@main) - β Review action code before using in production
DON'T:
- β Store AWS credentials in GitHub Secrets (use OIDC roles)
- β Use overly permissive IAM policies
This project uses:
- Snyk: Vulnerability scanning for dependencies
- Secretlint: Prevents accidental secret commits
- Biome: Code quality and security linting
- Dependabot: Automated dependency updates
- Parameters are encrypted at rest using AWS KMS
- All API calls are logged in CloudTrail
- Access is controlled via IAM policies
- Supports versioning and automatic rotation
- Generated
.envfiles contain sensitive data - Ensure proper file permissions (e.g.,
chmod 600 .env) - Delete or rotate secrets if
.envis accidentally committed
- AWS SSM Security Best Practices
- GitHub Actions Security Hardening
- OWASP Secrets Management Cheat Sheet
When I receive a security vulnerability report:
- I will confirm the vulnerability and determine its impact
- I will develop and test a fix
- I will release a security advisory and patched version
- I will credit the reporter (unless anonymity is requested)
Public Disclosure Timeline:
- Critical vulnerabilities: Disclosed after patch is released
- Non-critical vulnerabilities: Coordinated disclosure with reasonable timeline based on severity
Note: As a solo maintainer working on this project in my spare time, I appreciate your understanding regarding response and fix timelines.
Thank you for helping keep Envilder and its users safe! π