【DevSecOps】アジャイル開発におけるセキュリティ | パターン・ランゲージ 解説

2022 年 7 月に「アジャイル開発におけるセキュリティ | パターン・ランゲージ」が公開されました。

こちらのドキュメントは、「アジャイル開発においてセキュリティをどのように担保するか」をパターン・ランゲージを使って解説されたものになっており、DevSecOps に取り組むためにとても参考になります。

今回は DevSecOps を成功させるためのポイント共に「アジャイル開発におけるセキュリティ | パターン・ランゲージ」の内容を紹介し、具体的にどのようなことを検討し、取り組み必要があるのかを私の経験を踏まえて解説したいと思います。

「アジャイル開発におけるセキュリティ | パターン・ランゲージ」とは？

「アジャイル開発におけるセキュリティ | パターン・ランゲージ」は、「脆弱性診断士スキルマッププロジェクトが作成した『アジャイル開発においてセキュリティをどのように担保するか』のヒントを過去の成功事例などを基にパターン・ランゲージを使って解説したもの」になっています。

パターン・ランゲージという言葉が使われていますが、この言葉をパターン・ランゲージとは？ | CreativeShiftより引用して説明すると、

パターン・ランゲージは、元々は建築家クリストファー・アレグザンダーが考案したもので、町や建物に繰り返し現れる関係性を「パターン」と呼び、それを「ランゲージ」(言語)として共有する方法のことを言います。

パターン・ランゲージは、すでに豊かな経験を持っている人から「コツの抽出」をし、他の人が「やってみたくなるヒント集」として提示するという、新しい「知恵の伝承＆学び」の方法です。

「パターン」は、ある「状況」（Context）において生じる「問題」（Problem）と、その「解決」（Solution）の方法がセットになって記述され、それに「名前」（パターン名）がつけられる、という構造を持っています。

「アジャイル開発におけるセキュリティ | パターン・ランゲージ」でも、「名前」（パターン名）「概要」「状況」「解決したい課題」「解決策」という構造を持って書かれています。

DevSecOps とは？

「アジャイル開発におけるセキュリティ | パターン・ランゲージ」の中でも触れられています DevSecOps について解説したいと思います。

ウォーターフォール開発では、開発が終わってから別途セキュリティのテストをすることが多かったのですが、アジャイル開発では新しい機能を継続的にリリースしていくサイクルへと変化したため、従来の方法を利用したセキュリティの担保が難しくなりました。

今までのセキュリティチェックの仕組みをそのまま取り込んでしまうと短いサイクルで行われる開発サイクルをセキュリティが阻害してしまうことがあります。

継続的な開発・リリースを行うための仕組み(DevOps)の中にセキュリティが組み込まれ、セキュリティ上の問題への対応を開発・運用と同じ流れで行われていくことを目的としたものが DevSecOps となります。

DevSecOps を成功させるためには、「セキュリティを考慮する文化・意識の向上」、「メンバーのセキュリティスキル底上げ」、「自動化のための仕組み作り」、「小さく始めて改善」することが大切です。

この4つのポイントを押さえた上で、「アジャイル開発におけるセキュリティ | パターン・ランゲージ」について私のこれまでの経験を交えて解説していきたいと思います。

チームビルディング

1. セキュリティ・チャンピオンの役割定義と任命

概要
各プロダクトチームの中にセキュリティ上の問題をチェックし、開発者との橋渡しの役割を担う『セキュリティ・チャンピオン』を置くことで、セキュリティが開発工程の中に組み込まれるDevSecOpsの文化を創ろう

状況
セキュリティを考慮する文化がない

解決したい問題
機能優先のみで実装を行うことによる非セキュアなプロダクトがリリースされてしまう

解決策
プロジェクト立ち上げの際にメンバーの役割を決めるとき、チーム内の開発メンバーの一人にセキュリティ・チャンピオンの役割を担わせる

セキュリティチャンピオンは、チームにおけるセキュリティの窓口となり、開発チームとセキュリティチーム間のコミュニケーションの改善、メンバーのセキュリティの知識や意識の向上などの役割を持ちます。

ただし、セキュリティの専門家しかセキュリティチャンピオンになれないわけではなく、開発メンバーから任命することができます。

