HDF5 Library and File Format

本サイトが提示する下記のベストプラクティスを実行するプロジェクトは、Open Source Security Foundation (OpenSSF) バッジを達成したことを自主的に自己認証し、そのことを外部に示すことができます。

ソフトウェアに欠陥や脆弱性がないことを保証する手立てはありません。形式論的な証明ができたとしても、仕様や前提が間違っていると誤動作の可能性があります。また、プロジェクトが健全で、かつ機能的な開発コミュニティであり続けることを保証する手立てもありません。しかし、ベストプラクティスの採用は、プロジェクトの成果の向上に寄与する可能性があります。たとえば、いくつものベストプラクティスがリリース前の複数人によるレビューを定めていますが、それによりレビュー以外では発見困難な技術的脆弱性を見つけるのを助け、同時に異なる企業の開発者間の信頼を築き、さらに交流を続けることに対する意欲を生んでいます。バッジを獲得するには、すべてのMUSTおよびMUST NOT基準を満たさなければなりません。すべてのSHOULD基準も満たさなければなりませんが、正当な理由がある場合は満たさなくても構いません。そしてすべてのSUGGESTED基準も満たさなければなりませんが、満たさないとしても、少なくとも考慮することが望まれます。フィードバックは、 GitHubサイトのissueまたはpull requestとして提示されれば歓迎します。また、議論のためのメールリストも用意されています。

