ソースコードセキュリティ：シグナルから検証済みのリスクへ | Ostorlab

スキャナーが、リポジトリ内に危険な関数を見つけたとします。

これはシグナルです。

攻撃者がそこに到達できること、信頼できないデータがそこへ流れ込むこと、他の制御によってその経路が安全になっていないことの実証には、まだなっていません。こうした問いへの答えによって、そのコードが本当の脆弱性にあたるのか、そして開発者が手を止めてまで修正すべきものなのかが決まります。

これこそが、ソースコードセキュリティテストの中心にある課題です。

疑わしいコードを見つけること自体は容易になりました。難しいのは、脆弱性をノイズから切り分け、リスクを文脈に沿って説明し、開発者が実際に使える修正を提示することです。

ソースコードセキュリティテストとは

ソースコードセキュリティテストは、アプリケーションのコードを検査し、弱点が本番環境に到達する前に見つけ出す取り組みです。静的アプリケーションセキュリティテスト（SAST）、シークレット検出、依存関係の分析、手動のセキュアコードレビュー、AIを活用した調査などが含まれます。

NISTの定義によれば、ソースコードセキュリティアナライザーとは、ソースコードを検査し、セキュリティ脆弱性につながりうる弱点を報告するツールです。この区別は重要です。疑わしい弱点が脆弱性につながることはありますが、両者が自動的に同じものになるわけではありません。

有用なソースコードセキュリティのプロセスは、次の4つの問いに答えられる必要があります。

1. 弱点はどこにあるか
2. このアプリケーションにおいて、到達可能か、あるいは悪用可能か
3. どのような影響を及ぼしうるか
4. どのような変更を加えれば安全に修正できるか

最初の問いにしか答えられないツールが見つけたのは、セキュリティチームの作業であり、必ずしも脆弱性ではありません。

脆弱性はアプリケーションの実行前から存在しうる

セキュリティ上の問題は、本番環境ができるのを待ってはくれません。

設定ファイルには、すでにシークレットがハードコードされているかもしれません。マニフェストでは、脆弱な依存関係のバージョンがすでに固定されているかもしれません。ユーザーが制御できる入力が、すでに安全でないクエリに到達しているかもしれません。機密性の高い操作から、認可チェックがすでに抜け落ちているかもしれません。

これらはいずれも、公開URLやテストアカウント、稼働中のアプリケーションがなくても成立します。

ソースコードテストなら、該当する変更の記憶が新しいうちに、こうした弱点を捉えられます。検出結果は影響を受けるファイル、関数、コードパスを直接示すことができ、コードが共有インフラや本番環境のリスクとなる前に、フィードバックを開発者に届けられます。

これが早期にテストする価値です。ただし、早期検出が役に立つのは、その結果を信頼できる場合に限られます。

従来のSASTはどのように脆弱性を見つけるのか

静的アプリケーションセキュリティテストは、アプリケーションを実行せずにコードを解析します。エンジンによって異なりますが、次のような処理を行います。

• コードをトークンや抽象構文木（AST）に解析する
• 入力、機密性の高い関数、既知の安全でないパターンを特定する
• 関数をまたいでデータフローと制御フローを追跡する
• サニタイザーやセキュリティ制御を認識する
• 脆弱性クラスに対応するルールやクエリを適用する
• 疑わしい問題と、それを生み出した経路を報告する

SQLインジェクションの可能性がある箇所を例に考えてみましょう。データベースクエリを見つけるだけでは不十分です。スキャナーは、攻撃者が制御できる入力がそのクエリに到達しうるか、その入力がパラメーター化またはサニタイズされているか、そしてその経路が実際に成立しうるかを判断しなければなりません。

GitHubによるSASTアーキテクチャの解説は、この違いを明確に示しています。機密性の高いシンクを見つけただけでは、それ自体が脆弱性の実証にはなりません。重要なエビデンスとなるのは、ソースからそのシンクへ至る安全でない経路です。

単純なパターンマッチングが限界を迎えるのは、まさにこの点です。

ソースコードスキャナーが誤検知を生む理由

誤検知（フォールスポジティブ）とは、スキャナーには危険に見えるものの、そのアプリケーションの文脈では実際の脆弱性ではない、報告された問題のことです。

