OWASPとは

OWASP（The Open Web Application Security Project）はWebアプリケーションを作成する開発者や、Webアプリケーションに関わる意思決定を行う方々に対し、組織が信頼できるアプリケーションやAPIを開発、購入、維持できるよう支援するオープンなコミュニティです。すべてのOWASPのツール、ドキュメント、ビデオ、プレゼンテーション、そしてチャプター（支部）は自由でオープンなものであり、アプリケーションセキュリティを改善する人なら誰でも活用することができます。

日本においては、本稿執筆時点でOWASP Fukuoka（福岡）、OWASP Fukushima（福島）、OWASP Kansai（大阪、京都、神戸）、OWASP Nagoya（愛知）、OWASP OKINAWA（沖縄）、OWASP Saitama（埼玉）、OWASP Sendai（仙台）、そして主に首都圏から全国をサポートするOWASP Japanという8つのローカルチャプターが設立されています。コロナ禍で開催頻度は少し落ち着いていますが、各チャプターではローカルチャプターミーティングというカジュアルな勉強会を開催しています。また2022年8月29日からOWASP Global AppSec APAC 2022と呼ばれるグローバルカンファレンスが8年ぶりにバーチャル形式で開催されます。時差が少ないアプリケーションセキュリティに特化したグローバルカンファレンスはなかなかありませんので、ご興味のある方はぜひご参加ください。

OWASPプロジェクトとは

OWASPプロジェクトは、ボランティアのコミュニティによって運営されるWebアプリケーションセキュリティに関連するドキュメントやツールの作成に関する活動です。OWASPには現在100以上のアクティブなプロジェクトがあり、毎週新しいプロジェクトの申請が行われています。主要なプロジェクトの関係性を把握するには、OWASP Integration Standards Projectが作成しているApplication Security Wayfinderが便利です。セキュア開発サイクル（Secure Development Life Cycle）の各段階に役立つプロジェクトがマッピングされています。

これらのプロジェクトの中でも、アプリケーション・セキュリティ全体にとって戦略的な価値を実証したプロジェクトは、Flagshipプロジェクト（最も重要なプロジェクト群）に指定されています。Application Security Wayfinderの中でFlagshipプロジェクトに緑色の枠をつけてみました。SDLCの各工程にFlagshipプロジェクトの成果物が有効であることがわかります。ここでは、これらのFlagshipプロジェクトの中でも最も有名なプロジェクトの1つであるOWASP Top 10について紹介します。

OWASP Top 10とは

OWASP Top 10は、開発者とWebアプリケーションセキュリティのための標準的な啓発文書です。Webアプリケーションに対する最も重大なセキュリティリスクについて、データと有識者の意見をもとに表現されています。2003年から作成され、2021年版が7回目の更新となります。本稿執筆者もOWASP Top 10 2021翻訳チームとしてOWASP Top 10 2021日本語抄訳に協力いたしました。

• OWASP Top 10 2021 日本語訳

OWASP Top 10の主なユースケースはApplication Security Wayfinderにもあるように、トレーニングとしての活用や意識向上プログラムです。もしアプリケーションセキュリティにおける要件設計や、検証観点の確認を行う目的とした文書を探している際には、OWASP ASVSを参照してください。

OWASP Top 10 2021

OWASP Top 10 2021では最も重大なセキュリティリスクが10のカテゴリーに表現されています。各カテゴリーに含まれる共通脆弱性タイプ一覧（CWE）が明記されています。

OWASP Top 10 Projectは前回のOWASP Top 10 2017ではTop10のカテゴリーを選別するにあたり、約30のCWEからなるサブセットに焦点を当て、アプリケーションの脆弱性情報提供いただける協力者から情報を収集しました。2021年版ではCWEに制限を設けずに脆弱性情報を収集したため193の脆弱性タイプが10のカテゴリに集約されています。こうして収集したデータセットの中から10項目のうち8項目をTop10のカテゴリとして選定し、残り2項目がコミュニティからの調査によって選定されています。こうしたデータの収集方法が透明化されている点もOWASP Top 10の魅力の１つです。

2021年版トップ10では、3つの新しいカテゴリー、4つのカテゴリーの名称とスコープの変更がありました。

本稿では新しく追加されたカテゴリである「A04:2021 - 安全が確認されない不安な設計」と「A08:2021 – ソフトウェアとデータの整合性の不具合」について、当グループの事例を交えながら紹介します。

A04:202 1- 安全が確認されない不安な設計

「A04:2021 - 安全が確認されない不安な設計」は、さまざまな設計上の欠陥を表す広範なカテゴリーです。根本的な原因と改善方法が異なるため、「⁠実装」における欠陥とは明確に分けられています。

