基準の説明

ソフトウェアに欠陥や脆弱性がないことを保証できる一連のプラクティスはありません。正式な手法であっても、仕様や仮定が間違っていれば失敗する可能性があります。また、プロジェクトが健全で機能的な開発コミュニティを維持することを保証できる一連のプラクティスもありません。

しかし、ベストプラクティスに従うことで、プロジェクトの成果を向上させることができます。たとえば、リリース前に複数人によるレビューを可能にするプラクティスもあります。これは、発見しにくい技術的な脆弱性を発見するのに役立ち、異なる組織の開発者の間で信頼を築き、繰り返しやりとりすることができます。

このページでは、Open Source Security Foundation (OpenSSF) のベストプラクティスバッジのために開発された、Free/Libre and Open Source Software (FLOSS) プロジェクトのためのベストプラクティスのセットについて説明します。これらのベストプラクティスに従っているプロジェクトは、自主的に自己認証を行い、関連するバッジを達成したことを示すことができます。プロジェクトは、Webアプリケーション (BadgeApp) を使用して、どのようにしてこれらのベストプラクティスとその詳細な基準を満たしているかを説明することで、無料でこれを行うことができます。

これらのベストプラクティスは、以下の目的で作成されました。

プロジェクトがベストプラクティスに従うことを奨励する。
新しいプロジェクトがそれらのプラクティスを発見するのを助ける。
どのプロジェクトがベストプラクティスに従っているのかをユーザーが知るのに役立つ（結果としてユーザーがそのようなプロジェクトを好むようになる）。

イディオム「ベストプラクティス」とは、「組織、業界などで推奨または標準と見なされる手順または一連の手順」を意味します。（出典：Dictionary.com）。これらの基準は、より広いFLOSSコミュニティで広く「推奨または標準と見なされている」と私たちが信じているものです。

これらの基準がどのように開発されたかの詳細については、OpenSSF Best PracticesバッジGitHubサイトを参照してください。

また、完全な基準を見ることもできます。

基準の構造

ベストプラクティスの基準は次の3レベルに分かれています。

Pass（合格）は、適切に実行されているFLOSSプロジェクトが通常従うベストプラクティスに焦点を当てています。合格バッジを取得することは成果です。バッジを追求しているプロジェクトのうち、一度で合格レベルに達成するプロジェクトはわずか10%ほどです。
Silver（シルバー） はPassよりも厳しい基準ですが、小規模で単一組織のプロジェクトによって達成できるでしょう。
Gold（ゴールド）はシルバーよりもさらに厳しく、小規模または単一組織のプロジェクトでは達成できない基準が含まれています。

各基準には短い名前が付けられており、基準テキストの後の角括弧内に上付きのテキストとして表示されています。

他のプロジェクトとの関係

Linux Foundationは、「高品質のフリーおよびオープンソースソフトウェア（FOSS）コンプライアンスプログラム」の基準を特定する OpenChain Projectも後援しています。OpenChainは、組織がFLOSSを最適に使用し、FLOSSプロジェクトに貢献する方法に焦点を当てていますが、OpenSSFベストプラクティスバッジは、FLOSSプロジェクト自体に焦点を当てています。 OpenSSFベストプラクティスバッジとOpenChainは連携して、FLOSSとFLOSSの使用方法を改善します。

基準の自動化

場合によっては、プロジェクトが標準の規則に従っていて、適切なAPIサポートを備えたサイト（GitHubなど）でホストされている場合、情報を自動的にテストして入力します。

将来的には、この自動化を改善する予定です。自動化の改善は大歓迎です！

ただし、手頃な価格で自動化できない場合でも、意図的に「重要なこと」を優先しています。自動測定は確かに素晴らしいですが、重要なものをすべて自動化できるわけでも、手頃な価格で自動化できるわけでもありません。

時間の経過による変化

これらの慣行とその詳細な基準は、時間の経過とともに更新されることを期待しています。新しい基準を追加する予定ですが、それを「将来の」基準としてマークしておくことで、プロジェクトがその情報を追加してバッジを維持できるようにします。

フィードバックは大歓迎です。GitHubサイトからイシューやプルリクエストで提出してください。一般的な議論のためのメーリングリストもあります。

キーワード