誤検知がよく起こるのは、スキャナーが全体像の一部しか見ていないためです。別ファイルにある独自のサニタイザーを見落としたり、フレームワークによる制御を理解できなかったり、到達不能な経路をたどったり、テストデータを本番環境のシークレットと取り違えたりすることがあります。

主な原因には次のようなものがあります。

• 不完全なデータフロー解析または制御フロー解析
• スキャナーが認識できない独自の検証処理
• フレームワーク、依存関係、ビルドに関するコンテキストの欠如
• デッドコードや到達不能なコード
• テスト用の値や設定例
• 実際の影響ではなく、一般的な弱点に基づいた重大度

OWASPは、誤検知、検出漏れ（フォールスネガティブ）、そして問題が実際の脆弱性であることを実証する難しさを、静的解析の限界として挙げています。

コストは、誤ったアラート1件の確認に費やす時間だけにとどまりません。ノイズが繰り返されると、開発者はスキャナーを信用しなくなっていきます。そして本物の脆弱性が現れても、誰もが無視することに慣れてしまったキューに入ってしまいます。

だからこそ、基準は「より多く見つけること」であってはなりません。「開発者に対応を求める前に、不確実性をできる限り取り除くこと」であるべきです。

静的スキャンからエージェント型の調査へ

従来のスキャンは、通常、次のような短い経路をたどります。

Pattern or query → match → alert

エージェント型のソースコードセキュリティは、ここに調査のレイヤーを加えます。

Signal → gather context → follow the path → challenge the hypothesis → assess impact → report or discard → propose a fix

エージェントは、疑わしい操作を起点に周辺の関数を調べ、インポートや呼び出し経路をたどり、リポジトリ内の別の場所にある制御を探し、他の解釈が成り立たないかを検証し、答えが明確でない場合は調査を続けられます。

両者の違いは、ルールがなくなる点にあるのではありません。決定論的な解析は、候補となる弱点を見つけるうえで今も有用です。エージェントの役割は、最初のシグナルがこのアプリケーションにおいて何を意味するのかを調査することです。

エージェントは、単一のルールでは答えが出ないことの多い問いを立てられます。

• 入力は本当に攻撃者が制御できるものか
• 影響を受ける関数は到達可能か
• 共通のミドルウェアで検証が適用されているか
• 疑わしいシークレットは本物で実際に使われているのか、それとも単なるサンプル値か
• 依存関係に含まれる脆弱な機能は、実際に呼び出されているか
• フローの前段で認可制御が適用されているか
• 悪用にはどのような条件が必要か
• 想定される影響は、割り当てられた重大度に見合っているか

結果として得られるべきものは、より長いアラートではありません。より明確なエビデンスの連鎖を備えた、より少数の検出結果です。

このアプローチを採用しているのがOstorlab Source Codeです。Ostorlabは疑わしい一致の段階で止まらず、リポジトリのコンテキスト、影響を受ける経路、重大度、悪用可能性、ビジネスへの影響、修復ガイダンスをひとまとめに保持します。そのソースコードエージェントは、複雑な経路やロジックの欠陥を掘り下げ、開発者がレビューして対応できる検出結果を返すように設計されています。

検証は実際にどのように誤検知を減らすのか

従来のスキャナーは、疑わしいパターンをすべて報告し、どの検出結果が本物かの判断をセキュリティチームに委ねることが少なくありません。

Ostorlabは、その調査をスキャンそのものに組み込みます。ソースコードエージェントは脆弱な経路をたどり、周囲の制御を調べ、到達可能性と悪用可能性を評価し、より深い解析に耐えられないシグナルを除外します。

開発者に届くのは、はるかに少数の検出結果です。それぞれには、対応に必要な影響を受ける経路、影響、裏付けとなるコンテキスト、修復ガイダンスが含まれます。検証によって誤検知は減りますが、なくなるわけではありません。そのため、すべての検出結果には、レビュー担当者がすばやく確認または却下するために必要なエビデンスが引き続き付与されます。

これが、アラートを増やすことと、重要な脆弱性を見つけることの違いです。

ソースコードセキュリティテストで見えるもの、見えないもの

ソースコード解析では、次のような弱点を検出できます。

