Aikido 、Arnica、Amplify、Endor Labs、Jit、Kodem、Legit、Mobb、Orca Security、Phoenix Securityといったセキュリティベンダー各社が、SemgrepをフォークしてOpengrepを開発してから1年が経ちました。その根本的な目的は単純明快でした。すなわち、静的解析機能をオープンソースとして維持しつつ、最先端のエンジンを構築することにありました。
このプロジェクトは、当時Semgrep CE内では困難あるいは不可能だった4つの分野に焦点を当てました。具体的には、共有メモリ並列処理を備えたOCaml 5への移行、ファイル内関数間テイント解析の導入、言語サポートの拡充（Visual Basic、Apex、Elixirを含む）、そしてWindowsネイティブサポートの実現です。その後、Semgrepも同様の技術的優先事項に基づき、独自のOCaml 5移行とWindowsサポートを進めています。
1年後、これらの変更は、既存のルールや設定と完全に互換性を保ちつつ、目に見える成果を出し始めています：
- 大規模なリポジトリ全体でルールセットをすべて実行した場合、スキャン速度が25～74%向上します
- テイント解析の処理速度が最大2倍に向上し、より詳細なデータフローのセキュリティチェックが可能になります
- GitHubのリリースから174万回のバイナリダウンロード
- GitHubのスター数2,000以上
- 本番環境でOpengrepを導入している10社のセキュリティ企業
しかし、オープンソースのフォークを開始した最初の1年は、単に機能を提供するだけではありません。プロジェクトへの信頼を築き、フォークの背景にある目標が長期的に持続可能であることを証明し、ガバナンスを確立し、プロジェクトが成熟するにつれてセキュリティ対策の質を高めていくことが重要です。これらは、私たちの マニフェスト およびリポジトリ内のREADMEに明記されています。
この記事では、Opengrepにおいて何がうまくいったか、何が改善の余地があったか、そして今後どうなっていくかについて考察します。
メンテナQ&A
現在、Opengrepはディミトリス・モストロス、マチェイ・ピログ、およびコルネリウ・ホフマンによってメンテナンスされています。
このQ&Aでは、Opengrepに関する重要な質問をすべて投げかけています。
Q. 当時のSemgrepでは実現できなかったことを、このフォークによって可能にしたのは何ですか？
A. このフォークにより、既存の上流プロジェクト内では困難だったであろう、いくつかのアーキテクチャ上の決定を下すことができました。
まず、エンジンを共有メモリ並列処理に対応したOCaml 5へ移行しました。当時、Semgrepは依然としてforkベースの並行処理モデルを採用しており、Windowsへの対応など、特定の機能改善を行うことが極めて困難でした。OCaml 5への移行により、パフォーマンスの向上やクロスプラットフォーム対応に向けたより強固な基盤が整いました。その結果、Windowsへのネイティブ対応を実現することができました。
その後、私たちはクロスファンクション・テイント解析機能をオープンソース化し、あらゆるサードパーティベンダーが利用できるようにしました。Opengrepでは、--taint-intrafileフラグを使用してこの機能を利用でき、複数の言語にわたる高階関数のサポートも含まれています。
また、言語サポートを拡充し、Visual Basicを追加するとともに、オープンソースエンジンでApexとElixirを利用可能にしました。Clojureのtaintサポートも追加されました。
さらに、このフォークにより、テレメトリやプロプライエタリな依存関係排除することができました。
Q. OpengrepとSemgrep CEの間に、どのような明確な違いがありますか？
A. Opengrepは、検索ルールのスキャンとテイントルールのスキャンの両方で処理速度が速くなっています。また、テイント検出性能も優れており、マルチホップ環境での検出件数がより多くなっています（例えば、ComfyUIでのテイントルール適用時、25件対5件）。 また、より幅広い環境で容易に実行可能です。OpengrepはPythonへの依存関係のないスタンドアロンバイナリとして提供され、標準でより多くの言語に対応しているほか、ルールごとのタイムアウト、ファイルサイズに基づく動的タイムアウト、設定可能な無視アノテーションなどの機能を導入しています。
Q. 1年目にどのようなエンジニアリング業務を担当しましたか？
A. パフォーマンスの向上や新機能の実現には、膨大な量の技術開発作業が費やされました：
- 43件のリリースを配信
- 318件のプルリクエストにまたがる1,116件のコミット
- 1,546 個のファイルが変更されました
- このプロジェクトには21名の貢献者が関わっています
開発の大部分は3人の主要メンテナが主導してきましたが、プロジェクトは外部からの貢献も集め始めています。初年度には、17人の外部コントリビューターから29件のプルリクエストが提出されました。外部からの貢献には、テイント追跡や言語機能の改善（Kotlinスコープ関数）、配布インフラ（インストールスクリプト）、出力機能の改善（フィンガープリント）などが含まれます。 参入障壁は高いです。コードベースは約20万行のOCamlで構成されており、言語機能への貢献には、言語の解析方法、汎用ASTへの変換方法、そして中間表現やテイントエンジンの仕組みを理解する必要があります。2026年に向けて外部貢献者の基盤を拡大することは、私たちの重要な目標です。
Q. どこを間違えましたか？
A. 私たちはPyPI上でパッケージ名を保護しておらず、リリース時にWheels形式のパッケージを配布していました。これに加え、設定ミスが重なったことで、悪意のあるユーザーがパッケージを乗っ取る余地が生じてしまいました。
ガバナンスと長期的な持続可能性
メンテナチーム（ディミトリス・モストロス、マチェイ・ピログ、コルネリウ・ホフマン）は、投稿されたコードの審査、リリースの管理、ロードマップの策定など、プロジェクトの技術的な方向性を担っています。
Opengrepは、高度な静的解析機能をオープンソースとして提供し続けるという共通の目標を掲げた、セキュリティエコシステムに属する複数の企業による共同プロジェクトとして始まりました。現在、このプロジェクトはメンテナーチームによって運営され、GitHub上でオープンに開発が進められており、ロードマップに関する議論や技術的な決定事項はコミュニティに公開されています。
今後、透明性のあるガバナンスを維持しつつ、Opengrepのコミュニティをさらに拡大していくことを目指しています。
OpengrepはLGPL-2.1ライセンスの下で公開されており、エンジンおよびその派生作品がオープンソースとして維持されることが保証されています。
AIセキュリティ分析の時代において、なぜOpengrepが重要なのか
AIスキャナーは確率的なものです。同じ入力でも、モデルの状態、サンプリング、コンテキストによって、実行ごとに異なる出力が得られることがあります。 これは新たな脆弱性を発見する上では問題ありませんが、CI/CD 深刻な問題を引き起こします。実行ごとに結果が変動すると、再現性が損なわれ、コンプライアンスの遵守が困難になり、ツールへの信頼が失われます。Opengrepは、同じコードとルールを使用すれば、常に同じ検出結果を生成します。この一貫性こそが、スキャン出力をパイプラインのゲートとして機能させ、監査に耐えうるものとし、開発者に検出結果に対処する動機を与えるのです。
実用面でも課題があります。AIスキャナーは通常、API GPUによる演算、あるいはその両方を必要とします。LatioのJames Berthoty氏によるテストでは、確率的モデルが17分と155,000トークンを費やして発見した問題を、Opengrepはわずか30秒で検出しました。Opengrepはローカルで動作し、外部サービスを必要とせず、チームが確認・調整可能な明確なルールに基づいて動作します。コミットごとに実行される既知の脆弱性 については、その経済的メリットは明らかです。
最も強力なセキュリティパイプラインは、この両方を組み合わせています。まず、決定論的スキャンが実行され、既知のパターンを迅速かつ一貫して検出します。その後、AIによる推論が、分類、悪用可能性の評価、優先順位の決定を行います。例えば、OpengrepSAST を担い、その上にAIを配置することで、誤検知を抑制し、文脈に基づいて深刻度を評価することができます。AIを活用したパイプラインにおいて、決定論的層の価値が高まるのは、AIが推論を行うために一貫したシグナルを必要とするためです。
AIエージェントやコーディングアシスタントが開発ワークフローに組み込まれるにつれ、それらはプログラムから呼び出すことができ、毎回確定的な出力、構造化された結果、そして予測可能な動作を提供するツールが必要となります。Opengrepはこの要件に最適であり、プログラムによる統合や、当社の公式エージェントスキルを利用してAIワークフローに組み込むことが可能です。さらに、コーディングエージェントを使用してルールを定義し、そのルールに基づいてOpengrepを用いて効率的かつ大規模なスキャンを行うことができます。
Opengrepの今後の展開は？
コアアーキテクチャが整った今、Opengrepの次の段階では、エンジンの機能拡張と使いやすさの向上に注力していきます。優先事項の多くは、本番環境のユーザーやコミュニティの貢献者からのフィードバックを直接反映したものです。
最優先事項の一つは、ファイル間テイント解析です。これにより、エンジンは信頼できないデータが単一のファイル内だけでなく、複数のファイルにわたってどのように流れるかを追跡できるようになります。これにより、実際のコードベースにおける複雑な脆弱性の検出精度が大幅に向上します。
もう一つの重要なマイルストーンは、残りのPythonラッパーを削除し、完全にスタンドアロンのOCamlバイナリへと移行することで、インストールとCIでの利用を簡素化することです。また、ロードマップには、新しい言語のサポート、既存の言語文法の改善、そしてHomebrew、Winget、aptなどのパッケージマネージャーを通じたより広範な配布も含まれています。
私たちのロードマップは野心的ですが、開発者やセキュリティチームが引き続き自由に利用できる、高速で高性能な静的解析エンジンの構築に注力していきます。
