継続的統合パイプライン

継続的インテグレーション・パイプラインは、アプリケーションのリポジトリからデプロイ可能なアーティファクトをビルドします。

パイプラインは、アーティファクトをビルドする前に、プルリクエストの処理と同様に、コードがスキャンおよびテスト済みであることを確認します。 ビルドされた成果物もまた、パイプラインで脆弱性がないかスキャンされ、署名された後に、インベントリーの中で、リリースおよびデプロイできる状態であることを示すマークが付けられます。 プル要求パイプラインとは異なり、継続的統合パイプラインは、ビルドの各ステージ (テスト、スキャン、署名など) でエビデンスと結果の成果物を収集します。 このデータは、ビルドされた成果物に対応しているので、デプロイメント・プロセスと変更管理で追跡できます。

ステージとタスク

次の表は、CIパイプラインで実行されるタスクの一覧である。 さらに、この表には、以下の各ステージの概要も示されています。

  • タスクまたはステージ: これは、 .pipeline-config.yaml 構成ファイル内で定義されているステージの名前を参照します。

  • 簡略説明: ステージの実行中に実行されたアクションについて簡潔に説明します。

  • 許容されるカスタマイズ: これは、 .pipeline-config.yaml ファイルにカスタム・スクリプトを挿入することによって、ステージのデフォルトの動作を変更または置換する柔軟性がユーザーにあるかどうかを示します。

  • デフォルトのリファレンス実装: これは、DevSecOpsパイプラインには、ステージの定義済みまたはデフォルトの実装が付属しています。 特に、特定のステージでは unit-tests または setup、DevSecOpsパイプラインは、すぐに使用できる実装を提供しません。 代わりに、ユーザーは、アプリケーションの要件に合わせて調整されたカスタム・スクリプトまたはコードを提供する必要があります。

  • エビデンス・コレクション: ステージが標準エビデンスの収集を実行するかどうかを示します。 いつDevSecOpsパイプラインステージのリファレンス実装を提供すると、証拠収集がすぐに実行されます。 ただし、 「ユーザー」 がこれらの事前定義ステージを変更または置換することを選択した場合は、カスタム実装に適切なエビデンス・コレクションが含まれていることを確認する必要があります。 ユーザーは、DevSecOpsパイプラインはすぐに使用できる実装を提供しないため、証拠収集を実行する必要があります。 この列は、エビデンス収集の実行を担当するエンティティー (ユーザー/パイプライン) を示します。

  • スキップ可能 (バージョン> = v10に適用可能): これは、 .pipeline-config.yaml でスキップ・プロパティーを true に設定することによって、ユーザーがこのステージの実行をオプトアウトできるかどうかを示します。 ただし、この機能を使用する場合、特に証拠を収集するために設計されたステージでは注意が必要です。 このようなステージをスキップすると、ビルドに不可欠な証拠が欠落する可能性があります。

継続的インテグレーションのステージとタスク
タスクまたはステージ 簡略説明 .pipeline-config.yaml で許容されるカスタマイズ デフォルトの参照実装 エビデンスの収集 スキップが許可されます
start パイプライン環境をセットアップします。 いいえ ある パイプライン いいえ
setup ビルドとテストの環境をセットアップします。 ある いいえ NA いいえ
detect-secrets アプリケーション・コードに対して秘密スキャンの検出を実行します。 ある ある パイプライン いいえ
test アプリケーション・コードに対して単体テストとアプリケーション・テストを実行します。 ある いいえ ユーザー ある
static-scan アプリケーション・コードに対して静的スキャン・コードを実行します。 ある ある パイプライン ある
compliance-checks アプリ・リポジトリーに対して Code Risk Analyzer スキャンとその他のコンプライアンス検査を実行します。 ある ある パイプライン ある
peer-review マージされたプルリクエストに対するピアレビューに関するコンプライアンスデータを収集する。 ある ある パイプライン ある
containerize 成果物をビルドします。 ある いいえ NA いいえ
sign-artifact ビルド成果物に署名します。 ある ある パイプライン いいえ
deploy ビルド成果物を開発環境にデプロイします。 ある いいえ NA いいえ
dynamic-scan アプリケーションで動的スキャンを実行します。 ある ある パイプライン ある
acceptance-test 開発環境で、デプロイされたビルド成果物に対して受け入れテストと統合テストを実行します。 ある いいえ ユーザー ある
scan-artifact ビルド成果物をスキャンします。 ある ある パイプライン ある
release ビルド成果物をインベントリーに追加します。 ある いいえ NA ある
finish ログ・ファイル、成果物、エビデンスを収集、作成し、エビデンス・ロッカーにアップロードします。 ある ある NA ある

