実際に壊れること
- 過去の判断がリポジトリに紐付いていないため、同じ無害な検出結果が繰り返し現れる。
- スキャンの背後に耐久性のあるチーム状態がないため、開発者ごとに同じ issue の見え方が変わる。
- リーダー層には、検出結果、サプレッション、進捗の継続的な物語ではなく、スナップショットしか見えない。
チームメモリ
単発スキャン以上を必要とするチームのための共有セキュリティメモリ
すべてのスキャンがゼロから始まると、セキュリティワークフローは破綻します。Oryon はリンク済みリポジトリを共有メモリとして扱うことで、サプレッション、検出結果、プロジェクト履歴を開発者や将来のスキャンをまたいで維持します。
共有セキュリティメモリ
セキュリティに共有メモリがないと失われるもの
リポジトリがリンクされると、リポジトリに紐付いた検出結果と依存関係の脆弱性を一括同期できる。
- サプレッションとスキャン履歴を、単一のローカルセッションを超えて残したい。
- ダッシュボードを主スキャナーではなく、共有メモリとして使いたい。
- 開発者ワークフローとチーム全体のフォローアップを、より強く結び付けたい。
なぜメモリが重要か
セキュリティに共有メモリがないと失われるもの
仕組み
ローカルスキャンがチーム共有状態になるまで
01
リポジトリをプロジェクトにリンク
ワークフロー内
拡張機能はリポジトリを識別し、プロジェクトに紐付けることで、以後のアップロードが同じチームコンテキストに属するようにします。
何が残るか
これにより、孤立したローカルスキャンが、個々のセッションを超えて残る継続レイヤーへ変わります。
02
検出結果と依存関係状態を一括同期
ワークフロー内
リンク後は、検出結果と依存関係の脆弱性をチャンク単位でアップロードでき、そのリポジトリの最新スキャン状態がダッシュボードに反映されます。
何が残るか
これにより、スキャン実行場所を変えずに、エンジニアリングと AppSec が同じ共有参照点を持てます。
03
サプレッションと履歴を引き継ぐ
ワークフロー内
共有サプレッションとスキャン履歴はリポジトリに結び付いたまま保持されるため、後続スキャンはゼロから作り直すのではなく、そのコンテキストを再利用できます。
何が残るか
これが、単発スキャナーと継続運用できるシステムの違いです。
適したケース
共有セキュリティメモリが本当の利点になるケース
Oryon を選ぶべきケース
- サプレッションとスキャン履歴を、単一のローカルセッションを超えて残したい。
- ダッシュボードを主スキャナーではなく、共有メモリとして使いたい。
- 開発者ワークフローとチーム全体のフォローアップを、より強く結び付けたい。
別のモデルが向いているケース
- 最初のスキャン後にリポジトリ連携の継続性が必要ない。
- 共有サプレッションやスキャン履歴が運用モデル上重要ではない。
- ローカルファースト層を維持するよりも、スキャンエンジン自体を中央集約したい。
FAQ
最初のスキャン後も継続性が欲しいときによくある質問
- 具体的に何が共有メモリになりますか？
- 共有レイヤーには、リンク済みプロジェクト状態、検出結果、依存関係の脆弱性、サプレッション、リポジトリに紐付くスキャン履歴が含まれます。
- 開発者は引き続きローカルで作業しますか？
- はい。共有セキュリティメモリは、ローカルファーストワークフローを置き換えるものではありません。ローカルスキャン後も有用であるべき状態を保持するものです。
- なぜこれで重複レビュー作業が減るのですか？
- 同じ無害な検出結果を再判断したり、リポジトリ再スキャンのたびに以前のスキャンコンテキストを失ったりしなくなるからです。