Advancing HDF5 Security: New CNA Status & Digital Signatures – Glenn Song on Call the Doctor 4/7/26

Learn how The HDF Group is streamlining cybersecurity as a new CVE Numbering Authority (CNA). PSIRT Lead Glenn Song explains the new Vulnerability Disclosure Policy for HDF5, HSDS, and HDF4.

In this session of Call the Doctor, Glenn Song introduced The HDF Group’s new status as a CNA under MITRE, which covers all HDF software within their GitHub scope. This shift allows the team to maintain higher quality records and exercise more control over the disclosure process. Glenn also walked through the updated Vulnerability Disclosure Policy, emphasizing that security issues should be reported via private GitHub advisories or a dedicated security email rather than public issues.

CNA Authority Press Release: https://www.hdfgroup.org/2026/04/15/the-hdf-group-designated-as-a-cve-numbering-authority-taking-control-of-the-hdf5-vulnerability-lifecycle/
Vulnerability Disclosure Policy: https://ssp.hdfgroup.org/policy/Vulnerability_Disclosure_Policy

Topics Covered:

  • CVE Numbering Authority (CNA) scope
  • Private vulnerability reporting protocols
  • Incident response service-level objectives (SLOs)
  • Digital signatures for HDF5 integrity
  • Security-driven patch release strategies

Video Chapters

[00:00] Introduction: Glenn Song, PSIRT Lead.
[00:15] Announcement: The HDF Group as a CVE Numbering Authority (CNA).
[
01:12] Benefits of CNA status: Speed, quality, and disclosure control.
[
01:30] Navigating the new Vulnerability Disclosure Policy on the website.
[
02:22] How to report vulnerabilities: Private advisories vs. public issues.
[
03:22] Standard and Accelerated response timelines.
[
04:57] Repository-specific security policies (security.markdown).
[
05:15] Feature Update: Digital signatures for HDF5
[
06:03] Q&A: How security fixes are integrated into releases and patch releases.

Summary

The HDF Group’s transition to a CVE Numbering Authority (CNA) marks a significant milestone in its commitment to software security and community trust. By gaining the authority to assign CVE IDs directly, the organization can now bypass third-party bottlenecks, ensuring that vulnerabilities in HDF5 and related technologies are identified, tracked, and remediated with greater speed and technical accuracy.

For the user community, this provides a clear, structured pathway for responsible disclosure. The introduction of standardized response timelines—ranging from 24-hour acknowledgment for high-priority exploits to a 120-day full technical disclosure cycle—provides transparency and predictability. Furthermore, the shift toward prioritizing security-only patch releases allows the team to deliver critical fixes without the delays often associated with new feature deployments, significantly hardening the HDF5 ecosystem against emerging threats.

Transcript

  • [00:00] Glenn Song introduces herself as a software engineer and the Lead for the Product Security Incident Response Team (PSIRT) at The HDF Group.

  • [00:22] She announces that The HDF Group is now authorized by the CVE Program (under MITRE) to assign CVE IDs to vulnerabilities within their software scope, including HDF5, HDF4, HSDS, and HDFU.

  • [01:28] Glenn demonstrates where to find the new safety and security policies on the official website under the “Support” menu.

  • [02:22] Reporting Guidance: She strongly requests that users do not submit security vulnerabilities as public GitHub issues. Instead, they should use the private “draft security advisory” feature on GitHub or the new dedicated security email with the provided PGP key.

  • [03:22] Timelines: For standard issues, the goal is acknowledgement within 3 days and triage within 30 days. Full technical disclosure is targeted by day 120. An accelerated track exists for high-priority or active exploits, aiming for acknowledgement in 1 day and a fix within 7-10 days.

  • [05:15] Glenn briefly highlights an ongoing Pull Request (PR) for a new digital signature feature in HDF5.

  • [06:03] During the Q&A, it is clarified that security fixes are typically rolled into the next official release (e.g., 2.0.x or 2.1.x), but urgent vulnerabilities may trigger dedicated patch releases containing only fixes and no new features.

Leave a Comment

Your email address will not be published. Required fields are marked *


Scroll to Top