.pipeline-config.yaml ファイルを使用してステージをカスタマイズする方法の詳細については、「 カスタムスクリプト 」および「 パイプラインパラメータ の一覧」を参照してください。

ステージとエビデンス

以下の表は、様々な種類の証拠と、その収集が行われるパイプライン内の特定の段階との関係を示している。

継続的インテグレーションのステージと関連証拠
タスクまたはステージ エビデンス・タイプ
start NA
setup NA
detect-secrets com.ibm.detect_secrets
test com.ibm.unit_tests
static-scan com.ibm.static_scan
compliance-checks com.ibm.code_bom_check, com.ibm.code_cis_check, com.ibm.code_vulnerability_scan, com.ibm.branch_protection
peer-review com.ibm.peer_review
containerize NA
sign-artifact com.ibm.cloud.image_signing
deploy NA
dynamic-scan com.ibm.dynamic_scan
acceptance-test com.ibm.acceptance_tests
scan-artifact com.ibm.cloud.image_vulnerability_scan
release NA
finish com.ibm.pipeline_logs, com.ibm.pipeline_run_data

collect-evidence スクリプトを使用してカスタマイズ可能なユーザー・ステージ内で証拠を収集する方法について詳しくは、 収集-エビデンス・スクリプト を参照してください。

シークレット・スキャンの検出

IBM Detect Secrets ツールは、アプリ・コード内でシークレットが可視状態になっている場所を特定します。 スキャン用のリポジトリーのセットアップについて詳しくは、 ここ を参照してください。

静的コード・スキャン

静的コード・スキャン・ステージは、指定されたアプリケーション・リポジトリーで多数の静的コード・アナライザー・ツールを実行します。 pipelinectl save_repo コマンドによって指定されるリポジトリーとデフォルトのアプリ・リポジトリーがスキャンされます。

パイプラインに静的コードを追加するために、以下のいずれかの方法を使用できます。

  • SonarQube ツールをツールチェーンに追加することによって、既に実行中の SonarQube インスタンス名、URL、および資格情報を指定します。 静的スキャン・タスクは指定したリポジトリーに対してスキャンを実行します。

  • 独自の SonarQube インスタンスがない場合、パイプラインの実行中にパイプラインが SonarQube インスタンスを作成します。 そのインスタンスには、static-scan ステージの実行が完了した後にアクセスできます。

  • opt-in-gosec パラメーターを使用して、Golang セキュリティー・チェックの gosec スキャンを実行します。

  • カスタム実装のために、お客様の静的スキャン・コードを .pipeline-config.yaml ファイルの静的スキャン・カスタム・ステージに追加します。

パイプラインへの SonarQube スキャンの追加

SonarQube と継続的統合パイプラインの統合について詳しくは、 SonarQubeの構成 を参照してください。

パイプラインへの gosec スキャン統合の追加

gosec を使用して、スキャンされたリポジトリー内の golang ソース・コードを検査します。

gosec スキャンを有効にするには、以下のパラメーターを指定し、値を 1 に設定します。

gosec スキャンパラメータ
名前 タイプ 説明 必須またはオプション
opt-in-gosec text gosec スキャンを有効にするオプション オプション

継続的統合パイプラインでの gosec スキャンのセットアップについて詳しくは、 GoSec を参照してください。

他の静的スキャナーの使用

独自の静的スキャン実装を使用したい場合は、 .pipeline-config.yaml ファイルを修正し、 static-scan ステージに独自 のカスタムスクリプト を追加することができます。

コンプライアンス検査でのスキャンと検査

