Salesforceによると、最先端モデルとエージェント用ハーネスが、エンジニアリングチームの処理能力を超えるペースで悪用可能なコード上の脆弱性を見つけています。同社のセキュリティ責任者は、発見後の工程にボトルネックがあると説明します。どの指摘に対応し、どう分類するかの判断が追いついていません。脆弱性の発見はAIによって加速しましたが、検証や修正の進め方は同じ速度では変わっていません。検証には環境へのアクセス権や認証情報、専門家の判断が必要で、修正にはレビューとリリースの手順があります。そのため発見は機械の速度で進む一方、修正は人間の速度にとどまっています。

Salesforceは、異なる期間で進める二つの対策を軸に修正を整理しています。戦略的アプローチではコードベース全体に潜む体系的なリスクを見つけ、設計上の修正で対処します。戦術的アプローチでは、個別の攻撃経路を検証して塞ぎ、数時間から場合によっては数週間で対応します。各対策は工程の異なる段階を担います。戦略的な作業では検証時に重複する欠陥をまとめ、報告時に共通ライブラリーやデータの流入先を基準に指摘を分類します。戦術的な作業では、攻撃経路が最初から最後まで実際に機能するか、検証と再攻撃で確かめます。

同社によると、詳細な監査で見つかる指摘は、プラットフォームの初期設定、安全でない基本処理、チェック機構の欠如など、少数の共通原因に集中することがよくあります。一つの不適切な基本処理が、数百件から数千件の指摘を生む場合もあります。共通する設計上の原因を修正すれば、多数の指摘を一度に解消できます。一方、指摘ごとに対応するには、それぞれに担当者の設定、レビュー、導入、再テストが必要です。Salesforceは、体系的な修正によって、技術責任者が資源を割り当て、日程を決められる範囲に設計上のリスクを整理できると説明します。その実行には明確なガバナンスとエンジニアリング上の責任者が必要です。発見規模の拡大には計算資源が要りますが、その結果を受け止めるには組織設計が求められます。

戦術的な修正では、検証済みの複数段階のエクスプロイトチェーン（複数の手順を組み合わせた攻撃経路）ごとに対応し、その後に再テストします。最も重大度の高い対象では、Salesforceは稼働中のステージング環境で攻撃経路を試します。静的解析では到達可能に見えても、実際には悪用できない経路と区別するためです。同社によると、実行時の設定、機能フラグ、ミドルウェアが、見かけ上の経路を遮断する場合があります。この検証を通過した確度の高い指摘は、実際の対象に対する攻撃として高い成功率を示してきたとしています。直近の実行では、独立して提出されたバグ報奨金の報告と一致する重大な問題をパイプラインが発見しました。各サービスをテスト用に準備するには時間とサービスチームの知識が必要なため、同社はこの手順を重大度の高い対象に限っています。サービスチームが動作するコンテナやComposeの定義を提供すれば、検証をより自動化できる可能性があると説明しています。

Salesforceは、どちらか一方だけでは対応に抜けが生じると指摘します。戦略的な修正では個別に検証された攻撃経路を見落とす可能性があり、戦術的な修正だけでは個別対応が予算やエンジニアリングの作業待ちを圧迫しかねません。同社は、長期的な設計改善と、攻撃者が対応する前に修正する必要がある脆弱性へのパッチを組み合わせています。セキュリティ責任者には、体系的なリスクを独立した成果として分類し、発見規模を拡大する前に担当エンジニアとリリース計画を決めるよう勧めています。また、修正までに使える時間を基準に検証済みの攻撃経路を優先し、分析エンジンを交換できるハーネスを構築するよう提言しました。手法は積み重ねて発展させられる一方、基盤となる分析エンジンは交換可能だとしています。エンジンは、担当者が介在する際のコストと信頼性について、チームの業務に照らして評価する必要があると述べています。

Salesforceによると、最先端モデルとエージェント用ハーネスが、エンジニアリングチームの処理能力を超えるペースで悪用可能なコード上の脆弱性を見つけています。同社のセキュリティ責任者は、発見後の工程にボトルネックがあると説明します。どの指摘に対応し、どう分類するかの判断が追いついていません。脆弱性の発見はAIによって加速しましたが、検証や修正の進め方は同じ速度では変わっていません。検証には環境へのアクセス権や認証情報、専門家の判断が必要で、修正にはレビューとリリースの手順があります。そのため発見は機械の速度で進む一方、修正は人間の速度にとどまっています。

Salesforceは、異なる期間で進める二つの対策を軸に修正を整理しています。戦略的アプローチではコードベース全体に潜む体系的なリスクを見つけ、設計上の修正で対処します。戦術的アプローチでは、個別の攻撃経路を検証して塞ぎ、数時間から場合によっては数週間で対応します。各対策は工程の異なる段階を担います。戦略的な作業では検証時に重複する欠陥をまとめ、報告時に共通ライブラリーやデータの流入先を基準に指摘を分類します。戦術的な作業では、攻撃経路が最初から最後まで実際に機能するか、検証と再攻撃で確かめます。

同社によると、詳細な監査で見つかる指摘は、プラットフォームの初期設定、安全でない基本処理、チェック機構の欠如など、少数の共通原因に集中することがよくあります。一つの不適切な基本処理が、数百件から数千件の指摘を生む場合もあります。共通する設計上の原因を修正すれば、多数の指摘を一度に解消できます。一方、指摘ごとに対応するには、それぞれに担当者の設定、レビュー、導入、再テストが必要です。Salesforceは、体系的な修正によって、技術責任者が資源を割り当て、日程を決められる範囲に設計上のリスクを整理できると説明します。その実行には明確なガバナンスとエンジニアリング上の責任者が必要です。発見規模の拡大には計算資源が要りますが、その結果を受け止めるには組織設計が求められます。

戦術的な修正では、検証済みの複数段階のエクスプロイトチェーン（複数の手順を組み合わせた攻撃経路）ごとに対応し、その後に再テストします。最も重大度の高い対象では、Salesforceは稼働中のステージング環境で攻撃経路を試します。静的解析では到達可能に見えても、実際には悪用できない経路と区別するためです。同社によると、実行時の設定、機能フラグ、ミドルウェアが、見かけ上の経路を遮断する場合があります。この検証を通過した確度の高い指摘は、実際の対象に対する攻撃として高い成功率を示してきたとしています。直近の実行では、独立して提出されたバグ報奨金の報告と一致する重大な問題をパイプラインが発見しました。各サービスをテスト用に準備するには時間とサービスチームの知識が必要なため、同社はこの手順を重大度の高い対象に限っています。サービスチームが動作するコンテナやComposeの定義を提供すれば、検証をより自動化できる可能性があると説明しています。

Salesforceは、どちらか一方だけでは対応に抜けが生じると指摘します。戦略的な修正では個別に検証された攻撃経路を見落とす可能性があり、戦術的な修正だけでは個別対応が予算やエンジニアリングの作業待ちを圧迫しかねません。同社は、長期的な設計改善と、攻撃者が対応する前に修正する必要がある脆弱性へのパッチを組み合わせています。セキュリティ責任者には、体系的なリスクを独立した成果として分類し、発見規模を拡大する前に担当エンジニアとリリース計画を決めるよう勧めています。また、修正までに使える時間を基準に検証済みの攻撃経路を優先し、分析エンジンを交換できるハーネスを構築するよう提言しました。手法は積み重ねて発展させられる一方、基盤となる分析エンジンは交換可能だとしています。エンジンは、担当者が介在する際のコストと信頼性について、チームの業務に照らして評価する必要があると述べています。