このドキュメントの英語のキーワード、"MUST"、"MUST NOT"、 "SHOULD"、"SHOULD NOT"、および "MAY" は、RFC 2119 で説明されているように解釈されます。"SUGGESTED" も追加されています。要約すると、これらのキーワードには次の意味があります。

MUST（～なければならない）は絶対的な要件であり、MUST NOT（～してはならない）は絶対的な禁止です。
SHOULD（～べきである）という用語は、通常必要とされる基準を示しますが、特定の状況ではそれを無視する正当な理由が存在する場合があります。ただし、別のコースを選択する前に、完全な影響を理解し、慎重に検討する必要があります。
基準を考慮する必要がある場合は、SHOULDの代わりにSUGGESTED（推奨される）という用語が使用されますが、SHOULDよりもさらに一般的に「そうしない正当な理由」が存在します。
MAY（～ことができる）という用語は、記述された実装が受け入れ可能であることを明確にするためなど、何かを行うことができる方法の一つを提供します。

実装が困難な場合や、実装コストが高い可能性がある場合は、実行するべきである（SHOULD）や、推奨される（SUGGESTED）と記述されます。

バッジの取得

バッジを取得するには、すべてのMUSTおよびMUST NOTの基準については「満たしている必要があり」、すべてのSHOULDの基準については「満たしているか、正当な理由で満たしていない必要があり」、そしてすべてのSUGGESTEDの基準については、「考慮している必要がある（満たしているか満たしていないかを評価されるが、時に明記されていない限り正当な理由は必要ない）」となります。N/A（「該当しない」）の回答は、これが許可されている場合は、「満たしている」と同じと見なされます。場合によっては、特に上位レベルでは、正当化やURLが必要になることがあります。

一部の基準には、これに影響を与える特別なマークがあります。

{N/A allowed} - "N/A" ("該当しない") が許可されている。
{N/A justification} - "N/A" ("該当しない") が許可されているが、正当な理由が必要。
{Met justification} - "適合" には正当な理由が必要。
{Met URL} - "適合" にはURLによる正当化が必要。
{Future} - この基準への回答は現在は効果がないが、将来必要になる可能性がある。

プロジェクトは、次のレベルを達成するために前のレベルを達成する必要があります。場合によっては、SHOULD基準がより高いレベルのバッジではMUSTになり、低レベルのSUGGESTED基準がより高いレベルのバッジではSHOULDまたはMUSTになることもあります。また、基準がどのように満たされているかを他の人に理解してもらいたいため、高レベルのバッジにはより多くの正当性が求められます。

一部のソフトウェアは暗号化機能を直接使用する必要がないため、（多くの）暗号化基準が常に適用されるとは限りません。そのような場合は、N/Aと答えてください。

暗黙の合格基準が1つあります。すべてのプロジェクトには、安定したURLを持つ公開Webサイトが必要（MUST）です。これは、最初にバッジエントリを作成するために必要です。

用語

ソフトウェア開発やFLOSSプロジェクトの実行に慣れていない場合は、KarlFogelによるオープンソースソフトウェアの作成などの資料が役立つ場合があります。

重要な用語をいくつかご紹介します。

A プロジェクトは、プロジェクトメンバーがいて、プロジェクト結果を生成するアクティブなエンティティです。そのメンバーは、プロジェクトサイトを使用して、結果を調整および配布します。プロジェクトは正式な法人である必要はありません。
プロジェクト メンバーは、プロジェクトの結果を生み出すために協力する1人以上の人々または企業のグループです。一部のFLOSSプロジェクトには、さまざまな種類のメンバーとさまざまな役割がありますが、それは私たちの範囲外です。
プロジェクトの成果物は、プロジェクトメンバーが協力して最終目標として作成するものです。通常、これはソフトウェアですが、プロジェクトの結果には他のものも含まれる場合があります。「プロジェクトによって作成されたソフトウェア」を参照する基準は、プロジェクトの成果物を参照しています。
プロジェクト サイトは、プロジェクトの成果物の開発・普及を支援するためのサイトであり、プロジェクトのWebサイト、リポジトリ、ダウンロードサイトなどが含まれます（sites_httpsを参照)。
プロジェクトのWebサイト、別名プロジェクトのホームページは、新規ユーザーがプロジェクトの情報を見るために訪れるワールドワイドウェブ（WWW）上のメインページです。プロジェクトのリポジトリサイトと同じである可能性があります（GitHubなど）。
プロジェクト リポジトリは、プロジェクトの成果物とその成果物の改訂履歴を管理・保存します。自動生成された成果物ではなく、編集可能なバージョンの管理・保存のみを行うことを求めているため、プロジェクトのソースリポジトリとも呼ばれています（生成された成果物はリポジトリに保存されていないことが多い）。
プロジェクトのセキュリティメカニズム提供されたプロジェクトのソフトウェアによって提供されるセキュリティメカニズムです。

