セキュリティ検出結果と証拠¶
セキュリティ検出では、セキュリティ上重要な呼び出しに限定されたモデル化されたソースからのデータ フローの観察または候補コードのリスクが記録されますが、脆弱性、悪意のある意図、または悪用の成功は確認されません。次の動作は、Java、Node.js、および Python の公開バージョンに基づいており、PHP または .NET に同じ分析機能があることを意味するものではありません。 .NET の公開範囲については、.NET Security を参照してください。
公開バージョンとイベント形式¶
| 言語 | リクエストごとのロギングと攻撃証拠を初めてサポート | スキーマ v2 を初めて使用する | このガイドで使用されているバージョン |
|---|---|---|---|
| Java | 1.3.0 | 1.3.3 | 1.3.4 |
| Node.js | 1.3.0 | 2.0.0 | 2.0.1 |
| Python | 1.2.0 | 1.2.3 | 1.2.4 |
レコードを解釈する前に、schema_version を読み取ります。イベント名は依然として beacon.security.finding で、フィンガープリントのバージョンは依然として 1 です。スキーマを共有しても、実行時のカバレッジが同じになるわけではありません。古い運用エンドポイントには、オプションのリクエスト レコード、サンプリング、または攻撃証拠フィールドが欠落している可能性があります。 missing fields do not equal no_evidence.
コードのリスク、証拠の要求、およびエクスプロイトの結果¶
スキーマ v1 では、assessment=observation または candidate_risk はコードのリスクを示し、validation=unvalidated は検証されていないことを意味し、オプションの attack_evidence は現在のリクエストを示します。これら 3 つの次元は個別に解釈する必要があります。
attack_evidence.status |
意味 |
|---|---|
unknown |
分析が利用できない、サポートされていない、不正確である、予算を超えている、または必要な境界ポリシーが欠如している。 |
no_evidence |
サポートされる分析で攻撃の証拠が見つからなかったことを示します。安全であることやコード上のリスクがないことを意味しません。 |
suspected |
サポートされている分析は、悪用の可能性の証拠を明らかにしますが、悪意のある意図や悪用の成功を証明するものではありません。 |
attack_evidence.reason は、プログラムで読み取ることができる長さ制限のある理由であり、元の要求値は含まれません。 attack_evidence.outcome=not_assessed の v1。スキーマ v2 では、固定の評価および検証のプレースホルダー フィールドと固定の結果フィールドが省略されています。省略した場合でも使用が確認されたわけではありません。呼び出し、通常の戻り、または特定の HTTP ステータスを観察するだけでは、悪用の成功を証明することはできません。
テイント範囲が正確で、サポートされている ANSI SQL 分析が有効になっている場合、次の状況は異なる意味を持ちます。キーワードによる攻撃の一致ルールではなく、機密性の高い通話のコンテキストを説明する例:
| 用途 | 解釈 |
|---|---|
| 通常の入力は動的SQLの引用符で囲まれた値に結合されます | サポートされている分析で no_evidence が返された場合でも、候補コードのリスクが依然として存在する可能性があります。 |
| 個別にバインドされたパラメータ値を持つ SQL テンプレートを修正 | SQL テンプレート インジェクションの検出は、プレーン バインディング値では発生しません。ステートメントを準備する前に信頼できないテンプレートを構築する場合は別のケースです。 |
| 信頼できない入力コントロールは SQL 構造演算子またはコメント区切り文字をサポートしました | suspected が返される場合がありますが、データベースがエクスプロイトを実行したことを証明するものではありません。 |
| 方言が設定されていない、構文がサポートされていない、汚染が不正確である、または分析予算が枯渇している | unknown を保持してください。これに基づいて安全性を主張することはできません。 |
ANSI スイッチと分析境界は、個々の言語ページで提供されます。上記のバージョンでは、ネットワーク許可リストやファイル システム ルート ディレクトリ ポリシーが実装されておらず、これらの境界ポリシーに依存する攻撃判定は依然として unknown です。単なるパスの正規化だけではパスは安全になりません。
1 つの発見、多くのリクエスト¶
finding_id は安定したコード リスク フィンガープリントを表し、occurrence_id はディスカバリーの検出リクエストを識別します。 Java 1.3.0 スキーマ v1 では、これはリクエストの evidence_id に相当します。同じリクエスト内で同じフィンガープリントが繰り返し検出された場合は、1 回だけカウントされます。より強力な証拠があれば、同じ ID でリクエスト レコードを更新できます。
次の Java 1.3.0 の例では、集約が利用可能であり、3 つのリクエストが同じ完全な証拠サンプリング間隔内にあることを前提としています。テーブル内の ID は、リテラルのイベント ペイロードではなく、回路図ラベルです。各リクエストには、現在のリクエストに対する独自のトレース/スパン コンテキストがあります。
| リクエスト | finding_id |
evidence_id = occurrence_id |
Trace / Span | 詳細な証拠を保持 | occurrences_total |
|---|---|---|---|---|---|
| A | F | A1 | trace-A / span-A | はい、最初のサンプリングです | 1 |
| B | F | B1 | trace-B / span-B | いいえ、間隔サンプリング | 2 |
| C | F | C1 | trace-C / span-C | いいえ、間隔サンプリング | 3 |
詳細な証拠のサンプリングは、リクエスト レコードのエクスポートおよび OpenTelemetry トレースのサンプリングとは独立しています。 B の詳細な証拠はサンプリングされませんでしたが、これは B が検出されなかったことを意味するものではありません。トレースの欠落またはサンプリングされていないトレースは、安全な検出を妨げません。また、検出時のトレース ID は、対応するリンクがバックエンドに到達したこと、またはまだ保存されていることを保証しません。
同じリクエスト内の証拠の優先順位は suspected > unknown > no_evidence です。証拠のエスカレーションでは、リクエストのステータス数は移動しますが、発生数は増加せず、通常の証拠サンプリング間隔をバイパスできます。さまざまなリクエストは通常→疑わしい→通常と個別に分類され、最後のリクエストは疑わしいリクエストには変わりません。保持されている最も強力な代表的な証拠はおそらく中間リクエストからのもので、last_trace_id は最新のリクエストからのものです。 v2 は、ローカル診断出力が明示的に有効になっている場合にのみ、完全な代表的な証拠と累積的なローカル カウントを保持します。
v1 の attack_evidence_counts は、集計リクエストの数を 3 つの状態に分割します。これは証拠ステータスの数であり、確認された攻撃の数ではありません。 v2 のオンライン ロードには累積発生回数がありません。コンシューマは、instance_id + occurrence_id によって重複排除し、finding_id によってグループ化し、同じ発生のアップグレードをマージします。各更新は新しいリクエストとしてカウントできません。
サンプリングと移行¶
| プロジェクト | Java 1.3.0–1.3.2 schema v1 | 上記スキーマ v2 バージョン |
|---|---|---|
| リクエストレコード識別子 | evidence_id とその別名 occurrence_id |
occurrence_id; evidence_idを削除 |
| 詳細な証拠がサンプリングされていない | evidence_sampled=false、必須の sources、propagation、ranges、stack 配列が空です |
evidence_sampled=false;空の証拠配列が省略されました |
| サンプリングの理由 | evidence_sample_reason、詳細を省略する場合はtruncated=true、truncation_reason=evidence_sampled_outを追加 |
evidence_sample_reason;サンプリングのみでは切り捨てを意味しません |
| 収集制限 | 切り捨てられたフィールド説明の証拠は不完全です | collection_complete は観測の品質を表します。 truncated=true は、実際の取得またはコーディングの切り捨てを表します。 |
| 重合 | aggregation_status=tracked の場合、プロセス ローカル occurrences_total があります。 capacity_exceeded の場合、合計数は省略され、制限付きリクエスト レコードのエクスポートが続行されます。 |
オンラインの合計および独立した要約、健全性、損失、および切り捨て記録イベントを削除します。受信したリクエストレコードのバックエンド集約 |
空の証拠配列または省略された証拠配列は、汚染がないことを証明するものではありません。 v1 プロセスのローカル数は、クラスター レベルまたは永続的な合計ではありません。 v2 レコードは、v1 イベント スキーマに対して検証できません。公開されている Java v1 リファレンス および Java v2 リファレンス を参照してください。
輸出ポリシーと配送制限¶
Java 1.3.4、Node.js 2.0.1、および Python 1.2.4 は、デフォルトでは、no_evidence の結果を OpenTelemetry ログおよび証拠の JSONL にエクスポートしません。 BEACON_SECURITY_EXPORT_NO_EVIDENCE_ENABLED=true を設定してエクスポートを再開します。 unknown および suspected は引き続きエクスポートでき、SBOM は影響を受けません。フィルタリングはキューに参加する前に行われ、キューや送信クォータを占有せず、エクスポート損失としてカウントされません。内部検出、重複排除、および同一リクエスト証拠のアップグレードは引き続き実行されます。このスイッチは Java 1.3.3 ではまだ使用できませんが、1.3.4 から使用できるようになります。上記の A/B/C v1 の例は、このエクスポート ポリシーより前のものです。
詳細な証拠のサンプリングを行ったとしても、重複した結果によりログの量が増加する可能性があります。キュー、メモリ、エントリあたりのバイト数、およびレート バジェットには上限があります。 v1 は観察可能な損失数を提供します。通常のレコードが収まらない場合は、最小限の切り捨てエンベロープのみが送信される場合がありますが、これは必ずしもオカレンス フィールドやトレース フィールドを保持するわけではありません。 v2 では、これらの独立した診断イベントが削除され、失われたレコードを補うための再生イベントは生成されません。レコードの欠落は、ポリシーのフィルタリング、収集制限、キューの損失、転送の失敗、または保持ポリシーが原因で発生する可能性があります。受信した記録に基づくカウントは受信した観測値のみを表しており、完全な国勢調査ではありません。リクエストのログ記録も OpenTelemetry API 呼び出しも、永続的な配信やバックエンドの確認を保証しません。