2021/3/23 - 読み終える時間: 6 分

How to deliver secure code more frequently の翻訳版です。

安全なコードをより頻繁に提供する方法

2021年3月22日

著者: HCL Software / A division of HCL Technologies (HCL)

ソフトウェア・デリバリー・パイプラインにおいて、セキュリティは全員の責任です。アプリケーション・セキュリティと継続的デリバリーを組み合わせて、全体的にセキュアな DevOps ソリューションを構築する必要があります。ここでは、その方法を説明します。まず、同じページにたどり着くための定義を説明します。

継続的インテグレーション／継続的デプロイメント (CI/CD) パイプライン

CI/CD とは、コードの変更をより頻繁に、より確実に行うための手法の集合体です。CI/CD パイプラインは、HCL Launch のようなツールを使ってこれらのプラクティスを自動化します。

継続的インテグレーションとは、複数の開発者が同一機能のために開発したコードを頻繁に統合し、エラーを早期に発見するための開発手法です。このプロセスには次のようなステップがあります。

• 開発者は、開発ボックスにコードを記述
• 開発者はコードをバージョンコントロールリポジトリにプッシュする
• 自動化サーバーは、チェックインを確認するためのビルドを実行し、すべてのユニットテストと統合テストを実行
• 自動化サーバーは、ビルドとテストの結果を開発チームと共有
• 障害が発生した場合、チームはその修正に取り組む

継続的デプロイメントとは、以下の条件が満たされた場合、準備ができ次第、すべての良いビルドをユーザーにリリースすることです。

• ビルドとユニットテスト、統合テストが成功した場合、そのビルドは UAT サーバーにデプロイされます
• UAT が成功した場合、ビルドは本番サーバーにデプロイされます

AppSec

AppSec (Application Security) とは、ソフトウェアの開発サイクルの中で、セキュリティの脆弱性を発見し、修正し、防止するプロセスのことです。セキュリティインシデントの85％はアプリケーション層で観測されており、また、脅威の数は毎年着実に増加しているため、ソフトウェア開発ライフサイクルの中で AppSec を持つことは重要である。アプリケーション・セキュリティ対策は、SDLCの初期段階でセキュリティ問題を特定して修正し、全体的な開発コストを削減し、安全なコードを提供するために実施されます。広く使用されているアプリケーション・セキュリティ・テスト方法論は以下の通りです。

• Static Analysis Security Testing (SAST) - ホワイトボックステストで、ソースコードを内部から分析し、セキュリティの脆弱性を検出して報告します。問題点は、開発段階で発見することができるので、開発者にすぐにフィードバックできます。ツールやIDEプラグインが存在し、非実行状態やコードが実行されていない状態のソースやコンパイルされたバージョンのコードのセキュリティの欠陥を特定します。SAST レポートには、ファイル名、問題を修正するための行番号、偽陽性の特定など、必要な詳細情報がすべて含まれています。一般的で人気のある SAST ツールには、HCL AppScan Source、HCL AppScan on Cloud、Veracode、Checkmarx、SonarQubeなどがあります。SAST ツールは、開発者が問題を修正するために必要な情報を含むレポートを生成します。

• Software Composition Analysis (SCA) - アプリケーションにバンドルされている安全でないオープンソース・ライブラリーを特定し、これらのライブラリーが基本的なセキュリティ基準を満たし、組織にリスクをもたらさないことを確認するメカニズムです。SCAツールは、ソフトウェアライセンスや非推奨の依存関係も検出できます。一般的な SAC ソリューションとしては、HCL AppScan On Cloud、BlackDuck、Veracode、CheckMarx、WhiteSourceなどがあります。

• Dynamic Application Security Testing (DAST) - アプリケーションを外部からテストするブラックボックス・テストです。アプリケーションの実行中に外部からの攻撃をシミュレートすることで、セキュリティの脆弱性を探します。DAST は、アプリケーションの公開されたインターフェースに脆弱性や欠陥がないかをチェックすることで、外部からアプリケーションに侵入しようとします。いくつかの利点は、SAST では特定できないランタイムの問題を特定できること、技術に依存しないこと、偽陽性が少ないこと、サーバー構成の問題を特定できることです。利用可能な一般的な DAST ツールには、HCL AppScan Enterprise、HCL AppScan on Cloud、Veracode、Netsparker、Checkmarxなどがあります。

• インタラクティブ・アプリケーション・セキュリティ・テスト (IAST) - アプリケーションの実行中にコードを計測することで、アプリケーション内から動作し、セキュリティの脆弱性を検出して報告します。IAST は一般的に、自動/手動の機能テストに使用される際にQA環境に展開されます。 IAST レポートは、行番号を含む詳細な情報を提供し、開発者が問題を容易に修正し、偽陽性を特定するのに役立ちます。利用可能な一般的な IAST ツールには、HCL AppScan Enterprise、HCL AppScan on Cloud、Synopsis、Contrast Assessなどがあります。

AppSec による CI/CD パイプライン

AppSec のパイプラインは、DevOps の原則に従っており、DevSecOpsと呼ばれることもあります。セキュリティプラクティスを CI/CD パイプラインに含めることで、安全なコードをより頻繁に提供できます。

AppSec による継続的インテグレーション (CI)

• 開発者は、開発ボックスにコードを記述
• 開発者は、SAST IDEプラグインを使用してセキュリティテストを実行
• 開発者は、コードをバージョンコントロールリポジトリにプッシュ
• 自動化サーバーがビルドを実行してチェックインを確認し、すべてのユニットテストと統合テストを実行
• 自動化サーバーが、静的解析セキュリティテストのジョブを実行 (自動化)
• オートメーションサーバーがSCAジョブを実行 (自動化)
• 統合テスト、単体テスト、セキュリティテストの結果を、自動化サーバーが開発チームと共有
• 障害が発生した場合、チームはその修正に取り組む