セキュリティチャンピオンに任命された場合には、自分自身のセキュリティスキルの向上だけでなく、メンバーのセキュリティ知識・意識の向上を目指した活動を行う必要があります。

OWASP Summit 2017 のセキュリティチャンピオンに関するアンケート結果が公開されています。

この資料を見ることで、セキュリティチャンピオンがどういった役割の人から任命され、どのような活動を行っているのかの全体像を掴むことができます。

セキュリティチャンピオンとしてセキュリティに関わる幅広い活動が求められますが、DevSecOps を成功させるためのポイントの「セキュリティを考慮する文化・意識の向上」「メンバーのセキュリティスキル底上げ」が特に重要です。

具体的な施策の参考として、私のこれまでの経験では以下のような活動を社内のセキュリティチームを交えて行ったことがあります。

• 開発チームのセキュリティ担当者・セキュリティに興味があるメンバーを集めたセキュリティ設計・実装のクイズ大会
• 既に情報処理安全確保支援士に合格した人を講師になってもらい、興味があるメンバーを集めて勉強会・受験
• セキュリティチームによりハッキングデモ

セキュリティの知識向上の活動に注力したくなりますが、まずはセキュリティに興味を持ってもらう活動をメンバーと一緒に行うことが大切です。

2. 各自がセキュリティに責任を持ったチームビルディング

概要
開発する成果物のセキュリティ面での品質に対して各自が責任を持つようにしよう

状況
セキュリティチャンピオン以外のメンバーがセキュリティのことを気にしていない

解決したい問題
セキュリティ担当者、もしくはセキュリティチャンピオンへの負荷の集中

解決策
セキュリティ教育を実施し、リスクや脆弱性、対策方法に対する理解を深める様にしてください。

セキュリティチャンピオン一人で、プロダクトのセキュリティ全てを守ることはできません。

メンバーそれぞれがセキュリティを向上するための意識を持って行動し、セキュリティチャンピオンはそれをサポートする立場にいることが理想だと思います。

そのためにセキュリティチャンピオンは、メンバーにセキュリティの教育を行うことが求められます。

具体的な教育方法に関しては「4. セキュリティスキル底上げのための開発者向けトレーニング」で解説します。

3. セキュリティ向上のためのルール整備

概要
セキュリティに関して専門家にすべてを任せるのではなく、開発時に気を付けなければならない最低限のポイントについて開発者全員が実施できるルールを話し合って整備しよう

状況
チーム内でのセキュリティ対策については個人に依存している

解決したい問題
開発者によってセキュリティ面での品質が異なる実装が行われる

解決策
チーム内で話し合い、セキュリティ面での品質を担保するためのルールを整備しましょう。

セキュリティを向上させるためのルールを作る場合には、何から手をつければよいのかわからない、ルールが多く開発の妨げになるといった問題もあります。

現状の自分たちの環境においてセキュリティリスクが高い部分はどこか、対策があまりできていない部分はどこかといった視点でセキュリティリスクアセスメントを行う、メンバー全員で話し合うことでルール整備を進めることができます。

以下の中にセキュリティに関するルールを組み込むことが推奨されています。

• コーディングルール
• コードレビュー手法
• 承認フロー
• デプロイまでのフロー
• セキュリティテストのルール
• 脆弱性発見時の対応フロー
• 脆弱性管理
• 構成管理

また、一度に多くのルールを組み込んでしまうと正しく運用されなくなることがあるため、DevSecOps を成功させるポイントとしてあげた、「小さく始めて改善する」「自動化のための仕組み作り」を意識することが大切です。

ルールが守られているか自動でチェックする、楽にチェックするための方法に関しては「8. セキュリティテストの実施タイミングと方針検討」以降で解説します。

4. セキュリティスキル底上げのための開発者向けトレーニング

概要
セキュリティに関して専門家にすべてを任せるのではなく、開発時に気を付けなければならない最低限のポイントについてはトレーニングを受けることで開発者全員が理解できるようになろう。

状況
開発者によってセキュリティに対する知識にばらつきがある

解決したい問題
開発者によってセキュリティ面での品質が異なる実装が行われる

解決策
自社でトレーニングを実施できない場合には、外部のコンテンツを利用したり、トレーニングを受講しましょう。

