セキュア開発を実現するには？現場における課題とKDLでの取り組み【セキュア開発技術Blog】

セキュアなシステムを開発するには、セキュリティの知識やルールをきちんと踏まえて進めることが欠かせません。そのため当社神戸デジタル・ラボ（以下KDL）では、開発者が必要な知識を身につけられるようセキュア開発トレーニングを実施しています。しかし、プロジェクトの最中に毎回そのトレーニング資料や各種ガイドラインを参照するのは手間がかかります。

そこで開発の現場ですぐに参照できる「セキュア開発チェックリスト」を作成しました。今回の記事では、このチェックリストを活用した背景と、その活用方法についてご紹介します。

セキュア開発チェックリスト作成の背景

セキュア開発を始めるもしくは始める前に、このような疑問を持ったことはありませんか。

• 私たちの開発したシステムは本当にセキュアなのか？
• 私たちにセキュア開発を意識する必要があるのだろうか？
• 現時点で、私たちはどの程度セキュア開発ができているのだろうか？

これらの疑問を解消できるのが、OWASP SAMM や、OWASP ASVS などのドキュメントです。

OWASP SAMM

OWASP Software Assurance Maturity Model (SAMM) は、ソフトウェア開発におけるセキュリティ活動を組織的に計画・評価・改善するための 成熟度モデル です。OWASP（Open Worldwide Application Security Project）が公開しているオープンなフレームワークで、世界中の企業や開発組織が参考にできるよう無償で提供されています。

SAMMはソフトウェアライフサイクルをカバーする 5つのカテゴリ区分があります。

1. Governance（ガバナンス）
2. Design（設計）
3. Implementation（実装）
4. Verification（検証）
5. Operations（運用）

各カテゴリの下に プラクティス（実践領域） が定義されており、それぞれについて成熟度レベル（レベル1〜3）が設定されています。

出典：OWASP SAMM : https://owaspsamm.org/​

OWASP SAMMでできることと、実際の活用における課題

用意されている質問に回答することで、各カテゴリごとの達成状況をスコアリング。組織のセキュア開発度を可視化できます。

では実際どのようなドキュメントなのか。

例）SAMM Implementation | Secure Build | Software Dependencies
Do you have solid knowledge about dependencies you’re relying on?
利用している依存関係について、確かな知識を持っていますか？

出典：OWASP SAMM : https://owaspsamm.org/

Implementation の一例です。性質上どうしても抽象度が高く、現場のエンジニアが日々の開発で「具体的に何をすればよいのか」を判断するのは難しい側面があります。

SAMMは長期的な取り組みや組織全体での改善活動には適していますが、目の前のプロジェクトにすぐ活かせる即効性はあまり期待できません。そのため、限られたリソースで動いているチームや、リリース前に短期間で確認を済ませたい場面では使いづらいと感じられることも少なくありません。

• 「成熟度モデル」であるため、具体的な実装手順やコードレベルのチェックは示されていない
• そのままでは現場の開発者が「今日の開発で何をすればいいのか」が見えにくい

OWASP Application Security Verification Standard (ASVS)

OWASP Application Security Verification Standard（ASVS） は、一言で言うとWebアプリおよび Web サービスのセキュリティ要件を定義しています。こちらもOWASPが提供するオープンなドキュメントで、アプリケーション開発や第三者によるセキュリティ検証（セキュリティテスト）の「基準」として利用されます。

ASVSは、アプリケーションのセキュリティ要件を以下のような検証項目に分けて整理しています。

出典：OWASP Application Security Verification Standard : https://github.com/OWASP/ASVS

これらについて重要度や利用シーンに応じて 3つのレベル が定義されています。

• レベル1：インターネットに公開されるすべてのアプリケーション向け（基本的なセキュリティ）
• レベル2：機密データを扱う業務アプリケーション向け（より強固なセキュリティ）
• レベル3：高度な攻撃対象となるシステムや重要インフラ向け（最高レベルのセキュリティ）

SAMMが「組織やプロセスの成熟度」に焦点を当てているのに対して、ASVSは「アプリケーションそのもののセキュリティ要件・検証基準」に特化している点が大きな違いです。

ASVSでできることと、実際の活用における課題

ASVSのとおりに実装していればセキュリティ要件を満たしている、ということになります。

では実際どのようなドキュメントなのか。

