Security Vulnerability Disclosure Process#

The Security Vulnerability Disclosure Process for DBSurveyor defines how security researchers and users should report potential security vulnerabilities in the project. DBSurveyor implements a responsible disclosure process that balances the need for timely security fixes with coordinated public disclosure to protect users. The project offers three private reporting channels: GitHub Security Advisories (recommended), email reporting to security@evilbitlabs.io, and GitHub's built-in Private Vulnerability Reporting (PVR) system. Security vulnerabilities must never be reported via public GitHub issues to prevent exploitation before fixes are available.

The disclosure process follows defined timelines to ensure prompt response and resolution. Security reports receive an initial response within 48 hours, followed by a status update within 1 week detailing the investigation progress. Resolution timelines vary based on severity and complexity, with coordinated public disclosure occurring only after fixes are available and deployed.

DBSurveyor's security model is designed specifically for security-critical and air-gapped environments, with strong guarantees around offline-only operation, credential protection, and zero telemetry. The project employs proactive security measures including automated vulnerability scanning, weekly security audits, and comprehensive dependency management to prevent security issues before they occur.

Supported Versions#

DBSurveyor maintains security support for current releases only. Version 0.1.x is actively supported and receives security updates, while versions prior to 0.1 are not supported. Users should upgrade to supported versions to receive security patches and updates.

Reporting Methods#

DBSurveyor provides three confidential channels for reporting security vulnerabilities, ensuring that sensitive security information remains private during investigation and remediation.

GitHub Security Advisories (Recommended)#

The recommended reporting method uses GitHub's Security Advisories feature. To report a vulnerability, navigate to the repository's Security tab and click "Report a vulnerability." This creates a private issue visible only to repository maintainers, allowing for secure collaboration during the investigation and fix development process.

Email Reporting#

Alternatively, security vulnerabilities can be reported via email to security@evilbitlabs.io. Reports should use the subject format: [SECURITY] DBSurveyor - [Brief Description] to ensure proper routing and priority handling. For particularly sensitive reports, a PGP key is available upon request to enable encrypted communication.

Private Vulnerability Reporting (PVR)#

DBSurveyor also supports GitHub's built-in Private Vulnerability Reporting (PVR) system, which ensures complete confidentiality during the investigation phase. This GitHub feature provides an additional layer of privacy for security researchers who prefer to use GitHub's native reporting infrastructure.

Important: Public Disclosure Prohibition#

Security vulnerabilities must never be reported through public GitHub issues. Public disclosure before maintainers can develop and deploy fixes puts all users at risk by providing attackers with vulnerability details before protective measures are in place.

Required Information for Reports#

To enable effective investigation and resolution, security vulnerability reports should include comprehensive technical details. The required information includes:

1. Description: A clear, technical explanation of the vulnerability, including the nature of the security flaw and the systems or components affected.

2. Steps to Reproduce: Detailed reproduction steps that allow maintainers to verify the vulnerability. These steps should be sanitized to remove any sensitive data such as actual credentials, internal hostnames, or proprietary information.

3. Impact Assessment: An evaluation of the vulnerability's severity and potential consequences, including what data or systems could be compromised and the likely attack vectors.

4. Affected Versions: Specific version numbers or commit ranges where the vulnerability exists, helping maintainers understand the scope of the issue.

5. Proposed Fix: Any mitigation suggestions or proposed fixes, if available. While not required, suggested solutions help accelerate the remediation process.

Response Timeline#

DBSurveyor commits to defined response timelines for security vulnerability reports, ensuring that security researchers receive timely feedback and that issues are addressed promptly:

• Initial Response: The security team acknowledges receipt of vulnerability reports within 48 hours of submission. This acknowledgment confirms that the report has been received and is under review.

• Status Update: Within 1 week, maintainers provide a status update detailing the investigation progress, preliminary severity assessment, and estimated timeline for resolution.

• Resolution: The resolution timeline depends on the severity and complexity of the vulnerability. Critical issues affecting core security guarantees receive highest priority and expedited handling.

• Public Disclosure: Coordinated public disclosure occurs only after fixes are available and deployed. This approach protects existing users while ensuring the security community is informed once protective measures are in place.

Security Guarantees and Scope#

DBSurveyor's security model defines explicit guarantees and scope boundaries to help security researchers understand which vulnerabilities are considered in-scope and highest priority.

In-Scope Security Guarantees#

DBSurveyor provides the following security guarantees that form the foundation of its security model:

• Offline-Only Operation: The application makes no external network calls except to target databases. Any vulnerability that enables unauthorized network communication represents a critical security breach.

• No Telemetry: Zero data collection or external reporting occurs during operation. Vulnerabilities that leak operational data or enable telemetry violate this core guarantee.

• Credential Protection: Database credentials are never stored, logged, or included in output. Any exposure of credentials through logs, error messages, or output files is a high-priority security issue.

• Encryption: Sensitive data is protected using AES-GCM encryption with random nonces. Vulnerabilities affecting the encryption implementation or key management are critical concerns.

