mcp-searxng

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

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

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


これらはベースラインレベル2の基準です。 これらは基準バージョン v2026.02.19 の評価項目です。

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

        

 基本的情報

  • 一般

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

    MCP server for SearXNG web search integration

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

 管理策 19/19

  • 管理策


    CI/CDタスクが権限を指定せずに実行される場合、CI/CDシステムはパイプラインで付与される最低限の権限をタスクの権限としてデフォルトで設定しなければなりません。 [OSPS-AC-04.01]
    プロジェクトの設定を構成して、デフォルトで新しいパイプラインに利用可能な最低限の権限を割り当て、特定のタスクに必要な場合にのみ追加の権限を付与します。

    GitHub Actions workflows define explicit least-privilege permissions at the workflow/job level; read-only permissions are used by default and publish/signing jobs grant only the specific write/id-token scopes needed.
    https://github.com/ihor-sokoliuk/mcp-searxng/blob/main/.github/workflows/scorecard.yml
    https://github.com/ihor-sokoliuk/mcp-searxng/blob/main/.github/workflows/docker-publish.yml



    公式リリースが作成される場合、そのリリースには一意のバージョン識別子を割り当てなければなりません。 [OSPS-BR-02.01]
    プロジェクトによって生成される各リリースに、一貫した命名規則または番号付けスキームに従って一意のバージョン識別子を割り当てます。例には、SemVer、CalVer、またはgit commit idが含まれます。

    Each released project result has a unique version identifier. The package metadata declares the current version, and releases/changelog entries use distinct versions such as 1.3.3, 1.3.2, 1.3.1, and 1.3.0.
    https://github.com/ihor-sokoliuk/mcp-searxng/blob/main/package.json
    https://github.com/ihor-sokoliuk/mcp-searxng/blob/main/CHANGELOG.md [version_unique]



    公式リリースが作成される場合、そのリリースには機能的およびセキュリティの変更の記述的なログを含めなければなりません。 [OSPS-BR-04.01]
    すべてのリリースに記述的な変更ログを含めるようにしてください。変更ログが人間が読めるものであり、コミットメッセージだけでなく、セキュリティへの影響や異なるユースケースとの関連性についての説明などの詳細を含めることが推奨されます。機械可読性を確保するために、「## Changelog」などのmarkdownヘッダーの下にコンテンツを配置してください。

    Non-trivial release notes file in repository: https://github.com/ihor-sokoliuk/mcp-searxng/blob/main/CHANGELOG.md. [release_notes]



    ビルドとリリースのパイプラインが依存関係を取り込む場合、利用可能な場合は標準化されたツールを使用しなければなりません。 [OSPS-BR-05.01]
    エコシステム用の一般的なツール(パッケージマネージャーや依存関係管理ツールなど)を使用して、ビルド時に依存関係を取り込みます。これには、必要な依存関係を指定するための依存関係ファイル、ロックファイル、またはマニフェストを使用し、ビルドシステムによって取り込まれることが含まれます。

    The release/build pipelines use standardized tooling: npm dependencies are installed reproducibly with npm ci from package-lock.json, and Docker images are built with the standard docker/build-push-action workflow.
    https://github.com/ihor-sokoliuk/mcp-searxng/blob/main/.github/workflows/npm-publish.yml
    https://github.com/ihor-sokoliuk/mcp-searxng/blob/main/package-lock.json



    公式リリースが作成される場合、そのリリースには署名するか、各アセットの暗号ハッシュを含む署名付きマニフェストで説明しなければなりません。 [OSPS-BR-06.01]
    ビルド時にすべてのリリースされたソフトウェア アセットを、GPGまたはPGP署名、Sigstore署名、SLSAプロベナンス、またはSLSA VSAなどの暗号署名または証明で署名します。署名付きマニフェストまたはメタデータファイルに各アセットの暗号ハッシュを含めます。

    Published Docker release images are signed with Cosign keyless signing, and SECURITY.md documents how to verify the published image signatures.
    https://github.com/ihor-sokoliuk/mcp-searxng/blob/main/.github/workflows/docker-publish.yml
    https://github.com/ihor-sokoliuk/mcp-searxng/blob/main/SECURITY.md



    プロジェクトがリリースを行った場合、プロジェクトのドキュメントには、プロジェクトが依存関係をどのように選択、取得、および追跡するかについての説明を含めなければなりません。 [OSPS-DO-06.01]
    この情報をソースコードリポジトリ、プロジェクトウェブサイト、またはその他のチャネルなどの公開表示可能なリソース上で、プロジェクトの技術および設計ドキュメントと一緒に公開することが推奨されます。

    Dependencies are declared in package.json and locked/tracked in package-lock.json. SECURITY.md documents dependency auditing with npm audit and the security script used to check dependencies for known vulnerabilities.
    https://github.com/ihor-sokoliuk/mcp-searxng/blob/main/package.json
    https://github.com/ihor-sokoliuk/mcp-searxng/blob/main/package-lock.json
    https://github.com/ihor-sokoliuk/mcp-searxng/blob/main/SECURITY.md



    プロジェクトのドキュメントには、必要なライブラリ、フレームワーク、SDK、および依存関係を含む、ソフトウェアのビルド方法に関する手順が含まれていなければなりません。 [OSPS-DO-07.01]
    この情報は、CONTRIBUTING.mdや他の開発者タスクドキュメントなど、プロジェクトの貢献者ドキュメントと一緒に公開することが推奨されます。これはまた、Makefileターゲットや他の自動化スクリプトを使用して文書化することもできます。

    Build instructions are documented for contributors, including npm install, npm run build, npm test, and coverage checks. README.md also documents Docker build instructions.
    https://github.com/ihor-sokoliuk/mcp-searxng/blob/main/CONTRIBUTING.md
    https://github.com/ihor-sokoliuk/mcp-searxng/blob/main/README.md



    有効な間、プロジェクトのドキュメントには、機密性の高いリソースへのアクセス権を持つプロジェクトメンバーのリストを含めなければなりません。 [OSPS-GV-01.01]
    プロジェクトのソースコードリポジトリ内のmembers.md、governance.md、maintainers.md、または同様のファイルなどのアーティファクトを通じて、プロジェクト参加者とその役割を文書化します。これは、メンテナのリストに名前またはアカウントハンドルを含めるだけの簡単なものでも、プロジェクトのガバナンスに応じてより複雑なものでも構いません。

    Sole maintainer



    有効な間、プロジェクトのドキュメントには、プロジェクトのメンバーの役割と責任の説明を含めなければなりません。 [OSPS-GV-01.02]
    プロジェクトのソースコードリポジトリ内のmembers.md、governance.md、maintainers.md、または同様のファイルなどのアーティファクトを通じて、プロジェクト参加者とその役割を文書化します。

    Project documentation describes contributor expectations in CONTRIBUTING.md and maintainer responsibilities for conduct/report handling in CODE_OF_CONDUCT.md.
    https://github.com/ihor-sokoliuk/mcp-searxng/blob/main/CONTRIBUTING.md
    https://github.com/ihor-sokoliuk/mcp-searxng/blob/main/CODE_OF_CONDUCT.md



    有効な間、プロジェクトのドキュメントには、受け入れ可能な貢献の要件を含むコード貢献者向けのガイドを含めなければなりません。 [OSPS-GV-03.02]
    プロジェクトドキュメントのCONTRIBUTING.mdまたはCONTRIBUTING/の内容を拡張して、コーディング標準、テスト要件、コードコントリビューターのための提出ガイドラインを含む、受け入れ可能な貢献の要件を概説します。このガイドがコントリビューターと承認者の両方にとって信頼できる情報源であることが推奨されます。

    The project is released under the MIT License. The LICENSE file contains the full MIT license text, and package.json declares "license": "MIT".
    https://github.com/ihor-sokoliuk/mcp-searxng/blob/main/LICENSE [contribution_requirements]



    アクティブな間、バージョン管理システムは、すべてのコードコントリビューターが、すべてのコミットで関連する貢献を行うことが法的に認められていると主張することを要求する必要があります。 [OSPS-LE-01.01]
    プロジェクトのリポジトリにDCOを含め、コードコントリビューターが、すべてのコミットで関連する貢献を行うことが法的に認められていると主張することを要求します。ステータスチェックを使用して、主張が行われたことを確認します。CLAもこの要件を満たします。GitHubなどの一部のバージョン管理システムでは、これがプラットフォームの利用規約に含まれている場合があります。

    Sole contributor/admin/owner



    プライマリブランチにコミットが行われる場合、コミットの自動ステータスチェックは、合格するか手動でバイパスされる必要があります。 [OSPS-QA-03.01]
    プロジェクトのバージョン管理システムを設定して、すべての自動ステータスチェックが合格するか、コミットがプライマリブランチにマージされる前に手動確認を要求するようにします。オプションのステータスチェックは、承認者がバイパスしたくなるような合格または不合格の要件として設定しないことが推奨されます。

    コミットが受け入れられる前に、プロジェクトのCI/CDパイプラインは、変更が期待を満たすことを確認するために少なくとも1つの自動テストスイートを実行する必要があります。 [OSPS-QA-06.01]
    自動テストは、プライマリブランチへのすべてのマージの前に実行される必要があります。テストスイートはCI/CDパイプラインで実行され、結果はすべてのコントリビューターに表示される必要があります。テストスイートは一貫した環境で実行され、コントリビューターがローカルでテストを実行できるような方法で実行される必要があります。テストスイートの例には、ユニットテスト、統合テスト、エンドツーエンドテストが含まれます。

    プロジェクトがリリースを行った場合、プロジェクトドキュメントは、システム内のすべてのアクションとアクターを示す設計ドキュメントを含む必要があります。 [OSPS-SA-01.01]
    プロジェクトドキュメントに、アクションとアクターを説明する設計を含めます。アクターには、システム内の別のセグメントに影響を与えることができるサブシステムまたはエンティティが含まれます。これが新機能や破壊的変更のために更新されることを確認してください。

    The README includes design documentation showing the main actors and data flow: AI assistant → mcp-searxng MCP server → SearXNG instance. The Tools section documents the project actions exposed by the system, and SECURITY.md documents the main security-relevant surfaces.
    https://github.com/ihor-sokoliuk/mcp-searxng#how-it-works
    https://github.com/ihor-sokoliuk/mcp-searxng#tools
    https://github.com/ihor-sokoliuk/mcp-searxng/blob/main/SECURITY.md#threat-model



    プロジェクトがリリースを行った場合、プロジェクトドキュメントは、リリースされたソフトウェアアセットのすべての外部ソフトウェアインターフェースの説明を含む必要があります。 [OSPS-SA-02.01]
    リリースされたソフトウェアアセットのすべてのソフトウェアインターフェース(API)を文書化し、ユーザーがソフトウェアとどのように対話できるか、どのようなデータが期待または生成されるかを説明します。これが新機能や破壊的変更のために更新されることを確認してください。

    The README documents the external interface in the Tools section. It describes the two MCP tools, searxng_web_search and web_url_read, including their inputs such as query, pageno, time_range, language, safesearch, url, maxLength, section, paragraphRange, and readHeadings. It also documents HTTP endpoints for HTTP transport.
    https://github.com/ihor-sokoliuk/mcp-searxng#tools
    https://github.com/ihor-sokoliuk/mcp-searxng#http-transport [documentation_interface]



    プロジェクトがリリースを行った場合、プロジェクトは、ソフトウェア内で発生する可能性のある最も可能性が高く、影響の大きい潜在的なセキュリティ問題を理解するためにセキュリティ評価を実行する必要があります。 [OSPS-SA-03.01]
    セキュリティ評価を実行することで、プロジェクトメンバーと下流の消費者の両方に、プロジェクトがソフトウェア内で発生する可能性のある問題を理解していることを知らせます。どのような脅威が実現する可能性があるかを理解することは、プロジェクトがリスクを管理および対処するのに役立ちます。この情報は、プロジェクトのセキュリティの能力と実践を示すために、下流の消費者にとって有用です。これが新機能や破壊的変更のために更新されることを確認してください。

    SECURITY.md includes a threat model and identifies the most likely security-impactful problem areas, including SSRF in web_url_read, HTTP transport risks, credential exposure, query forwarding, dependency vulnerabilities, and deployment risks. The repository also runs CodeQL/code scanning.
    https://github.com/ihor-sokoliuk/mcp-searxng/blob/main/SECURITY.md#threat-model
    https://github.com/ihor-sokoliuk/mcp-searxng/blob/main/.github/workflows/codeql.yml



    アクティブな間、プロジェクトドキュメントは、明確な対応期間を持つ協調的脆弱性開示(CVD)のポリシーを含む必要があります。 [OSPS-VM-01.01]
    ディレクトリのルートにSECURITY.mdファイルを作成し、プロジェクトの協調的脆弱性開示のポリシーを概説します。脆弱性を報告する方法を含めます。プロジェクトが報告された問題にどのように対応および対処するかについての期待を設定します。

    SECURITY.md is present at the repository root and documents the vulnerability reporting process, including private reporting through GitHub Security Advisories, required report details, and expected response timelines.
    https://github.com/ihor-sokoliuk/mcp-searxng/blob/main/SECURITY.md#reporting-a-vulnerability [vulnerability_report_process]



    アクティブな間、プロジェクトドキュメントは、プロジェクト内のセキュリティ連絡先に直接脆弱性を非公開で報告する手段を提供する必要があります。 [OSPS-VM-03.01]
    セキュリティ研究者がプロジェクトに非公開で脆弱性を報告する手段を提供します。これは、専用の電子メールアドレス、ウェブフォーム、VCS専用ツール、セキュリティ連絡先の電子メールアドレス、またはその他の方法である可能性があります。

    SECURITY.md instructs reporters not to open public GitHub issues for vulnerabilities and directs them to report privately using GitHub Security Advisories.
    https://github.com/ihor-sokoliuk/mcp-searxng/blob/main/SECURITY.md#reporting-a-vulnerability
    https://github.com/ihor-sokoliuk/mcp-searxng/security/advisories/new [vulnerability_report_private]



    アクティブな間、プロジェクトドキュメントは、発見された脆弱性に関するデータを公開する必要があります。 [OSPS-VM-04.01]
    CVEエントリ、ブログ投稿、またはその他のメディアなど、予測可能な公開チャネルで既知の脆弱性に関する情報を提供します。可能な限り、この情報には、影響を受けるバージョン、消費者が脆弱かどうかを判断する方法、および緩和または修復の手順が含まれる必要があります。

    Release notes/changelog identify the publicly known run-time vulnerabilities fixed in the release, including the published GitHub Security Advisories GHSA-q87f-qc2r-2gw4 and GHSA-wppf-h75h-6pm6. The advisories are published in the repository Security Advisories, and the changelog records the corresponding security fixes.
    https://github.com/ihor-sokoliuk/mcp-searxng/security/advisories
    https://github.com/ihor-sokoliuk/mcp-searxng/blob/main/CHANGELOG.md [release_notes_vulns]



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

プロジェクト バッジ登録の所有者: Ihor Sokoliuk.
エントリの作成日時 2026-06-09 18:56:50 UTC、 最終更新日 2026-06-13 05:06:43 UTC 最後に2026-06-11 18:14:57 UTCにバッジ合格を達成しました。