Skip to main content

​
概要

​
機能

ブロッキングルールは、どの検出結果でプルリクエストのチェックやCIパイプラインを失敗させるかを定義するガードレールです。コードベースが組織のセキュリティ基準と品質基準に沿うようにします。 ブロッキングルールは3種類作成できます:
  • Code Vulnerability Rules: セキュリティ脆弱性、コード品質の検出結果、またはその両方に基づいてPRをブロックする
  • Dependency Vulnerability Rules: SCAスキャンで検出された脆弱な依存関係に基づいてPRをブロックする
  • License Compliance Rules: 特定のSPDXライセンスまたはライセンスファミリを持つ依存関係をブロックする

​
誰のためか

ブロッキングルールは主に以下のために設計されています:
  • 開発チーム
  • プロジェクトマネージャー
  • セキュリティ専門家
この機能は、厳格なコンプライアンス要件を持つ組織や、コードの品質とセキュリティが最重要となるミッションクリティカルなアプリケーションに取り組む場合に特に有用です。

​
主な特徴と利点

Common Weakness Enumerations（CWE）に基づくルールを定義し、特定の脆弱性やコード品質の問題を導入するプルリクエストをブロックします。
問題の種類ごとに緊急度（Critical、High、Medium、Low など）を割り当て、優先度を付けて対応できます。
Dependency Vulnerabilityルールでは、両端を含むCVSSスコア範囲を指定し、該当する脆弱な依存関係をブロックします。
CIに適用するDependency Vulnerabilityルールでは、脆弱なコードがアプリケーションから実際に到達可能な依存関係のみをブロック対象に絞り込めます。未使用または到達不能なパッケージがパイプラインを失敗させることはありません。
特定のSPDXライセンスID、またはCopyleft、Permissive、Commercialのライセンスファミリで依存関係をブロックします。
特定のプロジェクト、プロジェクトタグ、または組織全体にブロッキングルールを適用し、どのプロジェクトにどのルールを適用するかを細かく管理できます。
使いやすいインターフェースでブロッキングルールを作成、編集、削除でき、変化する要件に合わせてルールを最新の状態に保てます。
ブロッキングルールのステータスを切り替え、設定を失わずに一時的に有効化または無効化できます。

​
ルールの種類

ブロッキングルールには、幅広いセキュリティ要件に対応する3つのタイプがあります。

Code Vulnerability

セキュリティ脆弱性、コード品質の検出結果、またはその両方に基づいてプルリクエストをブロックします。設定方法:
  • 問題タイプの選択: All、Vulnerabilities、またはCode Quality
  • 特定のCWE（Common Weakness Enumeration）カテゴリの選択
  • 緊急度/重大度レベルの設定
SQLインジェクション、XSS、安全でない暗号化など、コードレベルの脆弱性があるプルリクエストをブロックできます。

Dependency Vulnerability

ソフトウェア構成解析（SCA）で検出された脆弱な依存関係に基づいてプルリクエストをブロックします。設定方法:
  • 緊急度/重大度レベルの設定（Critical、High、Medium、Low）
  • または、0.0から10.0までのCVSSスコア範囲を両端を含めて設定
  • 必要に応じて到達可能性で絞り込み（CIルールのみ）
既知のセキュリティ脆弱性があるパッケージの導入を防ぎ、サプライチェーンを保護できます。

License Compliance

依存関係が拒否対象のライセンスを使用している場合に、プルリクエストまたはCIパイプラインをブロックします。設定方法:
  • 1つ以上のライセンスファミリを選択: Copyleft、Permissive、またはCommercial
  • 特定のSPDXライセンスIDを入力（例: AGPL-3.0）
組織のオープンソースおよび商用ライセンスポリシーを適用するために使用します。

​
GitHubとの仕組み

前提条件 適切なリポジトリ権限で Corgea GitHub アプリ をインストールし設定している必要があります。
1

プルリクエスト提出

開発者がコード変更を含むプルリクエストを送信します
2

自動解析