安全な設計であっても、実装上の欠陥があると、それが悪用される可能性のある脆弱性につながります。安全でない設計は、完璧な実装によって修正することはできません。セキュリティの専門家は、ビジネス部門と連携してセキュアな開発ライフサイクルを確立する必要があります。常に脅威を評価し、既知の攻撃方法を防ぐためにコードを堅牢に設計しテストする「セキュリティ文化」と方法論を確立することが重要です。

開発部門とセキュリティチームとの効率的なコミュニケーションを構築し「セキュリティ文化」を組織全体に確立する方法論の１つに、Security Championsプログラムがあります。Securirty Champions Playbookは、OWASP Bucharest AppSec Conference 2017で公開されたドキュメントで、Security Championプログラムを構築するためのステップが解説されています。

Security Championとは、プロダクトやサービスの開発チームに所属するエンジニアのうち、セキュリティプロセスの中核、また単一窓口（Single Point of Contact, SPOC）としての役割を担うメンバーを意味します。Security Championは、各々が普段の業務で従事するプロダクトやシステムに関わる専門知識を主軸として、チームメンバーのトレーニングやセキュリティ要件の定義、設計、検証、実装、運用といった各セキュリティプロセスを開発メンバーとしての立場からセキュリティチームと連携して横断的にリードします。

楽天グループでは、2003年に基礎となるプログラムを開始し、2020年1月よりSecurity Championsプログラムと改め、開発部門とセキュリティチームとの密な連携の構築に活用しています。プログラムの中心となる社内組織であるSecurity Champion Committeeには、国内外の楽天グループの開発チームからセキュリティ業務に従事するエンジニアがそれぞれ選出され、現在約300名が所属しています。

楽天グループでは70超のサービスが日々開発・運用されていますが、サービスによって技術スタックや開発の体制、運用サイクル、事業要件は大きく異なります。プログラム導入以前は、セキュリティチームが中心となって個々の開発チームのセキュリティプロセスを統一的（＝「ガバナンス」的）にマネジメントしていました。しかし、近年のソフトウェア開発技術の多様化やグループ組織の規模拡大を背景として、ガバナンス的なマネジメントを行うことが次第に困難になりつつありました。たとえば、チームの成熟度によって必要なセキュリティトレーニングの内容は異なりますし、eコマースの分野とFinTechの分野で求められるセキュリティ要件も異なります。使用するプログラミング言語やフレームワークが異なれば、最適なセキュリティスキャナーも異なるでしょう。グループ組織全体でセキュアな開発ライフサイクルを維持していくためには、セキュリティチームから開発チームへの一方的なコミュニケーションではなく、双方向のコミュニケーションが必要不可欠でした。

Security Chamipionsプログラム導入後は、セキュリティチームによるセキュリティ監査やモニタリングなど「ガバナンス」的施策は行いつつも、セキュリティトレーニングやセキュリティレビューといったプロアクティブな活動のマネジメントは各Security Championに移譲され、セキュリティチームがその活動を支援（＝「エンパワーメント⁠」⁠）する形に移行しました。Security Championは単なる社内調整役ではありません。チームの中核メンバーがセキュリティプロセスのリードを行うことで、それぞれのチームで自律的なセキュリティ文化が醸成されました。

また、Security Championを中心として、開発チームとセキュリティチームが互いの専門領域を生かして双方向にエンパワーメントすることのできるコミュニケーションチャネルと信頼関係が構築され、これらを基盤としてセキュアな開発ライフサイクルをグループ全体に普及・確立することに成功しました。

A08:2021 – ソフトウェアとデータの整合性の不具合

「A08:2021 – ソフトウェアとデータの整合性の不具合」は、2017年度版の「A08:2017 - 安全でないデシリアライゼーション」の内容を踏襲しつつも、新たにCI/CDパイプラインの安全性やソフトウェアサプライチェーンの信頼性についても言及した、アプリケーションの整合性の不具合に関する問題をより広範にカバーする新しいカテゴリです。

近年のソフトウェア開発において、「⁠オープンソースソフトウェア」や「クラウド⁠」⁠、「⁠X as a Service」といったキーワードは決して珍しいものではなくなりました。今日のソフトウェア開発プロジェクトの多くは、第三者によって開発・メンテナンスされたプロダクトやシステムを何かしらの形で再利用し、その利便性を享受していると言えるでしょう。一方で、第三者のプロダクトやシステムを再利用すること、すなわちソフトウェアサプライチェーンの形成は、セキュリティ上の第三者への「依存性」も大きく複雑なものとしました。その結果、ソフトウェアサプライチェーンセキュリティの重要性と脅威への関心が以前よりも高まってきています。