AppSec による継続的デプロイメント (CD)

• ビルドとテストが成功すれば、ビルドは UAT サーバーにデプロイ
• DAST や IAST の実行 (自動化)
• UAT テストが成功した場合、ビルドはプロダクションサーバーにデプロイ

AppSec を CI/CD パイプラインに統合する手順

SAST をパイプラインに組み込む - SAST スキャンを自動化して、チェックインごとに実行することをお勧めします。SAST ツールのインクリメンタル スキャン機能を活用して、スキャン時間を短縮できます。

アプリケーションのオンボーディングは、CI/CD パイプラインにアプリケーションをオンボーディングするために、セキュリティの専門家と開発チームが一度にまとめて行う作業です。手順は以下の通りです。

• スキャン対象のファイル/パッケージをリストアップする。依存関係を省略もできます

• SAST ツールが必要とする設定ファイルを作成する

• スキャンを実行し、その結果をセントラル リポジトリにプッシュする

• 結果を中央リポジトリにプッシュするステップを自動化する

• スキャン結果をトリアージし、リポジトリで偽陽性をマークする

• スキャンのベースラインを設定します。その後のスキャンで新たな問題が発生すると、中央リポジトリでハイライトされます。これにより、解決されていない問題や再び現れた問題の再試行を避け、差分のみに集中できます。

• ビルドゲーティング (指定された基準を満たさない場合にビルドを失敗させる) を適用する前に、すべてのスキャンの結果を中央リポジトリにプッシュするプロセスを導入し、課題リポジトリに課題のマージ機能を持たせることが重要です。

SAST スキャンで留意すべき重要な点は以下の通りです。

• 最も正確で実用的な結果を得るためには、アプリケーションに特化したスキャン・ルール/コンフィグレーションとフィルターを作成することが重要です。これは、関心のある問題のセット (例：OWASPトップ10) に依存し、搭載されたアプリケーションの知識と、SAST の結果からシンク、ソース、テイントを理解する能力が必要です。

• SAST ツールは、コードが実行されるコンテキストを理解していないため、相対的に SAST はより多くの偽陽性を報告します。アプリケーションのコンテキスト、アプリケーションのユーザー、アプリケーションによって処理される情報、使用されている検証メカニズムを認識している人は、セキュリティ問題をトリアージし、偽陽性を識別してマークすることができるはずです。

• スキャンの自動化は、スキャンのベースライン化、問題のトリアージ、偽陽性の特定に続くプロセスの最後になります。スキャンを自動化するには、コマンドラインオプションかプラグインをオートメーションサーバーで使用します。

• スキャンが完了すると、欠陥追跡ツールにチケットを作成するプロセスが自動的に開始されます。fix-group (単一の修復タスクを必要とする問題) のような SAST ツールの機能を使用して、SAST 問題の束に対して単一のチケットを作成することが推奨されます。これにより、トリアージプロセスが簡素化され、迅速な修復が可能になります。

• 定義されたポリシーに応じて、ビルド/パイプラインを停止します。例: ((重要な問題の数 > 0) || (高い問題の数 > 5)) の場合、ビルドを停止する。

パイプラインへのDAST - コードのチェックインごとに、あるいは、1週間のうちの特定の日に、あるいは、アジャイル スプリントの特定のステージに到達したときに、DAST スキャンを実行したいと思うでしょう。DAST ツールのインクリメンタル スキャン機能を活用して、スキャン時間を短縮することをお勧めします。

DAST スキャンについて知っておくべき重要なこと

• アプリケーションのオンボーディングは、アプリケーションの開始 URL を特定し、記録されたログインシーケンスを生成してスキャンに含め、精度と速度のためにスキャン構成を調整する必要がある1回限りのアクティビティです。これはアプリケーションによって異なるため、スキャンの設定を行う担当者は、アプリケーションのコンテキストを把握する必要があります。

• Postman や SOAPUI などの API クライアントツールを使用した機能テストの際に、プロキシサーバー経由でキャプチャーされたトラフィックを含める必要がある Webサービス (例：REST API) をスキャンすることも同様に重要です。

• パイプラインを実行するたびに、アプリケーションの開始 URL を変更しないことが重要です。パイプラインが実行されるたびに、オートメーションサーバーーがアプリケーションを同じボックスにデプロイする必要があります。そうしないと、実行のたびにログインシーケンスが再生成され、スキャンに追加されることになります。

• 不具合追跡ツールでチケットを作成するプロセスを、スキャン完了時に自動的に開始させる。

• ポリシーに応じて、ビルド/パイプラインを停止する。

アプリケーションセキュリティを CI/CD パイプラインに適用することで、組織は以下のような一般的な問題を解決できます。

• 人的介入の削減 - 自動化により、退屈なプロセスから手作業を取り除くことでヒューマンエラーを削減します。

• セキュリティ問題の早期発見 - SDLCの早い段階でセキュリティテストを導入することで、脅威や脆弱性をより早く発見し、対処できます。

• 継続的な脆弱性のトリアージ - 自動化されたスキャンとチケット作成により、セキュリティエンジニアと開発者は、どれが直ちに対処しなければならないか、誰がその問題を解決する責任があるかを決定できます。

• 責任の明確化 - 自動化は、ソフトウェアのデプロイメントにおけるセキュリティの不確実性を取り除きます。セキュリティを移行すると、誰が何に責任を負うのかが混乱しますが、自動化されたスキャンは、開発のその段階で責任を負う当事者のための修復オプションを提示できます。

HCL Software のセキュアな DevOps ソリューションの詳細については、HCL Software DevOps ポートフォリオをご覧ください。