DevSecOps を成功させるためのポイントの「セキュリティを考慮する文化・意識の向上」、「メンバーのセキュリティスキル底上げ」を実現するためにも、開発者向けトレーニングの実施が必要です。

トレーニング方法は、自社でトレーニングする方法と外部コンテンツを利用したトレーニング方法があります。

外部コンテンツを利用したセキュリティトレーニングも最近ではとても充実してきています。

以下のようなセキュリティ資格があり、その資格取得のトレーニングも提供されています。

• GIAC
• CEH
• OSCP
• CISSP

セキュアコーディングの学習ができるオンラインサービスなどもあります。

今回紹介している「アジャイル開発におけるセキュリティ | パターン・ランゲージ」のように、OWASP の資料を使うことでもトレーニングすることができます。

また、セキュリティのオンラインセミナー、カンファレンス・EXPO に参加することでも知識や意識向上に繋がるのでおすすめです。

上記にあげた例のように、セキュリティのトレーニング方法、どういったセキュリティの教育がしたいのかなど幅広い選択肢があります。

セキュリティチャンピオンがまず全体像を把握し、チームの状態と目指す姿からどういったトレーニングがよいのかの検討が必要です。

私がこれまで実施したものを一例に紹介します。

• これまでに社内で起こったセキュリティの問題とその影響、解決策の共有を行い、セキュリティ意識の向上
• 社内で輪読会を開き、参加メンバーの認識を合わせながらセキュリティスキルの底上げ

身近な事例を共有することでメンバーにも自分たちに関係あることとして認識が変わり、意識の向上にも繋がります。

教育に関しても一度限りのものではなく、継続的な実施が大切です。

開発計画・プロジェクト計画

5. スプリント成果物に必要なセキュリティ要件の決定

概要
スプリント期間内に開発する成果物の完成の定義には、機能要件だけでなく、実装しておかなければいけないセキュリティ要件とそのテスト項目についても含めておこう

状況
セキュリティについての要件が曖昧なままスプリントが始まる

解決したい問題
十分なテストがされないまま開発が進み、脆弱性診断などで多くの脆弱性が発見され手戻りが多くなる

解決策
スプリントプランニングで成果物の完成の定義を検討するとき、Web システム／Web アプリケーションセキュリティ要件書やOWASP アプリケーションセキュリティ検証標準 4.0を参考に、成果物が実装しておかなければいけないセキュリティ要件を定義してください。

スプリント期間内にセキュリティの要件として何を守る必要があるのか、どうやってテストするのかを決める必要があります。

セキュリティの要件を決めるための資料として、OWASP ASVS (アプリケーションセキュリティ検証標準)があります。

OWASP ASVS では、286 項目の要求事項から成る Web アプリケーションに関する網羅的なセキュリティ要件のリストになっています。

またアプリケーションの特性に合わせて準拠すべきレベルを三段階に分けて定義されています。

ただし、すべてのアプリケーションを対象として Level 1 の要件数でも 136 件あり、まだあまりセキュリティが整備されていない場合には負荷の高い作業となります。

DevSecOps を成功させるためのポイントの「小さく始めて改善」を意識して、OWASP Top 10、OWASP Proactive Controlsといった導入しやすいものから始めることをおすすめします。

Top10シリーズとASVS

要件のチェックを全て手動で行うと属人化、開発のボトルネックになり形骸化にも繋がります。

そのための対策としてツールや外部サービスを利用し、「自動化のための仕組み作り」も一緒に検討することが大切になります。

こちらに関しては「8. セキュリティテストの実施タイミングと方針検討」以降で解説します。

6. リスクに応じた脆弱性対応方針の策定

概要
システムのアーキテクチャや扱う情報、サイバー攻撃のトレンドなどのリスクに応じて脆弱性の対応方針を決めよう

状況
どの脆弱性に対応するべきか判断できない

解決したい問題
重大な脆弱性が残ったままの非セキュアなプロダクトがリリースされてしまう

解決策
リスクの大きさの判断基準を決めましょう。
判断基準に応じたリスクの対応方針を決めましょう。

リスクの大きさの判断基準にはCVSS (Common Vulnerability Scoring System)がよく利用されます。

CVSS は「基本評価基準、現状評価基準、環境評価基準」 の 3 つの基準で脆弱性の深刻度を評価します。