• SQL、NoSQL、コマンド、テンプレートの各インジェクションの経路
• 安全でないファイル操作とパストラバーサル
• クロスサイトスクリプティングやサーバーサイドリクエストフォージェリのパターン
• ハードコードされたシークレットと、安全でない暗号の使用
• 安全でないデシリアライゼーション
• 脆弱な依存関係の使用
• 検証やセキュリティ制御の欠如
• 認証と認可の弱点
• 安全でない状態遷移とワークフローのバイパス
• 十分なコンテキストがある場合の、アプリケーション固有のロジックの欠陥

とはいえ、ソースコードはシステム全体ではありません。静的解析は、本番環境にしかない設定、外部サービス、インフラ間の関係、実行時の状態、あるいはドキュメントや人の頭の中にしか存在しないビジネスルールを扱うのが苦手な場合があります。

そのため、ソースコードテストは他の形態のテストを置き換えるのではなく、補完するものであるべきです。

手法	最も得意とする対象	見落としうるもの
SAST	実行前のソースコード内の弱点	実行時および環境のコンテキスト
動的アプリケーションセキュリティテスト（DAST）	稼働中のアプリケーションで外部から観測できる挙動	到達または観測できない内部の経路
ソフトウェア構成分析（SCA）	サードパーティの依存関係に含まれる既知のリスク	脆弱な機能が実際に到達可能かどうか
手動コードレビュー	アーキテクチャ、意図、独自の制御、ビジネスロジック	すべての変更にわたる継続的なカバレッジ
エージェント型ソースコードテスト	リポジトリ全体のコンテキスト、反復的な検証、修復	コードの中にもその周辺にも存在しないコンテキスト

OWASPのセキュアコードレビューに関するガイダンスも同様に、自動解析と手動レビューを補完し合うものとして扱っています。自動化は疑わしい箇所を浮かび上がらせ、より踏み込んだレビューは、ツールが見落としうるコンテキスト、アーキテクチャ、ロジックを扱います。

エージェント型分析はビジネスロジックの欠陥を見つけられるか

ビジネスロジックの脆弱性への対処が難しいのは、コードが技術的には正しくても、ワークフローが安全でない場合があるためです。

あるユーザーが同じ割引を繰り返し適用する。マネージャーが自分自身の取引を承認する。あるテナントが、正規のエンドポイントを通じて別のテナントのリソースにアクセスする。いずれも、普遍的に危険な関数に似ているとは限りません。欠陥は、ロール、状態、意図された動作の関係性の中に存在します。

エージェント型分析は、ワークフローを再構築し、関連する操作間で制御を比較し、状態遷移と認可の境界について推論することで、カバレッジを高められます。

しかし、「AI搭載」であること自体はエビデンスになりません。信頼できる検出結果は、影響を受ける経路、破られた前提、悪用に必要な条件、そして想定される影響を示すべきです。

Ostorlabは、認可の不備、安全でない状態遷移、ワークフローのバイパスなど、複雑な脆弱性やロジックのバグに対して、このより深い分析を明示的に適用しています。価値があるのは「エージェント型」というラベルではなく、調査によって生み出されるコンテキストです。

すぐ対応に着手できる検出結果に含めるべき内容

開発者が修正に着手する前に、スキャナーが行った調査をすべてやり直さなければならない状況は避けるべきです。

すぐ対応に着手できる検出結果には、次の内容を含めるべきです。

• 影響を受けるリポジトリ、リビジョン、ファイル、コードの位置
• 脆弱性の明確な説明
• 関連するデータフローまたは制御フローの経路
• 攻撃者が制御できる入力、または破られた信頼境界
• 欠如している、回避されている、または機能していないセキュリティ制御
• 現実的な前提条件と影響
• その検出結果が悪用可能と判断される理由を説明するエビデンス
• そのアプリケーションに即した修復ガイダンス
• 安全な修正を生成できる場合は、提案するコード変更

重大度だけでは説明になりません。信頼できる経路を伴わない「クリティカル」のラベルは、調査を開発者に差し戻しているにすぎません。

Ostorlabは、影響を受ける経路、悪用可能性、影響、重大度、修復の優先度を軸に検出結果を整理します。修正はプルリクエストに送り返すことができ、開発者はリスクを持ち込んだコードの隣で、提案された変更をレビューできます。

開発者のワークフローにソースコードセキュリティを組み込む