コンプライアンス・スキャンとチェック
スキャンまたは検査 説明
Code Risk Analyzer による脆弱点スキャン アプリのパッケージ依存関係、コンテナーの基本イメージ、オペレーティング・システム・パッケージのすべてについて脆弱性を検出します。 Code Risk Analyzer ツールを使用します。
Code Risk Analyzer による CIS 検査 Kubernetes デプロイメント・マニフェストに対して 構成チェック を実行します。 Code Risk Analyzer ツールを使用します。
Code Risk Analyzer による部品構成表 (BOM) 検査 すべての依存関係のペディグリーを取り込む、指定されたリポジトリーの BOM です。 この BOM はさまざまな細分度で収集されます。 例えば、BOM は、ビルドで使用される基本イメージのリスト、基本イメージにあるパッケージのリスト、基本イメージの上にインストールされるアプリ・パッケージのリストを収集します。 BOM は分析結果のグラウンド・トゥルースとして機能します。ポリシー・ゲートを適用するために使用できることもあります。 Code Risk Analyzer ツールを使用します。
リポジトリーのコンプライアンス検査 ブランチの保護設定が正しいことを検査します。 例えば、マスター/メイン・ブランチは、常に強制プッシュを制限する必要があります。 詳しくは、 Git Repos and Issue Tracking リポジトリーの構成 を参照してください。

これらのスクリプトは、パイプラインが認識するすべてのアプリ・リポジトリーに対して実行されます。 これらのスキャンにリポジトリーを追加するには、セットアップ・ステージで利用できる pipelinectl インターフェースを使用してください。

ユーザー・スクリプトの各ステージからの予想される出力について詳しくは、カスタム・スクリプトを参照してください。

注: CIパイプラインは、 branch protection checks や peer review check のような機能をサポートしていないため、タグをトリガーにはしません。 タグでCIパイプラインを実行する場合は、 peer-review-compliance と branch-protection-check プロパティを無効にし、 0 に設定してください。 ただし、この場合、証拠収集は行われないので注意すること。

ビルド

ビルド・ステージで、ユーザーは独自の成果物をビルドできます。 パイプラインでは Docker イメージ・タイプの成果物についていくつかのデフォルト機能を提供していますが、このステージでは任意のタイプの成果物をビルドできます。

パイプライン UI の環境変数を使用して、ビルド用の資格情報、シークレット、およびパラメーターを指定します。 これらの環境変数には、このステージおよびすべてのカスタム・ステージでアクセスすることができます。 カスタム・スクリプト・ステージでパラメーターとシークレットにアクセスする方法について詳しくは、カスタム・スクリプトを参照してください。

成果物のスキャンと署名

成果物のスキャン・ステージと署名ステージでは、Docker イメージのデフォルトの動作が用意されていますが、これらのステップはカスタマイズ可能です。

  • GPG 鍵を使用したイメージ署名。
  • Container Registry の脆弱性アドバイザーによるスキャン。

これらのステージを開始するには、pipelinectl インターフェースを使用するように、パイプライン用の成果物を用意します。 ビルド・スクリプトと .pipeline-config.yaml 構成を更新する必要はありません。

別のスキャン・プロセスや署名プロセスを使用する場合、または、icr.io で Docker イメージ以外の成果物を処理する場合は、プロジェクトで .pipeline-config.yaml 構成を使用して、これらのステージをカスタマイズすることができます。

開発へのデプロイ

デプロイ・ステージはビルド成果物を開発環境にデプロイします。

動的スキャン

動的コード・スキャンは、ソフトウェア・チームが実行中のアプリケーションをスキャンして脆弱性を特定できるようにするブラック・ボックス脆弱性スキャンの 1 つの形式です。

動的スキャン・ステージは、dev 環境へのデプロイメントが正常に完了した後、 Deploy to dev ステージの直後に実行されます。

デフォルトでは、パイプラインは Zed Attack Proxy (ZAP) Scan を実行するためのサポートを提供します。ZAP Scan は、OWASP の下で保守される無料のオープン・ソース侵入テスト・ツールです。 API と UI の両方の動的スキャンを実行します。どちらも、サンプルの hello-compliance-app で実行できます。

動的スキャンを実行するには、パイプライン・パラメーター opt-in-dynamic-scan を空でない値に設定します。 ステージが動的スキャンを実行できないようにするには、パイプライン・パラメーター opt-in-dynamic-scan を空に設定します。 パイプライン・パラメーターの設定について詳しくは、 パイプライン・パラメーター を参照してください。

CI パイプラインは、重大度に基づいて問題リポジトリーに問題を作成します。 問題に付加されているラベルは、脆弱性の重大度を示します。

ZAP API スキャン

ZAP API は、データの漏えい、コンテンツ・タイプ・エラー、外部リダイレクト、コード・インジェクション、SQL インジェクション、リモート OS コマンド・インジェクション、およびアプリケーションによって公開されるその他の脆弱性がないかアプリケーション・エンドポイントをスキャンします。 ZAP API スキャンは、ステージまたはテスト環境でこれらの脆弱性を検出し、アプリケーションが実稼働環境にデプロイされる前にそれらを修正することにより、開発者がアプリケーションを保護するのに役立ちます。

