This document includes information about the vulnerability reporting, patch, release, disclosure processes, and the general security posture.

• Security Policy
  • Supported Versions
  • Security Team
  • Reporting Vulnerability
    • When Should I Report Vulnerability?
    • When Should I NOT Report Vulnerability?
    • Vulnerability Response
  • Security Release & Disclosure Process
    • Private Disclosure
    • Public Disclosure
    • Security Releases
    • Severity
  • Security Policy Updates

The following versions are currently supported and receive security updates. Release candidates will not receive security updates.

The Security Team is responsible for the overall security of the project and for reviewing reported vulnerabilities. Each member is familiar with designing secure software, security issues related to CI/CD, GitHub Actions, and build provenance.

Security Team:

• Brian McGillion (@brianmcgillion)
• Manuel Bluhm (@mbssrc)
• Henri Rosten (@henrirosten)
• Mika Tammi (@mikatammi)

Security Team membership is currently considered on a case-by-case basis.

We are grateful to security researchers and users who report vulnerabilities. The project Security Team thoroughly investigates all reports.

You can report security vulnerabilities directly (privately or publicly) to the security team by using the Report a vulnerability form, as the ghaf repository is configured with the GitHub's Security Advisories feature. For information on how to submit a vulnerability using GitHub's interface, see Privately reporting a security vulnerability.

• You think you discovered a potential security vulnerability in Ghaf.
• You are unsure how a vulnerability affects Ghaf.
• You think you discovered a vulnerability in another project that Ghaf depends on.

For projects with their own vulnerability reporting and disclosure process, report it directly there.

• You need help tuning GitHub Actions for security.
• You need help applying security-related updates.
• When the issue is currently acknowledged in Ghaf Vulnerability Reports.
• Your issue is not security-related.

Each report is acknowledged and analyzed by the Security Team within 14 days. This sets off the Security Release & Disclosure Process.

Any vulnerability information shared with the Security Team stays within the Ghaf project and will not be disseminated to other projects unless it is necessary to get the issue fixed.

We keep a reporter updated as the security issue moves from triage to identified fix, and then to release planning.

Security vulnerabilities are handled quickly and sometimes privately. The primary goal of this process is to reduce the total time users are vulnerable to publicly known exploits.

We ask that all suspected vulnerabilities be privately and responsibly disclosed through the private disclosure process outlined above. Fixes may be developed and tested by the Security Team in a temporary private fork that is private from the general public if deemed necessary.

Vulnerabilities are disclosed publicly as Security Advisories.

A public disclosure date is negotiated by the Security Team and a vulnerability reporter. We prefer to fully disclose the bug as soon as possible once a user mitigation is available. It is reasonable to delay disclosure when a bug or fix is not yet fully understood, the solution is not well-tested, or for vendor coordination. The time frame for disclosure is from immediate (especially if it is already publicly known) to several weeks. For a vulnerability with straightforward mitigation, we expect a report date to disclosure date to be on the order of 14 days.

If you know of a publicly disclosed security vulnerability, please IMMEDIATELY report the vulnerability to inform the Security Team, so they may start the patch, release, and communication process.

If possible the Security Team will ask the person making the public report if the issue can be handled via a private disclosure process. If the reporter denies the request, the Security Team will move swiftly with the fix and release process. In extreme cases, you can use GitHub to delete the issue but this generally isn not necessary and is unlikely to make a public disclosure less damaging.

Once a fix is available, it will be released and announced in the project on GitHub, releases will announced and marked as a security release and include information on which vulnerabilities were fixed. As much as possible this announcement should be actionable and include any mitigating steps users can take before upgrading to a fixed version.

Fixes will be applied in patch releases to all supported versions and all fixed vulnerabilities will be noted in the Release Notes.

The Security Team evaluates vulnerability severity on a case-by-case basis, guided by the CVSS 3.1 specification document.

Changes to this Security Policy are reviewed and approved by the Security Team.