CI パイプラインに SCA ゲートを設定する：閾値設計から段階的ブロックまで
開発チームが普遍的に直面するジレンマがある。SCA スキャンを CI パイプラインに組み込んだ後、大量のアラートが放置されるか、あるいは即時ブロックによってパイプラインが毎日レッドになりエンジニアが迂回提出するようになるかのどちらかだ。どちらの結果も同じ失敗を指し示している——ゲートが形骸化するか、ゲートがチームの敵になるかだ。
問題は「スキャンするかどうか」ではなく、「ゲートポリシーをどう設計するか」にある。
ゲートの本質：リスク分級であり、全量ブロックではない
SCA を初めて導入するチームが最初に犯しがちな誤りは、「脆弱性を発見した」ことを即座に「ビルドをブロックする」と同一視することだ。このアプローチは初期段階で大量のノイズを生み出す。過去の依存関係に蓄積された既知の脆弱性、開発環境専用コンポーネントの低危険度の問題、そしてツール自体の誤検知がすべてブロックをトリガーし、最終的にエンジニアはアラートを無視する習慣を身につけるか、パイプラインを迂回するようになる。
より合理的な設計は三段階の分級である：
- ブロック（Block）：高危険度以上の脆弱性（CVSS ≥ 9.0）、既知の公開エクスプロイトチェーンが存在する重大脆弱性、製品リリースのコンプライアンスに影響するライセンス競合を持つコンポーネント。この段階はマージ前に解決が必須であり、例外は認めない。
- 警告（Warn）：中危険度の脆弱性、EOL コンポーネント（2015 年にはすでにメンテナンス終了している Log4j 1.x のようなバージョンを依然として使用している場合など）、潜在的なライセンス競合は存在するが影響範囲が未確認の状況。警告はチケットシステムに登録し、次のイテレーションで対処する。現在のビルドはブロックしない。
- 通過（Pass）：低危険度の脆弱性、テスト依存にのみ存在する問題、緩和策が講じられセキュリティチームが確認済みの既知リスク。SBOM に記録し、定期的に再審査する。
この分級ロジックは CleanSource SCA の内蔵ポリシーエンジンとほぼ一致している。CVSS スコア、脆弱性の到達可能性、ライセンス種別、コンポーネントの存在環境（本番/テスト/ビルド）など複数の軸を組み合わせたゲートルールの設定をサポートしており、一律適用による誤った影響を回避できる。
閾値設計：数字に意味を持たせる
「CVSS スコアがいくつになったらブロックするか」は最もよく聞かれる質問だが、閾値を決定するのは汎用的な基準ではなく、自社のビジネスシナリオだ。
閾値設計の段階で真剣に検討すべき観点を以下に示す：
- コンポーネントは攻撃面に直接露出しているか？ CVSS 7.5 の脆弱性が、内部バッチ処理のみに使われるバックエンドサービスに存在する場合と、外部向け API を提供するコアサービスに存在する場合とでは、対処優先度はまったく異なるべきだ。
- 公開 PoC または野外での利用が存在するか？ Log4Shell（CVE-2021-44228）は 2021 年 12 月に公開された時点で CVSS が 10 点だったが、野外での利用速度の速さはスコアそのものの参考価値を大きく薄めた——脆弱性の「注目度」がスコアよりも重要な場合もある。
- 修正バージョンは利用可能か？ アップストリームにパッチが存在しない場合、ブロックはプレッシャーを生むだけで解決策は生まれない。このような状況では、警告と緩和策の記録のほうが現実的だ。
- ライセンスリスクの境界はどこか？ GPL 系ライセンスを商業クローズドソース製品に取り込むことと、社内ツールに取り込むこととでは、法的影響がまったく異なる。ライセンス競合検出は製品形態に応じて個別にルールを設定する必要があり、脆弱性ゲートと同一の閾値を使い回すべきではない。
実行可能な出発点として：新規追加コンポーネント（増分部分）には厳格な閾値を適用し、既存コンポーネントには緩やかな閾値を適用しつつ、既存分には削減計画を設定する。これにより、技術的負債の無制限な拡大を許容せず、かつ過去の問題によって日常的な開発がブロックされることも防げる。
増分スキャン：ゲートを継続できるかどうかはスピードにかかっている
大規模プロジェクトでは、全量スキャンに数分から十数分かかることがある。MR のたびに全量スキャンが走れば、パイプラインの待機コストがすぐにエンジニアの反発を招く。
増分スキャンの核心的な考え方は：今回の変更で導入または更新されたコンポーネント、およびそれらと直接的な依存関係にあるコンポーネントのみをスキャンすることだ。変更のないコンポーネントについては前回のスキャンキャッシュの結果を流用し、定時ジョブ（例えば毎日深夜に全量スキャンを実行し、脆弱性インテリジェンスのマッチング結果を更新する）でのみ全量再確認を行う。
CleanSource SCA の増分スキャンモードは、MR トリガー 1 回あたりのスキャン時間を 60 秒以内に抑えることができる。Pre-Merge 段階でゲートを設定したいチームにとって、これは許容できるレイテンシ範囲だ。600 以上のパッケージ管理エコシステムをカバーし、3.2 億件のコンポーネントフィンガープリントを蓄積したデータ基盤と組み合わせることで、「変更部分のみスキャン」という方式でも脆弱性の見落としが生じるブラインドスポットは発生しない。
注目すべき点として、スニペットレベルの検出（ソースコードフラグメントの成分トレーサビリティ）とマニフェストレベルの検出を組み合わせることで、「依存関係ファイルには宣言されておらず、コードの中に潜んでいる」コンポーネントの混入を発見できる。両者のカバレッジの境界については、スニペットレベル SCA とマニフェストレベル SCA の比較分析を参照されたい。
誤検知処理：仕組みのないゲートは自己崩壊する
誤検知はすべてのセキュリティツールに固有の問題だ。チームに体系的な誤検知処理フローが整備されていなければ、最終的にアラートが集団的に無視されるか、誰かが設定を直接変更してルールを無効化するかのどちらかになる。CleanSource SCA の誤検知率は 15% 以内に抑えられているが、それでも規模の大きなプロジェクトでは誤検知の絶対数が認知的負担を生むには十分だ。
機能する誤検知処理フローには以下の要素が含まれるべきだ：
- 報告入口：エンジニアが CI 画面上で直接「誤検知の疑い」をマークし、判断根拠（例：脆弱性が影響するコードパスが当該プロジェクトでは到達不能など）を添付できること。
- 審査担当者：セキュリティチームまたは指定された Security Champion が固定 SLA 内（例：2 営業日）に確認または否認の判断を下すこと。
- 免除記録：誤検知と確認された場合、有効期限付きの免除エントリを生成し、プロジェクトレベルの設定ファイルに書き込んでバージョン管理に組み込むこと。免除エントリは期限切れ後に自動的に再審査をトリガーし、永久免除は認めないこと。
- アップストリームへのフィードバック：ツール側の体系的な誤検知については、ツールプロバイダーへのフィードバックチャネルを確立し、修正の進捗を追跡すること。
このフローの重要な点は「期限付き免除」であり「永久例外」ではないことだ——ゲートに柔軟性を持たせながら、免除リストが際限なく膨張してもう一つの形のルール失効になることを防ぐ。
Jenkins と GitLab CI への統合における実践的なポイント
Jenkins への統合
Jenkins では通常、Pipeline スクリプト（Jenkinsfile）を通じて SCA スキャンを統合する。推奨する挿入位置はユニットテストの後、アーティファクトのビルド前だ。CleanSource SCA は CLI ツールと REST API の両方の呼び出し方式を提供しており、sh ステップで直接呼び出せる。スキャン結果は JSON または SARIF 形式で出力され、後続の解析が容易だ。
ゲートロジックはツールのデフォルト動作に依存するのではなく、Jenkinsfile 内に明示的に記述することを推奨する。例えば：スキャン結果から重大な脆弱性の件数を読み取り、ゼロより大きければ error() を呼び出してパイプラインを終了する。中危険度の脆弱性の件数は環境変数に書き込み、unstable() でビルドを「不安定」とマークし、直接失敗とはしない。このような明示的な制御により、ポリシーの変更がツールのアップグレードに依存せず、バージョンも追跡可能になる。
GitLab CI への統合
GitLab CI の .gitlab-ci.yml では SCA スキャンを独立した stage として設定でき、allow_failure: true/false によって後続 stage をブロックするかどうかを制御できる。推奨する設定方式：
scanstage で CleanSource SCA を実行し、結果ファイルを出力する。gatestage でポリシー評価スクリプトを実行し、分級ルールに基づいてexit 1するかどうかを決定する。- スキャンレポートを
artifactsで保存し、MR 画面での表示と後続の監査に利用する。
GitLab の Merge Request Approval Rules は、gate stage が失敗した場合にセキュリティチームのメンバーが手動承認しなければマージできないよう設定できる。直接ブロックよりも柔軟であり、高速なイテレーションが求められるビジネスラインに適している。
SAST 機能も必要なチームには、CleanCode Security Agent を CleanSource SCA と同一パイプライン内で並列実行できる。共通のスキャントリガーを使用するため、重複した設定による保守負担を避けられる。バイナリ配信またはファームウェアのシナリオが関係する場合、CleanBinary がアーティファクト公開段階で成分分析のカバレッジを補完できる。
---
SCA ゲートの設定は一度きりのエンジニアリングタスクではなく、継続的なキャリブレーションを必要とするプロセスだ。脆弱性インテリジェンスは更新され続け、コンポーネントエコシステムは進化し、ビジネスのリスク許容度も変化する——ゲートポリシーもそれに応じて反復すべきである。段階的ブロックから始め、増分スキャンの速度を許容可能なレベルにまで引き上げ、誤検知処理のフローを機能させることで、ゲートは初めて開発プロセスの一部として定着し、エンジニアが迂回しなければならない障壁ではなくなる。
業界ごとの差異化された SCA ポリシー設計について知りたい場合は、金融業界におけるオープンソースガバナンスの実践および医療機器の SBOM コンプライアンスの具体的なケーススタディを参照されたい。