Black DuckのOSS脆弱性チェックをGitHub Code Scanningに統合する
はじめに
OSSの脆弱性チェックツールとして、DependabotやBlack Duckなどを利用している開発チームは多くあります。しかし、複数のツールを使用することで、以下のような課題に直面することがあります。
- 脆弱性チェック結果が複数の場所に散在し、管理が煩雑になる
- チームメンバー全員が脆弱性情報にアクセスできない
- ツール間で検出結果に差分が生じる
本記事では、Black DuckのOSS脆弱性チェック結果をGitHubのCode Scanning機能に統合することで、これらの課題を解決する方法を紹介します。
抱えていた課題
複数ツールによる脆弱性チェックの運用課題
私たちのチームでは、以下のような体制でOSSの脆弱性チェックを行っていました。
- Dependabot: 主な脆弱性チェックツールとして使用
- Black Duck: 導入済みだが、主にライセンスチェック機能のみを使用
この運用において、以下の課題が顕在化しました。
1. 検出結果の差分による対応漏れ
DependabotとBlack Duckの脆弱性チェック結果に差分が生じており、一部の脆弱性への対応が漏れていることが判明しました。これは、各ツールが使用する脆弱性データベースや検出アルゴリズムの違いによるものです。
2. 情報アクセスの制限
Black Duckの管理画面へのアクセス権限が限定的で、一部のチームメンバーが脆弱性情報を直接確認できませんでした。これにより、開発チーム全体での迅速な対応が困難になっていました。
解決策: GitHub Code Scanningへの統合
基本方針
以下の方針で運用を改善することにしました。
- Black Duckの結果を正とする: 全社標準ツールであるBlack Duckの検出結果を基準に運用を統一
- GitHubへの情報集約: 脆弱性情報を日々の開発業務の中心であるGitHubへ集約し、チーム全員がアクセスできる環境を構築
実装方針
Black Duckは、GitHub Actionsで実行できるBlack Duck Security Scanを提供しています。
このアクションには、検出結果をSARIF形式（Static Analysis Results Interchange Format）に変換する機能が含まれています。
変換した結果をGitHubのCode Scanning機能にアップロードできます。
これを活用することで、Black Duckのスキャン結果をGitHubのセキュリティタブに直接表示できます。
GitHub Actionsワークフローの実装
以下は、Black DuckスキャンをGitHub Actionsで実行し、結果をCode Scanningに統合するワークフローの例です。
name: BlackDuck Security Scan
on:
# push時に自動実行
push:
branches: [main, develop]
# 手動実行も可能
workflow_dispatch:
jobs:
blackduck-scan:
runs-on: ubuntu-latest
# Code Scanningへのアップロードに必要な権限設定
permissions:
contents: read
security-events: write # SARIF形式のレポートをアップロードするために必須
steps:
# ソースコードのチェックアウト
- name: Checkout Repository
uses: actions/checkout@v4
# BlackDuckスキャンの実行
- name: Run BlackDuck Security Scan
uses: blackduck-inc/black-duck-security-scan@v2.6.0
# BlackDuck検出ツールの環境変数設定
env:
# スキャン対象のプロジェクト名（GitHub Secretsまたは変数で管理）
DETECT_PROJECT_NAME: ${{ vars.BLACKDUCK_PROJECT_NAME }}
# スキャン対象のバージョン名（ブランチ名を使用）
DETECT_PROJECT_VERSION_NAME: ${{ github.ref_name }}
# 検出精度の要求レベル
DETECT_ACCURACY_REQUIRED: NONE
with:
### BlackDuck基本設定（必須項目）
blackducksca_url: ${{ secrets.BLACKDUCK_URL }} # BlackDuckサーバーのURL
blackducksca_token: ${{ secrets.BLACKDUCK_TOKEN }} # BlackDuck APIトークン
blackducksca_scan_full: true # フルスキャンを実行
### SARIF形式レポートの生成設定（GitHub連携の要）
blackducksca_reports_sarif_create: true # SARIFレポートを作成
blackducksca_reports_sarif_file_path: "./blackduck-results.sarif" # レポートの保存先
blackducksca_reports_sarif_severities: "CRITICAL,HIGH" # レポートに含める脆弱性レベル
blackducksca_upload_sarif_report: true # Code Scanningへ自動アップロード
# SARIF アップロード時に必要（GitHub Tokenは自動で利用可能）
github_token: ${{ secrets.GITHUB_TOKEN }}
設定のポイント
1. 権限設定
permissions:
contents: read
security-events: write # SARIF形式のレポートをアップロードするために必須
security-events: write 権限がないと、Code ScanningへのアップロードがPermission Deniedエラーで失敗します。
2. 脆弱性レベルのフィルタリング
blackducksca_reports_sarif_severities: "CRITICAL,HIGH"
blackducksca_fixpr_filter_severities: "CRITICAL,HIGH"
GitHub上での確認方法
Code Scanningタブでの表示
ワークフローを実行すると、GitHubリポジトリの Security > Code scanning タブに検出された脆弱性が表示されます。
フィルタリング機能
デフォルトブランチ以外の結果を確認したい場合は、ブランチフィルタを使用できます。
脆弱性の詳細確認
各脆弱性をクリックすると、以下の情報を確認できます。
- 脆弱性の詳細説明
- 影響を受けるパッケージとバージョン
- 推奨される修正方法
- CVSS スコア
脆弱性の解消
コードを変更し、再スキャンを実行して脆弱性が解消されると、該当のアラートは自動的に Closed タブに移動します。
Artifacts
スキャン実行後、Actions の実行結果に Artifacts として SARIF ファイルがアップロードされます。これをダウンロードして、詳細な解析結果を確認できます。
実装時のハマりポイント
1. ローカル環境での検証の難しさ
act を使用してローカル環境でGitHub Actionsを実行しようとしましたが、Black Duckサーバーとの通信がうまくいかず、ローカル環境での検証はできませんでした。
本番環境でのテストが必要になるため、テスト用のリポジトリで事前検証することを推奨します。
2. pull_requestトリガーの制限
pull_request トリガーでワークフローを実行した場合、Blackduck SCA SARIF Issues Fetcher という機能が正しく動作しません。
そのため、セキュリティタブにアラートが登録されませんでした。
そのため、push トリガーまたは workflow_dispatch トリガーを使用することを推奨します。
まとめ
Black DuckのOSS脆弱性チェック結果をGitHub Code Scanningに統合することで、以下のメリットが得られました。
- 情報の一元化: 開発者全員がGitHub上で脆弱性情報を確認可能
- 迅速な対応: 日常的に使用するGitHubに統合されることで、脆弱性への対応が迅速化
- 運用の標準化: Black Duckを正とする運用に統一し、ツール間の差分問題を解消
GitHub ActionsとBlack Duckを組み合わせることで、セキュアな開発環境を効率的に構築できます。ぜひ参考にしてみてください。
Discussion