Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

ADR-0006: Vulnerability reporting

Note

Architecture decision: accepted.

Context and problem statement

Security vulnerabilities in Shiin could allow actions to bypass authorization, which would defeat the entire purpose of the project. The project needed a process for receiving, triaging, and fixing vulnerability reports that keeps details private until a fix is available.

Decision drivers

  • Private reporting for active vulnerabilities.
  • Clear response expectations for reporters.
  • Coordination with downstream users and integrators.
  • No requirement for reporters to create a GitHub account.

Considered options

  1. A SECURITY.md file with a private email address and a PGP key, handled under embargo.
  2. A public GitHub issue tracker only.
  3. A third-party vulnerability disclosure platform (for example, HackerOne).

Decision outcome

Chosen option: “A SECURITY.md file with private reporting”, because it is standard for Rust projects and requires no external service.

  • SECURITY.md at the repository root documents the reporting process.
  • Reports are sent to a maintainer-controlled email address.
  • Maintainers triage reports within 72 hours and respond within 7 days.
  • Fixes are coordinated with an embargo and released with a security advisory.
  • The threat model classifies bypass vulnerabilities as in-scope.

Consequences

  • Good, because the process is standard and accessible.
  • Good, because it does not depend on a third-party platform.
  • Bad, because it relies on maintainer availability for initial response.

Confirmation

  • SECURITY.md exists at the repository root and links to the vulnerability disclosure page.
  • The README links to SECURITY.md for security-relevant reports.

Pros and cons of the options

SECURITY.md with email

  • Good, because it follows Rust ecosystem conventions.
  • Good, because it requires no account or platform.
  • Bad, because it depends on maintainer email availability.

Public issue tracker only

  • Good, because all discussion is public.
  • Bad, because it discloses vulnerabilities before a fix exists.

Third-party platform

  • Good, because it provides tooling for coordination.
  • Bad, because it adds a dependency on an external service and may require accounts.

More information

The vulnerability disclosure page describes the full process. The threat model treats any bypass of a deny decision as in-scope.