ZAP API スキャンでは、アプリケーションをスキャンするために以下の入力が必要です。

  • Swagger 定義ファイル - アプリで公開されている HTTP API と関連パラメータの説明。
  • API キー-API エンドポイントで認証を行うために必要な認証トークン。
  • API エンドポイント-ZAP にスキャンさせたい Swagger 定義からのエンドポイント。
  • 除外 URL-ZAP スキャナーによって無視される URL。

ZAP API スキャナーは、示されている入力を使用してスキャンを実行し、レポートを生成します。

ZAP API スキャンを実行するには、 opt-in-dynamic-api-scan を空でない値に設定します。 オプトアウトするには、このパラメーターを空に設定します。

ZAP UI スキャン

ZAP UIは、アプリケーションのエンドポイントをスキャンし、Webページ自体に存在する脆弱性（設定されている不安全なCookie、不適切なキャッシュヘッダー設定、クロスドメインファイルインクルージョン、不適切な CORS 設定、およびアプリケーションによって露呈されるその他の脆弱性など）を検出します。

UI スキャンは API スキャンと同様に機能しますが、Swagger ファイルの代わりに UI テスト・スクリプトを使用します。 UI テスト・スクリプトは、ZAP スキャナーのプロキシーを介してプロキシーするように構成されたヘッドレス・ブラウザーを開始し、UI エンドポイントに対して UI テストを実行します。 ZAP UI テストを実行するプロセスは、以下のとおりです。

  • テスト・スクリプトを ZAP スキャナー・コンテナーにコピーします。
  • ZAP プロキシーを実行します。
  • ザップ・テスト・スクリプトを実行します。

ZAP プロキシーはトラフィックを記録し、スキャンするエンドポイントを検出します。 スキャンが終了すると、プロキシーはレポートを生成し、ZAP API スキャンと同じ方法で問題を生成します。

ZAP API スキャンを実行するには、 opt-in-dynamic-ui-scan を空でない値に設定します。 オプトアウトするには、このパラメーターを空に設定します。

  • 独自の実装を行うには、 .pipeline-config.yaml ファイル内の「dynamic-scan」カスタムステージに、独自の動的スキャンコードを追加してください。

ZAP API スキャンおよび ZAP UI スキャンについて詳しくは、 ZAP スキャンの構成 を参照してください。

インベントリーへのリリース

「インベントリーへのリリース」ユーザー・スクリプト・ステージを使用して、cocoa inventory add CLI コマンドを使用して成果物をインベントリーに追加します。 このコマンドについて詳しくは、 cocoa inventory add のトピックを参照してください。

パイプラインに問題がある場合に在庫更新をスキップするには、以下の環境変数を使用してパイプラインの状況を確認します。 インベントリーを更新する前に、それらの状況を確認します。

  • skip-inventory-update-on-failure 在庫更新を実行するかどうかを指定するための、パイプラインからのオプトイン環境変数。
  • パイプライン実行にステージ障害がある場合、 one-pipeline-status は 1 に設定されます。

pipelinectl インターフェースを使用すると、 list_repos、 load_repo、 list_artifacts、および load_artifact コマンドを利用して、リポジトリやアーティファクトにアクセスできます。 コマンドについて詳しくは、 pipelinectl の資料を参照してください。

ビルドに関するコンプライアンス・データの収集

パイプラインが正常に実行されると、ビルドに関する情報を収集できます。

すべての検査、スキャン、テスト、および成果物署名のエビデンスはエビデンス・ロッカーに収集されます。 パイプラインのログ・ファイルも、Tekton 定義が含まれるパイプライン・データそのものと一緒にロッカーに保存されます。 ピア・レビューに対するコンプライアンス・データもこのステップで収集されます。 パイプラインは、pipelinectl を使用して、最終ビルド以降にマージされたプル要求が入っているリポジトリーを検索します。 また、それらのレビュー状況を検査し、成果物として保存して、結果に基づくエビデンスを作成します。

最後のスクリプトはエバリュエーターです。エビデンスの状況に基づいてパイプライン状況を緑または赤にマーク付けします。 失敗がなければ、継続的統合の実行は赤とマーク付けされます。