Patch Management and Security Update Policy at Specify
Scope
This document outlines how our team manages, prioritizes, and discloses vulnerabilities in the codebase. It covers the process from vulnerability identification through remediation and disclosure. This policy applies to all engineering teams and stakeholders responsible for securing and maintaining the Specify application.
Patch Management Process
1. Review Cadence and Scope
Our primary patching cycle follows our development milestone rhythm, which occurs approximately every 3 months. At the start of each milestone, the engineering team reviews all open vulnerabilities flagged on GitHub that are labeled Critical or High severity.
These are surfaced in our internal #dev Slack channel for evaluation. Each vulnerability is assessed for its applicability, impact, and urgency. Based on this assessment, the team decides whether it will be included in the current milestone for remediation.
2. Triage and Issue Tracking
- All open security vulnerabilities are converted into internal issues.
- These issues are visible to the internal team for tracking, prioritization, and remediation planning.
- Each issue is assigned a severity rating using the following criteria:
| Severity | Definition |
|---|---|
| Critical | Unauthenticated or easily exploitable flaws leading to full compromise, data loss, or disruption. |
| High | Vulnerabilities requiring specific conditions (e.g., user interaction) but still potentially impactful. |
| Medium | Vulnerabilities that may contribute to broader attack chains or cause partial disruption. |
| Low | Minor flaws with little to no security impact, often informational. |
3. Remediation and Engineering Ownership
- Once included in a milestone, vulnerabilities are assigned to a developer for remediation.
- The assigned owner is responsible for:
- Proposing a fix.
- Estimating the level of effort.
- Coordinating the implementation within the milestone timeline.
- The patch is reviewed by a designated peer for validation.
4. Verification and Release Notes
- Upon merging a fix, the vulnerability is marked as resolved in GitHub.
- The fix is verified and tested to ensure it fully addresses the issue.
- A summary of fixed vulnerabilities is included in the release notes immediately upon release.
- We do not delay disclosure post-patch unless there is an ongoing risk to unpatched systems.
5. Disclosure Timeline
We follow a principle of responsible and timely disclosure:
- Vulnerabilities are publicly acknowledged in the release notes as soon as they are patched.
- Critical vulnerabilities may be accompanied by a GitHub Security Advisory if the scope of impact warrants a formal notification.
- We do not publicly disclose detailed technical information or proof-of-concept exploits until a reasonable portion of users have had a chance to upgrade.
Responsibilities
Engineering Team
- Maintain visibility on GitHub vulnerabilities.
- Ensure review cadence occurs at each milestone.
- Define severity ratings and confirm remediation scope.
- Propose and implement fixes within milestone timelines.
- Collaborate with the rest of the team for review and testing.
- Provide effort estimates when triaging new vulnerabilities.
Summary
- Milestone-based review every ~3 months.
- Focused on Critical and High vulnerabilities.
- Open issues tracked internally.
- Immediate release note inclusion for all fixed vulnerabilities.
- Public disclosure follows a responsible, risk-based timeline.