システムはコード変更を有効なブロッキングルールと照らして分析します
3

ルール検証

違反が見つかった場合、プルリクエストは自動的にブロックされます
4

開発者通知

開発者がルール違反に関する詳細な通知を受け取ります
5

解決

開発者は違反を修正してFixedとしてマークするか、False PositiveまたはAccepted Riskとしてマークしなければマージできません

​
Azure DevOpsでの仕組み

前提条件：CorgeaとのAzure DevOps連携が設定され、必要な権限が付与されていることを確認します。
1

プルリクエスト提出

開発者がAzure DevOpsでコード変更を含むプルリクエストを送信します。
2

自動解析

システムはコード変更をCorgeaで設定された有効なブロッキングルールと比較して評価します。
3

ルール検証

違反が見つかると、プルリクエストは自動的にブロックされます。
開発者はPRが解決されるまでマージできません。
4

開発者通知

開発者はCorgea Scanページで失敗した問題の詳細情報を見るリンクを受け取ります。
5

解決

開発者は違反を修正するか、False PositiveまたはAccepted Riskとしてマークしなければマージできません。

​
使用ガイド

​
新しいブロッキングルールの作成

1

作成を開始する

「Add Blocking Rule」ボタンをクリックします
2

ルールタイプを選択

ブロッキングルールの種類を選択します。
  • Code Vulnerability: コードのセキュリティ問題に基づくプルリクエストをブロック（SASTの検出結果）
  • Dependency Vulnerability: 脆弱な依存関係に基づくプルリクエストをブロック（SCAの検出結果）
  • License Compliance: 拒否対象のSPDXライセンスまたはライセンスファミリに基づいて依存関係をブロック
Add Blocking Rule modal with Applies To, rule types, and Issue Type
3

基本情報

ルール名と説明を入力し、Applies Toを選択します。
  • Pull Requestsは、プルリクエストのチェックでルールを自動的に適用します。
  • CIは、パイプラインがcorgea scan --block-on <slug>でルールを指定した場合にのみ適用します。CIルールはプルリクエストをブロックしません。
新しいルールのデフォルトはPull Requestsです。Corgeaはルール名からslugを生成し、ルール一覧に表示します。Pull Requestルールでは、対応が必要な検出結果のみにコメントします。Corgeaは、到達不可能と確認された検出結果、False Positiveまたは未対応言語の結果として保留された検出結果、およびプロジェクトで無視するパス内の検出結果にはコメントしません。これらの検出結果は引き続きCorgeaで確認できますが、Pull Requestをブロックしません。
Add Blocking Rule modal with CI selected and License Compliance configured
4

設定を構成する

Code Vulnerabilityルールでは、Issue Typeとして、All、Vulnerabilitiesのみ、またはCode Qualityの検出結果のみを選択します。デフォルトのAllでは、既存ルールの動作が維持されます。次に、緊急度（Critical、High、Medium、Low）または対象のCWEを選択します。ルールを有効にするには、少なくともどちらか一方を指定する必要があります。Dependency Vulnerabilityルールでは、重大度またはCVSSスコアのどちらで絞り込むかを選択します。緊急度（Critical、High、Medium、Low）を選択するか、0.0から10.0までのCVSSスコアの最小値と最大値を入力し、その範囲内の脆弱な依存関係をブロックします。必要に応じて、到達可能性の状態を1つ以上選択してルールをさらに絞り込めます。到達可能性による絞り込みを参照してください。License Complianceルールでは、拒否対象のライセンスファミリ（Copyleft、Permissive、またはCommercial）を少なくとも1つ選択するか、1つ以上のSPDXライセンスIDを入力します。報告されたライセンスのいずれかが選択したファミリまたは特定のIDに一致する場合、その依存関係はブロックされます。
5

スコープを設定

対象のプロジェクトやプロジェクトタグを必要に応じて選択します。プロジェクトが直接選択されている場合、または選択したタグのいずれかがプロジェクトに付いている場合にルールが適用されます。プロジェクトもタグも選択していない場合、ルールはすべてのプロジェクトに適用されます。
6

