BadgeApp

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

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

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


これらはベースラインレベル1の基準です。

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

        

 基本的情報

  • 識別情報

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

    BadgeApp is the web application that allows developers to provide information about their project and (hopefully) get an Open Source Security Foundation (OpenSSF) Best Practices badge. This project was originally known as the Core Infrastructure Initiative (CII) best practices badge project.

    The Open Source Security Foundation (OpenSSF) is managed by The Linux Foundation. The OpenSSF Best Practices badge online application (aka the BadgeApp) enables developers to quickly determine whether they are following best practices and to receive a badge they can display on GitHub and other locations. The application and its criteria are an open source project to which developers can contribute.

    You can see the program running, and use it to try to get a badge, by visiting: https://bestpractices.coreinfrastructure.org/

    The BadgeApp is written in Ruby on Rails and Javascript.

    See the development site on GitHub for more about how we secure this application.

    Note that the BadgeApp gets its own badge!

 管理策 24/24 ●

  • 管理策


    バッジには十分です！

    ユーザーがプロジェクトの権威リポジトリにある機密リソースを読み取ったり変更したりしようとする場合、システムは多要素認証プロセスの完了をユーザーに要求しなければなりません。 [OSPS-AC-01.01]
    プロジェクトのバージョン管理システムに多要素認証を強制し、協力者が機密データにアクセスしたりリポジトリ設定を変更したりする際に第2の認証形式を提供するよう要求します。パスキーはこの管理として許容されます。

    The authoritative repository is hosted on GitHub, which requires multi-factor authentication to modify sensitive resources or to read sensitive resources like keys. GitHub allows anyone to read publicly available resources (such as the source code), and that's fine.


    バッジには十分です！

    新しい協力者が追加される場合、バージョン管理システムは手動による権限割り当てを要求するか、デフォルトで協力者の権限を最低利用可能な特権に制限しなければなりません。 [OSPS-AC-02.01]
    ほとんどの公開バージョン管理システムは、この方法で設定されています。プロジェクトのバージョン管理システムが、協力者を追加する際にデフォルトで常に利用可能な最低限の権限を割り当て、必要な場合にのみ追加の権限を付与するように設定してください。

    New collaborators are only given lowest available privileges. We generally don't add many collaborators who can directly edit the software, but instead ask people to fork the repository and create pull requests from them, which gives them no privileges by default.


    バッジには十分です！

    プロジェクトのプライマリブランチに直接コミットが試行された場合、強制メカニズムが変更の適用を防止しなければなりません。 [OSPS-AC-03.01]
    バージョン管理システムが集中型の場合は、プロジェクトのバージョン管理システムのプライマリブランチにブランチ保護を設定してください。あるいは、Linuxカーネルのような分散型アプローチを使用します。この場合、変更はまず別のリポジトリで提案され、プライマリリポジトリへの変更のマージには特定の個別の操作が必要です。

    Our main branch is protected (it's named main).


    バッジには十分です！

    プロジェクトのプライマリブランチの削除が試行された場合、バージョン管理システムはこれを機密性の高い活動として扱い、意図の明示的な確認を要求しなければなりません。 [OSPS-AC-03.02]
    プロジェクトのバージョン管理システムのプライマリブランチにブランチ保護を設定して削除を防止してください。

    GitHub requires this.


    バッジには十分です！

    CI/CDパイプラインが入力パラメータを受け取る場合、そのパラメータはパイプラインで使用する前にサニタイズおよび検証されなければなりません。 [OSPS-BR-01.01]

    Other the branch name we don't use input parameters. See below in OSPS-BR-01.02 for branch names.


    バッジには十分です！

    CI/CDパイプラインがその機能でブランチ名を使用する場合、その名前の値はパイプラインで使用する前にサニタイズおよび検証されなければなりません。 [OSPS-BR-01.02]

    Branch names are checked before they are used if they are used. Note that the scorecard workflow doesn't use the branch name, so it doesn't check it easier (we can't add that check because the scorecard workflow is only allowed to do certain things).


    バッジには十分です！

    プロジェクトがURIを公式プロジェクトチャンネルとしてリストする場合、そのURIは暗号化されたチャンネルを使用して排他的に配信されなければなりません。 [OSPS-BR-03.01]
    プロジェクトのウェブサイトおよびバージョン管理システムを、データ送信にSSHまたはHTTPSなどの暗号化されたチャンネルを使用するように設定してください。プロジェクトドキュメントで参照されるすべてのツールとドメインが、暗号化されたチャンネルを介してのみアクセスできるようにしてください。

    https: is always used.


    バッジには十分です！

    プロジェクトがURIを公式配布チャンネルとしてリストする場合、そのURIは暗号化されたチャンネルを使用して排他的に配信されなければなりません。 [OSPS-BR-03.02]
    プロジェクトのリリースパイプラインを、SSHまたはHTTPSなどの暗号化されたチャンネルを使用してデータ送信を行うウェブサイト、APIレスポンス、およびその他のサービスからのみデータを取得するように設定してください。

    https: is always used.


    バッジには十分です！

    プロジェクトは、シークレットや認証情報などの暗号化されていない機密データが、バージョン管理システムに意図せず保存されることを防止しなければなりません。 [OSPS-BR-07.01]
    機密情報を含む可能性のあるファイルを除外するために、.gitignoreまたは同等のものを設定してください。プリコミットフックおよび自動スキャンツールを使用して、コミットに機密データが含まれることを検出および防止してください。

    We enable secret scanning to prevent this.


    バッジには十分です！

    プロジェクトがリリースを行った場合、プロジェクトドキュメントには、すべての基本機能に対するユーザーガイドを含まなければなりません。 [OSPS-DO-01.01]
    プロジェクトのすべての基本機能について、インストール、設定、およびプロジェクトの機能の使用方法を説明するユーザーガイドまたはドキュメントを作成してください。既知の危険な行為または破壊的な行為が利用可能な場合は、非常に目立つ警告を含めてください。

    The project doesn't create "releases" for many to download and install. Its primary purpose is to be a specific website's implementation. Therefore, it must be completely usable without any "user guides" for end users (who spend relatively little time on the site). We do have guides for setting up and running the site, primarily to enable others to install it so they can add features to it as proposals.


    バッジには十分です！

    プロジェクトがリリースを行った場合、プロジェクトドキュメントには、欠陥報告のためのガイドを含まなければなりません。 [OSPS-DO-02.01]
    プロジェクトでは、バージョン管理システムのデフォルトの課題追跡ツールを使用することをお勧めします。外部ソースが使用される場合は、プロジェクトドキュメントと貢献ガイドで報告システムの使用方法を明確かつ目立つように説明してください。プロジェクトドキュメントでは、欠陥がどのようにトリアージおよび解決されるかについての期待値を設定することもお勧めします。

    See SECURITY.md for how to report defects.


    バッジには十分です！

    アクティブな間、プロジェクトには、提案された変更および使用上の障害に関する公開討論のための1つ以上のメカニズムがなければなりません。 [OSPS-GV-02.01]
    メーリングリスト、インスタントメッセージング、または課題追跡ツールなど、プロジェクト内の公開討論のための1つ以上のメカニズムを確立し、オープンなコミュニケーションとフィードバックを促進してください。

    GitHub provides issues and pull requests. We also use a mailing list.


    バッジには十分です！

    アクティブな間、プロジェクトドキュメントには、貢献プロセスの説明を含まなければなりません。 [OSPS-GV-03.01]
    変更の提出手順やプロジェクトメンテナーとのやり取りを含む、貢献プロセスの概要を示すCONTRIBUTING.mdまたはCONTRIBUTING/ディレクトリを作成します。

    See CONTRIBUTING.md.


    バッジには十分です！

    アクティブな間、ソースコードのライセンスはOSIオープンソース定義またはFSFフリーソフトウェア定義を満たす必要があります。 [OSPS-LE-02.01]
    OSI（Open Source Initiative）によって承認されたライセンス、またはFSF（Free Software Foundation）によって承認されたフリーライセンスを含むLICENSEファイルをプロジェクトのリポジトリに追加します。そのようなライセンスの例としては、MIT、BSD 2-clause、BSD 3-clause revised、Apache 2.0、Lesser GNU General Public License（LGPL）、およびGNU General Public License（GPL）が含まれます。特許などの他の障害がない場合、パブリックドメインへのリリースはこの管理を満たします。

    We use the MIT license, which meets the OSI Open Source Definition and the Free Software Definition.


    バッジには十分です！

    アクティブな間、リリースされたソフトウェア資産のライセンスはOSIオープンソース定義またはFSFフリーソフトウェア定義を満たす必要があります。 [OSPS-LE-02.02]
    リリースされたソフトウェア資産に異なるライセンスが含まれている場合は、OSI（Open Source Initiative）によって承認されたライセンス、またはFSF（Free Software Foundation）によって承認されたフリーライセンスであることを確認してください。そのようなライセンスの例としては、MIT、BSD 2-clause、BSD 3-clause revised、Apache 2.0、Lesser GNU General Public License（LGPL）、およびGNU General Public License（GPL）が含まれます。リリースされたソフトウェア資産のライセンスはソースコードとは異なる場合があることに注意してください。

    We use the MIT license, which meets the OSI Open Source Definition and the Free Software Definition.


    バッジには十分です！

    アクティブな間、ソースコードのライセンスは、対応するリポジトリのLICENSEファイル、COPYINGファイル、またはLICENSE/ディレクトリに維持される必要があります。 [OSPS-LE-03.01]
    ライセンス条件に関する可視性と明確性を提供するために、プロジェクトのソースコードライセンスをプロジェクトのLICENSEファイル、COPYINGファイル、またはLICENSE/ディレクトリに含めます。ファイル名には拡張子を付けることができます。プロジェクトに複数のリポジトリがある場合は、各リポジトリにライセンスファイルが含まれていることを確認してください。

    See file LICENSE for the source code.


    バッジには十分です！

    アクティブな間、リリースされたソフトウェア資産のライセンスは、リリースされたソースコードに、またはリリース資産と一緒にあるLICENSEファイル、COPYINGファイル、またはLICENSE/ディレクトリに含まれている必要があります。 [OSPS-LE-03.02]
    ライセンス条件に関する可視性と明確性を提供するために、プロジェクトのリリースされたソフトウェア資産のライセンスを、リリースされたソースコードに、または対応するリリース資産と一緒にあるLICENSEファイル、COPYINGファイル、またはLICENSE/ディレクトリに含めます。ファイル名には拡張子を付けることができます。プロジェクトに複数のリポジトリがある場合は、各リポジトリにライセンスファイルが含まれていることを確認してください。

    See file LICENSE for the source code.


    バッジには十分です！

    アクティブな間、プロジェクトのソースコードリポジトリは、静的URLで公開読み取り可能である必要があります。 [OSPS-QA-01.01]
    GitHub、GitLab、Bitbucketなどの一般的なVCSを使用します。リポジトリが公開読み取り可能であることを確認してください。主要なソースを明確にする可視性の高いドキュメントがない限り、リポジトリの複製またはミラーリングを避けてください。リポジトリURLに影響を与える可能性のある頻繁なリポジトリの変更を避けてください。リポジトリが公開されていることを確認してください。

    バッジには十分です！

    バージョン管理システムには、行われたすべての変更、誰が変更を行ったか、いつ変更が行われたかの公開読み取り可能な記録が含まれている必要があります。 [OSPS-QA-01.02]
    GitHub、GitLab、Bitbucketなどの一般的なVCSを使用して、公開読み取り可能なコミット履歴を維持します。コミットの作成者が不明瞭になるような方法でコミットをスカッシュまたは書き換えることは避けてください。

    バッジには十分です！

    パッケージ管理システムがサポートしている場合、ソースコードリポジトリには、直接の言語依存関係を説明する依存関係リストが含まれている必要があります。 [OSPS-QA-02.01]
    これは、package.json、Gemfile、go.modなど、すべての直接依存関係を列挙するパッケージマネージャーまたは言語依存関係ファイルの形式を取ることができます。

    バッジには十分です！

    アクティブな間、プロジェクトのドキュメントには、サブプロジェクトと見なされるコードベースのリストが含まれている必要があります。 [OSPS-QA-04.01]
    プロジェクトによって生成され、リリースにコンパイルされる追加のサブプロジェクトコードリポジトリを文書化します。このドキュメントには、それぞれのコードベースのステータスと意図を含める必要があります。

    バッジには十分です！

    アクティブな間、バージョン管理システムには、生成された実行可能アーティファクトを含めてはなりません。 [OSPS-QA-05.01]
    プロジェクトのバージョン管理システムで生成された実行可能アーティファクトを削除します。生成された実行可能アーティファクトがテストなどのプロセスで重要と思われるシナリオでは、代わりにビルド時に生成するか、別に保存して、明確に文書化されたパイプライン ステップ中に取得する必要があることが推奨されます。

    バッジには十分です！

    アクティブな間、バージョン管理システムには、レビュー不可能なバイナリアーティファクトを含めてはなりません。 [OSPS-QA-05.02]
    プロジェクトのバージョン管理システムにレビュー不可能なバイナリアーティファクトを追加しないでください。これには、実行可能なアプリケーションバイナリ、ライブラリファイル、および同様のアーティファクトが含まれます。これには、グラフィック画像、音声や音楽ファイル、および通常バイナリ形式で保存されるコンテンツなどのアセットは含まれません。

    バッジには十分です！

    有効な間、プロジェクトのドキュメントにはセキュリティ連絡先を含めなければなりません。 [OSPS-VM-02.01]
    プロジェクトのセキュリティ連絡先を含むsecurity.md（または同様の名前の）ファイルを作成してください。


このデータは、Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0)のもとで利用可能です。これは、データ受領者が、データ受領者がこの契約のテキストを共有データとともに利用可能にする限り、変更の有無にかかわらずデータを共有できることを意味します。David A. WheelerおよびOpenSSFベストプラクティスバッジのコントリビューターにクレジットを表示してください。

プロジェクト バッジ登録の所有者： David A. Wheeler.
エントリの作成日時 2015-10-23 22:02:10 UTC、 最終更新日 2025-12-27 00:48:28 UTC 最後に2023-09-19 06:10:11 UTCにバッジ合格できませんでした。 最後に2023-09-19 06:10:30 UTCにバッジ合格を達成しました。