Skip to content

Security-Vulnerability-Disclosure.md

Latest commit

 

History

History
135 lines (110 loc) · 8.19 KB

Security-Vulnerability-Disclosure.md

File metadata and controls

135 lines (110 loc) · 8.19 KB
Raw

Security Vulnerability Disclosure

ECMWF software is deployed in operational forecasting chains, national meteorological services, and critical infrastructure. Security vulnerabilities must therefore be handled responsibly: reported privately, fixed before they are made public, and disclosed in a coordinated way so that downstream users can update before the details are known to potential attackers.

This procedure defines the mechanism and workflow for reporting and handling security vulnerabilities in ECMWF repositories, implementing ADR-011. It complements two existing documents and should be read alongside them:

  • The Open Source Principles, which require security to be considered from the outset and a timely response to vulnerability disclosures.
  • The ECMWF SECURITY.md policy and template (Repository Structure/SECURITY.md), which advertise to reporters how to make contact. This procedure defines what happens after contact is made.

The reporting channel is built on GitHub Private Vulnerability Reporting (PVR) and repository security advisories, which give maintainers and reporters a single private space to report, discuss, and fix a vulnerability without exposing it publicly.

Not to be confused with audit reports. Reports produced by the Codex audit skills (open-source-audit, security-audit) are internal assessments filed in the private ecmwf/repo-audits store (ADR-009). An externally reported vulnerability is a different artefact: it is handled in a private security advisory on the affected repository, following this procedure.

Scope

This procedure applies to all repositories in the ECMWF GitHub organisations (ecmwf, ecmwf-ifs, ecmwf-training).

  • Public repositories: PVR is available and must be enabled (see Enabling private vulnerability reporting). PVR is the primary reporting channel.
  • Private/internal repositories: where PVR is unavailable, the fallback channel and the draft-advisory workflow below still apply. Security issues must never be triaged in a public issue or pull request.

Principle: coordinated disclosure

A security issue is not an ordinary bug — if exposed too early it is effectively a blueprint for attackers. ECMWF follows Coordinated Vulnerability Disclosure (CVD): the initial report is made privately; the maintainer develops and validates a fix in private; and full details are only published once a patch is available, with credit to the reporter. Fixes must not be pushed to public branches or pull requests before the coordinated release, because a visible fix can reveal the vulnerability before users have updated.

Reporting channels

Primary — GitHub Private Vulnerability Reporting (PVR)

Where PVR is enabled, a reporter opens the repository's Security → Advisories page, clicks Report a vulnerability, and submits a private advisory form (title and description are mandatory; reporters are encouraged to include reproduction steps and impact). The report is visible only to the reporter and to repository administrators and security managers. PVR is independent of SECURITY.md: where it is enabled, a reporter does not need to follow the SECURITY.md contact instructions.

Fallback — SECURITY.md contact

If PVR is not available on a repository, reporters follow the contact instructions in the repository's SECURITY.md (the ECMWF Support Portal). On receiving such a report, the maintainer immediately opens a draft security advisory on the affected repository to move the discussion into a private workspace. Do not continue the exchange over unstructured channels once an advisory exists.

Enabling private vulnerability reporting

  • Organisation-wide (preferred): an organisation owner enables PVR across all public repositories so the channel is present by default, including on newly created repositories. This is the ECMWF default and should not be disabled per-repo without a documented reason.
  • Per-repository: repository owners, administrators, and security managers can enable PVR under the repository's code security settings. New public repositories provisioned via the Requesting a New Repository procedure should have PVR confirmed as enabled as part of setup.
  • Notifications: maintainers and security managers must watch each repository with Security alerts (or All Activity) selected and email notifications enabled, or private reports may go unseen. Ensuring appropriate watchers are configured is part of repository setup.

Handling a report — workflow

  1. Acknowledge and triage. A privately reported vulnerability appears in the repository's Advisories list with status Triage. Validate the report. From the advisory you can: comment to request more information from the reporter; Start a temporary private fork to begin work on a fix; or Accept and open as draft to accept it as a draft advisory. None of these actions makes the report public. Acknowledge within 5 business days and provide an initial assessment within 10 business days (matching the SECURITY.md template).
  2. Fix in private. Work in the draft security advisory and its temporary private fork. Add only trusted collaborators needed for the fix; collaborators gain read/write access to the advisory discussion and metadata. Develop and test the patch here, not on public branches.
  3. Coordinate the release. Prepare the patched release and agree a disclosure timeline (embargo) with the reporter. Where the vulnerability affects downstream ECMWF packages, coordinate the release across them. Target remediation within 90 days, shorter for actively exploited issues.
  4. Publish and disclose. Once the fix is released, publish the advisory to disclose the vulnerability to the community. On publication you can request a CVE (GitHub is a CVE Numbering Authority), and the advisory is added to the GitHub Advisory Database, which notifies downstream projects that depend on the package. Assign credit to the reporter.

Roles and responsibilities

  • Reporter (internal or external): reports privately via PVR or SECURITY.md; does not disclose publicly before the coordinated release.
  • Maintainer: triages promptly, drives the private fix, and publishes the advisory.
  • Security managers / organisation owners: ensure PVR is enabled and watchers are configured; assist with cross-repository coordination.
  • Technical Officer: owns the process for a given project and escalates as needed.
  • Head of Development: arbitrates disclosure-timeline and coordinated-disclosure decisions where a reporter and maintainer cannot agree, or where impact is broad.

Maintainer checklist

  • PVR enabled on the repository (or inherited from the organisation default).
  • SECURITY.md present and pointing reporters to the PVR channel.
  • Security managers/maintainers watching Security alerts with email enabled.
  • Report triaged promptly; reporter acknowledged.
  • Fix developed and tested in a draft advisory / temporary private fork — never in public.
  • Coordinated release prepared; embargo agreed with the reporter.
  • Advisory published, CVE requested where appropriate, and reporter credited.

References