Document Version: 1.0 Last Updated: 2025-12-11 Classification: Public Applicable Standards: ISO 27001, OWASP, CISA

pg_tviews takes security seriously and welcomes responsible disclosure of security vulnerabilities. This policy outlines how to report security issues, our response process, and how we handle security updates.

Note: Only the latest minor version in the 0.1.x series receives security updates.

DO NOT open public GitHub issues for security vulnerabilities.

1. GitHub Security Advisories (Preferred):

   • Go to: https://github.com/your-org/pg_tviews/security/advisories
   • Click "Report a vulnerability"
   • Provide details including:
     • Affected version(s)
     • Steps to reproduce
     • Potential impact
     • Suggested fix (optional)

2. Email (Alternative):

   • Send to: security@your-domain.com
   • Use PGP key: 9E57E2899574FA24DB1F1651C8FCB4AB8FDB6DB4
   • Include same details as above

• Description: Clear description of the vulnerability
• Impact: What an attacker could achieve
• Affected Versions: Which versions are vulnerable
• Reproduction Steps: How to reproduce the issue
• Environment: PostgreSQL version, OS, etc.
• Mitigations: Any workarounds you've identified

We follow a coordinated disclosure process:

• Confirm receipt of report
• Assign severity level
• Provide initial assessment timeline

• Reproduce the issue
• Assess full impact and exploitability
• Determine affected versions
• Develop fix or mitigation

• Critical/High: Fix within 7-14 days
• Medium: Fix in next minor release
• Low: Fix in next maintenance cycle

• Publish security advisory
• Update release notes
• Notify users via appropriate channels

• Remote code execution
• SQL injection with system access
• Authentication bypass
• Data exfiltration at scale

Response: Immediate hotfix within 24-48 hours

• Privilege escalation
• Significant data leakage
• Denial of service affecting production
• Supply chain compromise

Response: Patch within 7 days

• Information disclosure
• Limited denial of service
• Cross-tenant data access
• Configuration issues

Response: Fix in next minor release (30 days)

• Minor information leaks
• Edge case vulnerabilities
• Performance issues
• Cosmetic security issues

Response: Address in maintenance cycle

Security fixes follow this process:

1. Development: Fix developed on private branch
2. Testing: Full regression testing + security testing
3. Review: Security review by maintainers
4. Release: Simultaneous release of fix and advisory
5. Communication: User notification via multiple channels

• GitHub Security Advisories: Official security notices
• Release Notes: Security fixes highlighted
• Changelog: Detailed change descriptions
• Email: Direct notification for critical issues (future)

Security releases use this scheme:

• Patch releases: 0.1.2 → 0.1.3
• Security patches: Include "Security" in release title
• Breaking changes: May require minor version bump

We follow industry best practices for coordinated disclosure:

1. Private Investigation: Work with reporter privately
2. Fix Development: Develop and test fix
3. Vendor Coordination: Coordinate with downstream users
4. Public Release: Simultaneous release of fix and advisory
5. Post-Mortem: Analysis and prevention improvements

• Security researchers receive credit in advisories
• Contributors acknowledged in release notes
• Hall of fame for significant contributions (future)

Currently, pg_tviews does not offer monetary rewards for security research. However:

• Public recognition and thanks
• Priority consideration for future rewards program
• Invitation to contribute to security improvements

1. Keep Updated: Use latest patch versions
2. Monitor Advisories: Subscribe to security notifications
3. Validate Downloads: Verify signatures and checksums
4. Secure Configuration: Follow security guidelines
5. Report Issues: Use private reporting channels

1. Security Reviews: All changes undergo security review
2. Dependency Scanning: Automated vulnerability detection
3. Code Standards: Follow secure coding practices
4. Testing: Comprehensive security testing
5. Documentation: Security implications documented

In case of security breach:

1. Immediate Response: Isolate affected systems
2. Assessment: Determine scope and impact
3. Notification: Inform affected users within 72 hours
4. Recovery: Provide remediation guidance
5. Prevention: Implement preventive measures

• Data Protection: GDPR, CCPA compliance for user data
• Notification Laws: Applicable breach notification requirements
• Documentation: Incident logs and response records

• Primary Contact: Lionel Hamayon (Project Lead)
• Email: security@your-domain.com
• PGP Key: 9E57E2899574FA24DB1F1651C8FCB4AB8FDB6DB4
• Response Time: Within 48 hours

• Issues: https://github.com/your-org/pg_tviews/issues
• Discussions: https://github.com/your-org/pg_tviews/discussions
• Documentation: https://github.com/your-org/pg_tviews/docs

We track and publish:

• Mean time to patch vulnerabilities
• Number of security advisories per quarter
• Audit coverage percentage
• Security test pass rates

This security program evolves based on:

• Industry best practices
• Regulatory requirements
• Community feedback
• Incident lessons learned

• Bug bounty program
• Security mailing list
• Automated security scanning
• Third-party security audits
• Security training materials

Document Control:

• Author: Lionel Hamayon
• Reviewers: Project Contributors
• Next Review: 2026-06-11
• Distribution: Public