保存

内容を確認し、Createをクリックします。

​
既存のルールの管理

名前や設定でルールを検索したり、プロジェクトタグまたはApplies Toの対象で一覧を絞り込んだりできます。ルール表のID列には各ルールのslugが表示され、プロジェクトスコープ、ルールタイプ、およびPull RequestsまたはCIの対象はTriggers Onにチップで表示されます。slugを選択すると、CIコマンドで使うためにコピーできます。プロジェクトやタグのスコープがないルールはすべてのプロジェクトに適用され、長いスコープ一覧は**+N more**のツールチップにまとめられます。
Blocking rules list showing slug, Triggers On chips, and CI badge

​
CIでのルール適用

Applies ToをCIに設定した有効なルールを作成し、そのslugをscanコマンドに渡します。ルール名は、例えばno-criticalsではなくcriticalsのように、トリガーされる条件に合わせて付けてください。こうすると--block-onが直接的な表明として読めます。--block-onにはCorgea CLI 1.10.0以降が必要です。
複数のCIルールを適用するには、slugをカンマ区切りのリストで指定します。いずれかの指定ルールに違反する検出結果があると、コマンドは失敗します。未知のslug、無効なルール、またはプルリクエスト向けのルールはスキップされず、設定エラーとして扱われます。--block-onはBLASTスキャナーのみでサポートされ、--failまたは--fail-onと併用できません。
  1. 表でルールを見つける
  2. Editボタンをクリック
  3. 必要に応じて設定を変更する
  4. Updateをクリックして保存

​
スキャンでのルール確認

スキャンに適用されるブロッキングルールは、以下の2か所で確認できます。
  1. スキャン詳細ページには「Blocking Rules」セクションがあり、評価されたすべてのルールが表示されます。
  1. 個別の問題では、問題の詳細でどのブロッキングルールが適用されたかを確認できます。
これにより、どのルールがスキャンや特定の問題に影響しているかを把握でき、特定の変更がブロックされる理由を特定しやすくなります。

​
到達可能性による絞り込み

ほとんどのプロジェクトでは、脆弱な依存関係の多くは実際にはコードから使用されていません。到達可能性による絞り込みを使うと、Dependency Vulnerabilityルールが本当に重要な検出結果のみをブロックできます。呼び出していないパッケージのCriticalなCVEがパイプラインを失敗させることはなくなります。
CIルール専用 到達可能性が解析されるのは、corgea scanで自分が開始したスキャンのみです。プルリクエストの作成時に自動的に実行されるスキャンでは解析されません。このフィルタを使うにはApplies ToをCIに設定してください。Pull Requestルールではこの項目は表示されません。ルールはパイプラインからcorgea scan --block-on <slug>で参照します。
前提条件 到達可能性の利用には、組織でAI-Native SCAが有効になっている必要があります。有効でない場合は依存関係が解析されないため、このフィルタを使うルールは何もブロックしません。設定が無効な場合、ルール編集画面に警告が表示されます。
Add Blocking Rule modal with CI and Dependency Vulnerability selected and Reachable checked under Reachability
次の状態から1つ以上を選択します。 到達可能性フィルタは、重大度、CVSS、Maliciousのフィルタを置き換えるのではなく、それらと組み合わせて適用されます。したがって、検出結果は両方の条件に一致する必要があります。重大度Criticalと Reachable を設定したルールは、到達可能でもあるCriticalな脆弱性のみをブロックします。到達可能性を空のままにすると、到達可能性に関係なくブロックする従来の動作が維持されます。

​
解析の待機

