open-code-review

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

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

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


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

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

        

 基本的情報 5/5 ●

  • 一般

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

    Open-source & free — Battle-tested at Alibaba's scale. Hybrid architecture code review tool: deterministic pipelines + LLM Agent, precise line-level comments, built-in fine-tuned ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI & Anthropic compatible.

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

    The project has 10+ contributors. Multiple team members within the Alibaba organization have deep familiarity with the codebase and can maintain the project independently.
    https://github.com/alibaba/open-code-review/blob/main/GOVERNANCE.md#continuity


    バッジには十分です！

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

    https://github.com/alibaba/open-code-review/graphs/contributors，The project has multiple significant contributors from unassociated organizations. Besides the lead maintainer (Alibaba), regular external contributors each have 20+ commits from non-Alibaba domains.


  • その他


    バッジには十分です！

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

    Every source file includes "SPDX-License-Identifier: Apache-2.0" near the
    beginning. This is enforced by CI via make license-check (runs
    scripts/verify-license.sh). New files are automatically stamped with
    make license-add.


 変更管理 4/4 ●

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


    バッジには十分です！

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

    Repository on GitHub, which uses git. git is distributed.


    バッジには十分です！

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

    CONTRIBUTING.md directs newcomers to small, well-scoped tasks via the "good first issue" and "help wanted" labels, with direct links. Available tasks: https://github.com/alibaba/open-code-review/issues?q=state%3Aopen%20label%3A%22good%20first%20issue%22


    バッジには十分です！

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

    GitHub requires 2FA as of March 2023. [osps_ac_01_01]


    バッジには十分です！

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

    Project maintainers protect their GitHub accounts with cryptographic 2FA — TOTP authenticator apps and/or WebAuthn security keys, not SMS. This satisfies the requirement for phishing-resistant, non-SMS second factors.


 品質 7/7 ●

  • コーディング標準


    バッジには十分です！

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

    Review and merge expectations are documented in GOVERNANCE.md ("Reviews and Merge Expectations") and CONTRIBUTING.md. https://github.com/alibaba/open-code-review/blob/main/GOVERNANCE.md


    バッジには十分です！

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

    All changes land on the main branch exclusively through GitHub Pull Requests. Branch protection on main requires at least one approving review from someone other than the author before merge, and this rule is enforced for administrators as well (enforce_admins enabled). CI (the test job: build, race-enabled tests, coverage gate, smoke test) is a required status check for merge. Merged PRs: https://github.com/alibaba/open-code-review/pulls?q=is%3Apr+is%3Amerged


  • 作業ビルドシステム


    バッジには十分です！

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

    The build is reproducible. All dependencies are pinned by cryptographic hash in go.sum; the build toolchain is pinned to a specific container image (golang:1.26.5) in CI; release binaries are built with CGO_ENABLED=0 for static, deterministic output; and SHA-256 checksums are generated for every release artifact via make sha256sum. See https://github.com/alibaba/open-code-review/blob/main/Makefile and https://github.com/alibaba/open-code-review/blob/main/.github/workflows/ci.yml


  • 自動テスト スイート


    バッジには十分です！

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

    The test suite is invoked in the standard Go way: go test ./..., wrapped as make test (which runs go test -race -count=1 across all packages). It runs automatically in CI on every push and pull request. See https://github.com/alibaba/open-code-review/blob/main/Makefile and https://github.com/alibaba/open-code-review/blob/main/.github/workflows/ci.yml


    バッジには十分です！

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

    https://github.com/alibaba/open-code-review/blob/main/.github/workflows/ci.yml


    バッジには十分です！

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

    The project is written in Go (see go.mod). Go's built-in go test -cover is a
    FLOSS statement-coverage tool, so this criterion's precondition is satisfied and
    it is reported as Met (not N/A).

    The authoritative measurement is the CI gate, which runs go test -race ./...
    over the whole module and currently reports total statement coverage of 90.2%.
    This is enforced in CI: the "Check coverage threshold" step in
    .github/workflows/ci.yml fails the build if coverage drops below 90%.

    The Makefile make coverage target is a local convenience that reports a
    slightly higher number (90.6%) because it measures a smaller package set: it
    omits -race and excludes extensions/ via PACKAGES. The two figures cover
    different package sets and are not the same measurement; the CI figure governs.

    Reproduce (authoritative, CI scope):
    go test -count=1 -race -coverprofile=coverage.out ./...
    go tool cover -func=coverage.out | grep total:

    local convenience (excludes extensions/, no -race):

    make coverage


    バッジには十分です！

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

    The project is written in Go (see go.mod). The Go toolchain's built-in coverage
    support (go test -cover) only offers three modes -- set, count, and atomic --
    all of which measure statement coverage. It does not measure branch (or
    condition) coverage; there is no -covermode=branch and go tool cover exposes
    no branch-coverage output. This was verified against the go1.26 toolchain via
    go help testflag and go tool cover -h. Per this criterion's own precondition
    ("if there is at least one FLOSS tool that can implement this criterion in the
    selected language"), the criterion is Not Applicable for a Go project.


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

    Justification: All network communications use HTTPS exclusively. The project communicates with LLM API providers (OpenAI, Anthropic, etc.) via HTTPS using Go's net/http standard library. There is no support for insecure HTTP connections to API endpoints. The viewer component also serves over HTTPS when configured.


    バッジには十分です！

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

    Justification: Go's crypto/tls package enforces TLS 1.2 as the minimum version by default (since Go 1.18). The project does not override this default. All outbound HTTPS connections to LLM APIs use TLS 1.2 or later.


  • 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 (github.com/alibaba/open-code-review) and download site
    (GitHub Releases) are hosted on GitHub, which is known to send hardened
    headers. The project website https://open-codereview.ai/ returns hardening
    headers with non-permissive values on every response: Strict-Transport-Security,
    a strict Content-Security-Policy (default-src 'self', no unsafe script-src),
    X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: no-referrer,
    and Permissions-Policy. Scanning https://open-codereview.ai/ on securityheaders.com
    yields an A grade.


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


    バッジには十分です！

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

    A security review was performed by project members and is documented in ASSURANCE_CASE.md. It covers security requirements, the threat model, trust boundaries, Saltzer & Schroeder secure-design principles, and countermeasures mapped to OWASP Top 10 / CWE Top 25. The review includes human analysis of design-level issues, supported by static and dynamic tooling (go vet, govulncheck, the Go race detector). https://github.com/alibaba/open-code-review/blob/main/ASSURANCE_CASE.md


    バッジには十分です！

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

    OCR applies multiple hardening mechanisms in the software it produces:
    (1) written in Go (memory-safe) and built with CGO_ENABLED=0, eliminating
    C-family memory-corruption and undefined-behavior classes;
    (2) the local web viewer sends defense-in-depth HTTP headers on every response --
    a strict Content-Security-Policy (default-src 'self', no unsafe-inline),
    X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy,
    and Permissions-Policy (internal/viewer/securityheaders.go);
    (3) the viewer enforces a host-header allowlist blocking DNS-rebinding
    (internal/viewer/hostguard.go);
    (4) the Go race detector runs in CI.
    See https://github.com/alibaba/open-code-review/blob/main/ASSURANCE_CASE.md


 分析 2/2 ●

  • 動的コード分析


    バッジには十分です！

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

    OCR runs its full automated test suite under the Go race detector (go test -race) in CI on every push and pull request, and therefore before every release. The race detector is a dynamic-analysis tool (ThreadSanitizer-based) that instruments the running binary and detects data races and memory-ordering bugs at execution time. CI additionally runs govulncheck for reachability-based vulnerability analysis. See https://github.com/alibaba/open-code-review/blob/main/.github/workflows/ci.yml


    バッジには十分です！

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

    The produced software performs always-on runtime invariant checks: explicit panics guard violated preconditions (e.g. tool-registration invariants in internal/tool/definitions.go, embedded-config parse invariants in internal/config/allowlist), and the memory-safe Go runtime unconditionally enforces bounds, nil, and type checks. Unlike C/C++ assert(), these are never compiled out -- there is no NDEBUG-style switch that could disable them in production or testing. All are exercised during dynamic analysis: the 80+ package test suite drives the code while the race detector runs alongside, so any triggered invariant fails the build. See https://github.com/alibaba/open-code-review/blob/main/.github/workflows/ci.yml



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

プロジェクト バッジ登録の所有者： lizhengfeng.
エントリの作成日時 2026-06-22 06:51:21 UTC、 最終更新日 2026-08-06 04:57:39 UTC 最後に2026-06-26 12:15:08 UTCにバッジ合格できませんでした。 最後に2026-06-26 12:41:47 UTCにバッジ合格を達成しました。