ソフトウェアサプライチェーンセキュリティが注目された最近の事例として、2021年末のLog4Shell（CVE-2021-44228）や、2022年3月のSpring4Shell（CVE-2022-22965）は記憶に新しいかと思います。これらのケースでは、セキュリティエンジニアはもちろんのこと、アプリケーションエンジニアやインフラエンジニアなど多くのエンジニアが、プロダクトやシステムへの影響調査やコード修正、マネジメント層や顧客への報告といった作業に対応を追われました。自分が「つくったもの」だけでなく「利用しているもの」も把握し、管理することの必要性に気付かされるケースであったと言えるでしょう。

楽天グループでは、このような近年のソフトウェアサプライチェーンセキュリティの動向を鑑み、また、日々多様化する脅威に迅速に対応するために、OWASP CycloneDXとOWASP Dependency-Trackを用いてサプライチェーンマネジメントの改善に取り組んでいます。

OWASP CycloneDXは、OWASPが主導して策定を行っているソフトウェア部品表（Software Bill of Materials, SBOM）のフォーマット標準です。SBOMはプロダクトやシステムが依存するソフトウェアコンポーネントとそのバージョン情報を構造化した文書で、近年ソフトウェアサプライチェーンマネジメントを改善するための新しい概念として注目されています。

CycloneDX SBOMファイルでは、CPE（Common Platform Enumeration）や、purl（Package URL）、チェックサムなど、一意に識別可能な情報を用いてXMLあるいはJSONファイルとしてSBOMを記述することができます。OWASP CycloneDXの導入により、ソフトウェアコンポーネントの管理と情報共有がSBOMとして共通言語化され、組織内外との情報のやりとりを標準化・円滑化することができます。

一方、OWASP Dependency-TrackはSBOMの管理と分析の機能を備えています。日々更新されるNVD（National Vulnerability Database）やGitHub Advisory Database等の脆弱性データベースと、SBOMファイルを通じて登録されたソフトウェアコンポーネントの情報とを継続的にマッチングすることにより、プロダクトやシステムが抱える脆弱性の早期発見と効率的な管理を行うことが可能です。以上のプロセスは一般に、ソフトウェア構成分析（Software Composition Analysis, SCA）と呼ばれます。

SBOMファイルの生成には、OWASP CycloneDXプロジェクトが直接メンテナンスするSBOM生成ツールのほか、Anchore社のSyftや、Aqua Security社のTrivyなどといったオープンソースソフトウェアを用いることができます。これらのツールを用いることで、プロダクトやシステムのソースコードリポジトリ、あるいはコンテナイメージからSBOMファイルを生成することができます。2022年7月には、Microsoft社がSBOM生成ツールをオープンソースソフトウェアとして公開し、注目を集めました。

楽天グループでは、これまでソフトウェアコンポーネントの管理のために、一部商用ツールや内製ツール等を導入していました。しかし、システムやサービス、チームによって、技術スタックや開発の体制、運用サイクル、事業要件が大きく異なるためにSCAに必要となる開発チームおよびセキュリティチームの工数が高くなる傾向にありました。この教訓を生かし、現在、社内においてOWASP CycloneDXとOWASP Dependency-Trackを中心としたソフトウェアコンポーネント管理の標準化と自動化に向けた検証を進めています。開発チームとセキュリティチーム双方が開発や運用上の負担のない形でソフトウェアコンポーネント情報を継続的に管理し、Log4Shellのような脅威があった場合に「標準的」で効率の良い運用を行う「セキュリティ文化」の定着を目指しています。

SBOMを中心としたソフトウェアサプライチェーンの管理の技術とコミュニティは、近年急速に拡大し注目を集めています。SBOMの普及により、その利用ケースは将来的に脆弱性管理にとどまらず、ソフトウェア資産管理や調達などさまざまな場面に及び、いずれのケースでもSBOMはソフトウェアコンポーネント情報の管理ややりとりの円滑化を我々にもたらしてくれるでしょう。

現時点ではSBOMのフォーマット標準はOWASP CycloneDXだけではなく、Linux Foundationが主導するSPDX（Software Package Data Exchange）や、SWID（Software Identification）Taggingなど多岐に渡り、企業やコミュニティ、実装の対応状況も千差万別です。これらの異なる仕様間の差をどのように吸収するかは未だ利用者側に委ねられているのが現状です。今後、これらの仕様の共通化・標準化がより一層進み、また、導入障壁が軽減されることで、業界全体でSBOMの利活用が広がることが期待されます。楽天グループもこうした標準化への取り組みに貢献していきます。

まとめ

本稿ではOWASP Top 10の概要について説明し、2つのカテゴリについて当グループでの活用事例をご紹介しました。OWASPの各ローカルチャプターでは、皆様と一緒にアプリケーションセキュリティを学び、現場の組織での対策に活かすためにさまざまな活動を行っています。本稿が皆様の良きOWASPライフとInternet World Peaceの一助になれば幸いです。