Skip to main content

​
フィンガープリントとは

フィンガープリントは、コードベース内のセキュリティ脆弱性をCorgeaが一意に識別するための仕組みです。各セキュリティ問題の「DNA」に相当する一意の識別子であり、時間の経過とともにコードが多少変化しても、複数のスキャンにわたって同じ脆弱性を認識できます。
フィンガープリントはバックグラウンドで自動的に機能します。設定やメンテナンスは不要で、コードのスキャンを開始した時点からそのまま利用できます。

​
仕組み

Corgeaがコードをスキャンしてセキュリティ問題を特定すると、次のような主要な特徴に基づいてフィンガープリントを作成します。
  • 位置:問題が発生するファイルパスと行番号
  • コンテキスト:特定のコード行とその周囲の構造
  • 分類:セキュリティ脆弱性の種類(例:SQLインジェクション、XSSなど)
これらの要素を組み合わせ、コードベースを複数回スキャンしても維持される、一意で一貫した識別子を作成します。

​
ASTを活用した識別

Corgeaは**抽象構文木（AST）**解析を使用し、コードの変更に対してフィンガープリントをより高精度かつ堅牢にします。
抽象構文木は、テキストそのものだけでなく、異なるコード要素間の意味や関係を理解するコードの構造的表現です。テキストの完全一致や行番号だけに基づく従来のフィンガープリントは、次のような変更で簡単に一致しなくなる場合があります。
  • 空欄やコメントの追加・削除
  • コードの再フォーマット(インデント、スペースの変更など)
  • 変数名や関数シグネチャのリファクタリング
ASTが重要な理由: AST情報をフィンガープリントに組み込むことで、Corgeaは次のことが可能になります。
  • 表面的なコード変更が起きても同じ脆弱性を認識
  • テキストの一致だけでなく意味に注目
  • コードの再編成やリファクタリング後も追跡を継続
  • 見た目は似ていても異なる問題による誤検知を削減
ASTベースのフィンガープリントにより、コードが進化する中でも、開発ライフサイクル全体を通じてセキュリティ問題をより安定かつ確実に追跡できます。

​
フィンガープリントの用途

複数回のスキャンを実行した場合、Corgeaはフィンガープリントを使用して問題が次のどの状態にあるかを認識します。
  • 以前のスキャンから継続して存在
  • 修正済みで、検出されなくなった
  • 解決後に再登場

​
フィンガープリントが変わる条件と理由

Corgeaのフィンガープリントは軽微なコード変更では変わらないように設計されていますが、正当な理由で変わる場合もあります。次の条件を把握しておくと、スキャン結果を正しく解釈できます。
フィンガープリントが変わる条件を理解することは、問題を正確に追跡してセキュリティを管理するうえで重要です。

​
新しいフィンガープリントが生成される状況