私たちは多言語で情報を提供していますが、翻訳版に矛盾や意味の不一致がある場合は、英語版を正式な記述とします。
これがあなたのプロジェクトなら、あなたのプロジェクトページにあなたのバッジステータスを表示してください！バッジステータスは次のようになります。 プロジェクト 7802 のバッジ レベルは in_progress です バッジステータスの埋め込み方法は次のとおりです。
バッジステータスを表示するには、あなたのプロジェクトのマークダウンファイルに以下を埋め込みます
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/7802/badge)](https://www.bestpractices.dev/projects/7802)
あるいは、以下をHTMLに埋め込みます
<a href="https://www.bestpractices.dev/projects/7802"><img src="https://www.bestpractices.dev/projects/7802/badge"></a>


これらは合格レベルの基準です。シルバーまたはゴールドレベル基準を表示することもできます。

        

 基本的情報 13/13 ●

  • 識別情報

    他のプロジェクトが同じ名前を使用していないか注意してください。

    Official HDF5® Library Repository

    どのようなプログラミング言語を使ってプロジェクトを実装していますか？
    複数の言語がある場合は、コンマを区切り（スペースを入れてもよい）としてリストし、使用頻度の高いものから順に並べます。使用言語が多くある場合は、少なくとも最初の3つの最も多く使われるものをリストアップしてください。言語がない場合（例：ドキュメントだけ、またはテスト専用のプロジェクトの場合）、1文字 " - "を使用します。言語ごとにある大文字・小文字の慣用を踏襲してください（例：「JavaScript」）。
    Common Platform Enumeration（CPE）は、情報技術（IT）システム、ソフトウェア、およびパッケージのための構造化された命名体系です。脆弱性を報告する際に、多くのシステムやデータベースで使用されています。

  • 基本的なプロジェクト ウェブサイトのコンテンツ


    バッジには十分です！

    プロジェクトのウェブサイトは、ソフトウェアが何をするのか（何の問題を解決するのか）を簡潔に記述しなければなりません。 [description_good]
    これは、潜在的なユーザーが理解できる言語でなければなりません（例えば、それは最小限の専門用語を使用します）。

    The README.md file succinctly describes what HDF5 does and what problem it solves:

    1 Primary Description

    The README states:

    • "This repository contains a high-performance library's source code and a file format specification that implements the HDF5® data model. The model has been adopted across many industries, and this implementation has become a de facto data management standard in science, engineering, and research communities worldwide."

    2 This clearly describes:

    • What it does: Provides a high-performance library and file format for data management
    • What problem it solves: Data management and storage needs in science, engineering, and research
    • Its significance: De facto standard adopted across many industries

    Reference: README.md

    3 Additional Context

    The README also directs users to The HDF Group's website for more information:


    バッジには十分です！

    プロジェクトのウェブサイトは、取得方法、フィードバックの提供方法（バグ報告や拡張機能）、ソフトウェアへの貢献方法に関する情報を提供しなければなりません。 [interact]

    1 How to Obtain the Software

    The README includes multiple sources for obtaining HDF5:

    Reference: README.md#snapshots-previous-releases-and-source-code

    2 How to Provide Feedback (Bug Reports and Enhancements)

    The README provides clear channels for feedback:

    Reference: README.md#help-and-support and README.md#forum-and-news

    3 How to Contribute

    While not detailed in README.md itself, the repository contains a comprehensive CONTRIBUTING.md file that explains the contribution process in detail. URL: https://github.com/HDFGroup/hdf5/blob/develop/README.md The project website (accessible through the links in README.md) provides all necessary information for obtaining, providing feedback, and contributing to the software.


    バッジには十分です！

    貢献する方法に関する情報は、貢献プロセス（たとえばプル リクエストが使用されか、など）を説明する必要があります。 (URLが必要です) [contribution]
    別段の記載がない限り、GitHub上のプロジェクトは、（GitHubが提供する）課題管理とプルリクエストを使用することを想定します。この情報は不足しているかもしれません。すなわち、プロジェクトがプルリクエストと課題追跡ツールを使うことか、メーリングリストへの投稿を言及している。（どちら？）

    Reference: https://github.com/HDFGroup/hdf5/blob/develop/CONTRIBUTING.md The file clearly explains that pull requests are the mechanism for contributions and provides comprehensive process documentation.


    バッジには十分です！

    貢献する方法に関する情報は、貢献を受け入れるための要件（たとえば、必要なコーディング標準への参照）を含むべきです。 (URLが必要です) [contribution_requirements]

    Reference: CONTRIBUTING.md#checklist-for-contributors URL: https://github.com/HDFGroup/hdf5/blob/develop/CONTRIBUTING.md

    The file comprehensively addresses coding standards, development conventions, and contribution requirements throughout multiple sections. Specifically:

    1 Development Conventions Section

    This section documents required coding standards, including:

    • Code organization (public, private, package visibility levels)
    • Function naming conventions (H5Xfoo(), H5X_foo(), H5X__foo())
    • Function structure requirements (entry/exit macros, error handling)
    • Error handling conventions
    • Platform independence requirements
    • Memory management standards

    Reference: CONTRIBUTING.md#development-conventions

    2 Acceptance Criteria Section

    This section explicitly lists requirements for pull requests:

    • Clear purpose
    • Proper documentation
    • Testing requirements
    • Compatibility requirements (100% backward compatibility, machine independence, binary compatibility)
    • Documentation standards (Doxygen, CHANGELOG.md)

    Reference: CONTRIBUTING.md#acceptance-criteria

    3 Checklist for Contributors Section

    Provides a verification checklist covering:

    • Code conventions (naming, portability, structure)
    • Documentation requirements
    • Testing requirements

  • FLOSSライセンス

    プロジェクトのライセンスはどのようなものですか？
    SPDXライセンスの表現形式を使用してください。 例：「Apache-2.0」、「BSD-2-Clause」、「BSD-3-Clause」、「GPL-2.0+」、「LGPL-3.0+」、「MIT」、「(BSD-2-Clause OR Ruby)」。一重引用符または二重引用符を含めないでください。


    バッジには十分です！

    プロジェクトによって作成されたソフトウェアは、FLOSSとしてリリースされなければなりません。 [floss_license]
    FLOSSは、オープンソース定義またはフリーソフトウェア定義を満たす方法でリリースされたソフトウェアです。そのようなライセンスの例としては、CC0、MIT、2項型BSD、 3項型BSD、 Apache 2.0 、Less GNU General Public License（LGPL）、および GNU General Public License（GPL）を参照してください。私たちの目的のためには、これはライセンスが以下のものでなければならないことを意味します： ソフトウェアは他の方法でライセンスされているかもしれません（たとえば、「GPLv2またはプロプライエタリ」は許容されます）。

    https://github.com/HDFGroup/hdf5/blob/develop/LICENSE The BSD-3-Clause license is approved by the Open Source Initiative (OSI).


    バッジには十分です！

    プロジェクトによって作成されたソフトウェアに必要なライセンスは、オープンソース・イニシアチブ（OSI）によって承認されていることが推奨されています。 [floss_license_osi]
    OSIは、厳格な承認プロセスを使用して、どのライセンスがOSSであるかを判断します。

    https://opensource.org/license/bsd-3-clause The BSD-3-Clause license is approved by the Open Source Initiative (OSI).


    バッジには十分です！

    プロジェクトは、結果のライセンスをソースリポジトリの標準的な場所に投稿しなければなりません。 (URLが必要です) [license_location]
    たとえば、LICENSEまたはCOPYINGという名前の最上位ファイルです。ライセンスファイル名の後に ".txt" や ".md" などの拡張子を付けることができます。別の規則は、ライセンスファイルを含むLICENSESという名前のディレクトリを持つことです。これらのファイルは通常、 REUSE仕様で説明されているように、SPDXライセンス識別子とそれに続く適切なファイル拡張子として名前が付けられます。この基準は、ソースリポジトリの要件にすぎないことに注意してください。ソースコード（実行可能ファイル、パッケージ、コンテナなど）から何かを生成するときに、ライセンスファイルを含める必要はありません。たとえば、Comprehensive R Archive Network（CRAN）のRパッケージを生成するときは、標準のCRANプラクティスに従います。ライセンスが標準ライセンスの場合は、標準の短いライセンス仕様を使用して（テキストのコピーをさらにインストールしないようにするため）、リストします。 .Rbuildignoreなどの除外ファイル内のLICENSEファイル。同様に、Debianパッケージを作成する場合、著作権ファイルに /usr/share/common-licenses のライセンス テキストへのリンクを配置し、作成したパッケージからライセンス ファイルを除外できます（たとえば、dh_auto_installを呼び出した後にファイルを削除します ）。可能な場合は、生成された形式で機械可読ライセンス情報を含めることをお勧めします。

    The project posts its license in the standard location:


  • ドキュメンテーション


    バッジには十分です！

    プロジェクトは、プロジェクトによって作成されたソフトウェアに関する基本的なドキュメンテーションを提供しなければなりません。 [documentation_basics]
    このドキュメントは、インストール方法、起動方法、使用方法（可能であれば例示したチュートリアル）、および、そのソフトウェアの適切なトピックであれば安全に使用する方法（たとえば何をするべきで、何をすべきでないか）を記述し、メディア（たとえば、テキストやビデオなど）に収められている必要があります。セキュリティの文書は必ずしも長文である必要はありません。プロジェクトは、ドキュメンテーションとしてプロジェクト以外の素材へのハイパーテキストリンクを使用してもよいです。プロジェクトがソフトウェアを作成しない場合は、「該当なし」（N / A）を選択します。

    The project provides comprehensive basic documentation through multiple channels:

    • README.md - Quick Start Documentation

    1 The README.md file in the repository root provides essential documentation, including:

    • What the software does (high-performance data management library)
    • How to obtain the software
    • Where to get help and support
    • Release information
    • Reference: README.md

    2 Installation Documentation

    The release_docs/ directory contains detailed installation and usage instructions:

    • INSTALL - General compilation and installation instructions
    • INSTALL_CMAKE - CMake-specific build instructions
    • INSTALL_Windows and INSTALL_Cygwin - Platform-specific installation
    • README_HPC.md - HPC system configuration
    • USING_HDF5_CMake - Building applications with HDF5
    • USING_CMake_Examples - Building and testing examples

    Reference: release_docs/

    3 CONTRIBUTING.md - Development Documentation

    Comprehensive guide for developers covering:

    • How to build for development
    • Source code organization
    • Development conventions and coding standards
    • Testing procedures

    Reference: CONTRIBUTING.md

    4 Online Documentation

    The README.md directs users to comprehensive online documentation:

    5 API Documentation

    • Doxygen documentation: The project includes Doxygen markup in public headers for API documentation
    • The doxygen/ directory contains Doxygen build files for generating API documentation

    6 CHANGELOG.md

    The release_docs/CHANGELOG.md file documents:

    • Changes from release to release
    • New features
    • Bug fixes
    • Known problems

    Reference: release_docs/CHANGELOG.md URL: https://github.com/HDFGroup/hdf5/blob/develop/README.md The project provides extensive basic documentation both in the repository (README, INSTALL files, CONTRIBUTING guide) and online (comprehensive API documentation and user guides).


    バッジには十分です！

    プロジェクトは、プロジェクトによって作成されたソフトウェアの外部インタフェース（入力と出力の両方）を記述する参照ドキュメントを提供しなければなりません。 [documentation_interface]
    外部インターフェイスのドキュメントは、エンドユーザーまたは開発者に、その使用方法を説明します。ドキュメントには、ソフトウェアにアプリケーション プログラム インターフェイス（API）が含まれている場合、アプリケーション プログラム インターフェイスが含まれます。ライブラリの場合、呼び出すことができる主要なクラス/型とメソッド/関数を文書化します。ウェブ アプリケーションの場合、URLインタフェース（多くの場合、RESTインタフェース）を定義します。コマンドラインインターフェイスの場合は、サポートするパラメータとオプションを文書化します。多くの場合、ドキュメントのほとんどを自動生成すると、ソフトウェアが変更されたときにドキュメントがソフトウェアと同期したままなので、最も良い方法ですが、これは必須ではありません。プロジェクトは、ドキュメンテーションとしてプロジェクト以外の素材へのハイパーテキストリンクを使用してもよいです。ドキュメンテーションは自動的に生成されるかもしれません（実際的に、しばしばこれを行う最良の方法です）。 RESTインタフェースのドキュメントは、Swagger / OpenAPIを使用して生成することができます。コード インタフェースのドキュメントは、 JSDoc （JavaScript）、 ESDoc （JavaScript）、pydoc（Python）、devtools (R)、pkgdown (R)、およびDoxygen（多数）のいずれかです。実装コードにコメントがあるだけでは、この基準を満たすには不十分です。すべてのソースコードを読むことなく情報を見るための簡単な方法が必要です。プロジェクトがソフトウェアを作成しない場合は、「該当なし」（N/A）を選択します。

    The project provides comprehensive reference documentation describing the external interface (both input and output):

    1 Doxygen-Documented Public API Headers

    All public API functions are documented with Doxygen markup in the public header files. These include detailed descriptions of:

    * Input parameters: Each parameter is documented with \param[in], \param[out], or \param[in,out] tags
* Return values: Documented with \return tags
* Detailed descriptions: Comprehensive \details sections explaining function behavior
* Code examples: Many functions include \par Example sections
* Version information: \since tags indicating when functions were introduced

    2 Online Reference Documentation

    The README.md directs users to comprehensive online API reference documentation:

    * Latest HDF5 API Documentation: https://support.hdfgroup.org/documentation/hdf5/latest
* This is generated from the Doxygen markup in the source code

    Reference: README.md#documentation

    3 Complete API Coverage

    Public API headers covering all major functionality

    4 Doxygen Build System

    The project includes a complete Doxygen build system in the doxygen/ directory for generating reference documentation from the annotated source code. URL: https://support.hdfgroup.org/documentation/hdf5/latest The project provides extensive reference documentation with detailed input/output specifications for all public API functions, both in the source code (Doxygen comments) and in published online documentation.


  • その他


    バッジには十分です！

    プロジェクトサイト（ウェブサイト、リポジトリ、およびダウンロードURL）は、TLSを使用したHTTPSをサポートしなければなりません。 [sites_https]
    これには、プロジェクトのホームページのURLとバージョン管理リポジトリのURLが「http：」ではなく「https：」で始まる必要があります。Let's Encryptからフリーの証明書を入手できます。プロジェクトは、（例えば） GitHubページ、 GitLabページ、またはSourceForgeプロジェクトページを使ってこの基準を実装してもよいです。HTTPをサポートしている場合は、HTTPトラフィックをHTTPSにリダイレクトすることを強くお勧めします。

    All project sites support HTTPS using TLS:

    1 Project Website

    Reference from README.md and CONTRIBUTING.md

    2 Source Code Repository

    The GitHub repository uses HTTPS:

    Reference: README.md#snapshots-previous-releases-and-source-code

    3 Download URLs

    All download locations use HTTPS:

    Reference: README.md

    4 Help and Support URLs

    Support sites use HTTPS:

    Reference: README.md#help-and-support

    5 License URL

    License information uses HTTPS:

    Referenced throughout source code files and CONTRIBUTING.md URL: All project URLs use HTTPS (see above) All project sites, repositories, and download locations exclusively use HTTPS with TLS encryption.


    バッジには十分です！

    プロジェクトは、議論（提案された変更や問題を含む）のための1つ以上の検索可能なメカニズムを持たなければならず、メッセージやトピックがURLでアドレス指定され、新しい人々がディスカッションのいくつかに参加できるようにしなければならず、クライアント側でプロプライエタリなソフトウェアのインストールを必要としないようにします。 [discussion]
    受け入れ可能なメカニズムの例には、アーカイブされたメーリングリスト、GitHubのイシューとプルリクエストの議論、Bugzilla、Mantis、Tracなどがあります。非同期ディスカッション メカニズム（IRCなど）は、これらの基準を満たしていれば許容されます。 URLアドレス可能なアーカイブ機構があることを確認してください。独自のJavaScriptは、推奨されませんが、許可されています。

    The project has multiple mechanisms for discussion that meet all the requirements:

    1 GitHub Issues

    The project uses GitHub Issues for bug reports, feature requests, and discussions:

    • URL: https://github.com/HDFGroup/hdf5/issues
    • Searchable: Yes, GitHub provides full search functionality
    • Addressable by URL: Yes, each issue has a unique URL
    • Open participation: Yes, anyone with a GitHub account can participate
    • No proprietary software: GitHub is accessible via web browser

    Reference: CONTRIBUTING.md#contributing-changes states "Open a GitHub issue (https://github.com/HDFGroup/hdf5/issues)"

    2 HDF Forum

    The project provides a public forum for discussions:

    Reference: README.md#forum-and-news states "The HDF Forum is provided for public announcements, technical questions, and discussions of interest to the general HDF5 Community."

    3 GitHub Pull Request Discussions

    Pull requests enable threaded discussions about proposed changes:

    • URL: https://github.com/HDFGroup/hdf5/pulls
    • Searchable: Yes
    • Addressable by URL: Yes, each PR has a unique URL
    • Open participation: Yes, anyone can comment on public PRs
    • No proprietary software: Web browser access only

    Reference: CONTRIBUTING.md#contributing-changes describes the pull request workflow URL: https://github.com/HDFGroup/hdf5/issues and https://forum.hdfgroup.org All mechanisms are searchable, URL-addressable, open to new participants, and accessible via web browsers without proprietary software installation.


    バッジには十分です！

    プロジェクトは英語で文書を提供し、英語でコードに関するバグ報告とコメントを受け入れることができるべきです。 [english]
    現在、英語はコンピュータ技術のリンガ フランカです。英語をサポートすることで、世界中のさまざまな潜在的な開発者とレビュアーの数を増やします。コア開発者の主要言語が英語でなくても、プロジェクトはこの基準を満たすことができます。

    The project provides documentation in English and accepts bug reports and comments in English:

    1 Documentation in English All project documentation is written in English:

    • README.md - Written in English
    • CONTRIBUTING.md - Written in English
    • LICENSE - Written in English
    • INSTALL files in release_docs/ - Written in English
    • CHANGELOG.md - Written in English
    • API documentation at https://support.hdfgroup.org/documentation/hdf5/latest - Written in English
    • Code comments and Doxygen documentation in source files - Written in English

    Reference: All documentation files in the repository

    2 Bug Reports in English

    The project accepts bug reports in English through multiple channels:

    Reference: README.md#help-and-support states "The HDF Group staffs a free Help Desk accessible at https://help.hdfgroup.org" Reference: CONTRIBUTING.md#contributing-changes states "Open a GitHub issue" for reporting bugs

    3 Code Comments in English

    All code comments, function documentation, and discussions in pull requests are conducted in English:

    • Source code comments - English
    • Doxygen annotations in header files - English
    • Pull request discussions - English
    • Commit messages - English

    Reference: Source code files like src/H5Dpublic.h contain English documentation URL: https://github.com/HDFGroup/hdf5/blob/develop/README.md The project provides comprehensive documentation in English and accepts bug reports and code comments in English through GitHub Issues, the Help Desk, and the HDF Forum.


    バッジには十分です！

    プロジェクトはメンテナンスされている必要があります。 [maintained]
    少なくとも、プロジェクトは重大な問題と脆弱性の報告に対応するように努める必要があります。バッジを積極的に追求しているプロジェクトは、おそらくメンテナンスされているでしょう。すべてのプロジェクトや人のリソースには限りがあり、提案された変更をプロジェクトが拒否しなければならないこともあるため、リソースに限りがあることや、提案が拒否されることが、メンテナンスされていないプロジェクトを示すわけではありません。

    プロジェクトが今後メンテナンスされなくなることがわかった場合は、この基準を「不適合（Unmet）」に設定し、適切なメカニズムを使用して、メンテナンスされないことを人々に示す必要があります。たとえば、READMEの最初の見出しに「DEPRECATED」（将来のサポートが保証されないので使用すべきでない）を使用し、ホームページの先頭近くに「DEPRECATED」を追加し、コード リポジトリのプロジェクトの説明の先頭に「DEPRECATED」を追加し、そのREADMEおよび/またはホームページにno-maintenance-intendedバッジを追加し、すべてのパッケージ リポジトリでdeprecated（非推奨）としてマークしたり（例： npm deprecate ）、コード リポジトリのマーキングシステムを使用してアーカイブします（例：GitHubの"archive" 設定、GitLabの"archived" マーキング、 Gerritの "readonly" ステータス、またはSourceForgeの"abandoned" プロジェクト ステータス）。詳細な説明については、こちらを参照してください。

    The project is actively maintained:

    1 Recent Commit Activity

    The git status shows recent commits to the develop branch (as of 12/25):

    2 Active CI/CD System

    README.md shows multiple active CI/CD badges indicating continuous testing:

    • develop cmake build status
    • HDF5 develop daily build
    • netCDF build status
    • h5py build status
    • CVE regression testing
    • HDF5 VOL connectors build status
    • HDF5 VFD build status
    • Link checker status

    Reference: README.md displays active build status badges

    3 Active Issue and Pull Request System

    The project uses GitHub Issues and Pull Requests for ongoing maintenance:

    4 Ongoing Development Roadmap

    README.md shows active development with planned features:

    • Major update on March 10, 2025 (CMake-only builds)
    • Future roadmap includes: Multi-threaded HDF5, crashproofing, Full SWMR, encryption, etc.

    Reference: README.md states "HDF5 version 2.0.1 currently under development"

    5 Dedicated Maintainer

    The HDF Group is the official maintainer:

    Reference: README.md states "The HDF Group is the developer, maintainer, and steward of HDF5 software"

    6 Regular Release Schedule

    README.md describes the release approach:

    • "HDF5 does not follow a regular release schedule. Instead, updates are based on the introduction of new features and the resolution of bugs. However, we aim to have at least one annual release for each maintenance branch."
    • Release progress badge shows active release planning

    URL: https://github.com/HDFGroup/hdf5 The project is actively maintained by The HDF Group with recent commits, active CI/CD, ongoing issue resolution, and planned future development.





 変更管理 9/9 ●

  • 公開されたバージョン管理ソースリポジトリ


    バッジには十分です！

    プロジェクトには、公開され、URLを持つ、バージョン管理のソース リポジトリがなければなりません。 [repo_public]
    URLはプロジェクトのURLと同じであってもよいです。プロジェクトは、変更が公開されていない間に（例えば、公開前に脆弱性を修正するため）、特定のケースでプライベート（非公開）ブランチを使用することができます。

    The project has a version-controlled source repository that is publicly readable with a URL:

    1 Version Control System

    The project uses Git for version control:

    • The environment information shows: "Is directory a git repo: Yes"
    • Git commit history is available, showing recent commits with hashes (bd76ec789a, b986a34474, 5e2a73d542, etc.)

    2 Publicly Readable Repository

    The repository is hosted on GitHub and is publicly accessible:

    Reference: README.md#getting-the-source-code states "Development code is available at our Github location: https://github.com/HDFGroup/hdf5.git" Reference: CONTRIBUTING.md#getting-the-source-code provides instructions: "git clone https://github.com/HDFGroup/hdf5.git cd hdf5"

    3 Public Access to All Branches

    Multiple branches are publicly accessible:

    • develop branch (main development branch)
    • Various release branches (hdf5_1_14, etc.)
    • All commit history is publicly visible

    Reference: Git status shows "Current branch: develop" and "Main branch (you will usually use this for PRs): develop"

    4 Web Interface

    GitHub provides a web interface for browsing the repository:

    URL: https://github.com/HDFGroup/hdf5 The project has a publicly readable Git repository hosted on GitHub with full version control history accessible to everyone.


    バッジには十分です！

    プロジェクトのソース リポジトリは、どのような変更が行われたのか、誰が変更を行ったのか、いつ変更が行われたのかを追跡しなければなりません。 [repo_track]

    The project's Git repository tracks what changes were made, who made the changes, and when the changes were made:

    1 What Changes Were Made

    Git tracks all file modifications, additions, and deletions:

    • Commit messages describe changes (e.g., "Improved usage information (#6070)", "Minor optimizations of r-tree implementation (#6039)")
    • Diff information shows exact code changes
    • Git log shows complete history of modifications

    2 Who Made the Changes

    Git tracks author information for every commit:

    • CONTRIBUTING.md references git log command to see commit authorship
    • Git commit format includes author name and email
    • CONTRIBUTING.md mentions checking authorship with: "git log -1 --format='%an %ae'"

    Reference: CONTRIBUTING.md#committing-changes-with-git states "Before amending: ALWAYS check authorship (git log -1 --format='%an %ae')"

    3 When Changes Were Made

    Git tracks timestamps for all commits:

    • Each commit has a timestamp
    • File listing shows modification dates (e.g., "Nov 11 22:02" for LICENSE file)
    • Git log shows the complete temporal history
    • CONTRIBUTING.md describes using git log to see recent commit history

    Reference: The bash output showed "Nov 11 22:02" timestamp for the LICENSE file

    4 Version Control Best Practices

    The project follows Git best practices:

    • Detailed commit messages with issue references (#6070, #6075, etc.)
    • Pull request workflow that preserves change history
    • Branch strategy documented in CONTRIBUTING.md
    • Co-authored commits supported (CONTRIBUTING.md shows "Co-Authored-By: Claude noreply@anthropic.com" format)

    Reference: CONTRIBUTING.md#committing-changes-with-git provides detailed Git workflow instructions

    5 Public Access to History

    All change history is publicly accessible:

    URL: https://github.com/HDFGroup/hdf5/commits/develop The Git repository fully tracks what changes were made (commit diffs and messages), who made them (author information), and when they were made (commit timestamps). Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.


    バッジには十分です！

    共同レビューを可能にするために、プロジェクトのソースリポジトリには、リリース間のレビューのための中間バージョンが含まれなければなりません。最終リリースのみを含めることはできません。 [repo_interim]
    プロジェクトは、公開ソース リポジトリから特定の暫定版を省略することを選択することができます。（たとえば、特定の非公開のセキュリティ脆弱性を修正するものは、公開されないか、または、合法的に投稿できないか、最終リリースに入らないです）

    The project's source repository includes interim versions for review between releases, not only final releases:

    1 Active Development Branch

    The repository has an active development branch with interim commits:

    • Current branch: develop
    • Recent interim commits visible:
      • bd76ec789a "Improved usage information (#6070)"
      • b986a34474 "Bump the github-actions group with 6 updates (#6075)"
      • 5e2a73d542 "Minor optimizations of r-tree implementation (#6039)"

    These are work-in-progress commits, not final releases.

    2 Pull Request Workflow

    CONTRIBUTING.md describes a collaborative review process using pull requests:

    • "Submit a pull request (PR)"
    • "Address any formatting or testing issues reported by CI"
    • "Work with HDF Group developers to meet acceptance criteria"

    This workflow requires interim code to be visible in the repository for review before merging. Reference: CONTRIBUTING.md#contributing-changes

    1. Development Version in Repository README.md states: "HDF5 version 2.0.1 currently under development" This shows the repository contains work-in-progress code, not just released versions.

    2. Development Snapshots The project provides periodic development snapshots: "Periodically development code snapshots are provided at the following URL: https://github.com/HDFGroup/hdf5/releases/tag/snapshot" Reference: README.md#snapshots-previous-releases-and-source-code

    3. Branching Strategy for Collaboration CONTRIBUTING.md describes branching strategy enabling interim review: "Target the develop branch for new features and bug fixes" "Small features: Develop in forks of the main repository" "Large collaborative work: Use feature branches named feature/" Reference: CONTRIBUTING.md#branching-strategy

    4. Unmerged Work Visible The git status shows numerous untracked and modified files, indicating ongoing development work: Multiple Makefile.in files Test files (a.out, object files) Patch files (hdf5_subfiling_mapping.patch, subfiling_mapping.patch, subfiling_mapping2.patch)

    URL: https://github.com/HDFGroup/hdf5 The repository contains interim development versions on the develop branch and feature branches for collaborative review, not just final releases.


    バッジには十分です！

    プロジェクトのソース リポジトリに共通の分散バージョン管理ソフトウェア（gitなど）を使用することを推奨します。 [repo_distributed]
    Gitが特別に必要とされているわけでなく、プロジェクトでは、集中型バージョン管理ソフトウェア（例：subversion）を正当とする証拠を持って使用できます。

    The project uses Git, a common distributed version control software:

    1 Git Repository Confirmed

    The environment information confirms Git usage: * "Is directory a git repo: Yes"

    2 Hosted on GitHub

    The repository is hosted on GitHub, which uses Git:

    Reference: README.md#getting-the-source-code states "Development code is available at our Github location: https://github.com/HDFGroup/hdf5.git" Reference: CONTRIBUTING.md#getting-the-source-code provides Git clone instructions: "git clone https://github.com/HDFGroup/hdf5.git cd hdf5"

    3 Git Prerequisites

    CONTRIBUTING.md lists Git as a required tool:

    • "Git: For version control."
    • "If you are new to Git and GitHub, we encourage you to check out the GitHub tutorial"

    Reference: CONTRIBUTING.md#prerequisites

    4 Git Workflow Documentation

    CONTRIBUTING.md extensively documents Git workflows:

    • Git commit procedures
    • Git branch strategy (develop branch, feature branches)
    • Git commands for commits, status, diff, log, push
    • Pull request workflow using Git

    Reference: CONTRIBUTING.md#committing-changes-with-git and CONTRIBUTING.md#branching-strategy

    5 Git Commit History

    The repository shows a typical Git commit history:

    • Commit hashes (bd76ec789a, b986a34474, etc.)
    • Git status shows branch information ("Current branch: develop")
    • Recent commits log available

    URL: https://github.com/HDFGroup/hdf5 The project uses Git, which is one of the most common distributed version control systems and is the de facto standard for modern software development.on GitHub, which uses git. Repository on GitHub, which uses git. git is distributed.


  • 一意的なバージョン番号


    バッジには十分です！

    プロジェクトの結果には、ユーザーが使用することを意図されたリリースごとに固有のバージョン識別子が必要です。 [version_unique]
    これはコミットID（git commit idやmercurial changeset idなど）やバージョン番号（YYYYMMDDのようなセマンティックバージョニングや日付ベースのスキームを使用するバージョン番号を含む）など、さまざまな方法で対応できます。

    The project uses unique version identifiers for each release:

    1 Current Version Identifier

    README.md shows the current development version:

    • "HDF5 version 2.0.1 currently under development"
    • This follows semantic versioning (major.minor.patch).

    2 Release Version Examples

    README.md references specific versioned releases:

    Reference: README.md#snapshots-previous-releases-and-source-code

    3 Version Numbering System README.md describes the versioning approach:

    • Major versions for significant changes (2.0.0)
    • Maintenance branches for each major.minor version
    • Release schedule shows specific version numbers

    Reference: README.md#release-schedule states "we aim to have at least one annual release for each maintenance branch"

    4 Branching by Version

    CONTRIBUTING.md references version-specific branches:

    • "hdf5_X_Y" format for release support branches
    • "hdf5_X_Y_Z" format for release preparation branches
    • Example: "hdf5_1_14" branch

    Reference: CONTRIBUTING.md mentions maintenance branches and release_docs/RELEASE_PROCESS.md references version-specific branches

    5 Maven Artifact Versioning

    README.md shows versioned Maven artifacts:

    • "org.hdfgroup:hdf5-java" with version identifiers
    • Snapshot versions with "-SNAPSHOT" suffix
    • Maven Central releases with specific versions

    Reference: README.md#snapshots-previous-releases-and-source-code

    6 GitHub Releases

    The project uses GitHub releases with version tags:

    Reference: README.md URL: https://github.com/HDFGroup/hdf5/releases Each release has a unique version identifier following the format major.minor.patch (e.g., 2.0.1, 1.14.x), ensuring users can identify and reference specific releases.


    バッジには十分です！

    リリースには、Semantic Versioning (SemVer)またはCalendar Versioning (CalVer)のバージョン番号形式を使用することが推奨されます。CalVerを使用する場合は、マイクロレベル値を含めることが推奨されます。 [version_semver]
    プロジェクトは一般的に、エコシステムで使用されている通常のフォーマットなど、ユーザーが期待しているフォーマットを優先するべきです。多くのエコシステムではSemVerが好まれており、一般的にSemVerはアプリケーションプログラマインターフェース（API）やソフトウェア開発キット（SDK）に好まれています。CalVerは、規模が大きく、独自に開発した依存関係が異常に多いプロジェクトや、スコープが常に変化するプロジェクト、時間的な制約があるプロジェクトで使用される傾向があります。CalVerを使用する際には、マイクロレベルの値を含めることが推奨されます。マイクロレベルを含めることで、必要になった場合にはいつでも同時にメンテナンスされるブランチをサポートできるからです。git commit ID や mercurial changeset ID など、バージョンを一意に識別できるものであれば、他のバージョン番号形式をバージョン番号として使用することができます。しかし、(git commit ID のような)いくつかの代替形式は、リリースの識別子として問題を引き起こす可能性があります。すべての受信者が最新バージョンを実行しているだけの場合 （たとえば、継続的な配信を介して常に更新されている単一のWebサイトまたはインターネットサービスのコード）には、バージョン ID の形式はソフトウェアのリリースを識別する上で重要ではないかもしれません。

    バッジには十分です！

    プロジェクトがバージョン管理システム内の各リリースを特定することが推奨されています。たとえば、gitを使用しているユーザーがgitタグを使用して各リリースを特定することが推奨されています。 [version_tags]

    The project identifies releases within the version control system using tags:

    1 GitHub Release Tags

    README.md references GitHub releases with tags:

    This shows the project uses Git tags for releases (the "tag/snapshot" URL pattern indicates Git tags). Reference: README.md#snapshots-previous-releases-and-source-code

    2 Version-Specific Release Branches

    The project uses version-specific branches for releases:

    • "hdf5_X_Y" format for release support branches
    • "hdf5_X_Y_Z" format for release preparation branches
    • Example: "hdf5_1_14" branch for 1.14 releases

    Reference: RELEASE_PROCESS.md and CONTRIBUTING.md mention version-specific branches

    3 GitHub Releases Infrastructure

    The project uses GitHub's release system, which is built on Git tags:

    4 Release Documentation Process

    RELEASE_PROCESS.md describes the release workflow which includes version control system operations:

    • References to branches like "hdf5_X_Y" and "hdf5_X_Y_Z"
    • Mentions lifting code freeze on release branches
    • Describes version-specific branch management

    Reference: release_docs/RELEASE_PROCESS.md

    5 Maven Release Tags

    The project uses versioned releases for Maven artifacts:

    • Snapshot builds with version identifiers
    • Release workflows that create tagged versions

    Reference: CONTRIBUTING.md mentions Maven snapshot and release builds URL: https://github.com/HDFGroup/hdf5/releases The project uses Git tags to identify releases, as evidenced by the GitHub releases system (which uses Git tags) and the documented release process with version-specific branches and tags.


  • リリースノート


    バッジには十分です！

    プロジェクトは、各リリースにおいて、ユーザーがアップグレードすべきかどうか、また、アップグレードの影響を判断できるよう、そのリリースの主要な変更の要約を説明したリリースノートを提供しなければなりません（MUST）。リリースノートは、バージョン管理ログの生の出力であってはなりません（例えば、 "git log"コマンドの結果はリリースノートではない）。プロジェクトの成果物が複数の場所で再利用されることを意図していないプロジェクト（単独のウェブサイトやサービスのためのソフトウェアなど）で、かつ、継続的・断続的な配布を行う場合は、「該当なし」を選択することができます。 (URLが必要です) [release_notes]
    リリースノートは様々な方法で実装できます（MAY）。多くのプロジェクトは、 "NEWS"、 "CHANGELOG"、または "ChangeLog"という名前のファイルでそれらを提供し、 ".txt"、 ".md"、 ".html"などの拡張子を付けることもあります。歴史的には、 "change log"という言葉はすべての変更のログを意味していましたが、本基準を満たすために必要なものは、人間が読める要約です。リリースノートは代わりに、 GitHubリリースのワークフローなどのバージョン管理システムのメカニズムによって提供してもよい（MAY）。

    The project provides human-readable release notes that are not raw version control logs:

    1 CHANGELOG.md File

    The project maintains a comprehensive CHANGELOG.md file with curated release notes:

    • Located at: release_docs/CHANGELOG.md
    • Human-readable summaries organized by category
    • Not raw git log output, but structured documentation

    Reference: README.md states "See the CHANGELOG.md file in the release_docs/ directory for information specific to the features and updates included in this release of the library."

    2 Well-Structured Release Notes

    The CHANGELOG.md includes:

    • Executive Summary with key highlights
    • Performance Enhancements (specific improvements like "2500% faster" Virtual Dataset operations)
    • Breaking Changes section (e.g., "Updated default file format to 1.8")
    • New Features & Improvements organized by category
    • Bug Fixes section
    • Support for new platforms
    • Platforms Tested
    • Known Problems

    This format helps users determine whether to upgrade and understand the impact of the upgrade.

    3 Release Note Format Requirements

    CONTRIBUTING.md documents the release note format requirements:

    • "Title/Problem - Problem description paragraph explaining the issue and conditions where it occurs"
    • "Solution paragraph describing what was done to resolve the issue and any functional impact or workarounds"
    • When to write release notes: "Required: User-visible changes in functionality or behavior"
    • When not to write: "Not required: Internal code changes, comments, or build process changes"

    Reference: CONTRIBUTING.md#release-notes

    1. Historical Release Notes The project maintains release notes for older versions: HISTORY-1_10_0-1_12_0.txt for historical releases release.txt referenced for pre-2.0.0 releases Reference: CHANGELOG.md states "For releases prior to version 2.0.0, please see the release.txt file"

    2. Upgrade Impact Information The CHANGELOG provides clear upgrade impact guidance: Breaking changes clearly marked with warning symbol Compatibility issues documented (e.g., family driver changes) Migration guidance (e.g., CMake options replacing Autotools)

    URL: https://github.com/HDFGroup/hdf5/blob/develop/release_docs/CHANGELOG.md The project provides comprehensive, human-readable release notes in CHANGELOG.md that help users understand major changes and their upgrade impact, not raw version-control logs.


    バッジには十分です！

    リリースノートでは、このリリースで修正された、リリースの作成時にすでにCVE割り当てなどがあった、公に知られているランタイムの脆弱性をすべて特定する必要があります。 ユーザーが通常、ソフトウェアを実際に更新できない場合（たとえば、カーネルの更新によくあることです）、この基準は該当なし（N/A）としてマークされる場合があります。 この基準はプロジェクトの結果にのみ適用され、依存関係には適用されません。 リリースノートがない場合、または公に知られている脆弱性がない場合は、[N/A]を選択します。 [release_notes_vulns]
    この基準は、特定の更新によって一般に知られている脆弱性が修正されるかどうかをユーザーが判断するのに役立ち、ユーザーが情報に基づいて更新について決定できるようにします。ユーザーが通常、コンピューター上でソフトウェア自体を実際に更新することはできず、代わりに1つ以上の仲介者に依存して更新を実行する必要がある場合（カーネルお​​よびカーネルと絡み合っている下位レベルのソフトウェアの場合によくあることです）、この追加情報はそれらのユーザーには役立たないため、プロジェクトは「該当なし」（N/A）を選択する場合があります。同様に、すべての受信者が最新バージョンのみを実行している場合（継続的デリバリーによって絶えず更新される単一のWebサイトまたはインターネットサービスのコードなど）、プロジェクトはN/Aを選択できます。この基準はプロジェクトの結果にのみ適用され、依存関係には適用されません。プロジェクトのすべての推移的な依存関係の脆弱性を一覧表示することは、依存関係が増加および変化するにつれて扱いにくくなるため、不要です。依存関係を調べて追跡するツールがよりスケーラブルな方法でこれを実行できます。

    The release notes identify every publicly known run-time vulnerability fixed in releases with CVE assignments:

    1 CVE Vulnerabilities Documented in CHANGELOG.md

    The current CHANGELOG.md for version 2.0.1 identifies multiple CVE fixes with detailed descriptions:

    • CVE-2025-7067 - Heap buffer overflow in H5FS__sinfo_serialize_node_cb()
    • CVE-2025-2915 - Heap-based buffer overflow in H5F__accum_free
    • CVE-2025-7068 - Resource leaks during metadata cache entry discard
    • CVE-2025-6816, CVE-2025-6818, CVE-2025-6856, CVE-2025-2923 - Corrupted object header issues
    • CVE-2025-6750 - Heap buffer overflow in mtime message decoding
    • CVE-2025-6269 - Security vulnerabilities in H5C__reconstruct_cache_entry()
    • CVE-2025-2153 - Message flags field modification issue
    • CVE-2025-2925 - Double-free vulnerability in H5C__load_entry()

    Reference: release_docs/CHANGELOG.md Bug Fixes section

    2 CVE Information Includes Links

    Many CVE entries include direct links to the National Vulnerability Database:

    • Example: CVE-2025-2915
    • Example: CVE-2025-7068
    1. CVEs in Historical Release Notes

    Historical release documentation also identifies CVEs:

    • HISTORY-1_12_0-1_14_0.txt documents CVE-2019-8396, CVE-2021-37501, CVE-2018-13867, CVE-2021-46244, and many others
    • HISTORY-1_10_0-1_12_0.txt documents CVE-2018-11202, CVE-2018-11203, CVE-2018-11204, and others
    • HISTORY-1_14_0-2_0_0.txt documents numerous CVEs from 2023-2024

    4 GitHub Issue References

    Each CVE fix includes references to the specific GitHub issues:

    • Example: "Fixes GitHub issue #5577" for CVE-2025-7067
    • Example: "Fixes GitHub issue #5380" for CVE-2025-2915

    5 CVE Regression Testing

    • README.md shows active CVE regression testing:
    • "CVE regression" CI badge indicating continuous testing for CVE vulnerabilities

    URL: https://github.com/HDFGroup/hdf5/blob/develop/release_docs/CHANGELOG.md The project consistently identifies all publicly known vulnerabilities with CVE assignments in their release notes, with detailed descriptions, links to CVE databases, and references to GitHub issues.


 報告 7/8 ●

  • バグ報告プロセス


    バッジには十分です！

    プロジェクトは、ユーザーが不具合報告を送信するプロセスを提供しなければなりません（たとえば、課題トラッカーやメーリングリストを使用します）。 (URLが必要です) [report_process]

    The project provides multiple processes for users to submit bug reports:

    1 GitHub Issues (Primary Bug Reporting Mechanism)

    The project uses GitHub Issues as the primary bug reporting system:

    Reference: CONTRIBUTING.md#contributing-changes states: "1. Open a GitHub issue (HDF5 Issues) - Required unless the change is minor (e.g., typo fix). - Describe the problem or feature request clearly." Reference: README.md#help-and-support mentions GitHub Issues as a reporting mechanism

    2 Help Desk

    The HDF Group provides a free Help Desk for bug reports and support:

    Reference: README.md#help-and-support states: "The HDF Group staffs a free Help Desk accessible at https://help.hdfgroup.org and also monitors the Forum. Our free support service is community-based and handled as time allows."

    3 HDF Forum

    Users can report bugs and discuss issues on the HDF Forum:

    Reference: README.md#forum-and-news states: "The HDF Forum is provided for public announcements, technical questions, and discussions of interest to the general HDF5 Community."

    4 Issue Tracker is Searchable and Public

    The GitHub issue tracker is:

    • Publicly accessible
    • Searchable
    • Does not require proprietary software
    • Allows new users to participate

    Reference: CONTRIBUTING.md confirms GitHub Issues are used for bug reports and feature requests

    5 Bug Report Requirements

    CONTRIBUTING.md describes when to open issues:

    • "Required unless the change is minor (e.g., typo fix)"
    • "Describe the problem or feature request clearly"

    URL: https://github.com/HDFGroup/hdf5/issues The project provides a clear process for users to submit bug reports through GitHub Issues (primary), Help Desk, and the HDF Forum.


    バッジには十分です！

    プロジェクトは、個々の課題を追跡するための課題トラッカーを使用するべきです。 [report_tracker]

    The project uses GitHub Issues as an issue tracker for tracking individual issues:

    1 GitHub Issues Used for Issue Tracking

    The project uses GitHub's built-in issue tracker:

    Reference: CONTRIBUTING.md#contributing-changes states: "1. Open a GitHub issue (HDF5 Issues) - Required unless the change is minor (e.g., typo fix). - Describe the problem or feature request clearly."

    2 Individual Issue Tracking

    Each bug report and feature request gets its own individual issue with:

    • Unique issue number (e.g., #5577, #5380, #5578)
    • Individual URL for each issue
    • Status tracking (open/closed)
    • Labels and assignments

    Reference: CHANGELOG.md references specific GitHub issues.

    3 Pull Requests Reference Issues

    CONTRIBUTING.md requires pull requests to reference issues:

    • "Make sure to include the issue that the PR addresses in the description"

    This creates traceability between code changes and individual issues. Reference: CONTRIBUTING.md#contributing-changes

    4 Evidence of Active Issue Tracking

    Recent commits reference issue numbers:

    • "#6070" in commit "Improved usage information (#6070)"
    • "#6075" in commit "Bump the github-actions group with 6 updates (#6075)" " #6039" in commit "Minor optimizations of r-tree implementation (#6039)"

    5 Issue Tracker Features

    GitHub Issues provides:

    URL: https://github.com/HDFGroup/hdf5/issues The project actively uses GitHub Issues as an issue tracker for tracking individual bugs, feature requests, and security vulnerabilities.


    バッジには十分です！

    このプロジェクトは、過去2〜12か月間に提出された多数のバグ報告の受領を認めなければなりません。応答に修正を含める必要はありません。 [report_responses]

    The project has a triage procedure for issues as they come in:

    1 GitHub Project for Triage

    The project uses GitHub Projects for issue triage:

    This is the project management board where issues are triaged and tracked.

    2 Release Progress Tracking

    README.md references this project board:

    Reference: README.md#release-progress states: "The badge above shows the current progress of release-blocking issues with colors that reflect completion status" "Click the badge to view the detailed project board with current release-blocking issues."

    3 Active Project Management

    The project board indicates:

    • Issues are categorized and tracked
    • Release-blocking issues are identified
    • Progress is monitored with completion percentages
    • Multiple views available (view/24 suggests different perspectives on the same issues)

    4 Organizational Structure

    The project board is at the organization level (orgs/HDFGroup/projects/39):

    • Centralized issue management
    • Visible to the community
    • Integrated with GitHub Issues workflow

    5 Triage Indicators

    The existence of this project board suggests:

    • Issues are reviewed and categorized as they come in
    • Release-blocking vs non-blocking issues are identified
    • Priority and status are tracked
    • Progress is publicly visible

    URL: https://github.com/orgs/HDFGroup/projects/39 The project has an active triage procedure using GitHub Projects (project #39) to manage and categorize issues as they are submitted.


    バッジには十分です！

    プロジェクトは、直近2〜12ヶ月（2ヶ月を含む）に増強要求の多数（> 50％）に対応すべきです。 [enhancement_responses]
    応答は、「いいえ」や、そのメリットについての議論であってもよいです。目標は、単にプロジェクトがまだ生きていることを示している、いくつかの要求に対する応答があることです。この基準のために、プロジェクトは偽のリクエスト（スパマーや自動システムなど）をカウントする必要はありません。プロジェクトで機能強化が行われていない場合は、「満足されない」（unmet）を選択し、この状況をユーザーに明確にするURLを含めてください。プロジェクトが強化要求の数によって圧倒される傾向がある場合は、「満足されない」（unmet）を選択して説明してください。

    Enhancement requests are responded to through a weekly triage procedure:

    1 Weekly Triage Procedure

    Enhancement requests are responded to weekly through the triage procedure using the GitHub Projects board:

    * URL: https://github.com/orgs/HDFGroup/projects/39

    This ensures regular review and response to incoming enhancement requests.


    バッジには十分です！

    プロジェクトは、後で検索するために、レポートとレスポンスのアーカイブを公開する必要があります。 (URLが必要です) [report_archive]

    The project has publicly available archives for reports and responses that are searchable:

    1 GitHub Issues Archive

    GitHub Issues provides a permanent, publicly searchable archive:

    • URL: https://github.com/HDFGroup/hdf5/issues
    • All issues (open and closed) are archived
    • Searchable by keyword, label, date, author, etc.
    • Includes all comments and responses
    • Accessible without authentication for reading

    Reference: CONTRIBUTING.md states "Open a GitHub issue (https://github.com/HDFGroup/hdf5/issues)"

    2 GitHub Pull Requests Archive

    Pull requests and their discussions are archived:

    3 HDF Forum Archive

    The HDF Forum provides searchable archives:

    Reference: README.md#forum-and-news states: "These forums are provided as an open and public service for searching and reading."

    4 Permanent Record in Git History

    All changes and their associated discussions are permanently recorded:

    5 CHANGELOG and Historical Documentation

    Release notes archive historical issues:

    • CHANGELOG.md archives bug fixes and enhancements
    • HISTORY-*.txt files contain historical issue records
    • References to GitHub issues and CVE numbers

    Reference: release_docs/CHANGELOG.md contains archived issue references URL: https://github.com/HDFGroup/hdf5/issues

    The project maintains publicly available, searchable archives for bug reports and responses through GitHub Issues, Pull Requests, the HDF Forum, and documentation files.


  • 脆弱性報告プロセス


    バッジには十分です！

    プロジェクトは、脆弱性を報告するプロセスをプロジェクト サイトに公開しなければなりません。 (URLが必要です) [vulnerability_report_process]
    たとえば、https：// PROJECTSITE / securityの明示的に指定されたメール アドレスで、これはしばしばsecurity@example.orgの形式です。これはバグ報告プロセスと同じかもしれません。脆弱性レポートは常に公開される可能性がありますが、多くのプロジェクトでは、プライベート脆弱性を報告するメカニズムがあります。

    The project publishes the process for reporting vulnerabilities on the project site:

    1 SECURITY.md File in Repository

    The project has a SECURITY.md file in the repository root that documents the vulnerability reporting process:

    • File location: /SECURITY.md
    • Publicly accessible in the repository

    2 Vulnerability Reporting Process Documented

    SECURITY.md clearly describes how to report vulnerabilities:

    • "If you have discovered a security vulnerability in this project, please report it privately."
    • "Do not disclose it as a public issue."
    • Provides rationale: "This gives us time to work with you to fix the issue before public exposure"

    3 Reporting Mechanism Specified

    The document provides the specific method for reporting:

    This uses GitHub's private security advisory feature.

    4 Supported Versions Documented

    SECURITY.md specifies which versions receive security updates:

    • "Security updates are applied only to the latest release."

    This helps reporters understand which versions are supported.

    5 GitHub Security Advisory Integration

    GitHub automatically surfaces SECURITY.md to users:

    • Visible in the repository's "Security" tab
    • Linked from GitHub's security reporting interface
    • Standard location for security policies

    URL: https://github.com/HDFGroup/hdf5/blob/develop/SECURITY.md The project publishes its vulnerability reporting process in SECURITY.md, instructing users to report vulnerabilities privately via GitHub Security Advisories at https://github.com/HDFGroup/hdf5/security/advisories/new.


    バッジには十分です！

    プライベート脆弱性報告がサポートされている場合、プロジェクトは、プライベートに保持された方法で情報を送信する方法を含んでいなくてはなりません。 (URLが必要です) [vulnerability_report_private]
    例としては、HTTPS（TLS）を使用してWeb上に提出されたプライベート不具合報告や、OpenPGPを使用して暗号化された電子メールがあります。脆弱性報告が常に公開されている場合（プライベート脆弱性報告は存在しないため）、「該当なし」（N / A）を選択します。

    The SECURITY.md file specifies how to send vulnerability information privately:

    1 Private Reporting Method Specified SECURITY.md states: * "If you have discovered a security vulnerability in this project, please report it privately." * "Do not disclose it as a public issue." * "Please disclose it at security advisory" URL provided: https://github.com/HDFGroup/hdf5/security/advisories/new

    2 GitHub Security Advisories Keep Reports Private

    The specified method (GitHub Security Advisories) is a private reporting channel:

    • Reports submitted through this URL are private by default
    • Only visible to project maintainers
    • Not disclosed publicly until a fix is ready
    • Explanation Provided

    SECURITY.md explains why private reporting is important: * "This gives us time to work with you to fix the issue before public exposure, reducing the chance that the exploit will be used before a patch is released."

    URL: https://github.com/HDFGroup/hdf5/blob/develop/SECURITY.md The project includes instructions for sending vulnerability information privately via GitHub Security Advisories at https://github.com/HDFGroup/hdf5/security/advisories/new.


    バッジには不十分です。

    過去6ヶ月間に受け取った脆弱性報告に対するプロジェクトの初期応答時間は、14日以下でなければなりません。 [vulnerability_report_response]
    過去6か月間に脆弱性が報告されていない場合は、「該当なし」（N/A）を選択します。

    There is no current procedure in place to meet this requirement. It is under advisement to add one.


 品質 13/13 ●

  • 作業ビルドシステム


    バッジには十分です！

    プロジェクトによって作成されたソフトウェアを利用するためにビルドが必要な場合、プロジェクトは、ソース コードからソフトウェアを自動的にリビルドできる作業ビルド システムを提供しなければなりません。 [build]
    ビルドシステムは、ソフトウェアをリビルドするのに必要なアクション（およびその順序）を決定し、それらのステップを実行します。たとえば、ビルドシステムは、ソースコードをコンパイルするためにコンパイラを呼び出すことができます。実行可能ファイルがソースコードから生成される場合、ビルドシステムは、プロジェクトのソースコードを変更でき、その変更を含む更新された実行ファイルを生成できなければなりません。プロジェクトによって生成されたソフトウェアが外部ライブラリに依存する場合、ビルドシステムはそれらの外部ライブラリをビルドする必要はありません。ソースコードが変更されても、ソフトウェアを使用するためにビルドする必要がない場合、「該当なし」（N/A）を選択します。

    The project provides a working build system that automatically rebuilds the software from source code:

    1 CMake Build System

    The project uses CMake as its build system:

    • CMake minimum version: 3.26
    • Supports automated building from source

    Reference: CONTRIBUTING.md#building-for-development states: "CMake is the required build system for all platforms" Reference: CHANGELOG.md states: "CMake minimum version is now 3.26"

    2 Build Instructions Provided

    CONTRIBUTING.md provides clear build instructions.

    3 Installation Documentation

    README.md and release_docs/ directory contain build documentation:

    • INSTALL - General compilation and installation instructions
    • INSTALL_CMAKE - CMake-specific build instructions
    • Platform-specific instructions (INSTALL_Windows, INSTALL_Cygwin)

    Reference: README.md#documentation

    4 Automated CI/CD Builds

    The project has automated builds in CI/CD:

    • Multiple CI workflows shown in README.md badges
    • Daily builds
    • Platform-specific builds (Linux, Windows, macOS)

    5 CMake-Only Since 2025

    README.md confirms:

    • "Starting with HDF5 2.0, only the CMake build system is supported."
    • Autotools was removed March 10, 2025

    The project provides CMake as a working build system that automatically rebuilds the software from source code.


    バッジには十分です！

    ソフトウエアをビルドするために、一般的なツールを使用することをお勧めします。 [build_common_tools]
    たとえば、Maven、Ant、cmake、autotools、make、rake (Ruby)、 devtools （R）などです。

    The project uses CMake, which is a common and widely used build tool:

    1 CMake is a Common Build Tool

    CMake is one of the most widely-used cross-platform build systems:

    • Industry standard for C/C++ projects
    • Used by thousands of open-source and commercial projects
    • Supported on all major platforms (Linux, Windows, macOS)

    2 Required Build Tool

    CONTRIBUTING.md states:

    • "CMake is required"
    • "CMake is the required build system for all platforms"

    The project uses CMake, a common and widely adopted build tool.


    バッジには十分です！

    プロジェクトは、FLOSSツールだけを使用してビルドができるようにするべきです。 [build_floss_tools]

    The project can be built using only FLOSS (Free/Libre and Open Source Software) tools:

    1 Build System - CMake

    CMake is FLOSS:

    • License: BSD 3-Clause
    • Open source and freely available

    2 Compilers - GCC and Clang

    The project supports FLOSS compilers:

    • GCC (GNU Compiler Collection) - GPL licensed
    • Clang/LLVM - Apache 2.0/NCSA licensed

    Both are fully open source Note: MSVC (Microsoft Visual C++) is also supported on Windows, but is not required. Reference: CONTRIBUTING.md states "A C11-compatible C compiler (MSVC on Windows is supported)" - indicating MSVC is optional, not required.

    3 Version Control - Git

    Git is FLOSS:

    • License: GPL v2
    • Open source

    4 Other Required Tools are FLOSS

    CONTRIBUTING.md lists required tools, all FLOSS: * Perl - Artistic License/GPL * Make (Unix Makefiles) - GPL (For older versions of HDF5)

    5 Recommended Tools are FLOSS

    All recommended tools are FLOSS:

    • clang-format - Apache 2.0/NCSA
    • Doxygen - GPL
    • codespell - GPL

    The project can be built entirely using FLOSS tools (CMake, GCC/Clang, Git, Perl, Make) without requiring any proprietary software.


  • 自動テスト スイート


    バッジには十分です！

    プロジェクトは、FLOSSとして公開されている自動テストスイートを少なくとも1つ使用する必要があります（このテストスイートは、別個のFLOSSプロジェクトとして維持される場合があります）。 プロジェクトは、テストスイートの実行方法を明確に示すか文書化する必要があります（たとえば、継続的インテグレーション（CI）スクリプトを介して、またはBUILD.md、README.md、CONTRIBUTING.mdなどのファイルの文書を介して）。 [test]
    プロジェクトでは、複数の自動化されたテストスイートを使用することができます（たとえば、迅速に実行するもの、より完全であるが特別な装置が必要なもの）。Selenium (ウェブブラウザの自動化)、Junit (JVM, Java)、RUnit (R)、testthat (R) など、多くのテストフレームワークやテスト支援システムが利用可能です。

    1 Automated Test Suite Exists

    The project has test suites in the repository:

    • test/ directory - C library tests
    • testpar/ directory - Parallel C library tests
    • c++/test/ - C++ wrapper tests
    • fortran/test/ - Fortran wrapper tests

    2 Test Suite is FLOSS

    The test suite is part of the HDF5 repository:

    • Licensed under BSD 3-Clause (same as main project)
    • Publicly available in the repository

    3 Documentation on Running Tests

    CONTRIBUTING.md documents testing:

    • "Build and test thoroughly"
    • "Ensure all tests pass"
    • "All new functionality and bug fixes must include tests"
    • Test structure documented with examples using h5test.h macros

    Reference: CONTRIBUTING.md#testing

    4 CI System Shows Test Execution

    README.md shows active CI with automated tests: * Multiple CI badges indicating automated testing * Daily builds with tests * Platform-specific test runs

    5 CMake Test Integration

    Tests run via CMake:

    • CMakeLists.txt files in test directories
    • Standard CMake test commands (ctest)

    The project uses automated test suites (in test/ and testpar/ directories) that are FLOSS-licensed and documented in CONTRIBUTING.md, with execution shown via CI badges in README.md.


    バッジには十分です！

    テスト スイートは、その言語の標準的な方法で呼び出すことができるべきです。 [test_invocation]
    たとえば、「make check」、「mvn test」、「rake test」（Ruby）などです。

    The project uses CMake with CTest, which is the standard way to invoke tests for CMake-based C/C++ projects:

    • Standard command: ctest or make test
    • CMakeLists.txt files in test directories configure tests
    • Standard CMake test infrastructure

    Reference: CONTRIBUTING.md mentions "Ensure tests run and pass under CMake" and "Update CMakeLists.txt in the test/ directory" The test suite is invocable using standard CMake/CTest commands.


    バッジには十分です！

    テスト スイートは、コードブランチ、入力フィールド、および機能のほとんど（または理想的にはすべて）をカバーすることが推奨されています。 [test_most]

    Minimum automated testing is performed on branches, as features, bug fixes, and enhancements are derived from forks rather than the central HDF5 repository. Branches associated with releases are tested automatically.

    1 Coverage Reporting to CDash

    README.md provides link to coverage results:

    2 Automated Coverage Analysis

    .github/workflows/analysis.yml runs coverage testing:

    • Coverage test job: "Ubuntu GCC Coverage"
    • Uses lcov for coverage collection
    • DHDF5_ENABLE_COVERAGE:BOOL=ON
    • CODE_COVERAGE:BOOL=ON
    • Automated coverage generation and reporting

    3 Code Coverage Infrastructure

    config/sanitizer/code-coverage.cmake provides coverage support:

    • GCC/LCOV support
    • Clang/llvm-cov support
    • Multiple coverage targets for different granularity
    • HTML coverage reports generated

    Reference: config/sanitizer/README.md documents extensive code coverage capabilities

    4 Extensive Test Suite

    The project has comprehensive tests across multiple directories:

    • test/ - C library tests
    • testpar/ - Parallel C library tests
    • c++/test/ - C++ wrapper tests
    • fortran/test/ - Fortran wrapper tests
    • tools/test/ - Command-line tools tests

    5 Test Policy Requires Tests for New Code

    CONTRIBUTING.md mandates:

    • "All new functionality and bug fixes must include tests"
    • Ensures ongoing coverage improvement
    • Tests must be added for all code changes

    6 Multiple Sanitizers Provide Branch Coverage

    .github/workflows/analysis.yml runs multiple sanitizers:

    • AddressSanitizer
    • LeakSanitizer
    • UndefinedBehaviorSanitizer

    These dynamic analysis tools exercise code paths to detect issues and provide functional coverage verification.

    7 CVE Regression Tests

    README.md shows CVE regression testing:

    • Tests for previously fixed vulnerabilities
    • Ensures critical code paths are covered
    • Validates security-sensitive functionality

    8 OSS-Fuzz for Input Coverage

    OSS-Fuzz integration provides:

    • Automated fuzzing of input handling code
    • Explores different input combinations
    • Discovers edge cases and boundary conditions

    The project has comprehensive test coverage tracked through CDash, with automated coverage analysis in CI/CD, extensive test suites across all components, and mandatory testing requirements for new code.


    バッジには十分です！

    プロジェクトは、継続的インテグレーション（新しいコードまたは変更されたコードが頻繁に中央コードリポジトリに統合され、その結果に対して自動テストが実行される）を実装することを推奨されています。 [test_continuous_integration]

    1 Multiple CI Workflows

    README.md displays numerous CI badges showing active continuous integration:

    • develop cmake build status
    • HDF5 develop daily build
    • netCDF build status
    • h5py build status
    • CVE regression
    • HDF5 VOL connectors build status
    • HDF5 VFD build status
    • Link checker status

    2 GitHub Actions

    The project uses GitHub Actions for CI:

    • .github/workflows/ directory contains CI workflows
    • Automated testing on pull requests
    • Daily scheduled builds

    3 CI Requirements in CONTRIBUTING.md

    CONTRIBUTING.md mentions CI integration:

    • "Address any formatting or testing issues reported by CI"
    • "The CI system will automatically format pull requests if needed"
    • "The CI system builds with -Werror"

    4 CDash Integration

    Test results reported to CDash:

    The project implements continuous integration with multiple automated workflows, daily builds, and automated testing on code changes.


  • 新機能テスト


    バッジには十分です！

    プロジェクトは、プロジェクトで作成されたソフトウェアに主要な新機能が追加されたときに、その機能のテストを自動化されたテスト スイートに追加する必要があるという一般的な方針（正式でも、正式でなくても構いません）を持っていなければなりません。 [test_policy]
    開発者はテストを自動テスト スイートに追加して、新しい機能を追加する必要があるというポリシーが、口頭でも（文書化されていなくても）、存在する限り、「満たしている」を選択してください。

    CONTRIBUTING.md explicitly states the policy:

    • "All new functionality and bug fixes must include tests."

    This is a clear, mandatory policy requiring tests for new functionality. Reference: CONTRIBUTING.md#adding-new-tests states:

    • "All new functionality and bug fixes must include tests."
    • "Add tests to existing test files when appropriate."
    • "Create new test programs using h5test.h macros."

    The project has a formal policy requiring tests for all new functionality.


    バッジには十分です！

    プロジェクトによって作成されたソフトウェアの最新の大きな変更で、テストを追加するための test_policy が守られているという証拠がプロジェクトに存在しなければなりません。 [tests_are_added]
    主要な機能は、通常、リリースノートに記載されます。完璧は必要ないですが、プロジェクトによって生成されたソフトウェアに新しい主要機能が追加されたときに、自動テスト スイートに実際にテストが追加されているという証拠となります。

    1 Recent Major Changes Include Tests

    The CHANGELOG.md for version 2.0.1 documents extensive major changes with corresponding test evidence:

    • Bug fixes reference GitHub issues that include test cases
    • Security fixes (CVEs) have regression tests
    • CI badge shows "CVE regression" testing

    2 CVE Regression Testing

    README.md shows active CVE regression testing:

    • CVE regression CI badge indicates automated testing of security fixes
    • Multiple CVEs fixed in recent release with tests

    3 Test Requirements Enforced in CI

    CONTRIBUTING.md states:

    • "Address any formatting or testing issues reported by CI"
    • CI system validates that tests pass before merging

    4 Maven Testing for Java Changes

    Recent major Java enhancements include comprehensive testing:

    • "Complete Java examples Maven integration with cross-platform CI/CD testing"
    • Maven artifact validation scripts
    • Multi-platform testing workflows

    Reference: CHANGELOG.md#java-enhancements

    5 Pull Request References Show Test Integration

    Recent commits reference pull requests (#6070, #6075, #6039, #6049, #6066), which go through CI testing before merge. The project demonstrates adherence to its test policy through CI enforcement, CVE regression testing, and documented test requirements for recent major changes.


    バッジには十分です！

    テストを追加するこのポリシー（test_policyを参照）を変更提案に関する手順で文書化することを推奨します。 [tests_documented_added]
    しかし、実際にテストが追加されている限り、非公式の規則でも許容されます。

    CONTRIBUTING.md documents the test policy in the instructions for change proposals:

    1 In the Workflow Section

    Step 3 under "Make your changes": * "Add tests for new functionality or bug fixes."

    2 In the Adding New Tests Section

    Explicit documentation: * "All new functionality and bug fixes must include tests."

    3 In the Checklist for Contributors

    Testing checklist item:

    • "Pull request includes tests."

    4 In the Acceptance Criteria Section

    Testing requirement for pull request acceptance:

    • "Testing: Must pass HDF5 regression testing and include appropriate tests."

    Reference: CONTRIBUTING.md#contributing-changes, CONTRIBUTING.md#adding-new-tests, and CONTRIBUTING.md#checklist-for-contributors The test policy is documented in multiple sections of CONTRIBUTING.md where change proposals and pull requests are described.


  • 警告フラグ


    バッジには十分です！

    プロジェクトは、選択した言語でこの基準を実装することができる少なくとも1つのFLOSSツールがあれば、1つまたは複数のコンパイラ警告フラグ、「安全」言語モードを使用可能にするか、分離 「リンター」ツールを使用してコード品質エラーまたは共通の単純なミスを検索しなければなりません。 [warnings]
    コンパイラ警告フラグの例には、gcc / clang "-Wall"があります。 「安全」言語モードの例には、JavaScript「use strict」とperl5の「use warnings」があります。分離「リンター」ツールは、ソースコードを調べてコード品質のエラーや一般的な単純なミスを探すツールです。これらは、通常、ソースコードまたはビルド命令内で有効になります。

    1 Compiler Warning Flags Enabled

    CONTRIBUTING.md states:

    • "The CI system builds with -Werror"
    • "HDF5_ENABLE_DEV_WARNINGS:BOOL=ON" option available for extra warnings
    • "fix all compiler warnings before submitting pull requests"

    2 Developer Mode Warnings

    CONTRIBUTING.md documents developer build options: * "HDF5_ENABLE_DEVELOPER_MODE=ON" enables "warnings as errors" * "Developer Warnings: Enable extra warnings with HDF5_ENABLE_DEV_WARNINGS:BOOL=ON"

    3 Linter Tool - clang-format

    CONTRIBUTING.md lists clang-format as a recommended tool:

    • "clang-format: For code formatting. The CI system will automatically format pull requests if needed."

    4 CI Enforcement

    The CI system enforces code quality:

    • Builds with -Werror (warnings treated as errors)
    • Automatic code formatting
    • Must pass before pull request acceptance

    Reference: CONTRIBUTING.md#prerequisites and CONTRIBUTING.md#developer-build-tips The project enables compiler warning flags (-Werror), uses clang-format for linting, and enforces these in CI.


    バッジには十分です！

    プロジェクトは警告を出さなければならない。 [warnings_fixed]
    これらは、警告基準の実装によって識別される警告です。プロジェクトは、警告を修正するか、ソースコード内で警告を誤検出としてマークするべきです。理想的には警告がないことがいいですが、プロジェクトはある程度の警告（通常は100行あたり1警告未満、または全体で10警告未満）を受け入れることができます。

    CONTRIBUTING.md explicitly requires addressing warnings:

    • "The CI system builds with -Werror, so fix all compiler warnings before submitting pull requests."

    This policy ensures:

    • Warnings are treated as errors in CI builds
    • All warnings must be fixed before code can be merged
    • Pull requests cannot be accepted with warnings

    Reference: CONTRIBUTING.md#developer-build-tips The project requires all compiler warnings to be addressed before pull request submission.


    バッジには十分です！

    プロジェクトによって作成されたソフトウェアにある警告に、実際的な場合には、最大限に厳格になることを推奨されています。 [warnings_strict]
    一部の警告は、あるプロジェクトでは効果的に有効にすることはできません。必要なのは、プロジェクトが可能な限り警告フラグを有効にするように努力しており、エラーが早期に検出されるという証拠です。

    CONTRIBUTING.md shows the project is maximally strict with warnings:

    1 Warnings as Errors Required

    • "The CI system builds with -Werror" (treats all warnings as errors)
    • Mandatory for all pull requests

    2 Additional Developer Warnings Available * "HDF5_ENABLE_DEV_WARNINGS:BOOL=ON" enables extra warnings * "generates significant output but can be useful"

    3 Developer Mode Strictness * "HDF5_ENABLE_DEVELOPER_MODE=ON" enables "warnings as errors" * Recommended for development builds

    Reference: CONTRIBUTING.md#developer-build-tips The project uses the strictest possible warning level with -Werror in CI and optional extra warnings for developers.


 セキュリティ 14/16 ●

  • セキュリティに関する開発知識


    バッジには十分です！

    プロジェクトには、安全なソフトウェアを設計する方法を知っている少なくとも1人の主要な開発者が必要です。 （正確な要件については、「詳細」を参照してください。） [know_secure_design]
    これには、Saltzer and Schroeder の8つの原則を含む以下の設計原則を理解する必要があります。
    • メカニズムの経済性（たとえば、スイーピング シンプリフィケーションを採用して、メカニズムを実際的に単純化し小さくする）
    • フェイルセーフのデフォルト（アクセスの決定はデフォルトで拒否されるべきであり、プロジェクトのインストールはデフォルトで安全でなければならない）
    • 完全なメディエーション（制限されたすべてのアクセスは権限がチェックされ、バイパスされない）
    • オープンな設計（セキュリティメカニズムは攻撃者の設計に対する無知に依存するべきではなく、 簡単に保護ができて変更ができる鍵やパスワードのような情報に依存すべきです。
    • 特権の分離（理想的には、重要なオブジェクトへのアクセスは複数の条件に依存すべきで、1つの保護システムを破ることで完全なアクセスが可能にならないようにします。たとえば、パスワードとハードウェア トークンを必要とする多因子認証は単因子認証より強いです。
    • 最低限の権限（プロセスは最低限の権限で動作する必要がある）
    • 最低限の共通メカニズム（設計は、複数のユーザに共通のメカニズムや全てのユーザーに依存するメカニズムを最小限に抑えるべきです。）
    • 心理学的受容性（ヒューマンインタフェースは、使いやすく設計されていなければならない - 「驚きが最小限になる」という設計が助けになる）
    • 限られた攻撃面（攻撃面 - 攻撃者がデータを入力または抽出しようとする部分 - を制限する必要があります）
    • ホワイト リストで入力を検証します（入力は通常、この検証はブラックリスト（既知の不良値をリストする）ではなく、ホワイトリスト（既知の値のみを受け入れる）を使用する必要があります。
    プロジェクトの「主要な開発者」とは、プロジェクトのコードベースに精通していて、容易に変更を加えることができ、プロジェクトの他のほとんどの参加者によって認められている人です。主要な開発者は、通常、過去1年間に（コード、文書、または質問に回答して）多数の貢献を行います。ある開発者が、プロジェクトを開始している（3年以上プロジェクトから離れていない）、プライベート脆弱性報告チャネル（存在する場合）に関する情報を受け取る、プロジェクトを代表してコミットを受け入れる、最終リリースする、などを行う時主要な開発者とみなすことができます。開発者が1人だけの場合、その人物が主要開発者です。より安全なソフトウェアを開発し、設計について議論する方法を理解するのに役立つ多くの本やコースが利用可能です。 たとえば、 Secure Software Development Fundamentals コースは、3つのコースの無料セットです。 より安全なソフトウェアを開発する方法を説明しています。

    Evidence that primary developers understand secure software design principles:

    1 Economy of Mechanism

    CONTRIBUTING.md enforces simplicity:

    • "Avoid over-engineering. Only make changes that are directly requested or clearly necessary."
    • "Don't create helpers, utilities, or abstractions for one-time operations."
    • "The right amount of complexity is the minimum needed for the current task"

    2 Fail-Safe Defaults

    Security fixes show fail-safe approach:

    • CVE-2025-2915: "Added validation in H5O__mdci_decode to detect and reject invalid values early"
    • CVE-2025-6750: "allow invalid message size to be detected"
    • Default error handling with HGOTO_ERROR macro

    3 Complete Mediation

    CONTRIBUTING.md shows validation practices:

    • "Always check return values of functions that can fail"
    • Function structure includes parameter checks: "HDassert(/parameter check/)"

    4 Open Design

    The project is fully open source:

    • All security mechanisms in public repository
    • Security fixes documented in CHANGELOG.md
    • No security through obscurity

    5 Least Privilege

    CONTRIBUTING.md describes function visibility levels:

    • Public, Private, and Package scopes
    • "Package: Used only within the defining package"
    • Minimizes exposure of internal APIs

    6 Input Validation with Allowlists

    Multiple CVE fixes demonstrate input validation:

    • CVE-2025-2915: "Added validation...to detect and reject invalid values early, preventing the overflow condition"
    • CVE-2025-6816 series: "checking the expected number of object header chunks against the actual value"
    • CVE-2025-2925: "checks for an image buffer length of 0 before calling H5MM_realloc"
    • "Check for overflow in decoded heap block addresses"

    7 Limited Attack Surface

    CONTRIBUTING.md enforces minimalism:

    • Three-tier API (Public/Private/Package) limits attack surface
    • "Don't add features...beyond what was asked"

    8 OWASP Awareness

    CONTRIBUTING.md explicitly mentions security:

    • "Be careful not to introduce security vulnerabilities such as command injection, XSS, SQL injection, and other OWASP top 10 vulnerabilities."

    9 Professional Security Practices

    • Private vulnerability disclosure (SECURITY.md)
    • CVE regression testing
    • 15+ CVEs fixed in recent release with detailed technical understanding
    • Bounds checking, input validation, safe cleanup practices

    The project demonstrates knowledge of secure design principles through documented policies, extensive security fixes showing deep understanding, and explicit security requirements in the contribution guidelines.


    バッジには十分です！

    プロジェクトの主要開発者の少なくとも1人は、この種のソフトウェアの脆弱性につながる一般的な種類のエラーを知っていなければならず、それぞれを対策または緩和する少なくとも1つの方法を知っていなければなりません。 [know_common_errors]
    例（ソフトウェアの種類によって異なります）には、SQLインジェクション、OSインジェクション、従来のバッファオーバーフロー、クロスサイトスクリプティング、認証の欠落、承認の欠落などがあります。一般的に使用されるリストについては、 CWE/SANSトップ25またはOWASPトップ10を参照してください。より安全なソフトウェアを開発する方法を理解し、脆弱性につながる一般的な実装エラーについて説明するのに役立つ多くの書籍やコースが用意されています。たとえば、 Secure Software Development Fundamentalsコースは、より安全なソフトウェアを開発する方法を説明する3つのコースの無料セットです（受講は無料です。追加料金を払うと、学習したことを証明する証明書を入手できます）。

    Evidence that primary developers know common vulnerability types and mitigations:

    1 Buffer Overflows - Known and Mitigated

    Multiple CVE fixes demonstrate understanding:

    • CVE-2025-7067: "Fixed a heap buffer overflow in H5FS__sinfo_serialize_node_cb()" - Mitigation: "discarding file free space sections...when they are found to be invalid"
    • CVE-2025-2915: "Fixed a heap-based buffer overflow...caused by an integer overflow" - Mitigation: "Added validation...to detect and reject invalid values early"
    • CVE-2025-6750: "A heap buffer overflow occurred because an mtime message was not properly decoded" - Mitigation: "decoding old and new mtime messages which will allow invalid message size to be detected"

    2 Integer Overflows - Known and Mitigated

    • CVE-2025-2915: "integer overflow when calculating new_accum_size" - Mitigation: validation to prevent overflow
    • "Check for overflow in decoded heap block addresses" - Mitigation: "added a check in H5HL__fl_deserialize to ensure no overflow can occur"

    3 Memory Leaks and Resource Management - Known and Mitigated

    • CVE-2025-7068: "could cause the library to skip calling the callback to free the cache entry. This could result in resource leaks" - Mitigation: "attempting to fully free a cache entry before signalling that an error has occurred"
    • CVE-2025-6269: "memory leaks" - Mitigation: "safe cleanup"

    4 Double-Free Vulnerabilities - Known and Mitigated

    • CVE-2025-2925: "it was freed again in done, causing a double-free vulnerability" - Mitigation: "H5C__load_entry() now checks for an image buffer length of 0 before calling H5MM_realloc"

    5 Stack Overflows - Known and Mitigated

    • CVE-2025-6857: "An HDF5 file had a corrupted v1 B-tree that would result in a stack overflow" - Mitigation: "additional integrity checks"

    6 Input Validation Failures - Known and Mitigated

    • CVE-2025-2913, CVE-2025-2926: "The size of a continuation message was decoded as 0, causing multiple vulnerabilities" - Mitigation: "An error check was added to return failure to prevent further processing of invalid data"
    • CVE-2025-6816 series: "corrupted object header with a continuation message that points back to itself" - Mitigation: "checking the expected number of object header chunks against the actual value"

    7 OWASP Top 10 Awareness

    CONTRIBUTING.md explicitly requires:

    • "Be careful not to introduce security vulnerabilities such as command injection, XSS, SQL injection, and other OWASP top 10 vulnerabilities."

    8 Bounds Checking

    • CVE-2025-6269: "buffer overflows" - Mitigation: "bounds checks, input validation"

    9 Common Mitigation Techniques Used

    • Early validation and rejection of invalid input
    • Bounds checking before operations
    • Safe cleanup and error handling
    • Integer overflow detection
    • Resource leak prevention

    The project demonstrates comprehensive knowledge of common vulnerability types (buffer overflows, integer overflows, memory leaks, double-frees, stack overflows) and proper mitigation techniques through extensive CVE remediation and explicit security requirements.


  • 優良な暗号手法を使用する

    一部のソフトウェアは暗号化メカニズムを使用する必要がないことに注意してください。あなたのプロジェクトが作成するソフトウェアが、(1) 暗号化機能を含む、アクティブ化する、または有効化し、(2) 米国（US）から米国外または米国市民以外にリリースされる可能性がある場合は、法的に義務付けられた追加手順の実行を要求される可能性があります。通常、これにはメールの送信が含まれます。詳細については、 Understanding Open Source Technology & US Export Controls（「オープンソース技術と米国の輸出管理について」）の暗号化のセクションを参照してください。

    バッジには十分です！

    プロジェクトによって作成されたソフトウェアは、デフォルトで、一般に公開され、専門家によってレビューされている暗号プロトコルとアルゴリズムを使用しなければなりません。（暗号プロトコルとアルゴリズムが使用される場合） [crypto_published]
    ソフトウェアによっては暗号機能を直接使用する必要がないため、これらの暗号基準は常に適用されるわけではありません。

    バッジには十分です！

    プロジェクトによって作成されたソフトウェアがアプリケーションまたはライブラリであり、主な目的が暗号の実装でない場合、暗号機能を実装するために特別に設計されたソフトウェアを呼び出すだけにするべきです。自分用に（暗号機能を）再実装するべきではありません。 [crypto_call]

    バッジには十分です！

    暗号に依存するプロジェクトによって作成されるソフトウェアのすべての機能は、FLOSSを使用して実装可能でなければなりません。 [crypto_floss]
    オープン ソース イニシアチブによるオープン スタンダード要件を参照して下さい。

    バッジには十分です！

    プロジェクトによって作成されたソフトウェア内にあるセキュリティ メカニズムは、少なくとも、2030年までのNIST最小要件（2012年）を満たすデフォルト鍵長を使用しなければなりません。より小さな鍵長を完全に無効になるおうに、ソフトウェアを構成できなければなりません。 [crypto_keylength]
    これらの最小ビット長は、対称鍵112、ファクタリング係数2048、離散対数鍵224、離散対数群2048、楕円曲線224、ハッシュ224（パスワードハッシュはこのビット長でカバーされません。パスワードハッシュに関する詳しい情報は crypto_password_storage 基準にあります）です。さまざまな機関が出している推奨鍵長の比較については、https://www.keylength.comを参照してください。ソフトウェアは、 いくつかの構成ではより短い鍵長を許可するかもしれません（これはダウングレード攻撃を許すので、理想的には正しくありません。しかし、短い鍵長は、相互運用性のために時に必要となります）。

    バッジには十分です！

    プロジェクトによって生成されたソフトウェア内のデフォルトのセキュリティメカニズムは、壊れた暗号化アルゴリズム（MD4、MD5、シングルDES、RC4、Dual_EC_DRBGなど）に依存したり、実装する必要がない限り、コンテキストに不適切な暗号化モードを使用したりしてはなりません。相互運用可能なプロトコル（実装されたプロトコルがネットワークエコシステムによって広くサポートされている標準の最新バージョンであり、そのエコシステムではそのようなアルゴリズムまたはモードの使用が必要であり、そのエコシステムはこれ以上安全な代替手段を提供しません）。これらの壊れたアルゴリズムまたはモードが相互運用可能なプロトコルに必要な場合、ドキュメントには、関連するセキュリティリスクと既知の緩和策を記載する必要があります。 [crypto_working]
    ECBモードは、 ECBペンギンによって示されるように暗号文内の同一のブロックを明らかにするため、ほとんど適切ではありません。また、CTRモードは、認証を実行せず、入力状態が繰り返されると重複を引き起こすため、不適切なことがよくあります。多くの場合、Galois / Counter Mode（GCM）やEAXなど、機密性と認証を組み合わせるように設計されたブロック暗号アルゴリズム モードを選択するのが最善です。プロジェクトは、互換性のために必要な場合、ユーザーが壊れたメカニズムを有効にすることを許可する場合があります（構成中など）が、ユーザーはそれを実行していることを認識します。

    バッジには十分です！

    プロジェクトによって作成されたソフトウェア内のデフォルトのセキュリティ メカニズムは、既知の重大な脆弱性を持つ暗号アルゴリズムやモード（たとえば、SHA-1暗号ハッシュ アルゴリズムまたはSSHのCBC モード）に依存するべきではありません。 [crypto_weaknesses]
    SSHのCBCモードに関する懸念事項は、 CERT: SSH CBC 脆弱性にて議論されています。.

    バッジには十分です！

    プロジェクトによって作成されたソフトウェア内のセキュリティ メカニズムは、鍵合意プロトコルのための完全な順方向秘密を実装するべきなので、もし長期鍵が将来侵害された場合でも、長期鍵のセットから導出されるセッション鍵は侵害されません。 [crypto_pfs]

    バッジには十分です！

    プロジェクトによって作成されたソフトウェアが外部ユーザーの認証用のパスワードの保存を引き起こす場合、パスワードは、キーストレッチ（反復）アルゴリズム（Argon2id、Bcrypt、Scrypt、PBKDF2など）を使用して、ユーザーごとのソルトで反復ハッシュとして保存される必要があります。OWASP Password Storage Cheat Sheetも参照してください）。 [crypto_password_storage]
    この基準は、ソフトウェアがサーバー側Webアプリケーションなどの外部ユーザーのパスワードを使用してユーザーの認証（別名インバウンド認証）を実施している場合にのみ適用されます。ソフトウェアが他のシステムへの認証用のパスワードを保存している場合（別名、アウトバウンド認証、たとえば、ソフトウェアが他のシステムのクライアントを実装している場合）、そのソフトウェアの少なくとも一部がハッシュされていないパスワードにアクセスできる必要があるため、適用されません。

    バッジには十分です！

    プロジェクトによって作成されたソフトウェア内のセキュリティ メカニズムは、暗号学的にセキュアな乱数発生器を使用して、すべての暗号鍵とナンスを生成しなければなりません。暗号学的にセキュアでない発生器を使用してはいけません。 [crypto_random]
    暗号学的にセキュアな乱数発生器は、ハードウェアの乱数発生器でも、Hash_DRBG、HMAC_DRBG、 CTR_DRBG、Yarrow、Fortunaなどのアルゴリズムを使用する暗号学的にセキュアな疑似乱数発生器（CSPRNG）でもよいです。セキュアでない乱数発生器には、Javaのjava.util.RandomとJavaScriptのMath.randomがあります。

  • MITM（man-in-the-middle：中間者）攻撃に対応できる安全な配信


    バッジには十分です！

    プロジェクトは、MITM攻撃に対抗する配信メカニズムを使用しなければならない。httpsまたはssh+scpを使用することは許容されます。 [delivery_mitm]
    さらに強力な仕組みは、デジタル署名されたパッケージでソフトウェアをリリースすることです。配布システムへの攻撃を緩和するからです。しかし、これは、署名の公開鍵が正当なものであることをユーザーが確信でき、かつユーザーが実際に署名をチェックする場合にのみ有効です。

    The project uses delivery mechanisms that counter MITM attacks:

    1 HTTPS for Downloads

    All download URLs use HTTPS:

    2 HTTPS for Git Repository

    Source code repository uses HTTPS:

    Git also supports SSH:

    3 HTTPS for Maven Artifacts

    Maven package repository uses HTTPS:

    4 All Project URLs Use HTTPS

    Previously verified that all project sites use HTTPS:

    Reference: README.md and earlier analysis The project uses HTTPS for all delivery mechanisms (downloads, Git repository, Maven artifacts), which counters MITM attacks.


    バッジには十分です！

    暗号ハッシュ（たとえばSHA1SUM）は、http経由で運んではならず、暗号署名をチェックすることなしに使用してはいけません。 [delivery_unsigned]
    これらのハッシュは、送信中に変更することができます。

    1 No HTTP Hash Retrieval Found

    2 All Downloads Use HTTPS

    External downloads in CI workflows use HTTPS, not HTTP

    3 HTTP Timestamp Server Not Hash Retrieval

    The only HTTP usage is:

    The project does NOT retrieve cryptographic hashes over HTTP.


  • 広く知られた脆弱性を修正


    バッジには不十分です。

    60日を超えて公的に知られている中程度または重大度のパッチが適用されていない脆弱性は存在してはなりません。 [vulnerabilities_fixed_60_days]
    脆弱性は、プロジェクト自体によってパッチされ、リリースされなければなりません（パッチは他の場所で開発される可能性があります）。脆弱性が無料情報と共にCVE（共通脆弱性識別子）を持つとき（例えば、 National Vulnerability Database ）、またはプロジェクトに情報が伝えられ、その情報が（おそらくプロジェクトによって）一般に公開されたとき、脆弱性は一般に知られるようになります。Common Vulnerability Scoring System (CVSS)の定性的スコアが中程度以上であれば、脆弱性は中程度以上の深刻度とみなされます。CVSS のバージョン 2.0 から 3.1 では、これは CVSS のスコア 4.0 以上に相当します。プロジェクトは、広く利用されている脆弱性データベース（国家脆弱性データベースなど）で公開されているCVSSスコアを、そのデータベースで報告されている最新バージョンのCVSSを用いて使用することができます。代わりに、プロジェクトは、脆弱性が公表された時点で計算入力内容が公開されている場合には、脆弱性が公表された時点でのCVSSの最新版を用いて深刻度を計算することができます。注意：これは、ユーザーが最大60日間、世界中のすべての攻撃者に対して脆弱なままになる可能性があることを意味します。この基準は、責任ある開示の再起動でGoogleが推奨しているものよりも、はるかに簡単に満たすことができることが多いです。なぜなら、Googleはレポートが公開されていなくても、プロジェクトが通知された時点で60日間の期間が開始されることを推奨しているためです。また、このバッジの基準は、他の基準と同様に、個々のプロジェクトに適用されることにも注意してください。プロジェクトの中には、より大きな包括組織や大規模プロジェクトの一部であり、複数のレイヤーに分かれている場合もあります。また、多くのプロジェクトでは、複雑なサプライチェーンの一部として、他の組織やプロジェクトに成果を提供しています。個々のプロジェクトは、多くの場合、残りの部分をコントロールできませんが、個々のプロジェクトは、脆弱性パッチをタイムリーにリリースするための作業を行うことができます。そのため、私たちは個々のプロジェクトの対応時間に焦点を当てています。 一旦、個々のプロジェクトからパッチが利用可能になると、他のプロジェクトはそのパッチにどのように対処するかを決定することができます（たとえば、新しいバージョンにアップデートすることもできますし、選別されたソリューションのパッチだけを適用することもできます）。

    必須情報が不明、バッジに十分ではありません。

    プロジェクトは、すべての重要な脆弱性を、報告された後迅速に修正するべきです。 [vulnerabilities_critical_fixed]

  • その他のセキュリティ上の課題


    バッジには十分です！

    公開リポジトリは、パブリックアクセスを制限するための有効なプライベートクレデンシャル（たとえば、有効なパスワードやプライベートキー）を漏らしてはなりません。 [no_leaked_credentials]
    プロジェクトは、パブリック アクセスを制限する意図がない限り、テスト用や重要でないデータベース用の「サンプル」資格情報を漏らす可能性があります。

    1 All Credentials Use GitHub Secrets

    Workflow files properly use GitHub Secrets for sensitive credentials:

    • ${{ secrets.AZURE_CODE_SIGNING_NAME }}
    • ${{ secrets.AZURE_CERT_PROFILE_NAME }}
    • ${{ secrets.GPG_PRIVATE_KEY }}
    • MAVEN_PASSWORD referenced as environment variable, not hardcoded

    Reference: .github/workflows/ctest.yml, release.yml, maven-deploy.yml

    2 Test Credentials Are Clearly Fake

    The AWS-looking credential found (AKIAIMC3D3XLYXLN5COA) is in a test file:

    • File: tools/libtest/h5tools_test_utils.c
    • Purpose: "unit-test functionality of the routines in tools/lib/h5tools_utils"
    • Context: "real-world use case" test case for tuple parsing
    • This is test data for parsing AWS credential format, not an actual working credential

    3 No Private Key Files Found

    • No BEGIN PRIVATE KEY blocks
    • No .pem, .key, id_rsa, id_dsa files
    • No GitHub tokens (ghp_, gho_, ghu_ patterns)
    • No Slack tokens (xox patterns)

    4 Test Secrets Are Placeholder Values

    Test code uses obviously fake values:

    • test/vfd.c: secret_key = "plugh" (Adventure game reference)
    • tools/libtest: Various single-character test values ("w", "c", "z")

    ** 5 .gitignore Does Not Exclude Credential Files**

    The .gitignore doesn't exclude .env, .pem, or credential files, suggesting no such files exist or need to be excluded. The public repository does NOT leak valid private credentials. All sensitive credentials use GitHub Secrets, and AWS-format strings found are test data for parsing functionality.

    GitHub provides automatic secret scanning for public repositories, alerting maintainers when known credential patterns are detected. The project uses proper secret management practices (GitHub Secrets).


 分析 6/8 ●

  • 静的コード解析


    バッジには不十分です。

    選択した言語でこの基準を実装するFLOSSツールが少なくとも1つある場合、少なくとも1つの静的コード分析ツール（コンパイラの警告と「安全な」言語モード以外）を、ソフトウェアの主要な製品リリースの提案に、リリース前に適用する必要があります。 [static_analysis]
    静的コード解析ツールは、ソフトウェアコードを実行せずに特定の入力を用いて（ソースコード、中間コード、または実行可能ファイルとして）調べます。この基準のために、コンパイラの警告と「安全な」言語モードは、静的コード解析ツールとしてカウントされません（これらは通常、速度が重要なため深い解析を行いません）。このような静的コード解析ツールの例には、cppcheck (C, C++)、clang静的解析 (C, C++)、SpotBugs (Java)、FindBugs (Java) (FindSecurityBugsを含む)、PMD (Java)、Brakeman (Ruby on Rails)、lintr (R)、goodpractice (R), Coverity Quality Analyzer、SonarQube、 Codacyおよび HP Enterprise Fortify Static Code Analyzer.大きなツールのリストは、静的コード解析のためのWikipediaツール一覧, 静的コード解析に関するOWASP情報、 NISTソースコードセキュリティアナライザのリスト、およびウィーラーの静的解析ツール一覧などがあります。 使用する実装言語で使用できるFLOSS静的解析ツールがない場合は、「該当なし」（N/A）を選択します。

    かろうじてバッジには十分です。

    static_analysis基準に使用される静的解析ツールの少なくとも1つが、分析された言語または環境における共通の脆弱性を探すためのルールまたはアプローチを含むことが、推奨されています。 [static_analysis_common_vulnerabilities]
    一般的な脆弱性を探すために特別に設計された静的解析ツールは、それらを見つける可能性が高いです。つまり、静的ツールを使用すると、通常は問題を見つけるのに役立ちますので、利用を提案しますが、「合格」レベルのバッジには要求しません。

    バッジには不十分です。

    静的コード解析で発見された中程度および重大度の悪用可能な脆弱性はすべて、それらが確認された後、適時に修正されなくてはなりません。 [static_analysis_fixed]
    Common Vulnerability Scoring System (CVSS)の基本的な定性的なスコアが中程度以上であれば、脆弱性は中程度以上の深刻度とみなされます。CVSS のバージョン 2.0 から 3.1 では、これは CVSS のスコア 4.0 以上に相当します。プロジェクトは、広く利用されている脆弱性データベース（国家脆弱性データベースなど）で公開されているCVSSスコアを、そのデータベースで報告されている最新バージョンのCVSSを用いて使用することができます。また、脆弱性が公開された時点で計算入力が公開されている場合には、脆弱性が公開された時点でのCVSSの最新バージョンを用いて深刻度を計算することもできます。基準 vulnerabilities_fixed_60_days では、公開後 60 日以内にすべての脆弱性を修正することが要求されていることに注意してください。

    かろうじてバッジには十分です。

    静的ソースコード解析は、コミットごと、または少なくとも毎日実行することをお勧めします。 [static_analysis_often]

  • 動的コード分析


    バッジには十分です！

    リリース前に、ソフトウェアの主要な製品リリースに少なくとも1つの動的解析ツールを適用することが示唆されています。 [dynamic_analysis]
    動的解析ツールは、ソフトウェアを特定の入力で実行して検査します。たとえば、プロジェクトは、ファジングツール（アメリカンファジーロップなど）やウェブ アプリケーション スキャナ（例： ZAP または w3af ）です。場合によっては、 OSS-Fuzz プロジェクトがプロジェクトにファズテストを適用する可能性があります。この基準のために、動的分析ツールは、様々な種類の問題を探すために何らかの方法で入力を変更するかまたは少なくとも80％のブランチ カバレッジを持つ自動テスト スイートである必要があります。 動的解析に関するWikipediaのページと ファジングに関するOWASPページで、いくつかの動的解析ツールを特定しています。解析ツールは、セキュリティの脆弱性を探すことに重点を置くことができますが、これは必須ではありません。

    Evidence that dynamic analysis tools are applied before major production releases:

    1 Multiple Sanitizers in Analysis Workflow

    • .github/workflows/analysis.yml runs dynamic analysis before releases:
    • LeakSanitizer: "detects memory leaks"
    • AddressSanitizer: "fast memory error detector" for buffer overflows, use-after-free, etc.
    • UndefinedBehaviorSanitizer: detects undefined behavior at runtime

    2 Analysis Workflow Integrated into Release Process

    From .github/workflows/daily-build.yml: * uses: ./.github/workflows/analysis.yml * This calls the analysis workflow as part of the build process

    3 Sanitizer Infrastructure Available

    From config/sanitizer/sanitizers.cmake and config/sanitizer/README.md document:

    • HDF5_USE_SANITIZER CMake variable
    • Support for Address, Memory, Undefined, Thread, Leak, and CFI sanitizers
    • All are FLOSS dynamic analysis tools from LLVM/Clang

    Reference: config/sanitizer/README.md states: "Sanitizers are tools that perform checks during a program's runtime"

    4 Coverage Analysis

    From .github/workflows/analysis.yml:

    • Code coverage testing with gcov/lcov
    • While primarily for coverage metrics, it requires executing tests (dynamic analysis)

    5 OSS-Fuzz Integration

    README.md shows OSS-Fuzz badge:

    • Continuous fuzzing (dynamic analysis for vulnerability detection)
    • Indicates ongoing dynamic analysis

    6 Sanitizers Run on Multiple Configurations

    analysis.yml shows sanitizers run with:

    • Different compilers (Clang)
    • Different configurations
    • Automated in CI/CD pipeline

    The project applies multiple FLOSS dynamic analysis tools (LeakSanitizer, AddressSanitizer, UndefinedBehaviorSanitizer, and fuzzing) before releases through automated workflows.


    バッジには十分です！

    プロジェクトで作成されたソフトウェアにメモリ安全でない言語（CやC ++など）を使用して作成されたソフトウェアが含まれている場合、少なくとも1つの動的ツール（たとえば、ファジーまたはウェブ アプリケーション スキャナ）を、バッファの上書きなどのメモリの安全性の問題を検出するメカニズムと一緒にいつも使用します。プロジェクトがメモリ安全でない言語で書かれたソフトウェアを作成しない場合は、「該当なし」（N/A）を選択します。 [dynamic_analysis_unsafe]
    メモリの安全性の問題を検出するメカニズムの例としては、アドレスサニタイザー（ASAN）（GCCおよびLLVMで利用可能）、 Memory Sanitizer 、および valgrind が含まれます。他に使用される可能性のあるツールには、スレッドサニタイザと定義されていない動作サニタイザを参照してください。広範なアサーションも機能します。

    Evidence that dynamic tools are routinely used with memory safety detection for C/C++ code:

    1 HDF5 is Written in Memory-Unsafe Languages

    The project is primarily written in C (with C++ and Fortran wrappers):

    • CONTRIBUTING.md requires "A C11-compatible C compiler"
    • Source code in src/ is C code
    • This is a memory-unsafe language

    2 AddressSanitizer Detects Memory Safety Problems

    .github/workflows/analysis.yml runs AddressSanitizer: * CTEST_MEMORYCHECK_TYPE "AddressSanitizer" * HDF5_USE_SANITIZER:STRING=Address

    AddressSanitizer detects:

    • Buffer overflows (overwrites)
    • Use-after-free
    • Double-free
    • Out-of-bounds accesses

    Reference: config/sanitizer/README.md states AddressSanitizer "is useful for detecting most issues dealing with memory, such as: Out of bounds accesses to heap, stack, global"

    3 LeakSanitizer for Memory Leaks

    .github/workflows/analysis.yml runs LeakSanitizer:

    • CTEST_MEMORYCHECK_TYPE "LeakSanitizer"
    • HDF5_USE_SANITIZER:STRING=Leak

    4 OSS-Fuzz for Fuzzing

    README.md shows OSS-Fuzz badge:

    • Active fuzzing integration
    • Fuzzing is a dynamic tool that generates test inputs
    • Combined with sanitizers to detect memory safety issues

    5 Routine Use Through CI/CD

    The sanitizers run automatically:

    • .github/workflows/daily-build.yml calls analysis.yml
    • Runs on daily schedule
    • Integrated into continuous testing

    6 Multiple Memory Safety Mechanisms

    The project combines:

    • Fuzzing (OSS-Fuzz) - dynamic input generation
    • AddressSanitizer - detects buffer overwrites and memory errors
    • LeakSanitizer - detects memory leaks
    • UndefinedBehaviorSanitizer - detects undefined behavior

    The project routinely uses fuzzing (OSS-Fuzz) combined with AddressSanitizer to detect memory safety problems including buffer overwrites in its C/C++ code.


    バッジには十分です！

    プロジェクトでは、多くのアサーションを可能にする少なくとも一部の動的分析（テストやファジングなど）の構成を使用することをお勧めします。多くの場合、これらのアサーションは本番ビルドでは有効にしないでください。 [dynamic_analysis_enable_assertions]
    この基準は、本番環境でアサーションを有効にすることを示唆するものではありません。それは完全にプロジェクトとそのユーザーが決定することです。この基準の焦点は、展開前の動的分析中の障害検出を改善することです。プロダクション環境でのアサーションの有効化は、動的分析（テストなど）中にアサーションを有効にすることとはまったく異なります。場合によっては、プロダクション環境でアサーションを有効にすることは非常に賢明ではありません（特に高整合性コンポーネントの場合）。プロダクション環境でアサーションを有効にすることには多くの議論があります。たとえば、ライブラリは呼び出し元をクラッシュさせてはなりません。ライブラリが存在するとアプリストアによる拒否が発生する可能性があります。また、プロダクション環境でアサーションをアクティブにすると、秘密鍵などの秘密データが公開される可能性があります。多くのLinuxディストリビューションではNDEBUGが定義されていないため、これらのディストリビューションのプロダクション環境ではデフォルトで C/C++ assert() が有効になります。これらの環境でのプロダクション環境では、別のアサーションメカニズムを使用するか、 NDEBUGを定義することが重要です。

    The project uses configurations with assertions enabled for dynamic analysis:

    1 Developer Mode Enables Assertions

    CONTRIBUTING.md documents developer build options:

    • HDF5_ENABLE_DEVELOPER_MODE=ON enables developer-friendly settings
    • Developer mode is recommended for development builds

    2 Sanitizer Builds Use Debug Configuration

    .github/workflows/analysis.yml runs sanitizers with Debug configuration:

    • Coverage test: ctest -S HDF5config.cmake...CTEST_SOURCE_NAME=${{ steps.set-file-base.outputs.SOURCE_BASE }} -C Debug
    • LeakSanitizer runs with -C Debug
    • AddressSanitizer runs with -C Debug
    • UndefinedBehaviorSanitizer runs with -C Debug

    Debug builds typically enable assertions that are disabled in release builds.

    3 Assertion Macros in Code

    CONTRIBUTING.md shows assertion usage in function structure:

    • FUNC_ENTER_NOAPI(FAIL)

    HDassert(/parameter check/);

    The HDassert macro is used throughout the codebase for parameter checking.

    4 Memory Checker Configuration

    CONTRIBUTING.md documents memory checking option:

    • HDF5_ENABLE_USING_MEMCHECKER:BOOL=ON when using tools like Valgrind
    • This disables internal memory pools to enable better error detection

    Reference: "Use HDF5_ENABLE_USING_MEMCHECKER:BOOL=ON when using tools like Valgrind. This disables internal memory pools that can hide memory issues."

    5 Sanitizer Configuration Separate from Production

    .github/workflows/analysis.yml shows sanitizer builds are separate:

    • Different workflow from production builds
    • Uses specific build options not used in production
    • Runs in "Sanitize" group/model

    6 Coverage Build Uses Debug Settings

    .github/workflows/analysis.yml coverage test:

    • LOCAL_COVERAGE_TEST "TRUE"
    • DHDF5_ENABLE_COVERAGE:BOOL=ON
    • Coverage builds run with instrumentation not suitable for production

    The project uses Debug configuration with assertions enabled for dynamic analysis (sanitizers, fuzzing, testing), which are separate from production builds.


    バッジには十分です！

    動的コード分析で発見されたすべての中程度および重大度の悪用可能な脆弱性は、確認された後、適時に修正されなければなりません。 [dynamic_analysis_fixed]
    動的コード分析を実行しておらず、この方法で脆弱性が見つからない場合は、「該当なし」（N/A）を選択してください。 Common Vulnerability Scoring System (CVSS)の基本的な定性的スコアが中以上の場合、脆弱性は中程度以上の重大度と見なされます。 CVSSバージョン2.0から3.1では、これは4.0以上のCVSSスコアに相当します。プロジェクトは、広く使用されている脆弱性データベース（ National Vulnerability Databaseなど）で公開されているCVSSスコアを、そのデータベースで報告されている最新バージョンのCVSSを使用して使用できます。代わりに、脆弱性が公表された後に計算入力が公開された場合、プロジェクトは脆弱性の開示時に最新バージョンのCVSSを使用して重大度を自ら計算することができます。

    1 Extensive CVE Fixes Documented

    CHANGELOG.md shows that numerous security vulnerabilities have been fixed:

    • CVE-2025-7067 - Heap buffer overflow in H5FS__sinfo_serialize_node_cb()
    • CVE-2025-2915 - Heap-based buffer overflow in H5F__accum_free
    • CVE-2025-7068 - Resource leaks in metadata cache
    • CVE-2025-6816, CVE-2025-6818, CVE-2025-6856, CVE-2025-2923 - Object header vulnerabilities

    And many more...

    2 OSS-Fuzz Integration for Discovery

    README.md shows OSS-Fuzz badge:

    • Continuous fuzzing (dynamic analysis) for vulnerability detection
    • OSS-Fuzz reports vulnerabilities that are then fixed

    Reference: OSS-Fuzz badge indicates active participation in continuous fuzzing program

    3 CVE Regression Testing

    README.md shows CVE regression CI badge:

    • Automated testing to ensure CVE fixes remain effective
    • Prevents reintroduction of vulnerabilities

    4 Security Advisory Process

    SECURITY.md documents vulnerability handling:

    • Private disclosure process for security vulnerabilities
    • "This gives us time to work with you to fix the issue before public exposure"
    • Shows commitment to fixing vulnerabilities before disclosure

    5 GitHub Issues Track Vulnerabilities

    CHANGELOG.md references GitHub issues for each CVE:

    • "Fixes GitHub issue #5577" (CVE-2025-7067)
    • "Fixes GitHub issue #5380" (CVE-2025-2915)
    • "Fixes GitHub issue #5578" (CVE-2025-7068)

    Shows systematic tracking and resolution

    6 Multiple Fixes in Single Release

    Version 2.0.0 includes fixes for 10+ CVEs, demonstrating:

    • Active vulnerability remediation
    • Timely response to discovered issues
    • Comprehensive fixes are released together

    7 Sanitizer Findings Are Addressed

    The project runs sanitizers routinely:

    • AddressSanitizer, LeakSanitizer, UndefinedBehaviorSanitizer
    • Findings from these tools are used to fix memory safety issues
    • Many CVE fixes mention sanitizer-detectable issues (buffer overflows, use-after-free, memory leaks)

    The project demonstrates timely fixing of exploitable vulnerabilities discovered through dynamic analysis (fuzzing, sanitizers), with extensive CVE fixes documented in CHANGELOG.md and systematic tracking through GitHub issues.



This data is available under the Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). This means that a Data Recipient may share the Data, with or without modifications, so long as the Data Recipient makes available the text of this agreement with the shared Data. Please credit Scot Breitenfeld and the OpenSSF Best Practices badge contributors.

プロジェクト バッジ登録の所有者： Scot Breitenfeld.
エントリの作成日時 2023-09-05 17:54:26 UTC、 最終更新日 2025-12-03 17:51:05 UTC