hve-squad

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

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

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


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

Baseline Series: ベースラインレベル1 ベースラインレベル2 ベースラインレベル3

        

 基本的情報 0/5 ●

  • 一般

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

    APM package that assembles HVE Core agents, prompts, instructions, and skills into one installable bundle for Copilot target environments, and ships a Squad Coordinator that routes your request to a cast of agents in parallel.

    SPDXライセンスの表現形式を使用してください。 例：「Apache-2.0」、「BSD-2-Clause」、「BSD-3-Clause」、「GPL-2.0+」、「LGPL-3.0+」、「MIT」、「(BSD-2-Clause OR Ruby)」。一重引用符または二重引用符を含めないでください。
    複数の言語がある場合は、コンマを区切り（スペースを入れてもよい）としてリストし、使用頻度の高いものから順に並べます。使用言語が多くある場合は、少なくとも最初の3つの最も多く使われるものをリストアップしてください。言語がない場合（例：ドキュメントだけ、またはテスト専用のプロジェクトの場合）、1文字 " - "を使用します。言語ごとにある大文字・小文字の慣用を踏襲してください（例：「JavaScript」）。
    Common Platform Enumeration（CPE）は、情報技術（IT）システム、ソフトウェア、およびパッケージのための構造化された命名体系です。脆弱性を報告する際に、多くのシステムやデータベースで使用されています。

  • 前提要件


    バッジには不十分です。

    プロジェクトは、シルバー レベル バッジを達成しなければなりません。 [achieve_silver]

  • プロジェクトの管理・運営


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

    プロジェクトは2以上の "バス ファクタ"を持つ必要があります。 (URLが必要です) [bus_factor]
    「バス ファクタ」（別名「トラック ファクタ」）は、知見があり有能な人材が離脱して、プロジェクトが停止に至る時に、プロジェクトから突然消失する（「バスに当たった」）プロジェクトメンバーの最小人数です。 トラック ファクタツールは、GitHub上のプロジェクトに対してこれを見積もることができます。詳細については、Cosentino et al。の Gitリポジトリのバス ファクタの評価を参照してください。

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

    プロジェクトには少なくとも2人の関係を持たない重要な貢献者がいなければなりません。 (URLが必要です) [contributors_unassociated]
    同じ組織によって作業に対しに支払われ（従業員または請負業者）、組織がプロジェクトの成果の恩恵を受ける場合、貢献者は関連します。財務補助金が他の組織を通過する場合、同じ組織のものであると見なされません（例えば、共通の政府やNGOのソースから異なる組織に支払われた科学補助金は、貢献者を関連させません）。過去1年間にプロジェクトに些細でない貢献をしていれば、その人は大きな貢献をしています。重要な貢献者の良い指標の例としては、少なくとも1,000行のコード、50個のコミット、または少なくとも20ページの文書化が挙げられます。

  • その他


    バッジには不十分です。

    プロジェクトは、各ソースファイルにライセンスステートメントを含まなければなりません。これは、各ファイルの先頭近くに次のコメントを含めることによって行うことができます： SPDXライセンス識別子：[プロジェクトに対するSPDXライセンス表現] [license_per_file]
    これは、ライセンスを特定する自然言語での記述を含めることによっても行うことができます。プロジェクトには、ライセンス テキストまたは完全なライセンステキストを指し示す安定したURLを含めることもできます。 license_location基準は、プロジェクトライセンスが標準の場所にあることを要求します。 SPDXライセンスの詳細については、このSPDXチュートリアルを参照してください。 copyright_per_file との関係に注意してください。その内容は通常、ライセンス情報に先行します。

    The root MIT license does not substitute for a license statement in each source file. SPDX or equivalent per-file notices are not consistently present; for example: https://github.com/Peter-N91/hve-squad/blob/main/site/assets/site.js.


 変更管理 1/4 ●

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


    バッジには十分です！

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

    Repository on GitHub, which uses git. git is distributed.


    バッジには不十分です。

    プロジェクトは、新規または偶に参加する貢献者によって実行できる小さなタスクを明確に識別しなければなりません。 (URLが必要です) [small_tasks]
    この特定は、通常、課題トラッカーの選択された課題に対して、プロジェクトがそのために使用する1つまたは複数のタグ、たとえば、 up-for-grabs（誰でも使用可能）、first-timers-only（初心者専用）、Small fix（小修正）、microtask（小タスク）、またはIdealFirstBug（理想的な最初のバグ）のいずれかをマークすることによって行われます。 これらの新しいタスクには機能を追加する必要はありません。ドキュメントを改善したり、テストケースを追加したり、プロジェクトを支援したり、プロジェクトの詳細を貢献者が理解できるようにすることができます。

    The good first issue label exists, but there are no open issues carrying it at this review. Publish scoped newcomer tasks with sufficient reproduction or acceptance guidance: https://github.com/Peter-N91/hve-squad/issues?q=is%3Aissue%20is%3Aopen%20label%3A%22good%20first%20issue%22.


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

    プロジェクトは、中央リポジトリを変更したり、機密データ（プライベート脆弱性レポートなど）にアクセスするために、開発者に対して二要素認証（2FA）を要求する必要があります。推奨されませんが、2FAメカニズムは、SMSのような暗号化メカニズムを持たないメカニズムを使用することができます。 [require_2FA]

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

    プロジェクトの2要素認証（2FA）は、偽装を防ぐために暗号化メカニズムを使用すべきです。ショート メッセージ サービス（SMS）ベースの2FA自体は、暗号化されていないため、この基準を満たしていません。 [secure_2FA]
    この基準を満たす2FAメカニズムは、一定時間後に変更される認証コードを自動的に生成するタイムベースのワン タイム パスワード（TOTP）アプリケーションです。 GitHubはTOTPをサポートしています。

 品質 0/7 ●

  • コーディング標準


    バッジには不十分です。

    プロジェクトは、コードレビューの実施方法、チェックする必要があるもの、受け入れられる必要があるものなど、コードレビュー要件を文書化しなければなりません。 (URLが必要です) [code_review_standards]
    two_person_review とcontribution_requirementsも参照してください。

    Contribution guidance and the PR template cover maintainer review, tests, and sanitization, but do not fully document the general reviewer procedure, required checks, and acceptance criteria: https://github.com/Peter-N91/hve-squad/blob/main/CONTRIBUTING.md and https://github.com/Peter-N91/hve-squad/blob/main/.github/pull_request_template.md.


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

    プロジェクトは、公開する前に、提案されたすべての変更の少なくとも50％を著作者以外の人がレビューして、それが価値のある変更であり、取り込みに反対する既知の問題がないかどうかを判断しなければなりません。 [two_person_review]

  • 作業ビルドシステム


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

    プロジェクトが再現可能なビルドを持たなければなりません。ビルドが発生しない場合（たとえば、コンパイルされないでソースコードが直接使用されるスクリプト言語）、「該当なし」（N/A）を選択します。 (URLが必要です) [build_reproducible]
    再現可能なビルドは、複数の当事者がソース ファイルから情報を生成するプロセスを独立にやり直し、ビット単位でまったく同じ結果を得られることを意味します。ある場合には、これ（再現可能なビルド）は、あるソート順を強いることで解決されます。Javaスクリプトの開発者は、npm shrinkwrapとwebpack OccurenceOrderPluginの使用を検討するかもしれません。GCCとclangのユーザーは、-frandom-seedオプションが有用であることを見つけるかもしれません。ビルド環境（ツールセットを含む）は、リビルドに使用できる特定のコンテナや仮想マシンの暗号化ハッシュを指定することによって、外部パーティのために、しばしば定義可能です。再現可能なビルド プロジェクトは、これを行う方法を記載したドキュメントを有します。

  • 自動テスト スイート


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

    テストスイートは、その言語の標準的な方法で呼び出すことができなければなりません。 (URLが必要です) [test_invocation]
    たとえば、「make check」、「mvn test」、「rake test」（Ruby）などです。

    Tests are invoked in the standard way for PowerShell. Each suite is executed through Invoke-Pester with New-PesterConfiguration, the conventional Pester entry point, wrapped in a per-tier runner script (tests/tier0/Invoke-Tier0Tests.ps1 and equivalents for Tier 1 and Tier 2). The wrappers are required because the suites are parameterised through New-PesterContainer -Data, so they cannot be discovered by a bare Invoke-Pester call. A single-command entry point is also declared as the test target in the scripts: section of apm.yml, so apm run test runs the fast conformance suite in the same way make check would. CI invokes the same runner scripts, so local and CI invocation are identical.

    警告：URLが必要ですが、URLは見つかりません。


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

    プロジェクトは、新しいコードまたは変更されたコードが頻繁に中央コードリポジトリに統合され、その結果に対して自動化されたテストが実行される、継続的な統合を実装しなければなりません。 (URLが必要です) [test_continuous_integration]
    ほとんどの場合、これは、プロジェクトでフルタイムで働く各開発者が少なくとも1日に1回統合作業をすることを意味します。

    The project practises continuous integration against a single central repository. All changes land on main through squash-merged pull requests, with 103 commits integrated in the last 30 days, and branches are short-lived. Every pull request triggers automated validation in GitHub Actions: .github/workflows/tier0-conformance.yml installs the package the branch would deliver and runs the Pester static conformance suite against it, and .github/workflows/pr-validation.yml verifies release state and change-fragment hygiene. Security analysis runs on the same trigger through CodeQL, Zizmor, Checkov, and OpenSSF Scorecard. The same Tier 0 workflow is reused as the release gate via workflow_call, so the check that guards a merge is the check that guards a tag. Merged work is rebuilt onto a rolling pre-release tag within minutes, keeping the integrated state continuously installable and testable.

    警告：URLが必要ですが、URLは見つかりません。


    バッジには不十分です。

    プロジェクトは、選択された言語でこの基準を測定できる少なくとも1つのFLOSSツールがある場合、少なくとも80％のステートメント カバレッジを提供するFLOSS自動テストスイートを備えていなければなりません。 [test_statement_coverage90]

    No published instrumented result demonstrates at least 90% statement coverage of the authored executable code. Establish an explicit coverage scope, publish reports, and enforce the measured threshold: https://github.com/Peter-N91/hve-squad/tree/main/tests.


    バッジには不十分です。

    選択された言語でこの基準を測定できる少なくとも1つのFLOSSツールがあれば、少なくとも80％のブランチカバレッジを提供するFLOSS自動テストスイートがプロジェクトに存在しなければなりません。 [test_branch_coverage80]

    No published instrumented result demonstrates at least 80% branch coverage of the authored executable code. Use a FLOSS tool that actually measures branches for each applicable language and retain the reports: https://github.com/Peter-N91/hve-squad/tree/main/tests.


 セキュリティ 2/5 ●

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

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

    バッジには十分です！

    プロジェクトで作成されたソフトウェアは、ネットワーク通信すべてに対して、SSHv2以降、TLS1.2以降 (HTTPS)、IPsec、SFTP、SNMPv3などのセキュア プロトコルをサポートしなければなりません。FTP、HTTP、telnet、SSLv3以前、SSHv1などのセキュアでないプロトコルは、デフォルトで無効にしておき、ユーザーが特別に設定した亜場合のみ有効にしなければなりません。プロジェクトによって作成されたソフトウェアがネットワーク通信をサポートしない場合は、「該当なし」（N/A）を選択します。 [crypto_used_network]

    Project-authored repository and API operations use HTTPS by default through Git and PowerShell; no plaintext transport is enabled by default in those scripts: https://github.com/Peter-N91/hve-squad/blob/main/scripts/Update-ApmDependencies.ps1 and https://github.com/Peter-N91/hve-squad/blob/main/scripts/Test-HveCorePin.ps1.


    バッジには十分です！

    プロジェクトによって作成されたソフトウェアは、TLSをサポートあるいは使用する場合、少なくともTLSバージョン1.2をサポートしなければなりません。TLSの前身は、SSLと呼ばれていたことに注意して下さい。ソフトウェアがTLSを使用ない場合、「該当なし」（N/A）を選択します。 [crypto_tls12]

    The supported PowerShell 7/.NET and Git HTTPS clients support TLS 1.2 or later, with the TLS implementation delegated to the maintained host clients rather than project-authored cryptography: https://github.com/Peter-N91/hve-squad/blob/main/README.md#quick-start and https://github.com/Peter-N91/hve-squad/blob/main/scripts/Test-HveCorePin.ps1.


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


    バッジには不十分です。

    プロジェクトウェブサイト、リポジトリ（ウェブからアクセス可能な場合）、およびダウンロードサイト（別々の場合）には、許容できない値を持つキー強化ヘッダーが含まれていなければなりません。 (URLが必要です) [hardened_site]
    GitHubやGitLabはこれを満たしていることが知られているので注意してください。https://securityheaders.com/ のようなサイトは、これをすぐに確認することができます。重要なセキュリティ強化ヘッダーは以下の通りです。Content Security Policy (CSP)、HTTP Strict Transport Security (HSTS)、X-Content-Type-Options (「nosniff」として)、および X-Frame-Options 。Web ページからログインする機能のない完全に静的な Web サイトでは、いくつかの強化ヘッダーを省略してもリスクは少なくて済みますが、そのようなサイトを検出する信頼できる方法がないため、完全に静的なサイトであってもこれらのヘッダーが必要です。

    The documentation site's HTTP response includes HSTS but did not include Content-Security-Policy, X-Content-Type-Options, or X-Frame-Options at this review. Gold requires all four even for a static site. GitHub repository/release pages supply them; the Pages site needs a hosting/header solution: https://peter-n91.github.io/hve-squad/.


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


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

    プロジェクトは過去5年間にセキュリティレビューを実施していなければなりません。このレビューは、セキュリティ要件とセキュリティ境界を考慮しなければならりません。 [security_review]
    これは、プロジェクトメンバーおよび/または独立した評価によって行うことができます。この評価は、静的および動的解析ツールによってサポートされることができますが、ツールが検出できない問題（特に設計上）を特定するためには、人間によるレビューが必要です。

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

    プロジェクトによって作成されたソフトウェアで強化メカニズムを使用しなければならないので、ソフトウェア欠陥がセキュリティ上の脆弱性を引き起こす可能性が低くなります。 (URLが必要です) [hardening]
    強化メカニズムは、Content Security Policy（CSP）などのHTTPヘッダー、攻撃を緩和するコンパイラ フラグ（-fstack-protectorなど）、または未定義の動作を排除するためのコンパイラ フラグを含みます。私たちの目的のために、最低限の特権は強化メカニズムとはみなされません（最低の特権は重要ですが、別の話です）。

 分析 1/2 ●

  • 動的コード分析


    バッジには不十分です。

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

    The project applies automated testing before release but does not currently meet the specific bar this criterion sets. The release gate is the Tier 0 conformance suite, which installs the package exactly as a consumer receives it and executes 575 Pester assertions against the installed tree. Tier 1 additionally performs live behavioural runs against fixture repositories, executing the squad end to end and asserting on the state artifacts left on disk, and Tier 2 compares a live run against stored semantic baselines. However, none of these vary their inputs in the manner of a fuzzer or scanner: Tier 1 exercises a fixed set of recorded scenarios. Branch coverage is also not instrumented, since none of the tier runners enable Pester's CodeCoverage configuration, so the project cannot demonstrate the 80% threshold this criterion offers as an alternative. Coverage of the PowerShell build scripts would in any case be low, because Tier 0 asserts against an installed package tree rather than executing those scripts. Planned improvements are to enable Pester code coverage reporting in CI to establish a measured baseline, and to add unit tests for the build and release scripts, which are currently the least-covered executable surface.


    バッジには十分です！

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

    The test configuration deliberately enables more assertions than a normal run. The suites are assertion-based throughout, with 575 Pester assertions executing in the Tier 0 conformance run alone, and every case traces to a numbered entry in tests/squad-behavior-contract.md. Two switches exist specifically to widen assertion coverage during analysis. Tier 1's -Strict promotes consumption findings, which are advisory during a live run, to blocking during the self-check, on the reasoning that a mutation the contract merely mentions is a mutation it does not catch. Tier 0's -IncludeAdvisory enables additional assertion cases that are otherwise reported without gating. Tier 1 also ships mutation controls invoked with -SelfCheck, where each case breaks exactly one rule and requires the contract to detect it, which is the evidence that the assertions can fail rather than passing vacuously. All PowerShell scripts, modules, and test runners execute under Set-StrictMode -Version Latest with $ErrorActionPreference = 'Stop', turning uninitialised variable references, non-existent property access, and malformed method calls into terminating errors during analysis. Tier 0 additionally treats a run that produces zero tests as a failure, so a discovery error cannot be mistaken for success. None of this carries into what consumers receive: the shipped package is markdown assets with no runtime assertion machinery, so there is no production assertion cost or disclosure risk.



ツールやAIシステムを使って、https://www.bestpractices.dev/ja/projects/14231/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforcedのような簡単なURLで変更を提案できます。その方法については、自動化提案システムをご覧ください。 このデータは、Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0)のもとで利用可能です。これは、データ受領者が、データ受領者がこの契約のテキストを共有データとともに利用可能にする限り、変更の有無にかかわらずデータを共有できることを意味します。Peter NehmeおよびOpenSSFベストプラクティスバッジのコントリビューターにクレジットを表示してください。

プロジェクト バッジ登録の所有者： Peter Nehme.
エントリの作成日時 2026-08-25 06:53:21 UTC、 最終更新日 2026-10-19 21:45:30 UTC 最後に2026-08-25 08:33:58 UTCにバッジ合格を達成しました。