その中でも「基本評価基準」を使って評価した CVSS 基本値(Base Score)の値を利用したリスク判断が行われることが多いです。

しかし、CVSS 基本値だけでは実際に自分たちの環境でどれだけ影響があるのかはわかりません。

攻撃コードが出回っているかどうか(CVSS 現状評価値、Temporal Score)、自分たちの環境下ではどれだけ影響があるかどうか(CVSS 環境評価値、Environmental Score)まで算出することで実際の影響の判断が可能になります。

脆弱性深刻度の割り出し方

潜在的な脆弱性の影響(CVSS 基本値)が高い場合でも、自分たちの環境下で実際に脆弱性が悪用される影響(CVSS 環境評価値)は低い可能性もあります。

CVSS 基本値、現状評価値、環境評価値、どの値まで算出しリスクの判断をするのか、リスクを判断した結果を使ってどのような対応をするのかを事前に決めておくことが大切です。

判断基準を決める時も、DevSecOps を成功させるポイント「小さく始めて改善する」を意識して、リスクが特に高いものだけに絞って対応するようにし、運用がスムーズにできるようになってから基準・対応方針を見直すことをおすすめします。

7. 脆弱性トリアージ

概要
発見した脆弱性をチケット管理し、対応の優先順位を決めよう

状況
脆弱性診断を始めたところ、スプリント内で捌ききれないほどの大量の脆弱性が発見される

解決したい問題
発見した脆弱性が多く対応しきれない

解決策
脆弱性のリスクを分析しましょう。

脆弱性診断を初めて実施した場合には、多くの脆弱性を指摘されることがあります。

脆弱性診断のレポートにも Critical、High といった重要度が割り当てられていることも多いですが、High 以上のものだけに絞っても利用が多く、すぐには対応しきれないこともあります。

そういった場合には、リスク分析を行い、脆弱性が自分たちの資産、事業へ与える影響を明確化し、どの脆弱性に対応すべきかの優先順位付けをする必要があります。

リスク分析方法に関して、IPA 『制御システムのセキュリティリスク分析ガイド 第2版 ～セキュリティ対策におけるリスクアセスメントの実施と活用～』に詳しく書かれています。

こちらは制御システム向けに書かれた資料ではありますが、分析方法はWebシステム含めて利用することができます。

詳細リスク分析の手法として2つ紹介され、以下のような特徴があります。

• 資産ベースのリスク分析：システムを構成する資産をベースに、保護すべき資産の重要度(価値)、想定される脅威の発生可能性、脅威に対する脆弱性(現状の対策状況)の 3 つを評価指標として分析
• 事業被害ベースのリスク分析：回避したい事業被害をベースに、発生した場合の事業被害のレベル、その攻撃シナリオの発生可能性、攻撃に対する脆弱性(現状の対策状況)の 3 つを評価指標として分析

脆弱性診断の結果をベースにリスク分析をする場合には、指摘された脆弱性によって、システム内のどんな資産に影響を与えるのか(個人情報)、脆弱性が実際に悪用される可能性の検討(一定のスキルがある攻撃者ならいつでも攻撃可能)、その場合にどんな対策が現状あるのか(現状の対策はない)、といった観点で分析できます。

リスク分析に関しても細かく分析するためには多くの時間と知識が必要となります。

「小さく始めて改善する」を意識し、複数人で議論しながら攻撃者の視点で考えるよい機会となりますので少しずつ精度をあげていくことが大切です。

以下の記事では、Webシステムに脅威分析を行った時の背景や分析方法が書かれていますので参考になります。

継続的なセキュリティ対策をするために脅威分析をしました | PLAID Engineer Blog

セキュリティテスト

8. セキュリティテストの実施タイミングと方針検討

概要
プロジェクトの特性を考慮し、テストの実施タイミングや内容を計画しておき、開発したアプリや機能の安全性を適切に確認できるようにしよう

状況
プロジェクト内でいつセキュリティテストを実施したら良いのかわからない

解決したい問題
適切ではないタイミングでテストを行ってしまい非効率な開発が行われる

解決策
開発者、テスターと話し合い、セキュリティテストのタイミングや実施するテストの種類、内容の概要を計画として明記します。