• Airgap Compatibility: The tool provides full functionality in completely disconnected environments. Any runtime dependencies on external resources compromise this guarantee.

Vulnerabilities affecting these security guarantees receive highest priority for investigation and remediation, as they directly impact DBSurveyor's core security value proposition.

Out-of-Scope Responsibilities#

The following security concerns are considered out-of-scope for DBSurveyor and remain the responsibility of system operators:

• Network Transport Security: TLS/SSL configuration and certificate management for database connections
• Database Server Security: Vulnerabilities or misconfigurations in the target database systems
• Host System Security: Operating system hardening, file system permissions, and access controls
• Social Engineering: User education and operational security practices

These boundaries help focus security efforts on the application's direct responsibilities while acknowledging that comprehensive security requires defense-in-depth across multiple layers.

Responsible Disclosure Expectations#

Security researchers and vulnerability reporters are expected to follow responsible disclosure practices that balance security research with user protection:

• Confidentiality: Keep all vulnerability details confidential until the issue is resolved and public disclosure is coordinated with maintainers.

• Reasonable Timeline: Allow reasonable time for investigation, fix development, testing, and deployment before public disclosure.

• Coordinated Disclosure: Work with maintainers to coordinate the timing and content of public disclosure announcements.

• Limited Exploitation: Do not exploit vulnerabilities beyond what is necessary to demonstrate the issue for reporting purposes.

These expectations create a collaborative environment where security researchers can contribute to DBSurveyor's security while protecting existing users from harm.

Security Update Release Process#

When security vulnerabilities are confirmed and fixed, DBSurveyor follows a structured release process to deliver patches to users:

Security updates are released as patch versions following semantic versioning conventions (e.g., 0.1.1, 0.1.2). This versioning scheme ensures that security patches can be applied without introducing breaking changes or requiring significant migration effort.

Critical vulnerabilities may result in immediate patch releases outside the normal release schedule. When severity warrants expedited action, maintainers prioritize rapid deployment to minimize exposure windows. Users should monitor releases and apply security patches promptly to maintain protection against known vulnerabilities.

Security Contact Information#

The following contacts are responsible for security vulnerability handling:

• Primary Email: security@evilbitlabs.io — The dedicated security team contact for all vulnerability reports and security inquiries.

• Maintainer: @... — The primary project maintainer who oversees security responses and coordinated disclosure.

• Response Commitment: All security reports receive acknowledgment within 48 hours, demonstrating the project's commitment to responsive security handling.

Security Infrastructure and Automation#

Beyond the vulnerability disclosure process, DBSurveyor implements comprehensive proactive security measures to identify and prevent vulnerabilities before they reach production.

Automated Security Scanning#

The project employs multiple automated security scanning tools that run continuously:

• CodeQL Static Analysis: Identifies potential security vulnerabilities and code quality issues through semantic code analysis.

• Syft SBOM Generation: Creates Software Bill of Materials (SBOM) for supply chain transparency and vulnerability tracking.

• Grype Vulnerability Scanning: Scans dependencies for known vulnerabilities using comprehensive vulnerability databases.

• OSSF Scorecard Integration: Tracks security posture metrics against Open Source Security Foundation best practices.

• Weekly Automated Security Audits: GitHub Actions workflows perform regular security assessments without manual intervention.

Dependency Management#

Automated dependency management helps maintain security through timely updates:

• Dependabot Configuration: Weekly automated updates for Cargo packages, GitHub Actions, and DevContainers ensure dependencies remain current.

• Daily Cargo Deny Checks: Dependency auditing runs daily to detect security advisories, license issues, and banned crates.

• Outdated Dependency Monitoring: Tracks dependencies that have available updates to facilitate timely security patching.

This multi-layered security infrastructure reduces the attack surface and helps catch potential vulnerabilities early in the development cycle.

Security Track Record#

DBSurveyor demonstrates a proactive approach to security with no publicly disclosed vulnerabilities to date. The project has no published GitHub Security Advisories (GHSA-*) or evidence of historical security incident reports, suggesting that the comprehensive preventive security measures have been effective.

The project is designed specifically for security-critical and air-gapped environments, where security requirements are particularly stringent. This security-first design philosophy, combined with extensive automated scanning and monitoring infrastructure, reflects a preventive rather than reactive security posture. The absence of disclosed vulnerabilities should not be interpreted as lack of security scrutiny, but rather as evidence of effective security engineering practices and comprehensive automated testing.

Related Topics#

• Responsible Disclosure Standards: Industry best practices for coordinating security vulnerability disclosure between researchers and maintainers.

• GitHub Security Features: Platform capabilities including Security Advisories, Private Vulnerability Reporting (PVR), and Dependabot automated dependency updates.

• Supply Chain Security: Practices for securing software dependencies through SBOM generation, vulnerability scanning, and continuous monitoring.

• Air-Gapped Environment Security: Specialized security considerations for systems operating without network connectivity or with limited external communication.

• Database Tool Security: Security requirements and threat models specific to tools that interact with sensitive database systems.

Relevant Code Files#