Last updated: 10 November 2025

Hush Line is free and open-source software maintained by Science & Design, Inc. We take coordinated disclosure seriously and operate with a bias toward rapid remediation and transparency.

Notable history: Hush Line has remediated CVEs related to CSP and security headers; see CVE-2024-38522 and CVE-2024-55888 for context. These were fixed in subsequent releases.

An external security review has been supported via the Open Technology Fund program. Future independent assessments are governed by the “Independent Security Assessments” section below.

• Report channels

  • Preferred: submit via our verified Hush Line tip page (supports anonymous reporting).
  • Alternative: open a private GitHub Security Advisory draft on this repository.

• Safe harbor

  • Good-faith research, consistent with this policy and applicable law, will not be the basis for civil or criminal action initiated by us.

• Scope

  • In-scope: code and infrastructure in this repo and first-party hosted services under the hushline.app domain, including the tip submission service.
  • Out-of-scope examples: denial-of-service, rate limiting bypass without impact, speculative findings without proof-of-concept, social engineering of maintainers or users.

• Vulnerability classes we care most about

  • Authentication/authorization flaws, crypto misuse, XSS/HTML injection, CSRF, SSRF, template injection, insecure direct object reference, logic bugs affecting anonymity or confidentiality, supply-chain injection.

• What to include

  • A clear description, affected paths/versions, minimal reproducible steps or PoC, expected vs. actual behavior, impact assessment, and any logs/screens that help triage.

• Initial human response: within 3 business days.
• Triage + severity: within 7 days, we’ll assign CVSS and determine exploitability.
• Fix window (targets)
  • Critical: 7 days
  • High: 14 days
  • Medium: 30 days
  • Low: 90 days

If exploitation in the wild is detected, we may hotfix and publish advisories immediately.

We generally issue GitHub Security Advisories and, when applicable, request a CVE assignment and reference affected and fixed versions in release notes.

• Audit cadence An independent security audit will be scheduled annually, with the understanding that the actual timing of each audit will depend on the selected vendor’s availability and scheduling constraints.

• Right to assess, not a maintenance guarantee
  Science & Design, Inc. may commission independent third-party security assessments of Hush Line at its discretion, including static/dynamic testing, configuration review, threat modeling, and privacy analysis. These assessments are not guaranteed services under any maintenance agreement.

• Scope control
  Scope, methodology, data access, and test windows are defined by us to protect user privacy and service reliability. Testing that risks service stability will be isolated in staging environments unless otherwise authorized in writing.

• Deliverables & disclosure
  We may share: (a) a high-level attestation or summary; (b) a redacted report; or (c) a full report containing detailed technical findings when necessary to support transparency and verification. Public disclosure of findings follows the principles of ISO/IEC 29147:2018 — Vulnerability Disclosure and the CERT/CC Coordinated Vulnerability Disclosure framework. Findings are made public after remediation of high or critical issues and in conjunction with the publication of any related CVE or corresponding security advisory.

• No certification warranty
  Audit results are point-in-time and do not constitute a warranty of ongoing security or compliance fitness. Findings are triaged and tracked via our advisory process.

• End-to-end encryption for tip content; keys are never stored where they can be derived from plaintext submissions.
• Transport security: HTTPS/TLS enforced for all endpoints.
• Content Security Policy and security headers are enforced and regressions are treated as high severity in light of prior history.
• No plaintext secrets in code; repository and CI are scanned prior to release.

• Automated dependency updates with review.
• Build artifacts are reproducible where feasible; pinned versions for critical transitive dependencies.
• Third-party JS is minimized, integrity-checked when externally loaded, and reviewed for license and security posture.

• Mandatory code review for security-relevant changes.
• Static analysis and linters on CI; security checks run per PR.
• Secrets pre-commit hooks; forbidden patterns in CI.
• Security test coverage for authN/authZ, crypto, and request handlers under tests/.

• Managed hosting for application and databases with hardened configuration; infra-as-code defines baseline controls (network segmentation, backups, least-privilege).
• Separate staging environment for destructive testing; production changes require review and approver separation.
• Logs minimize sensitive data; retention is bounded; access is audited.

• Phases: detect → confirm → contain → eradicate → recover → learn.
• Notification: if a material security incident risks user data or anonymity, we will publish guidance and, when appropriate, in-product or site-wide notices.
• Post-mortems are written for high/critical incidents and may be public in summary form.

• Anonymous tip submission is a core requirement. We do not require PII to create an account or submit a tip. Use Tor/Onion services for additional network-layer protections when needed.

If you deploy Hush Line yourself, you are responsible for:

• TLS with modern ciphers; HSTS; robust CSP; referrer policy; frame-ancestors.
• Regular updates to OS, runtime, and dependencies.
• Strong secrets management and key rotation.
• Isolated database with minimum privileges; backups with tested restores.

Security-relevant changes are captured in releases and advisories. Review our Releases and the Security tab for patches and mitigation notes.

• Secure Disclosure: https://tips.hushline.app/to/scidsg
• Public: open a GitHub issue for non-sensitive questions