セキュリティに関するフィードバックは、コードがマージされて忘れ去られたずっと後に届いたのでは、その価値を失います。

実践的なワークフローでは、次の要素を組み合わせます。

• 変更単位のスキャン：現在レビュー中のコードに対して、迅速なフィードバックを返します。
• リポジトリ全体のスキャン：ベースラインとなるカバレッジを確保し、レガシーアプリケーションにも対応します。
• リリースチェック：実際に出荷されるコードリビジョンそのものを確認します。
• 定期的な再評価：コードベースや脅威に関する知見の変化に合わせて実施します。
• 一元的な可視化：開発者がタスクのたびに普段のワークフローを離れることなく、アプリケーションセキュリティ（AppSec）チームがリスクを追跡できるようにします。

Ostorlabの現在のソースコードワークフローは、GitHub、GitLab、Bitbucket、Azure DevOps、標準的なGitリポジトリ、ZIPアップロードに対応しています。チームは解析対象としてブランチ、タグ、コミットを選択し、脆弱な経路と関連するエビデンスを確認したうえで、修復内容をプルリクエストに送り返せます。

目指すところはシンプルです。検出結果、コード、修正を同じ会話の中にまとめておくことです。

ソースコードセキュリティツールを評価するには

機能一覧が長くても、スキャナーを実際に使ったときの感触はわかりません。代表的なコードでテストし、ツールが見つける脆弱性だけでなく、ツールが生み出す作業量も測定してください。

次の点を確認してください。

検出結果は信頼できるか

• 各検出結果は、信頼できる経路と裏付けとなるコンテキストを示しているか
• 重大度は、実際の到達可能性と影響を反映しているか
• 報告された問題のうち、専門家によるレビューを経ても残るものはどれくらいあるか

自社のコードベースを理解しているか

• 使用している言語、フレームワーク、リポジトリ、ビルドシステムに対応しているか
• 独自のライブラリやセキュリティ制御を追跡できるか
• 個々の構文パターンにとどまらない推論ができるか

最初のシグナルの後に何が起こるか

• ツールは仮説を検証するのか、それとも単にスコアを付けるだけか
• サニタイザー、認可制御、到達不能な経路を認識できるか
• 根拠のない検出結果を、開発者に届く前に除外しているか

修復は役に立つか

• ガイダンスは根本原因に対処しているか
• 提案される修正は、そのアプリケーションとフレームワークに即したものか
• 開発者は、変更を受け入れる前にその内容を確認できるか

開発ワークフローに適合するか

• レビュー対象のブランチ、タグ、コミットをそのままスキャンできるか
• 検出結果と修正は、開発者が普段作業している場所に表示されるか
• フィードバックは、リリースに反映できるほど迅速か

概念実証（PoC）では、既知の脆弱性、過去に修正した実際の問題、独自の制御、汎用スキャナーが誤判定しやすいコードを含めてください。確認済みの検出結果、見逃された脆弱性、トリアージにかかった時間、修復にかかった時間、提案された修正が開発者に受け入れられた割合を記録してください。

アラート件数が多いからといって、カバレッジが優れている証明にはなりません。単に、ツールがより多くの不確実性をチームに押し付けただけかもしれません。

AI生成ソフトウェアの時代におけるソースコードセキュリティ

AIコーディングツールによって、ソフトウェア変更の量と速度は増しています。セキュリティチームが、同じように加速したペースでアラートを生成して対応するわけにはいきません。

コード生成がスケールする一方で、セキュリティ上の仮説の一つひとつに依然として手動のトリアージが必要なままであれば、ボトルネックはAppSecチームとエンジニアリングチームに移るだけです。

したがって、ソースコードセキュリティは、より調査型のものへと変わらなければなりません。リポジトリのコンテキストを理解し、重要なものを検証し、開発者が安全にレビューできる段階まで修復を進める必要があります。

意味のある問いは、もはや次のものではありません。

スキャナーにはいくつのルールがあるか？

問うべきは次の点です。

人に対応を求める前に、どれだけの不確実性を取り除けるか？

これこそが、Ostorlab Source Codeが基盤とする基準です。シグナルを追い、経路を理解し、答えが明確でないときは掘り下げ続け、対応に必要なコンテキストと修正を添えてリスクを返します。

Ostorlab Source Codeの詳細を見る