バックナンバーはこちら

today&tomorrow

Technology Update

  • T&T HOME
  • Technology Update
  • アプリケーション・セキュリティ・マネージャーのためのアジャイル開発

2017 May Spring vol.106

アプリケーション・セキュリティ・マネージャーのためのアジャイル開発

シノプシス ソフトウェア・インテグリティ・グループ スタッフ

アジャイル環境におけるアプリケーション・セキュリティの達成

端的に言って、ソフトウェア開発者がアジャイルを利用する目的とは、議論や要件計画の必要性を抑えた迅速な開発ガイドラインを提供することにあります。開発チームはこの手法により顧客ニーズをより短期間で満足させます。顧客からのフィードバックとテストにより、最終的にアプリケーションが目標を達成するまで(これは顧客からの要件とフィードバックによって決まります)、短期間での修正を繰り返します。

では、どのようにすればセキュアな開発とアプリケーション・セキュリティ・テストをアジャイル・プロセスに組み入れることができるでしょうか。開発プロセスの最終段階で行っていては、隠れていた問題が露見したり新たな問題が発生してプロジェクトが振り出しに戻ってしまう危険性があります。したがって、セキュリティをプロセスのすべての工程に組み入れることが重要です。ここからは、アジャイル手法によるペースの速い開発においてアプリケーション・セキュリティを達成するための原則をいくつか示します。

アジャイル開発はチームでの作業であるため、アプリケーション・セキュリティもチームでの作業とする必要があります。アジャイルの最もよく知られた特長は「リーン」と「スピード」です。このため、アプリケーション・セキュリティをアジャイル・プロセスに組み入れる場合も同じ原則を採用する必要があります。

明確な要件を定義する

ほとんどの場合、開発チームと品質保証(QA)チームはセキュリティ・チームから提示される要件を十分に理解していません。開発チームは、セキュリティ対策とは自分たちの仕事を増やすだけの二度手間の作業だと感じていることが多いものです。特にプロジェクトの終盤になるまでアプリケーション・セキュリティ・テストが行われない場合にはそのように感じる傾向があります。

このため、なるべく早い段階で期待値を明確に定義しておくことが重要になってきます。開発チームとテスト・チームは、求められているセキュリティ・レベルとそのセキュリティ・レベルを達成することの意義、そしてどのようなセキュリティ・テストを実施し、どのような結果が期待されるのかという点について理解しておく必要があります。開発者がセキュリティをプロジェクト全体に上手に組み入れていくためには、チームがセキュリティの観点から何に重点的に取り組むべきか、そしてテストそのものに関する情報とその論理的根拠についても明確に記述しておくことが重要です。要件を定義する際には、まず開発者が次の質問の答えを出してみるとよいでしょう。

  • セキュアな開発およびセキュリティ・テストでは具体的にどの部分に注意すべきなのか。
  • これらのテストは定期的なペネトレーション・テストやセキュリティ監査を置き換えるものなのか、それとも両方を並行して実施する必要があるのか。
  • どれくらいの頻度で開発者はセキュリティ・テストを実施する必要があるのか、そしてチームの誰がこれらのテストの責任者となるのか。
  • 開発チームはどのようなセキュリティ規格に適合またはそれを上回るようにする必要があるのか(たとえばOWASPやPCI-DSSなどの業界標準規格、社内要件、その他)。

これらの質問に答えることができたら、開発チームは疑念や曖昧さを排除して、理解と協力に基づいてアプリケーション・セキュリティを最善の形でアジャイル開発プロセスに組み入れることができます。

重要なのは、要件を出すだけでなくトレーニングやセキュアなフレームワークなど何らかの形で目標達成支援も提供するということです。

プロセスに逆らわず、プロセスに沿って作業する

アジャイル開発チームは、プロジェクト・ライフサイクル全体で特定のプロセスを採用します。これはアジャイル全般に共通して言えることですが、これらのプロセスも軽量でリーンであることが求められます。アプリケーション・セキュリティをアジャイル開発に組み入れる一番よい方法は、現在のメンバー間相互作用に従って作業するということです。そうすれば、プロジェクトの要件をすべて満たしながらセキュリティと品質も高めたコードを作成できます。アジャイル宣言には、「プロセスやツールよりも個人と相互作用を重視する」という項目があります。しかしセキュリティに関して言えば、ツールを完全に度外視することはできません。全員が理解できる共通の言語を使用したツールを採用してチーム・メンバー間の相互作用を促し、ツールがプロセスを妨げないように注意する必要があります。

具体的な例で言えば、あるチームがバグ・トラッキング・ソフトウェアを使用しているならば、セキュリティの問題も同じインターフェイスでバグとして報告されるようにします。あるいは、すでに使用している自動化およびリグレッション・テストがあるならば、この環境に統合できるアプリケーション・セキュリティ・ツールを選ぶようにします。ツールは、開発者が理解できる言語で結果が出力されるものを選ぶことが必要です。コード内で特定された脆弱性については、その位置はもちろん、できればその脆弱性のリスク・レベルについての明確な説明と実際のリスクの具体的な説明なども見ることができれば、バグ修正の優先順位について不要な議論を防ぐことができます。

基本的に、セキュリティを別のプロセスとして分けてしまうとプロジェクト終盤でつまずきの原因となってしまうため、セキュリティをアジャイル・プロセスのすべての工程に組み入れることが重要です。

カテゴリートップ