kotiko

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

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

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


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

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

        

 基本的情報 3/5 ●

  • 一般

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

    Learn languages while you browse: Kotiko swaps words on the pages you read for the words you're learning, in any language. Local-first browser extension with an optional self-hosted server.

    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リポジトリのバス ファクタの評価を参照してください。

    Kotiko has two maintainers since 2026-10-06, but every commit so far was written by the lead maintainer, so the bus factor is still 1 in practice. We are working on it: the architecture, the assurance case and the coding standards are written down, every planned piece of work in slices/ is a buildable spec, and GOVERNANCE.md says how the maintainers continue without any one of them. https://github.com/ScriptKittyOS/kotiko/blob/main/docs/governance/continuity.md#bus-factor


    バッジには不十分です。

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

    Not yet. All significant contributions in the past year come from one person. Issues, Discussions and translations are open to everyone, and small tasks will be labelled for newcomers.


  • その他


    バッジには十分です！

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

    Every source code file carries an SPDX license identifier comment for Apache-2.0 near the top (another SPDX identifier where third-party data says so). Files that can't carry a comment (JSON, images), plus Markdown, test fixture pages and two formatter configs, get it through REUSE.toml, and reuse lint runs on every pull request as a required check.


 変更管理 3/4 ●

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


    バッジには十分です！

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

    git, hosted on GitHub: https://github.com/ScriptKittyOS/kotiko


    バッジには不十分です。

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

    Not yet. The good first issue and help wanted labels exist, but no issue carries them yet. Small tasks will be filed with those labels and linked from CONTRIBUTING.md.


    バッジには十分です！

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

    The ScriptKittyOS GitHub organization requires two-factor authentication for every member, so nobody can push to the repository, change its settings or read private vulnerability reports without it. GOVERNANCE.md requires it for store accounts too.


    バッジには十分です！

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

    GOVERNANCE.md requires maintainers (and a steward, if one is named) to protect their GitHub and store accounts with a passkey, a security key or an authenticator app, not SMS.


 品質 3/7 ●

  • コーディング標準


    バッジには不十分です。

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

    Partly documented. CONTRIBUTING.md and the pull request template list what every change must have (tests, a regression test for fixes, format and lint clean, docs and the security documents updated, no new runtime dependency in the extension), and main accepts only pull requests whose required checks pass. A code review guide saying how review is conducted, what the reviewer checks and what blocks a merge is planned.


    バッジには不十分です。

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

    Not yet. Kotiko has a second maintainer since 2026-10-06, but the merged pull requests so far were checked by their author and CI only. The next steps are reviews by the second maintainer, then an approving review required on main for every change.


  • 作業ビルドシステム


    バッジには十分です！

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

    The extension zips, the only built release files, are reproducible by anyone: the build uses entries sorted by path, the commit's timestamp, fixed permissions and a pinned pure-JavaScript deflate, so the bytes don't depend on the machine or time zone. The release workflow builds twice and compares, and docs/reproducible-builds.md shows how to rebuild a release from its tag and check it against the published SHA256SUMS. The server is released as source. https://github.com/ScriptKittyOS/kotiko/blob/main/docs/reproducible-builds.md


  • 自動テスト スイート


    バッジには十分です！

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

    npm test (Node's built-in test runner) for the extension and mix test for the server, the standard commands of each ecosystem; npm run e2e runs the Playwright end-to-end tests. https://github.com/ScriptKittyOS/kotiko/blob/main/CONTRIBUTING.md#setup


    バッジには十分です！

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

    Every change reaches main through a short-lived pull request, and GitHub Actions runs every test suite, the linters and the audits on each pull request and each push to main; main requires 8 checks to pass. https://github.com/ScriptKittyOS/kotiko/actions/workflows/ci.yml


    バッジには不十分です。

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

    Not yet. Measured 2026-10-06: the server's tests cover 87.8 % of lines (mix test --cover) and the extension's 92.6 % (node --test --experimental-test-coverage). Raising the server above 90 % (the Telegram client, the transcriber, the janitor and application start-up are the gaps) and adding a coverage gate to CI are planned.


    バッジには不十分です。

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

    Not yet. Measured 2026-10-06: the extension's tests cover 79.1 % of branches (node --test --experimental-test-coverage). For the server, Erlang's cover tool measures lines, not branches, and we know of no FLOSS branch-coverage tool for Elixir.


 セキュリティ 3/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]

    Kotiko's own outbound traffic uses HTTPS by default: model providers, OpenRouter, Telegram and Wiktionary. The server listens on 127.0.0.1 by default, so its plain-HTTP API doesn't leave the computer unless the owner sets BIND to another address; then the server logs a warning at start (daily for a public address), and the extension warns under the address field when the token would cross a network unencrypted. A plain-HTTP model endpoint (such as a local Ollama) is used only when the user enters one.


    バッジには十分です！

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

    TLS comes from Erlang/OTP (26 and newer, which offer TLS 1.2 and 1.3 by default) for the server's outbound requests and from the browser for the extension. Kotiko never sets or lowers the TLS version.


  • 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 repository (https://github.com/ScriptKittyOS/kotiko) and its release downloads are served by GitHub with HTTP Strict Transport Security, a Content Security Policy, X-Frame-Options: deny and X-Content-Type-Options: nosniff. The project website kotiko.org is not published yet; it is to be served through Cloudflare with the same headers before it goes live.


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


    バッジには不十分です。

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

    Not yet as gold requires. A line-by-line adversarial review with probes of the extension and the server (2026-10-01, docs/research/06-adversarial-qa.md) found and fixed an authentication bypass and other issues, but it predates the written security requirements. A pre-release review by three independent reviewers against the security requirements and trust boundaries is planned before the first store release; its report will be published in docs/security.


    バッジには十分です！

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

    Extension pages run under an explicit content security policy (script-src 'self'; object-src 'self') with no inline scripts, and ESLint forbids HTML string sinks (innerHTML, outerHTML, insertAdjacentHTML) so a bug can't turn word data into markup. The server checks the Host header against an allowlist before anything else (against DNS rebinding), caps request bodies, sends no CORS headers, marks answers no-store, binds to loopback by default, compares tokens in constant time, and filters secrets out of logs. Planned: X-Content-Type-Options and similar headers on server responses, and a sandboxed systemd unit. Evidence: https://github.com/ScriptKittyOS/kotiko/blob/main/extension/manifest.json and https://github.com/ScriptKittyOS/kotiko/blob/main/docs/security/assurance-case.md


 分析 1/2 ●

  • 動的コード分析


    バッジには不十分です。

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

    Not yet for every release. CI runs property-based tests (StreamData) that feed generated input to two server parsers, the end-to-end tests drive the real extension against the real server, and axe scans every interface, but no fuzzer or scanner is applied to each proposed release yet. Planned: property-based tests for the request parsers, the URL and response validators and the matcher, run in the release workflow, or an OWASP ZAP baseline scan of the server.


    かろうじてバッジには十分です。

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

    Not yet. The tests assert heavily, but the shipped code has no run-time assertions that are switched on during dynamic analysis. Planned with the property-based tests above.



ツールやAIシステムを使って、https://www.bestpractices.dev/ja/projects/15259/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)のもとで利用可能です。これは、データ受領者が、データ受領者がこの契約のテキストを共有データとともに利用可能にする限り、変更の有無にかかわらずデータを共有できることを意味します。Ayla CroftおよびOpenSSFベストプラクティスバッジのコントリビューターにクレジットを表示してください。

プロジェクト バッジ登録の所有者： Ayla Croft.
エントリの作成日時 2026-10-06 18:38:00 UTC、 最終更新日 2026-10-06 21:25:04 UTC 最後に2026-10-06 19:36:22 UTCにバッジ合格を達成しました。