スプリント中に全てのセキュリティテストが実施され、常に脆弱性がない状態が維持されていることが理想ではありますが、難しいケースがほとんどだと思います。

スプリント成果物にどんなセキュリティの要件が必要なのかは「5. スプリント成果物に必要なセキュリティ要件の決定」で定めていますが、具体的な実現方法をこの段階や次の「9. スプリント内で実施するテスト内容の策定」で決定していきます。

具体的なセキュリティテストの種類と特徴については次のパターンで解説します。

手動による脆弱性診断を行う場合には、どういったタイミングで行うのかを事前に決めておき、開発のスケジュールの中に組み込めるようにする必要があります。

9. スプリント内で実施するテスト内容の策定

概要
スプリントごとに行うテストを決めることで、セキュリティテストの実施漏れをなくす

状況
スプリント内でどのようなセキュリティテストを実施したら良いのかわからない

解決したい問題
本来必要なセキュリティテストが行われていない

解決策
毎回のスプリントごとに実施するテストを決めましょう。スキャナーを使用するなど自動的に実施されるセキュリティテストを導入しましょう。この段階では、脆弱性をゼロにするのが目的ではなく、低減することが目的です。

DevSecOps を成功させるためのポイントの「自動化のための仕組み作り」を意識して、自動化できるセキュリティテストは脆弱性スキャナーを利用して自動化し、手動によるテストは脆弱性スキャナーが苦手とする認可制御やビジネスロジック部分に絞って実施できるようにしましょう。

ここでは、Web アプリケーションにおける 3 つのセキュリティテストを紹介したいと思います。

(詳しくは「Webセキュリティはどこから手をつければよいのか？」で解説しています。)

ブラックボックステスト

• 動的アプリケーションセキュリティテスト（DAST / Dynamic Application Security Testing）

ホワイトボックステスト

• ソフトウェアコンポジション解析（SCA / Software Composition Analysis）
• 静的アプリケーションセキュリティテスト（SAST / Static Application Security Testing）

それぞれ得意分野、開発ライフサイクルの中での役割の違いがあるため、併用することができます。

SCAに関しては次の「10. 利用環境の脆弱性管理」で解説します。
自動化ツールを選定する時に必要な観点に関しては「11. セキュリティテストの自動化」で解説します。

以降のパターンを踏まえた上でどこまでスプリント内でテストするのかを決めていくことが必要です。

10. 利用環境の脆弱性管理

概要
自分たちが管理すべき環境（OS、フレームワーク、データベース、アプリケーション、ライブラリなど）に脆弱性がないかを確認し、対応状況を確認しよう

状況
現在利用している環境の状態が管理できていない

解決したい問題
既知の脆弱性が残ったままリリースされている

解決策
情報源を定期チェックしましょう。
脆弱性スキャナを定期的に利用しましょう。

自分たちが提供しているシステムに含まれる OS、ミドルウェア、フレームワーク、ライブラリの名称とバージョンを正しく管理し、常に脆弱性がないかを確認し、対応状況を確認する、という一連の作業を手動で行うことは手間も時間もかかるため大変な作業になります。

最近世の中を騒がせた Log4j の脆弱性 Log4Shell は、12 月 10 日に脆弱性情報が公開されてからすぐに攻撃活動が活発化したことからも脆弱性管理の重要性は高まってきています。

Log4Shell 攻撃活動の推移 (引用元 Apache Log4j2のRCE脆弱性（CVE-2021-44228）を狙う攻撃観測 | JPCERT/CC Eyes)

手動での脆弱性管理では、大量にあるソフトウェアの中に含まれる脆弱性を即座に調べることは困難なため、Log4Shell のような脆弱性への対応が遅れてしまうことがあります。

脆弱性管理は、「9. スプリント内で実施するテスト内容の策定」で触れました SCA を利用することで自動化が可能です。

SCA を使って自動化をすることで、手動では困難だった Log4Shell のような緊急度の高い脆弱性を即座に知ることも可能になります。

どのセキュリティテストを自動化すべきなのかについては次のパターン「11. セキュリティテストの自動化」で解説します。

11. セキュリティテストの自動化

概要
セキュリティテストを効率よく実施するためには自動化ツールの導入が必要となります。開発環境、体制にとって適切な最適な自動化ツールを選択し、効率的に実施しよう

