Security Policy

Reporting a vulnerability

If you discover a security vulnerability in Buglyst, please report it responsibly. Do not open a public GitHub issue or post it publicly.

Email your findings to security@buglyst.com. Include:

• A clear description of the vulnerability.
• Steps to reproduce it.
• The potential impact (data exposure, privilege escalation, etc.).
• Your suggested fix if you have one.

Current product safeguards

• Practice and assessment checks run in controlled, isolated server-side or managed sandbox environments with bounded execution.
• Hidden validation checks and solution material are kept on trusted server surfaces and are not included in public challenge payloads.
• Hiring workspaces, candidate reports, invitations, and reviewer actions use organization and role boundaries.
• Private GitHub or private-code workflows are controlled pilots only when enabled. Repository, commit, and path scope require explicit organization approval; they are not public self-service.
• Operational rate limits, audit records, secret scanning, and fail-closed feature flags protect sensitive or paid workflows.

These controls describe the current product scope. Buglyst does not claim a security certification or guarantee that the service is free of vulnerabilities.

What to expect

• We aim to acknowledge a complete report within 3 business days.
• We will triage confirmed findings by severity, impact, and the safety of the required remediation. Resolution time depends on that assessment.
• We will notify you when the issue is resolved and credit you in the changelog if you wish.

Safe harbour

Security research conducted in good faith is welcome. If you follow the limits below, we will treat the report as authorized for our internal triage and will not initiate a complaint solely because of that good-faith research. This statement cannot bind third parties or override applicable law.

• Report vulnerabilities promptly and do not exploit them beyond proof of concept.
• Do not access, modify, or destroy other users' data.
• Do not perform denial-of-service attacks or disruptive testing on production.
• Do not publicly disclose details before we have had a reasonable time to respond.

Testing against your own locally running instance is always fine and preferred.

Out of scope

• Attacks against the production service (DoS, brute force, scanning).
• Social engineering of team members.
• Vulnerabilities in third-party services we depend on (report those upstream).
• Rate-limit bypasses that do not result in meaningful data exposure.