ClosedSSPM

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

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

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


これらはベースラインレベル1の基準です。 これらの基準はベースラインバージョン v2025.10.10 のものであり、バージョン v2026.02.19 の更新された基準テキストが含まれています。バージョン v2026.02.19 で新たに追加された基準は「future」とラベル付けされており、2026-06-01 から適用が開始されます。その日までに「future」基準への回答を提供してください。

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

        

 基本的情報

  • 一般

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

    An open source SaaS Security Posture Management (SSPM) tool. Audits SaaS platforms for security misconfigurations, starting with ServiceNow coverage.

    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)システム、ソフトウェア、およびパッケージのための構造化された命名体系です。脆弱性を報告する際に、多くのシステムやデータベースで使用されています。

 管理策 24/25

  • 管理策


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

    GitHub requires 2FA as of March 2023.



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

    GitHub restricts new collaborators to read-only ("triage" level) by default



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

    Branch protection rules are enabled on main: require pull request, require status checks (Build and Test, CodeQL), disallow force pushes, direct commits to main are blocked.



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

    GitHub prevents deletion of the default branch (main) by design. branch protection rules are enabled which further prevent branch deletion.



    CI/CDパイプラインが入力パラメータを受け取る場合、そのパラメータはパイプラインで使用する前にサニタイズおよび検証されなければなりません。 [OSPS-BR-01.01]
    CI/CDパイプラインは、信頼できないソースに対応するすべてのメタデータ入力をサニタイズ(期待値の引用、エスケープ、または終了)する必要があります。これには、ブランチ名、コミットメッセージ、タグ、プルリクエストのタイトル、作者情報などのデータが含まれます。

    CI/CD workflows (ci.yml, codeql.yml, release.yml, trivy.yml, scorecard.yml) do not accept any user-supplied input parameters



    (今後追加されるバッジ基準) CI/CDパイプラインが信頼されていないコードスナップショットで動作する場合、特権のあるCI/CDクレデンシャルおよびアセットへのアクセスを防止しなければなりません。 [OSPS-BR-01.03]
    CI/CDパイプラインは、信頼されていないコードスナップショットを特権のあるクレデンシャルおよびアセットから分離する必要があります。特に、プロジェクトは、協力者によるレビュー前にコードをビルドまたは実行するワークフローがCI/CDクレデンシャルにアクセスできないよう注意する必要があります。


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

    Project URLs use HTTPS exclusively.



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

    Distribution channels use HTTPS exclusively.



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

    The .gitignore file excludes .env files. All credentials are exclusively read from environment variables at runtime, never from config files. Snapshot files (which may contain sensitive data) are also gitignored (*.snapshot.json, snapshot.json). GitHub push protection is enabled to block accidental secret commits.



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

    README.md includes: Quick Start guide, full CLI Reference for all 5 commands with flags and environment variables, MCP Server Interface documentation, Installation instructions for all platforms (Homebrew, binary, deb, rpm, Docker, source), Custom Policies guide, and Security Best Practices.



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

    Non-trivial SECURITY[.md] file found file in repository: https://github.com/PiotrMackowski/ClosedSSPM/blob/main/SECURITY.md.



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

    GitHub supports public discussions on proposed changes (via pull requests) and usage obstacles (via issues).



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

    README.md includes a "Contributing" section with step-by-step guidelines: open an issue first, fork and branch workflow, follow existing patterns, add tests, all CI checks must pass, one PR per change. Security vulnerability reporting is directed to SECURITY.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)が含まれます。特許などの他の障害がない場合、パブリックドメインへのリリースはこの管理を満たします。

    The Apache-2.0 license for the repository contents is approved by the Open Source Initiative (OSI).



    アクティブな間、リリースされたソフトウェア資産のライセンスは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)が含まれます。リリースされたソフトウェア資産のライセンスはソースコードとは異なる場合があることに注意してください。

    The goreleaser configuration includes the LICENSE file in every release archive (tar.gz/zip), deb package (/usr/share/doc/closedsspm/LICENSE), rpm package (/usr/share/doc/closedsspm/LICENSE), and Docker images carry the license label. Homebrew formula specifies license: Apache-2.0.



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

    License file found in repository.



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

    The goreleaser configuration includes the LICENSE file in every release archive (tar.gz/zip), deb package (/usr/share/doc/closedsspm/LICENSE), rpm package (/usr/share/doc/closedsspm/LICENSE), and Docker images carry the license label. Homebrew formula specifies license: Apache-2.0.



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

    Repository is publicly available on GitHub.



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

    Repository git metadata is publicly available on GitHub.



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

    The repository contains go.mod and go.sum files which list all direct and transitive Go module dependencies with exact versions and cryptographic checksums.



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

    The homebrew-closedsspm tap repository (https://github.com/PiotrMackowski/homebrew-closedsspm) is a distribution subproject that hosts the Homebrew formula for ClosedSSPM. It is automatically updated by goreleaser on each release. No other subprojects exist.



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

    The repository contains no generated executable artifacts. The .gitignore excludes all binary formats (*.exe, *.dll, *.so, *.dylib, *.test) and the build output directory (bin/). All executables are built from source in CI via goreleaser and distributed through GitHub Releases.



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

    The repository contains no binary or unreviewable artifacts. All files are human-readable source code (Go, YAML policies, HTML template, Dockerfile, Makefile, GitHub Actions YAML). No images, compiled objects, archives, or other opaque binary files are checked in.



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

    SECURITY.md contains security contact information: vulnerability reports are accepted via GitHub Security Advisories. README.md "Reporting Vulnerabilities" section links to SECURITY.md.



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

    Branch names are only used in the concurrency group expression ${{ github.workflow }}-${{ github.ref }}, which is a safe context (concurrency key, not a shell command). No branch names are interpolated into run: steps, script bodies, or other injection-vulnerable contexts. No pull_request_target trigger is use



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

プロジェクト バッジ登録の所有者: Piotr.
エントリの作成日時 2026-02-28 16:28:56 UTC、 最終更新日 2026-02-28 17:18:47 UTC