状況
セキュリティテストに時間が掛かる

解決したい問題
スプリント内でWebアプリケーションの脆弱性が効率よく見つからない

解決策
すべての脆弱性がスキャナーで発見できる訳ではありませんが、スキャナーを利用することで一部の脆弱性発見について効率化が図れます。

セキュリティテスト SAST、DAST、SCA の得意分野、開発ライフサイクルの中での役割の違いについては「9. スプリント内で実施するテスト内容の策定」で説明しました。

セキュリティテストのツールを導入する時には、機能の違いだけでなく、導入しやすさや運用しやすさといった観点も大切です。

ツールと自分たち環境との相性もあるので、以下の観点を持ってツール選定を行う必要があります。

• 自分たちの開発工程に組み込みやすいか
• 脆弱性の誤検出が少ないか
• 脆弱性のトリアージがしやすいか
• 診断したい対象を診断できるか
• 運用しやすいか・使いやすいか
• 費用対効果に見合うか
• ツールのサポート体制

セキュリティツール・サービス全般に言えることではありますが、導入しただけでは効果がない場合が多く、導入後に運用することでセキュリティの向上に繋がります。

運用を開始してから以下のような問題に気が付くことがあります。

• 脆弱性の検出はするが、その後の運用をサポートする機能がなく Excel などへの転記作業が発生する
• 検出結果を確認すると多くのものが誤検出
• 機能は豊富にあるが設定が複雑で使いこなせない
• 海外のサービスのためサポートからの対応が不十分

導入する時には以下の点を確認することをおすすめします。

• 複数のツール・サービスをトライアル利用し上記の観点をチェックする
• 実際に利用するメンバーに扱いやすいかどうか確認する
• ドキュメントが充実している・導入支援があるなど困ったときに解決する方法があるか確認する

セキュリティ品質向上

12. セキュリティの継続的向上のためのふりかえり

概要
反復的に繰り返される開発の中で、レトロスペクティブなどを活用し、セキュリティを実装するプロセスも見直しを行い、サービス・プロダクトのセキュリティを向上させよう

状況
スプリントごとに同じような脆弱性が繰り返し作り込まれてしまう

解決したい問題
セキュリティテストで検出される脆弱性を減らしたい

解決策
スプリントレトロスペクティブを活用し、スプリント内で実施されたセキュリティ実装・セキュリティテストを振り返ります。

繰り返しにはなりますが、DevSecOps を成功させるには「小さく始めて改善する」ことが大切です。

例えば、以下のテーマで話し合い、改善項目の洗い出しを行うことができます。

• コーディングルールの見直し
• テスト方法の見直し
• メンバーの意識の見直し
• 脆弱性対処基準の見直し
• リソース配分の見直し

改善する項目は、導入したセキュリティテストの項目や設定の見直しといったことから、セキュリティルール・基準の見直し、メンバーのセキュリティの知識や意識の改善など多岐にわたります。

これまで解説した 1 から 11 までのパターンを参考にして継続的に改善し、チームにあったセキュリティを担保する仕組みを構築しましょう。

おわりに

今回は、「アジャイル開発におけるセキュリティ | パターン・ランゲージ」について、具体的な例を示しながら説明しました。

セキュリティツールを導入するだけ、セキュリティ教育をするだけでは DevSecOps は実現できません。

DevSecOps を成功させるためのポイントは、「セキュリティを考慮する文化・意識の向上」、「メンバーのセキュリティスキル底上げ」、「自動化のための仕組み作り」、「小さく始めて改善」の4つがあり、この 4 つ全てを少しずつ成長させていくことが大切です。

KDDI様の導入事例では、アジャイル開発の中に yamory を導入した背景やメリットについて書かれています。

yamory を導入することで、チーム全体のセキュリティ意識の向上、開発スピードの向上にも役立てることができた事例となっていますので、興味のある方はぜひご覧ください。

yamory は、「10. 利用環境の脆弱性管理」の「脆弱性スキャナ」のひとつとして例示されているように、アプリケーションライブラリ、ミドルウェア/OS、コンテナの脆弱性管理を行うことができるクラウドサービスです。

ご興味がある方はこちらより資料請求を行うことができます。

セミナーも定期的に開催していますのでこちらのページよりご参加ください。