何が起こるか: ファイルを別のディレクトリに移動したり名前を変更したりすると、その脆弱性には新しいフィンガープリントが付与されます。例: src/utils/database.pyをsrc/core/db.pyに移動すると、脆弱性のあるコードが同一でも新しいフィンガープリントが作成されます。理由: ファイルパスはフィンガープリントの中核となる要素です。これにより、プロジェクト構造内のどこに脆弱性があるかを追跡できます。表示される内容: 古い問題は「修正済み」と表示され、新しい場所で新たな問題が検出される場合があります。
大規模なファイル再編成を行う場合は、セキュリティチームと連携してコンテキストを確認してください。
何が起こるか: 脆弱性のあるコードの構造やコンテキストを変更する大規模なリファクタリングでは、新しいフィンガープリントが生成されます。例: 脆弱なインラインSQLクエリを、同じ脆弱性を残したままデータベースヘルパー関数に変換すると、AST構造が大きく変わります。理由: ASTベースのフィンガープリントは軽微なリファクタリングには対応できますが、大幅な構造変更はコードのコンテキストが実質的に変わったことを示します。表示される内容: 根本的な脆弱性パターンが残っていても、元の問題が解決済みになり、新しい問題が表示されます。
大規模なリファクタリングを行う際は、単に脆弱性を移動するのではなく、修正の機会として捉えてください。
何が起こるか: 脆弱性のあるコードの位置が大きく変わる大規模な挿入や削除は、指紋が変わる可能性があります。例: 脆弱性の上に200行分の新しいコードを追加すると、そのコンテキストが変化し、指紋が変わるかもしれません。理由: フィンガープリントは軽微な行番号の変更には耐性がありますが、大幅な移動はファイル内でのコードのコンテキストが変わったことを示します。表示されるもの: 問題が解決したように見え、別の行番号で再出現することがあります。
ASTを利用しているため、この状況はまれです。発生した場合は、重複としてマークする前に本当に同じ問題か確認してください。
何が起こるか: Corgeaの分析で問題を再分類すべきと判断された場合（例:「Potential SQL Injection」から「Confirmed SQL Injection」）、新しいフィンガープリントが付与されます。例: 後続のスキャンで得られた追加のコンテキストにより、脆弱性の分類が引き上げられたり変更されたりする場合があります。理由: 分類は問題を一意に識別する要素の1つです。分類が異なれば、必要な修復方法も異なる場合があります。表示される内容: 1つの問題が終了し、同じ場所に重大度や種類の異なる別の問題が表示されます。
分類の変更に注目してください。これらはしばしばセキュリティリスクに関する重要な新情報を示しています。
何が起こるか: 脆弱性そのものを解消していなくても、脆弱なコード行を変更するとフィンガープリントが変わる場合があります。例: 変更前:
変更後:
SQLインジェクションの脆弱性は残りますが、フィンガープリントは変わります。理由: 具体的なコードのコンテキストもフィンガープリントの一部です。フィンガープリントが変わることで、誰かがコードを変更したことが分かり、適切に修正する機会になります。ご覧いただく内容: 古い問題は解決したように見えますが、新たに似た問題が発生しています。
脆弱なコードを修正する際は、表面的な変更だけでなく、セキュリティ問題を適切に修正する機会として活用してください。

​
フィンガープリントが変わらない状況

通常、次の変更はフィンガープリントに影響しません。
  • コメントの追加・削除
  • 空白やインデントの変更
  • 局所変数のリネーム(ほとんどの場合)
  • 脆弱性の行の前後にコードを追加する(合理的な範囲で)
  • スタイルガイドに基づく再フォーマット
  • ログやデバッグ文を近くに追加すること

​
フィンガープリント変更への対処

1

問題履歴を確認

Corgeaはすべての履歴イベントをフィンガープリント単位で追跡するため、元の問題のタイムラインを確認できます。
2

コード変更の確認

バージョン管理システムを活用して、スキャン間に何が変わったのかを確認してください。
3

追跡情報を更新

外部システム（Jiraなど）で問題を追跡している場合は、参照情報の更新が必要になることがあります。
4

修正の機会として活用

フィンガープリントの変更は、脆弱性のあるコードが変更されたことを意味する場合が多いため、修正が完全かつ適切か確認する好機です。
5

サポートに連絡

フィンガープリントが誤って変更された、または予期せず変更されたと思われる場合は、Corgeaのチームが調査を支援します。
「どのような変更があっても同じフィンガープリントを維持すればよいのでは」と思うかもしれません。Corgeaの方法には次の利点があります。
  • 精度:コードのコンテキストが実質的に変わった場合、新しいフィンガープリントによってコードベースの現状を正確に追跡できます。
  • 可視性:フィンガープリントの変更からコードが変更されたことが分かり、セキュリティチームにとって有用な情報になります。
  • 柔軟性:問題が修正済みとされているのに脆弱性が少し異なる形で残る、古い状態の問題追跡を防ぎます。
  • コンプライアンス:監査トレイルは、単に存在の継続を反映するのではなく、実際のコード変更を反映している場合により正確です。

​
主な利点

重複検出による件数の水増しを避け、セキュリティ態勢を正確に把握できます。また、コード変更が追跡中の脆弱性に影響したタイミングを確認できます。

​
お問い合わせ

フィンガープリントがあなたの特定のユースケースにどのように影響するかについて質問があったり、予期せぬ指紋変更に気づいたり、環境内での問題追跡について詳しく知りたい場合は、Corgeaのサポートチームにご連絡ください。

お困りの場合は

フィンガープリントやその他のご質問については、サポートチームまでお問い合わせください。