基準に含まれないもの

基準とは：

特定のテクノロジー、製品、またはサービスを必要としません。たとえば、git、GitHub、GitLabは必要ありません。基準は、一般的なケースのガイダンスとヘルプを提供します。その情報は、人々が基準を理解して満たすのに役立つためです。 gitまたはGitHubを使用するプロジェクトには、これらの一般的なケースでユーザーを支援するための特別な自動化がいくつかありますが、必須ではありません。したがって、新しいツールと機能が利用可能になると、プロジェクトはすぐにそれらに切り替えることができます。例外として、基準にはプロジェクトのWebページとTLSが必要です。
特定のプログラミング言語を要求したり禁止したりしません。特定の種類のプログラミング言語に対して追加の対策をとることを要求しますが、それは別のことです。
プロプライエタリなソフトウェア、プロプライエタリなサービス、プロプライエタリな技術の使用を決して要求しません。多くのフリーソフトウェア開発者はそのような基準を拒否するからです。プロジェクトがそれらを使用し依存することは許可されます。
プロジェクト内での積極的な開発やユーザーディスカッションは必要ありません。一部の高度に成熟したプロジェクトはめったに変更されないため、ほとんどアクティビティがない場合があります。ただし、この基準では、脆弱性がプロジェクトに報告された場合にプロジェクトが応答する必要があります。
バッジを取得するための料金は必要ありません。
すべての基準を一度に実装する必要はありません。ほとんどのプロジェクトは、時間をかけて実装しています。

合格レベルの基準には、たとえば多額の資金を必要とするものなど、1人で行うプロジェクトでは現実的ではないような基準は含まれていません。多くのFLOSSプロジェクトは小規模であり、彼らの権利を奪うことは避けたいと考えています。

プロジェクトの特定

私たちのアプリケーションはすべてのプロジェクトエントリに一意のIDを与えますが、それはプロジェクトを検索する人々を助けません。アプリケーションにとって、プロジェクトの実名はそのリポジトリのURLであり、それが利用できない場合は、プロジェクトの「フロントページ」のURLです。このURLへの変更をレート制限して、無意味な変更を防止しています。通常、プロジェクトには人間が読める名前が付いていますが、これらの名前は一意ではありません。

なぜ基準があるのか?

論文Open badges for education: what are the implications at the intersection of open systems and badging?（教育のためのオープンバッジ：オープンシステムとバッジ機能の接点がもたらす成果）では、バッジシステムが有効な一般的な理由として、以下の3つを挙げています（すべて当てはまります）。

バッジは行動の動機づけになります。ベストプラクティスを特定することで、それらのベストプラクティスをまだ実行していないプロジェクトにその実行を推奨します。
教育ツールとしてのバッジ。一部のプロジェクトは、他のプロジェクトによって適用されたベストプラクティスのいくつか、またはそれらを実際に適用する方法を認識していない場合があります。バッジは、彼らがそれらとそれらを実装する方法を認識するのに役立ちます。
シニフィアン（記号表現）やクレデンシャルとしてのバッジ。潜在的なユーザーは、ベストプラクティスを適用しているプロジェクトを使用して、一貫して良好な結果を生み出したいと考えています。バッジを使用すると、プロジェクトがベストプラクティスに従っていることを簡単に示すことができ、ユーザーはどのプロジェクトがそれを行っているかを簡単に確認できます。

なぜ自己認証なのか？

私たちが自己認証を採用した理由は、多くのプロジェクト（小さなプロジェクトであっても）が参加できるようにするためです。何百万ものFLOSSプロジェクトがあり、サードパーティにお金を払って個々に評価することはできません。プロジェクトが虚偽の主張をするリスクはありますが、そのリスクは小さく、ユーザーが自分で主張を確認でき、虚偽の主張を無効にすることができます。また、自動化を使用して虚偽の主張を無効にできるため、結果に自信を持つことができます。