We release patches for security vulnerabilities. Which versions are eligible for receiving such patches depends on the CVSS v3.0 Rating:
| Version | Supported | Status |
|---|---|---|
| latest | ✅ | Active development |
| < latest | ❌ | Security fixes only for critical issues |
We take the security of soy seriously. If you have discovered a security vulnerability in this project, please report it responsibly.
Please DO NOT report security vulnerabilities through public GitHub issues.
Instead, please report them via one of the following methods:
-
GitHub Security Advisories (Preferred)
- Go to the Security tab of this repository
- Click "Report a vulnerability"
- Fill out the form with details about the vulnerability
-
Email
- Send details to the repository maintainer through GitHub profile contact information
- Use PGP encryption if possible for sensitive details
Please include the following information (as much as you can provide) to help us better understand the nature and scope of the possible issue:
- Type of issue (e.g., SQL injection, buffer overflow, access control bypass, etc.)
- Full paths of source file(s) related to the manifestation of the issue
- The location of the affected source code (tag/branch/commit or direct URL)
- Any special configuration required to reproduce the issue
- Step-by-step instructions to reproduce the issue
- Proof-of-concept or exploit code (if possible)
- Impact of the issue, including how an attacker might exploit the issue
- Your name and affiliation (optional)
- Acknowledgment: We will acknowledge receipt of your vulnerability report within 48 hours
- Initial Assessment: Within 7 days, we will provide an initial assessment of the report
- Resolution Timeline: We aim to resolve critical issues within 30 days
- Disclosure: We will coordinate with you on the disclosure timeline
We prefer all communications to be in English.
When using soy in your applications, we recommend:
-
Keep Dependencies Updated
go get -u github.com/zoobz-io/soy
-
Use Context Properly
- Always pass contexts with appropriate timeouts
- Handle context cancellation in your queries
-
Input Validation
- Validate all user inputs before passing to queries
- Use parameterized queries (soy handles this automatically)
- Never construct raw SQL from user input
-
Error Handling
- Never expose internal error details to users
- Log errors securely without leaking sensitive data
- Implement proper fallback mechanisms
-
Database Security
- Use least-privilege database accounts
- Enable SSL/TLS for database connections
- Rotate database credentials regularly
- Never commit credentials to version control
-
SQL Injection Protection
- soy uses parameterized queries via sqlx
- All user inputs are properly escaped
- ASTQL validates query structure at initialization
-
Schema Validation
- Schema validation happens at initialization via ASTQL
- Invalid queries fail fast before reaching the database
- Column and table names are validated against schema
soy includes several built-in security features:
- Type Safety: Generic types prevent type confusion attacks
- SQL Validation: ASTQL validates all queries against schema
- Parameterized Queries: All values use SQL parameters, not string concatenation
- Context Support: Built-in timeout and cancellation support
- Error Isolation: Errors are properly wrapped without leaking sensitive data
- Zero SQL Injection Risk: Query structure is validated; values are parameterized
This project uses:
- CodeQL: GitHub's semantic code analysis for security vulnerabilities
- Dependabot: Automated dependency updates
- golangci-lint: Static analysis including security linters (gosec)
- Codecov: Coverage tracking to ensure security-critical code is tested
soy is designed to prevent SQL injection by:
- Validating query structure at initialization
- Using parameterized queries for all values
- Never concatenating user input into SQL strings
soy does not implement access control - this is the responsibility of:
- Your application layer
- Database-level permissions
- Row-level security policies
- Be careful with error messages in production
- Don't log sensitive query parameters
- Implement proper audit logging at application level
- Security vulnerabilities will be disclosed via GitHub Security Advisories
- We follow a 90-day disclosure timeline for non-critical issues
- Critical vulnerabilities may be disclosed sooner after patches are available
- We will credit reporters who follow responsible disclosure practices
We thank the following individuals for responsibly disclosing security issues:
This list is currently empty. Be the first to help improve our security!
Last Updated: 2025-11-04