例）ASVS V2.2.1 入力バリデーション
入力はその入力に対するビジネスまたは機能上の期待を満たすことを検証されている。これは、許容される値、パターン、範囲のリストに対する肯定的なバリデーションを使用するか、あらかじめ定義されたルールに従って、期待される構造および論理的限界と入力との比較に基づく必要がある。L1 では、これは特定のビジネスまたはセキュリティ上の意思決定に使用される入力に焦点を当てることができる。L2 以上では、これはすべての入力に適用する必要がある。

出典：OWASP Application Security Verification Standard : https://github.com/OWASP/ASVS

V2: バリデーションとビジネスロジック の一例です。アプリケーションのセキュリティを網羅的に検証できる優れた標準ですが、その反面現場での活用にはいくつかの課題があります。

項目数が非常に多く、すべてを確認しようとすると膨大な工数がかかってしまいます。特に小規模なプロジェクトや開発スピードを重視する現場では、「重すぎる」と感じられることが少なくありません。また、レベル1〜3と段階が分かれているものの、どのレベルをどのプロジェクトに適用すべきか判断が難しく、実務での使い分けに迷うケースもあります。

• 非常に網羅的でセキュア設計・実装の参考には有効だが、そのまま使うとチェック項目が膨大すぎて現場で回しづらい
• レベル1〜3と設定があるが、どこまでやれば十分か判断が難しい

こうしてセキュア開発チェックリストは生まれた

このようにオープンなドキュメントは存在するものの、日々の開発に活かすのは簡単ではありません。（もちろん読み込めば素晴らしいドキュメントであることには間違いありません・・・！）

そこでKDLでは、まず社内でセキュア開発トレーニングを重ねてきました。累計約50回開催し、セキュアなシステムとは何か、どのように実現すべきかといった幅広いテーマを扱ってきました。
──ただし、回数を重ねる一方で課題も見えてきました。

• トレーニング内容をその都度振り返るのに手間がかかる
• 必要な情報が「どの回で扱われたのか」を探すのが大変

そうしたエンジニアの声を受けて生まれたのが、いつでも手元で参照できるチェックリスト形式の 「セキュア開発チェックリスト」 です。トレーニングで学んだ内容や各種ガイドラインを探し回らなくても、日々の開発現場で効率的に活用できることを意識して作成しました。

セキュア開発チェックリストの活用事例

下記はセキュア開発チェックリストの内容の一部です。

No	種別	チェック項目
1	入力値検証	プログラムで扱う入力値をすべて検証している（POSTのみならず、GETやPathパラメータ、 Cookie、ファイルなどを含む）
2		入力値の検証は、可能な限り許可リスト（ホワイトリスト）方式を採用している
3		許可リストで検証できない場合、サイズ、文字種、フォーマットの各観点で入力値を検証してい る
4		入力値について、境界値テストを実施している
5		入力検証で、NGと判定した場合にNG内容がログに残っている
6		出力値が定義されたプロパティおよび型に準拠していることを検証している

入力値検証＝（先ほど例をあげた）ASVSの場合のバリデーションの例です。できるだけわかりやすい日本語であること、開発するシステムに適用しやすいこと、を意識して作成しています。

チェックリストをもとに可視化する

KDLで開発したシステムでは、担当エンジニアに「チェックリストの項目にどの程度対応できているか」を回答してもらい、その結果を見える化しています。

どのくらいのシステムが対応できているのか項目ごとに集計して数値化しています。具体的な数字は伏せますが下記のように可視化しています。

この例では下部の赤くなっている項目、「モニタリング」「コンポーネントの脆弱性」「過度な使用」が弱点、といった感じです。

改善のサイクルを回す

可視化の結果、弱点であると分かった部分を再度トレーニングします。チェックリストのすべてを網羅することは難しいので、“完璧を目指すよりも、改善のサイクルを作ること”を意識しています。

このような改善サイクルを回すことで、組織としてセキュアなシステム開発レベルをアップさせていければと考えています。

今回の記事のまとめ

KDLでは、できる限りエンジニアが理解しやすい言葉でセキュア開発チェックリストを作成しました。

このチェックリストは、「必要なポイントを手元ですぐ確認できるようにしてほしい」というエンジニアの声から生まれたものです。セキュア開発トレーニングの内容や主要なガイドラインを整理し、実際のプロジェクトで活用しやすい形にまとめています。

また、そのチェックリストに回答してもらうことで、対応できている箇所とそうでない箇所を可視化。さらに、その分析結果をもとにトレーニングを行い、再度チェックリストで可視化する──KDLでは、このサイクルを繰り返すことを通じて、継続的にセキュア開発へ取り組んでいます。