Policy as Codeは、セキュリティのルール、基準、条件をコードで定義・管理する方法であり、継続的インテグレーション/継続的デリバリー/継続的デプロイ(CI/CD)パイプライン内でプログラムによってセキュリティおよびリスク・ポリシーを適用します。アプリケーション・セキュリティ・テストにおいては、テスト・ワークフローを自動化し、ポリシーの評価、応答、通知のルールをコードで定義できます。
ポリシーは高水準言語で記述され、コードはクエリを使用するポリシー・エンジンに入力されます。ポリシー・エンジンはこれらのポリシーを入力として処理し、クエリ結果を提供します。この結果により、設定されたポリシーに沿って、適切なアプリケーション・セキュリティ・テスト(AST)の種類、およびテストを実施する時期と対象箇所が決定されます。
Policy as Codeは、特定のアプリケーションをテストするための前提条件を指定する読み取り可能なスクリプト・ファイルです。これらのファイルは組織が使用するツールと互換性のある、サポートされているプログラミング言語(YAMLやPythonなど)で記述されています。ポリシーはCIパイプラインへのAPI呼び出しによって適用されるため、現在のビルドを壊すことなくセキュリティ・テストを実行できます。
Policy as Codeに記述する際の重要な考慮事項
アプリケーション・セキュリティ・テストでは、Policy as Codeを活用して、テストするタイミング、使用するテスト・ツール、テストの必要性の有無などの条件を定義できます。これらのパラメータをコード化することで、複数のASTツールの連携を簡素化し、高精度のテスト・ワークフローを実現できます。これにより、セキュリティ・ポリシーを一貫性のある自動化された方法で適用することが可能になり、開発スピードを落とすことなくソフトウェア品質を向上させることができます。
Policy as Codeを適用することには、以下の重要な利点があります。
最近の組織は多様なASTツールを使用しており、セキュリティ・スキャンの結果が得られるまでに数日かかる場合もあります。そのため、ますます加速する開発のスピードについていくことができるアプリケーション・セキュリティ・テスト・ツールとプラクティスが必要になります。
さらに、ソフトウェアがポリシーに準拠し、セキュアであることが確認できれば、ソフトウェア開発ライフサイクル(SDLC)の早期の開発段階でソフトウェアのリスクを把握することができます。しかし、統合的なテスト戦略が策定されていなければ、結局、手動でのスキャンとコード・レビューを必要とし、セキュリティの全体的な衛生状態は一貫性のないものになります。
さらに、既存のパイプラインで使われている様々なツールを統合する作業は複雑で時間がかかる可能性があり、既存のビルドおよびリリース・パイプラインを破壊するリスクを高める要因にもなります。ASTツールと既存のソフトウェア・デリバリー追跡システムの統合や、リスクに基づくセキュリティ・アクティビティの優先順位付けを簡素化できなければ、セキュリティおよび開発のリソースはすぐに余力がなくなる可能性があります。
ツール環境に伴うこれらの課題によって、多くの場合、セキュリティのハードルが高まり、無関係なテストが行われて、開発生産性とのタイムラグが大きくなります。セキュリティ・アナリストはサイロ化されたツールや手作業でのレビューにより開発スピードに追いつくことが困難になり、プロセス、意思決定、重要な調査結果を大局的な視点で可視化する手段の欠如とテスト不足により、悪用される可能性がある高コストなソフトウェアの欠陥が検出されないまま残る可能性があります。
Policy as Codeは、これらのDevSecOpsの障害を克服するために有効な以下の機能を備えています。
包括的なASPMソリューションを提供するBlack DuckのSoftware Risk Managerでは、次のことが可能です。