到達可能性の解析はスキャン本体の完了後に実行されるため、corgea scanは結果をすぐに返さず、解析が終わるまでポーリングを続けます。すべての直接依存関係の解析が完了した時点で解析は終了します。通常は数分、最長で30分です。 このフィルタはフェイルオープンです。30分の待機時間の超過、解析の失敗、AI-Native SCAの無効化などにより解析を完了できない場合、ビルドを失敗させるのではなく違反なしとして報告します。パイプラインがブロックされるのは、Corgeaが実際に判定した到達可能性に基づく場合のみで、解析結果が欠けていることを理由にブロックされることはありません。
corgea scanは自身の制限時間を超えた場合はフェイルクローズで終了します。Corgea CLI 1.13.0以降では35分が確保されており、30分の解析ウィンドウを十分に上回ります。それより古いCLIでは制限時間が15分のため、Corgeaの解析中に超過してパイプラインが失敗する可能性があります。CLIを更新するか、CORGEA_BLOCKING_RULES_TIMEOUT_SECONDSで制限時間を延長してください。

​
例

ルールタイプ: Code VulnerabilityCWE-326（Inadequate Encryption Strength）とCWE-327（Use of a Broken or Risky Cryptographic Algorithm）を対象に、緊急度をCriticalとするルールを作成し、弱い暗号化方式の使用を防ぎます。
ルールタイプ: Code Vulnerability問題タイプとしてCode Qualityを選択し、CWE-398（Indicator of Poor Code Quality）とCWE-477（Use of Obsolete Functions）を対象に、緊急度をMediumとするルールを設定します。
ルールタイプ: Dependency Vulnerability緊急度としてCriticalとHighを選択し、重大度がCriticalまたはHighの脆弱性を含む依存関係を導入するプルリクエストを自動的にブロックします。これにより、既知の脆弱なパッケージがコードベースに入ることを防ぎ、サプライチェーンを保護します。
ルールタイプ: Dependency VulnerabilityCVSSスコア（7.0から10.0など）でフィルタリングするルールを作成し、そのスコア範囲内で脆弱な依存関係をもたらすプルリクエストをブロックします。
ルールタイプ: Dependency Vulnerability — 適用対象: CI緊急度として「Critical」と「High」を選択し、さらに到達可能性でReachableを選択します。このルールは、CriticalまたはHighの脆弱性がアプリケーションコードから到達可能な場合にのみパイプラインを失敗させるため、未使用や到達不能なパッケージが開発者の作業を妨げません。ブロック対象を広げるのではなく既存の重大度ルールを絞り込むため、最初の到達可能性ルールとして適しています。
ルールタイプ: Dependency Vulnerability — 適用対象: CI重大度やCVSSのフィルタを設定せず、到達可能性でUnused Dependencyのみを選択します。このルールは、コードベースのどこからも使用されていない脆弱なパッケージを導入した場合にパイプラインを失敗させ、開発者にアップグレードではなく依存関係の削除を促します。
ルールタイプ: License ComplianceCopyleftファミリを選択し、報告されたライセンスがそのファミリに属する依存関係をブロックします。ポリシーでより狭い拒否リストが必要な場合は、特定のSPDX IDを追加します。

​
ベストプラクティス

実装のヒント

  • 基本的なルールから始めて徐々に拡大する
  • Dependency Vulnerabilityルールでは、まずCriticalのみ、または限定したCVSS範囲から開始し、チームの運用が安定するにつれて対象を広げる
  • CIルールでは、既存の重大度ルールにReachableの到達可能性フィルタを追加し、実際に悪用可能な脆弱性のカバレッジを損なわずにノイズを削減する
  • Code Vulnerabilityルールでは、まず影響の大きいCWE（例: インジェクションの欠陥、認証の問題）に注目する
  • 定期的なレビューと更新
  • 明確なドキュメント作成とチームへの周知
  • フィードバックと協力の促進
  • 緊急度レベルの戦略的な活用
  • 同じルールを関連プロジェクト群に適用する場合はプロジェクトタグを検討する

​
トラブルシューティング

プルリクエストが予期せずブロックされた場合は、まず有効なルールとその設定を確認してください。
  • 予期しないブロック動作
  • ルールの対象設定の問題
  • プロジェクトスコープの問題
  • ルール設定を確認する
  • CWEの対象設定を確認する
  • プロジェクト設定を確認する
  • 必要に応じてサポートに連絡する