![](\"/assets/images/web/404-old-owasp.png\")
Try the SEARCH function in the main navigation to find something. If you are looking for chapter information, please see Chapters for the correct chapter. For information about OWASP projects see Projects. For common attacks, vulnerabilities, or information about other community-led contributions see Contributed Content.
\n \nIf all else fails you can search our historical site.
\n![](\"https://owasp.org/www-chapter-japan/assets/images/SCSK-Security_J_B2.jpg\")
](https://scsksecurity.co.jp/)|[![](\"https://owasp.org/www-chapter-japan/assets/images/Cybozu.png\")
](https://cybozu.co.jp/en/company/)|[![](\"https://owasp.org/assets/images/corp-member-logo/ub-secure.png\"){kind=logo}
](https://www.ubsecure.jp/) |[![](\"https://owasp.org/assets/images/corp-member-logo/aeyesecuritylab-logo.png\"){kind=logo}
](https://www.aeyesec.jp/) |\n|----|----|----|----|\n|||||\n| [![](\"https://owasp.org/www-chapter-japan/assets/images/snyk.png\")
](https://go.snyk.io/jp.html) | [![](\"https://owasp.org/www-chapter-japan/assets/images/Fastly_logo_2020.jpg\"){kind=logo}
](https://www.fastly.com/jp/) |[![](\"https://owasp.org/www-chapter-japan/assets/images/techmatrix.png\")
](https://www.techmatrix.co.jp/product/scw/index.html)\n\n#### OWASP Japan Chapter ローカル・スポンサーシップ\t\n * 1000ドルのご寄付/1ショット を受け付けています。\n * [OWASPへのDonation](https://owasp.org/donate/)で支払い、その後OWASP Foundation事務局に「OWASP Japan Chapterを支援したい」と伝えることで実現できます。\n * 自社のセミナールーム提供や一般の会場、また撮影スタジオやミートアップの飲食など費用を直接支払っていただくことによってVenueサポーターとなっていただくのも歓迎です。\n"
},
{
"path": "info.md",
"content": "[このサイトのGithubリポジトリ](https://github.com/OWASP/www-chapter-japan)\n\n### Japan Chapter Links\n* OWASP Japan Slack\n * OWASP正規会員の方は@owasp.orgのメアドを用いれば両方招待なしで入れます：\n * OWASP Japan Slack https://join.slack.com/t/owaspjapan/signup\n * OWASP Global Slack https://join.slack.com/t/owasp/signup\n * 非会員で参加もできます。招待をもらってください\n \n* [OWASP Japan Chapter メーリングリスト Google Groups](https://groups.google.com/a/owasp.org/g/japan-chapter)\n * イベント案内、プロジェクト招待など\n\n### イベント参加\n * [doorkeeper](https://owasp.doorkeeper.jp/) メイン\n * [Meetup](https://www.meetup.com/japan-owasp-meetup-group/) バックアップ\n\n \n### ユーザのみなさまへ日本語リソース紹介\n* [OWASPトップ10 for LLM日本語](https://github.com/owasp-ja/Top10-for-LLM/tree/main)\n\n* [OWASPトップ10 2021日本語](https://github.com/owasp-ja/Top10/blob/master/2021/docs/index.ja.md)\n\n* [OWASP Proactive Controls 2018日本語](https://github.com/owasp-ja/OWASP-Top10-Proactive-Controls-2018-JP)\n* [OWASP ASVS 4.0 日本語](https://github.com/owasp-ja/asvs-ja)\n\n* [Mobile ASVS日本語](https://github.com/OWASP/owasp-masvs/blob/master/Document-ja/0x02-Frontispiece.md)\n\n* [開発者のためのOWASPチートシート一覧表](https://docs.google.com/spreadsheets/d/1KNsAK1QbGih3WvmeTNeX5dj3_H1IHJTXrr98ZbFZZkg/edit#gid=0)\n\n### 旧バージョンのドキュメント\n* [JPCERT/CCより： OWASPアプリケーションセキュリティ検証標準(ASVS)3.0 日本語提供](https://www.jpcert.or.jp/securecoding/materials-owaspasvs.html)\n* [JPCERT/CCより： Cheatsheet日本語](http://jpcertcc.github.io/OWASPdocuments/)\n* [JPCERT/CCより： ソフトウェアセキュリティ成熟度モデル OWASP SAMM1.0日本語](https://www.jpcert.or.jp/research/2010/SAMM_20100407.pdf)\n\n* イベントアーカイブ\n * [Youtube OWASP Japan channel](https://www.youtube.com/channel/UCOsPioMMKzTTVv3__M0HFUw)\n \n* SNS\n * [Twitter @owaspjapan](https://twitter.com/owaspjapan)\n \n* カレンダー\n * [Google Calendar: OWASP JAPAN](https://calendar.google.com/calendar/b/1?cid=MGViaHU2dm5zdDYyOXMwM2lxMzR0NHZqbThAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ)\n * [Google Calendar: OWASP Event](https://calendar.google.com/calendar/embed?src=hl6cjgs6ep1h7oniqgueu2bhbo%40group.calendar.google.com)\n\n"
},
{
"path": "leaders.md",
"content": "### Leaders\n* [Riotaro OKADA](mailto:riotaro@owasp.org)\n* [Sen UENO](mailto:sen.ueno@owasp.org)\n\n### Board Member\n* Dracea Robert\n* Hiroshi Tokumaru\n* Masafumi Negishi\n* Takanori Nakanowatari\n* Yoshinari Fukumoto\n* Yoshinori Takesako\n* Yosuke Hasegawa\n* Yukihiro Nowatari\n* Shoichi Nakata\n"
},
{
"path": "secreq/README.md",
"content": "# Webシステム／Webアプリケーションセキュリティ要件書\r\nOWASP Web Application Security Requirements\r\n\r\nby [脆弱性診断士スキルマッププロジェクト](https://github.com/OWASP/www-chapter-japan/tree/master/skillmap_project)\r\n\r\n## 本ドキュメントについて\r\nWebシステム／Webアプリケーションセキュリティ要件書は、安全なWebアプリケーションの開発に必要なセキュリティ要件書です。発注者、開発者、テスト実施者、セキュリティ専門家、消費者が活用することで、以下のことを達成することを目的としています。\r\n* 開発会社・開発者に安全なWebシステム／Webアプリケーションを開発してもらうこと\r\n* 開発会社と発注者の瑕疵担保契約の責任分解点を明確にすること\r\n* 要求仕様やRFP（提案依頼書）として利用し、要件定義書に組み込むことができるセキュリティ要件として活用していただくこと\r\n\r\n## 本ドキュメントがカバーする範囲\r\n本ドキュメントではWebシステム／Webアプリケーションに関して一般的に盛り込むべきだと考えられるセキュリティ要件について記載しています。また、開発言語やフレームワークなどに依存することなくご利用いただけます。ただし、ネットワークやホストレベル、運用などに関するセキュリティ要件については記載していません。\r\n\r\n対象とするWebシステム／Webアプリケーションは、インターネット・イントラネット問わず公開するシステムで、特定多数または不特定多数のユーザーが利用するシステムを想定しています。この中でも特に認証を必要とするシステムが、本ドキュメントの主なターゲットとなっています。\r\n\r\n本ドキュメントは、セキュリティ要件としての利用しやすさを優先して記載しているため、一般的であろうというシステムを想定し、例外の記載を少なくしたセキュリティ要件となっています。そのため具体的な数値や対策を指定していることもありますが、要件定義書に記載する内容は開発者と折衝してください。\r\n\r\n## Download\r\n### Ver.4.0 （2022年6月リリース版）\r\n* [Webシステム／Webアプリケーションセキュリティ要件書（EXCEL版）](https://github.com/OWASP/www-chapter-japan/blob/master/secreq/OWASP_WebApplicationSecurityRequirements.xlsx)\r\n* [Webシステム／Webアプリケーションセキュリティ要件書（PDF版）](https://github.com/OWASP/www-chapter-japan/blob/master/secreq/OWASP_WebApplicationSecurityRequirements.pdf)\r\n* [Webシステム／Webアプリケーションセキュリティ要件書 (Ver.3.1 からの差分表示 PDF版）](https://github.com/OWASP/www-chapter-japan/blob/master/secreq/OWASP_WebApplicationSecurityRequirements_diff.pdf)\r\n\r\n\r\n## 脆弱性診断士スキルマッププロジェクトについて\r\n特定非営利活動法人日本ネットワークセキュリティ協会の日本セキュリティオペレーション事業者協議会のセキュリティオペレーションガイドラインWG（WG1）と、OWASP Japan主催の共同ワーキンググループです。\r\n\r\n## Ver.4.0 執筆メンバー\r\n* 上野 宣 ( ISOG-J WG1リーダー／OWASP Japan Chapter Leader／ 株式会社トライコーダ )\r\n* 国分 裕 ( ISOG-J WG1サブリーダー／三井物産セキュアディレクション株式会社 )\r\n* 池田 雅一 ( テクマトリックス株式会社 )\r\n* 岩間 湧 ( 株式会社セキュアスカイ・テクノロジー )\r\n* 大塚 淳平 ( NRIセキュアテクノロジーズ株式会社 )\r\n* 小河 哲之 ( 三井物産セキュアディレクション株式会社 )\r\n* 洲崎 俊 ( 三井物産セキュアディレクション株式会社 )\r\n* 関根 鉄平 ( 株式会社エーアイセキュリティラボ )\r\n* 野口 睦夫 ( NECソリューションイノベータ株式会社 )\r\n* 廣田 一貴 ( 三井物産セキュアディレクション株式会社 )\r\n* 細野 雄太 （ パーソルテクノロジースタッフ株式会社 )\r\n* 松本 悦宜 ( Capy株式会社 )\r\n* 水戸部 一貴 ( 富士ソフト株式会社 )\r\n* 吉田 聡 ( 株式会社ラック )\r\n\r\n## 改定履歴\r\n株式会社トライコーダ版\r\n* Ver.1.0\t\t初版（2009年3月17日）\r\n* Ver.1.1\t\t2009年4月22日改訂\r\n\r\nOWASP版\r\n* Ver.1.0\t\t初版（2013年11月1日）\r\n* Ver.2.0\t\t2015年10月13日改訂\r\n* Ver.3.0\t\t2019年1月15日改訂\r\n* Ver.3.1\t\t2021年3月改訂\r\n* Ver.4.0 2022年6月改訂\r\n\r\n"
},
{
"path": "skillmap_project/About-Skillmap_and_Syllabus.md",
"content": "# 脆弱性診断士（プラットフォーム）スキルマップ＆シラバスについて\n\n\n## はじめに\n近年、ITシステムのさらなる普及に伴い、様々なシステムに対する攻撃に起因する情報漏えいや経済的損失などの被害が発生していることを受け、システムのリリース前に脆弱性の有無を調査する脆弱性診断を行い、問題点を修正するという脆弱性診断の一連の営みに関する重要性が高まっている。\n脆弱性診断を行うためにはソフトウェアやネットワークなどの基本的な素養にはじまり、各種脆弱性診断ツールの使用手順や最新の技術動向へのキャッチアップなど、多岐に渡るスキルが必要とされる。\nしかし、脆弱性診断に関して保有すべき具体的なスキルマップや、学習の指針となるシラバスが関係者間で統一されていない。そのため、脆弱性診断を行う技術者やサービス事業者の技術力には差違が見られる。一方で、その差違は脆弱性診断サービスを利用する利用者には判りづらく、事業者も可視化することが難しい状況である。\n\n\n特定非営利活動法人 日本ネットワークセキュリティ協会（JNSA）の日本セキュリティオペレーション事業者協議会（ISOG-J）のセキュリティオペレーションガイドラインワーキンググループと、OWASP Japan主催の共同ワーキンググループである 「脆弱性診断士スキルマッププロジェクト （代表 上野宣、以下 本WG）」では、脆弱性診断を行う個人の技術的な能力を具体的にすべく、脆弱性診断を行う技術者（以下、脆弱性診断士）のスキルマップとシラバスを整備している。\n\nスキルマップとシラバスの作成を下記の方針に基づいて行った。\n* 脆弱性診断業務に必要な技術的な能力を対象とする\n* マネージメントスキルやコミュニケーションスキルは対象外とする\n* 脆弱性診断士に必要なスキルを明確化する\n* 特定の脆弱性診断ツールや環境に依存しないようにする\n* 現在必要だと考えられる技術水準を基に作成する\n* 脆弱性診断士が持つべきスキルの指標とするものであり、各社が提供する脆弱性診断サービスの品質については対象外とする\n\n\n## 「脆弱性診断士」について\n脆弱性診断士は、高い倫理を持ち、適切な手法でITシステムの脆弱性診断を行える者であり、脆弱性診断士スキルマップで求める技術や知識を保有している者に対して与えられる呼称である。\n脆弱性診断士の業務に係わる各分野で使用できるようにスキルマップを明確にした。以下のような分野/用途を想定しているがこれに限定するものではない。\n\n* 人事関連分野の用途\n * 採用基準、能力判定、人事評価基準、セキュリティエンジニアの人材育成\n* 開発関連分野の用途\n * リリース前の要件、システムの品質向上\n* 発注関連分野の用途\n * 入札仕様、診断サービス依頼先の選定\n\nこれらを通じて、脆弱性診断士の地位向上、待遇改善、給与向上につながることを目指している。また、脆弱性診断士が魅力ある職業として認知されることにより、セキュリティ事業を志す優秀な人材が増えることを期待しており、就職活動、教育活動を行なう上で基礎を規定する役割の一端を担うことも目指している。\n\n## 「脆弱性診断士」区分\n脆弱性診断の対象によって、脆弱性診断士に必要とされる技術、知識が異なるため、それぞれの対象をいくつかに分け、対象毎に脆弱性診断士を区分することとした。\n\n### 脆弱性診断士(Webアプリケーション)\nWebアプリケーション/Webシステムに対する脆弱性診断を行う者を対象に「脆弱性診断士(Webアプリケーション)」という区分を設ける。\nこの脆弱性診断士の対象者像としては、Webアプリケーション/Webシステムの脆弱性診断を必要とする者、Webアプリケーション/Webシステムの開発者、運用者を想定する。\n\n### 脆弱性診断士(プラットフォーム)\nシステムのプラットフォーム部分に対する脆弱性診断を行う者を対象に「脆弱性診断士(プラットフォーム)」という区分を設ける。\nこの脆弱性診断士の対象者像としては、システムのプラットフォーム部分の脆弱性診断を必要とする者、システムのプラットフォームの構築者、運用者を想定する。\n\n## 「脆弱性診断士」ランク\n脆弱性診断士のランクを定義するにあたっては、脆弱性診断業務に従事する者が全員知っておくべき技能（ Silver ランク）と、単独で診断業務を行うために必要な技能（ Gold ランク）を定義した２つのランクに分けた。\nSilver ランクは Gold ランクの者から指導を受けた上で診断サービスを提供する、もしくは、自社向けに脆弱性診断を実施するための必要スキルとして設定した。\nGold ランクは業務としての脆弱性診断サービスを提供するチームにおいて、最低限1名以上メンバーに加えるべきスキルとして設定した。\n\n### Silver\n* 対象者像\t\n * 自社のシステムのプラットフォーム部分の脆弱性診断（受入れ検査）を行う方\n * 脆弱性診断業務の従事を目指す方（学生など）\n* 業務と役割\n * Goldランクの者の指示の下、脆弱性診断を行う\n * 自社ITシステムの脆弱性診断を行う\n* 期待する技術水準\n * ITシステムを診断する上で（最低限）必要な技術や知識を保有\n\n### Gold\n* 対象者像\n * 自社のシステムのプラットフォーム部分の脆弱性診断（受入れ検査）を行う方\n * 脆弱性診断をサービスとして提供する業務に従事する方\n* 業務と役割\n * 脆弱性診断業務を管理し、診断方針の決定、作業指示の実施、診断結果の精査および評価を行うことができる\n * 脆弱性診断の報告書を作成し、技術的な説明ができる\n* 期待する技術水準\n * 脆弱性診断サービスを提供するのに必要十分な技術や知識を保有\n"
},
{
"path": "skillmap_project/README.md",
"content": "# 脆弱性診断士スキルマッププロジェクト\n[特定非営利活動法人日本ネットワークセキュリティ協会](https://www.jnsa.org/)の[日本セキュリティオペレーション事業者協議会](https://isog-j.org/)のセキュリティオペレーションガイドラインWG（WG1）と、OWASP Japan主催の共同ワーキンググループである 「脆弱性診断士スキルマッププロジェクト （代表 上野宣）」では、脆弱性診断を行う個人の技術的な能力を具体的にすべく、脆弱性診断を行う技術者（以下、脆弱性診断士）のスキルマップと学習の指針となるシラバス、脆弱性診断を行うためのガイドライン、Webアプリケーションを安全に構築するために必要な要件定義書などを整備しています。\n\n本ワーキンググループに関心のある方は Project leader: [Sen UENO](mailto:sen.ueno@owasp.org) まで\n\n## プロジェクトの成果物\n* [脆弱性診断士倫理綱領](https://github.com/OWASP/www-chapter-japan/tree/master/skillmap_project#%E8%84%86%E5%BC%B1%E6%80%A7%E8%A8%BA%E6%96%AD%E5%A3%AB%E5%80%AB%E7%90%86%E7%B6%B1%E9%A0%98)\n* [Webシステム／Webアプリケーションセキュリティ要件書](https://github.com/OWASP/www-chapter-japan/tree/master/secreq)\n* [ペネトレーションテストについて](https://github.com/OWASP/www-chapter-japan/tree/master/skillmap_project#%E3%83%9A%E3%83%8D%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%86%E3%82%B9%E3%83%88%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6)\n* [脆弱性情報開示のためのチートシート](https://github.com/OWASP/www-chapter-japan/tree/master/skillmap_project#%E8%84%86%E5%BC%B1%E6%80%A7%E6%83%85%E5%A0%B1%E9%96%8B%E7%A4%BA%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%83%81%E3%83%BC%E3%83%88%E3%82%B7%E3%83%BC%E3%83%88)\n* [アジャイル開発におけるセキュリティ | パターン・ランゲージ](https://github.com/OWASP/www-chapter-japan/blob/master/skillmap_project/README.md#%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E9%96%8B%E7%99%BA%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3--%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3%E3%83%A9%E3%83%B3%E3%82%B2%E3%83%BC%E3%82%B8)\n* [Webアプリケーション脆弱性診断ガイドライン](https://github.com/OWASP/www-chapter-japan/tree/master/skillmap_project#web%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E8%84%86%E5%BC%B1%E6%80%A7%E8%A8%BA%E6%96%AD%E3%82%AC%E3%82%A4%E3%83%89%E3%83%A9%E3%82%A4%E3%83%B3)\n* [GraphQL 脆弱性診断ガイドライン](https://github.com/WebAppPentestGuidelines/graphQLGuideLine)\n* [細かすぎるけど伝わってほしい脆弱性診断手法ドキュメント](https://webapppentestguidelines.github.io/newtechtestdoc/)\n* [脆弱性トリアージガイドライン作成の手引き](https://github.com/WebAppPentestGuidelines/TriageGuidelines/tree/main)\n* [ASM導入検討を進めるためのガイダンス（基礎編）](https://github.com/OWASP/www-chapter-japan/blob/master/skillmap_project/README.md#asm%E5%B0%8E%E5%85%A5%E6%A4%9C%E8%A8%8E%E3%82%92%E9%80%B2%E3%82%81%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AE%E3%82%AC%E3%82%A4%E3%83%80%E3%83%B3%E3%82%B9%E5%9F%BA%E7%A4%8E%E7%B7%A8)\n* [脆弱性診断士のキャリアデザインガイド](https://wg1.isog-j.org/CareerDesignGuide/)\n* [脆弱性診断士スキルマップ＆シラバス](https://github.com/OWASP/www-chapter-japan/tree/master/skillmap_project#%E8%84%86%E5%BC%B1%E6%80%A7%E8%A8%BA%E6%96%AD%E5%A3%AB%E3%82%B9%E3%82%AD%E3%83%AB%E3%83%9E%E3%83%83%E3%83%97%E3%82%B7%E3%83%A9%E3%83%90%E3%82%B9)\n\n\n---\n# 脆弱性診断士倫理綱領\n[脆弱性診断士スキルマッププロジェクト](https://github.com/OWASP/www-chapter-japan/tree/master/skillmap_project)では「脆弱性診断士倫理綱領」を制定し、脆弱性診断士の行動規範を示すこととしました。\n* [脆弱性診断士倫理綱領](https://wg1.isog-j.org/CodeofEthics/)\n\n---\n# Webシステム／Webアプリケーションセキュリティ要件書\nWebシステム／Webアプリケーションセキュリティ要件書（以下、本ドキュメント）は、安全なWebアプリケーションの開発に必要なセキュリティ要件書です。発注者、開発者、テスト実施者、セキュリティ専門家、消費者が活用することで、以下のことを達成することを目的としています。\n* 開発会社・開発者に安全なWebシステム／Webアプリケーションを開発してもらうこと\n* 開発会社と発注者の瑕疵担保契約の責任分解点を明確にすること\n* 要求仕様やRFP（提案依頼書）として利用し、要件定義書に組み込むことができるセキュリティ要件として活用していただくこと\n\n## 詳細はこちらから\n* [Webシステム／Webアプリケーションセキュリティ要件書](https://github.com/OWASP/www-chapter-japan/tree/master/secreq)\n\n\n---\n# ペネトレーションテストについて\nコンピュータシステムに対して実施するセキュリティテストの1つとして「脆弱性診断」がよく知られています。「脆弱性診断」は本プロジェクトでも紹介しているような脆弱性を発見するためのセキュリティテストの手法です。\n\n一方で最近は「ペネトレーションテスト」を採用する組織や、ペネトレーションテストサービスを提供する事業者（テストベンダー）が増えてきました。\nただ、現状では「ペネトレーションテスト」という名称に共通認識がなく、テストベンダーによっては「脆弱性診断」のことを「ペネトレーションテスト」と呼んでいることもあり、テストを採用する組織が目的に合ったサービスを見分けることが難しくなっています。\n\n本ドキュメントは「ペネトレーションテスト」の位置づけを明確にし、セキュリティテストを活用する組織が実施目的に合うサービスを選択できることを目的としています。\n\n* [ペネトレーションテストについて（2019年12月8日版）](https://github.com/ueno1000/about_PenetrationTest)\n\n---\n# 脆弱性情報開示のためのチートシート\n本ドキュメントは[Vulnerability Disclosure \\- OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html)の日本語訳です。\n\nセキュリティ研究者と組織の両方に**脆弱性の公開プロセスに関するガイダンス**を提供することを目的としています。\n\n* [Vulnerability Disclosure \\- OWASP Cheat Sheet Seriesの日本語訳](https://github.com/OWASP/www-chapter-japan/blob/master/skillmap_project/Vulnerability_Disclosure_Cheat_Sheet_ja.md)\n\n---\n# アジャイル開発におけるセキュリティ | パターン・ランゲージ\n本ドキュメントは『**アジャイル開発においてセキュリティをどのように担保するか**』のヒントを過去の成功事例などを基にパターン・ランゲージを使って解説したものです。\n\nウォーターフォール開発では、要件定義のフェーズではセキュリティ要件があり、それに沿ったセキュアな設計や実装が行われ、脆弱性診断を行ってからリリースされます。しかし、アジャイル開発ではそれらのフェーズが明確でないこともあり、セキュリティを如何に担保するかということが疎かになることもあります。\n本ドキュメントを活用して頂くことで、アジャイル開発のどの段階でどういった取り組みをすることでセキュリティを担保できるかといったヒントを得ることができます。\n\n* [アジャイル開発におけるセキュリティ | パターン・ランゲージ](https://github.com/OWASP/www-chapter-japan/blob/master/skillmap_project/Security%20in%20Agile%20Software%20Development.md)\n* [Security in Agile Development | Pattern Language](https://github.com/OWASP/www-chapter-japan/blob/master/skillmap_project/Security%20in%20Agile%20Software%20Development_EN.md)\n\n---\n# Webアプリケーション脆弱性診断ガイドライン\nWebアプリケーションの脆弱性診断は、自動診断ツールを使った脆弱性診断だけでは十分な診断結果が得られないと本プロジェクトでは考えており、そのため手動診断補助ツールを使った手動診断を併用することが望ましいとしています。しかし、手動診断は脆弱性診断士の経験やスキルによる診断能力の差違があります。そこで本プロジェクトでは、最低限必要な診断項目や手順を定義することで、一定レベルの手動診断による脆弱性診断を行うことができる「Webアプリケーション脆弱性診断ガイドライン」（以下、本ガイドライン）を作成し公開します。\n\n本ガイドラインは「脆弱性診断士」における「脆弱性診断士（Webアプリケーション）」区分における「Silver」ランクで要求される内容としています。\n\n## Webアプリケーション脆弱性診断ガイドライン\n* [第1.2版 (2022年3月1日リリース版)](https://github.com/WebAppPentestGuidelines/WebAppPentestGuidelines/tree/master/WebAppPentestGuidelines)\n\n## GraphQL 脆弱性診断ガイドライン\n特定非営利活動法人日本ネットワークセキュリティ協会の日本セキュリティオペレーション事業者協議会のセキュリティオペレーションガイドラインWG（WG1）「新技術に対する診断手法分科会」によって『GraphQL 脆弱性診断ガイドライン』を公開しました。\n\n* [GraphQL 脆弱性診断ガイドライン（2021年12月24日公開）](https://github.com/WebAppPentestGuidelines/graphQLGuideLine)\n\n## 細かすぎるけど伝わってほしい脆弱性診断手法ドキュメント\n特定非営利活動法人日本ネットワークセキュリティ協会の日本セキュリティオペレーション事業者協議会のセキュリティオペレーションガイドラインWG（WG1）「新技術に対する診断手法分科会」によって『GraphQL 脆弱性診断ガイドライン』を公開しました。\n本ドキュメントは、クロスサイトスクリプティングやSQL Injectionなどの著名な脆弱性をあえてスコープから外し、TOCTOUやクラウドサービスにおける誤った実装・設定不備など、メンバーが思い思いの脆弱性について記載したドキュメントとなります。\n\n* [細かすぎるけど伝わってほしい脆弱性診断手法ドキュメント](https://webapppentestguidelines.github.io/newtechtestdoc/)\n\n---\n# 脆弱性トリアージガイドライン作成の手引き\n本ドキュメントは「**組織が脆弱性に適切に対応することを目的として、脆弱性診断を実施した際に提供された報告書に記載された脆弱性対応の優先順位付け（トリアージ）を行うために、その組織に適したトリアージガイドラインを作成するための手引き**」です。\n\n* [脆弱性トリアージガイドライン作成の手引き](https://github.com/WebAppPentestGuidelines/TriageGuidelines/tree/main)\n\n---\n# ASM導入検討を進めるためのガイダンス（基礎編）\n本ドキュメントは、「ASMを活用したい組織やその担当者が、関連する用語や活用方法を理解し、目的に沿ったサービスを選定することや、既存のドキュメント（様々な組織が作成したドキュメント）を読み解く上で助けとなる情報の提供」を目的としています。本プロジェクトに関して質問や要望、改善すべき点等ございましたら、リンク先GitHubのIssueにてご連絡いただけますと幸いです。\n\n* [ASM導入検討を進めるためのガイダンス（基礎編）](https://webapppentestguidelines.github.io/ASMGuidance/)\n\n---\n# 脆弱性診断士スキルマップ＆シラバス\n\n## 作成方針\nスキルマップとシラバスの作成を下記の方針に基づいて行っています。\n* 脆弱性診断業務に必要な技術的な能力を対象とする\n* マネージメントスキルやコミュニケーションスキルは対象外とする\n* 脆弱性診断士に必要なスキルを明確化する\n* 特定の脆弱性診断ツールや環境に依存しないようにする\n* 現在必要だと考えられる技術水準を基に作成する\n* 脆弱性診断士が持つべきスキルの指標とするものであり、各社が提供する脆弱性診断サービスの品質については対象外とする\n\n## 「脆弱性診断士」ランク\n脆弱性診断士のランクを定義するにあたっては、脆弱性診断業務に従事する者が全員知っておくべき技能（ Silver ランク）と、単独で診断業務を行うために必要な技能（ Gold ランク）を定義した２つのランクに分けています。\n\n### Silver ランク\nGold ランクの者から指導を受けた上で診断サービスを提供する、もしくは、自社向けに脆弱性診断を実施するための必要スキルとして設定しています。\n\n* 対象者像\n * 自社のWebアプリケーション／システムの脆弱性診断（受入れ検査）を行う方\n * 脆弱性診断業務の従事を目指す方（学生など）\n* 業務と役割\n * Goldランクの者の指示の下、脆弱性診断を行う\n * 自社ITシステムの脆弱性診断を行う\n* 期待する技術水準\n * ITシステムを診断する上で（最低限）必要な技術や知識を保有\n\n### Gold ランク\n業務としての脆弱性診断サービスを提供するチームにおいて、最低限1名以上メンバーに加えるべきスキルとして設定しています。\n\n* 対象者像\n * Webアプリケーション／システムの脆弱性診断（受入れ検査）を行う方\n * 脆弱性診断をサービスとして提供する業務に従事する方\n* 業務と役割\n * 脆弱性診断業務を管理し、診断方針の決定、作業指示の実施、診断結果の精査および評価を行うことができる\n * 脆弱性診断の報告書を作成し、技術的な説明ができる\n* 期待する技術水準\n * 脆弱性診断サービスを提供するのに必要十分な技術や知識を保有\n\n# 脆弱性診断士（Webアプリケーション）スキルマップ＆シラバス\nWebアプリケーション/Webシステムに対する脆弱性診断を行う者が対象です。対象者像としては、Webアプリケーション/Webシステムの脆弱性診断を必要とする者、Webアプリケーション/Webシステムの開発者、運用者を想定しています。\n\n## Download\n### Ver.1.2 （2022年3月1日リリース）\n* [スキルマップ＆シラバスについて(PDF)](https://github.com/WebAppPentestGuidelines/WebAppPentestGuidelines/blob/master/Pentester-Web-Skillmap_and_Syllabus/About_Pentester-Web-Skillmap_and_Syllabus.pdf)\n* [スキルマップ＆シラバス(PDF)](https://github.com/WebAppPentestGuidelines/WebAppPentestGuidelines/blob/master/Pentester-Web-Skillmap_and_Syllabus/Pentester-Web-Skillmap_and_Syllabus.pdf)\n\n# 脆弱性診断士（プラットフォーム）スキルマップ＆シラバス\nシステムのプラットフォーム部分に対する脆弱性診断を行う者が対象です。対象者像としては、システムのプラットフォーム部分の脆弱性診断を必要とする者、システムのプラットフォームの構築者、運用者を想定しています。\n\n## Download\n### 2021年5月リリース版\n* [スキルマップ＆シラバス(PDF)](https://github.com/OWASP/www-chapter-japan/blob/master/skillmap_project/Pentester-Platform-Skillmap_and_Syllabus-2021.pdf)\n* [スキルマップ＆シラバス(EXCEL)](https://github.com/OWASP/www-chapter-japan/blob/master/skillmap_project/Pentester-Platform-Skillmap_and_Syllabus-2021.xlsx)\n* [スキルマップ＆シラバスについて](https://github.com/OWASP/www-chapter-japan/blob/master/skillmap_project/About-Skillmap_and_Syllabus.md)\n"
},
{
"path": "skillmap_project/Security in Agile Software Development.md",
"content": "# アジャイル開発におけるセキュリティ | パターン・ランゲージ\n\n# 本ドキュメントについて\n\n本ドキュメントは[脆弱性診断士スキルマッププロジェクト](https://github.com/OWASP/www-chapter-japan/tree/master/skillmap_project)が作成した『**アジャイル開発においてセキュリティをどのように担保するか**』のヒントを過去の成功事例などを基にパターン・ランゲージを使って解説したものです。\n\nウォーターフォール開発では、要件定義のフェーズではセキュリティ要件があり、それに沿ったセキュアな設計や実装が行われ、脆弱性診断を行ってからリリースされます。しかし、アジャイル開発ではそれらのフェーズが明確でないこともあり、セキュリティを如何に担保するかということが疎かになることもあります。\n本ドキュメントを活用して頂くことで、アジャイル開発のどの段階でどういった取り組みをすることでセキュリティを担保できるかといったヒントを得ることができます。\n\n本ドキュメントがアジャイル開発においてセキュリティが担保される一助になればと願います。\n\n\n\n# 目次\n- **チームビルディング**\n1. [セキュリティ・チャンピオンの役割定義と任命](#1-セキュリティ・チャンピオンの役割定義と任命)\n2. [各自がセキュリティに責任を持ったチームビルディング](#2-各自がセキュリティに責任を持ったチームビルディング)\n3. [セキュリティ向上のためのルール整備](#3-セキュリティ向上のためのルール整備)\n4. [セキュリティスキル底上げのための開発者向けトレーニング](#4-セキュリティスキル底上げのための開発者向けトレーニング)\n- **開発計画・プロジェクト計画**\n5. [スプリント成果物に必要なセキュリティ要件の決定](#5-スプリント成果物に必要なセキュリティ要件の決定)\n6. [リスクに応じた脆弱性対応方針の策定](#6-リスクに応じた脆弱性対応方針の策定)\n7. [脆弱性トリアージ](#7-脆弱性トリアージ)\n- **セキュリティテスト**\n8. [セキュリティテストの実施タイミングと方針検討](#8-セキュリティテストの実施タイミングと方針検討)\n9. [スプリント内で実施するテスト内容の策定](#9-スプリント内で実施するテスト内容の策定)\n10. [利用環境の脆弱性管理](#10-利用環境の脆弱性管理)\n11. [セキュリティテストの自動化](#11-セキュリティテストの自動化)\n- **セキュリティ品質向上**\n12. [セキュリティの継続的向上のためのふりかえり](#12-セキュリティの継続的向上のためのふりかえり)\n\n# チームビルディング\n\n## 1. セキュリティ・チャンピオンの役割定義と任命\n\n### 概要\n各プロダクトチームの中にセキュリティ上の問題をチェックし、開発者との橋渡しの役割を担う『セキュリティ・チャンピオン』を置くことで、セキュリティが開発工程の中に組み込まれるDevSecOpsの文化を創ろう\n\n### 状況\n* セキュリティを考慮する文化がない\n* セキュリティのことをメンバーの誰もが気にしていない\n* セキュリティを主体的に考える人が誰もいない\n\n### 解決したい問題\n* 機能優先のみで実装を行うことによる非セキュアなプロダクトがリリースされてしまう\n\n### 解決策\n* プロジェクト立ち上げの際にメンバーの役割を決めるとき、チーム内の開発メンバーの一人にセキュリティ・チャンピオンの役割を担わせる \n * プロダクトオーナーが具体的な役割などを定義し、担当者を任命\n* セキュリティ・チャンピオンはセキュリティの専門家である必要はありませんが、開発チームにおけるセキュリティの担当者として、開発している製品やサービスにおけるセキュリティ上の問題や脅威に対して、中心となってリーダーシップを発揮しながら対処を行わなければなりません。チーム内のリソースで対応できない場合、外部ベンダーなどの利用も検討してください。\n* 具体的な役割の例としては以下が挙げられ、実現可能なチームを編成することが望ましいです。\n * セキュリティレビューの実施\n * 開発物に対する脅威分析の実施\n * 開発におけるセキュリティ要件の定義やコーディング規約などの整備\n * 検出した脆弱性の管理や問題の報告、対策の優先順位付けなど\n * セキュリティテスト・脆弱性スキャンの導入・実施・検証\n * 教育や情報の共有などによって、チーム内のセキュリティ知識の標準化やセキュリティ意識の向上を促進\n * 外部セキュリティベンダーの選定やコントロール\n\n### 参考資料\n* [Security Champions 2.0](https://owasp.org/www-pdf-archive/OWASP_Bucharest_2017_Antukh.pdf)\n* [security-champions-playbook](https://github.com/c0rdis/security-champions-playbook)\n* [「開発者セキュリティチャンピオン」がDevSecOps革命の鍵を握る - リックソフトブログ](https://www.ricksoft.jp/blog/articles/001301.html)\n* [メルカリで「セキュリティチャンピオン」育成プログラムが開始！その内容と“発足した理由”を紹介 | mercan (メルカン)](https://mercan.mercari.com/articles/19140/)\n\n## 2. 各自がセキュリティに責任を持ったチームビルディング\n\n### 概要\n開発する成果物のセキュリティ面での品質に対して各自が責任を持つようにしよう\n\n### 状況\n* セキュリティチャンピオン以外のメンバーがセキュリティのことを気にしていない\n* チームビルディングを実施するときに、自分の担当範囲で責任を持つセキュリティ機能を理解していない\n* セキュリティのことをメンバーの誰もが気にしていない\n\n### 解決したい問題\n* セキュリティ担当者、もしくはセキュリティチャンピオンへの負荷の集中\n\n### 解決策\n\n* セキュリティ教育を実施し、リスクや脆弱性、対策方法に対する理解を深める様にしてください。\n* 開発時に混入したバグに関するケーススタディやコードレビューの結果などについて、チーム内で情報の共有を行いましょう。\n* セキュリティについての議論を各フェーズで実施しましょう。\n * 要件の段階で事前にリスクの洗い出しを行い、成果物に脆弱性が含まれる可能性を最小限にする。\n * 脆弱性検証を実施するタイミングを事前に検討しておく。\n* セキュリティの失敗で個人を責めないようにしましょう。\n * 仲間に対するHRT（Humility：謙虚、Respect：尊敬、信頼：Trust）の精神を大事にしよう。\n\n### 参考資料\n\n* [Team Geek](https://www.oreilly.co.jp/books/9784873116303/)\n\n## 3. セキュリティ向上のためのルール整備\n### 概要\nセキュリティに関して専門家にすべてを任せるのではなく、開発時に気を付けなければならない最低限のポイントについて開発者全員が実施できるルールを話し合って整備しよう\n\n### 状況\n* チーム内でのセキュリティ対策については個人に依存している\n\n### 解決したい問題\n* 開発者によってセキュリティ面での品質が異なる実装が行われる\n\n### 解決策\n* チーム内で話し合い、セキュリティ面での品質を担保するためのルールを整備しましょう。\n * 以下で列挙されているものの中に脆弱性の扱いに関するルールを組み込みましょう。\n * コーディングルール\n * コードレビュー手法\n * 承認フロー\n * デプロイまでのフロー\n * セキュリティテストのルール\n * 脆弱性発見時の対応フロー\n * 脆弱性管理\n * 構成管理\n * 例:\n * 入力値に対してエスケープ処理を実施するなど開発者が開発時に気を付けるポイントをコーディングルールとして組み込む\n * 脆弱性の検出時に、どのタイミングで誰が対応するかなどについて脆弱性発見時の対応フローに組み込む\n\n* 整備したルールはチーム内に周知し、可能であれば見直しの機会などを設けましょう。\n\n## 4. セキュリティスキル底上げのための開発者向けトレーニング\n\n### 概要\nセキュリティに関して専門家にすべてを任せるのではなく、開発時に気を付けなければならない最低限のポイントについてはトレーニングを受けることで開発者全員が理解できるようになろう。\n\n### 状況\n* 開発者によってセキュリティに対する知識にばらつきがある\n* 開発者にセキュリティの知識がない\n\n### 解決したい問題\n* 開発者によってセキュリティ面での品質が異なる実装が行われる\n* セキュリティについて詳しい個人に負荷が集中する\n\n### 解決策\n* 次のようなセキュリティトレーニングを実施しましょう。\n * 同業他社のインシデント事例\n * 発生しやすい脆弱性について\n * セキュアな要件定義、設計、コーディング、テストについて\n * セキュリティテストの種類（SAST,DAST…）\n* 自社でトレーニングを実施できない場合には、外部のコンテンツを利用したり、トレーニングを受講しましょう。\n\n### 参考資料\n* [OWASP Foundation \\| Open Source Foundation for Application Security](https://owasp.org/)\n* [ISOG\\-J 日本セキュリティオペレーション事業者協議会](https://isog-j.org/)\n* [NPO日本ネットワークセキュリティ協会](https://www.jnsa.org/)\n* [IPA 独立行政法人 情報処理推進機構：情報セキュリティ](https://www.ipa.go.jp/security/index.html)\n* [JPCERT コーディネーションセンター](https://www.jpcert.or.jp/)\n\n# 開発計画・プロジェクト計画\n\n## 5. スプリント成果物に必要なセキュリティ要件の決定\n\n### 概要\nスプリント期間内に開発する成果物の完成の定義には、機能要件だけでなく、実装しておかなければいけないセキュリティ要件とそのテスト項目についても含めておこう\n\n### 状況\n\n* セキュリティについての要件が曖昧なままスプリントが始まる\n\n### 解決したい問題\n\n* 十分なテストがされないまま開発が進み、脆弱性診断などで多くの脆弱性が発見され手戻りが多くなる\n* 脆弱性が残ったままの非セキュアなプロダクトがリリースされてしまう\n\n### 解決策\n\n* スプリントプランニングで成果物の完成の定義を検討するとき、[Web システム／Web アプリケーションセキュリティ要件書](https://github.com/OWASP/www-chapter-japan/tree/master/skillmap_project#web%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0web%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E8%A6%81%E4%BB%B6%E6%9B%B8)や[OWASP アプリケーションセキュリティ検証標準 4.0](https://www.saj.or.jp/documents/NEWS/pr/20200903_OWASP_ASVS4.0-ja.pdf)を参考に、成果物が実装しておかなければいけないセキュリティ要件を定義してください。\n* これらは一般的なセキュリティ要件が書かれており、スプリントで開発する対象によっては無関係な項目も含まれていますので、開発対象に応じて必要な項目を選定してください。\n* たとえば、入力値の検証や出力時のエスケープなどは、どのような場合でも必要になるでしょう。認証やセッション管理などは、それらの機能を実装するスプリントの場合にのみ必要になるでしょう。\n* スプリントのセキュリティ要件が決まったら、[Webアプリケーション脆弱性診断ガイドライン](https://github.com/OWASP/www-chapter-japan/tree/master/skillmap_project#web%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E8%84%86%E5%BC%B1%E6%80%A7%E8%A8%BA%E6%96%AD%E3%82%AC%E3%82%A4%E3%83%89%E3%83%A9%E3%82%A4%E3%83%B3)を参考に、それぞれに対応するテスト項目も併せて検討してください。\n\n\n### 参考資料\n\n* [Web システム／Web アプリケーションセキュリティ要件書](https://github.com/OWASP/www-chapter-japan/tree/master/skillmap_project#web%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0web%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E8%A6%81%E4%BB%B6%E6%9B%B8)\n* [OWASP アプリケーションセキュリティ検証標準 4.0](https://www.saj.or.jp/documents/NEWS/pr/20200903_OWASP_ASVS4.0-ja.pdf)\n* [Webアプリケーション脆弱性診断ガイドライン](https://github.com/OWASP/www-chapter-japan/tree/master/skillmap_project#web%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E8%84%86%E5%BC%B1%E6%80%A7%E8%A8%BA%E6%96%AD%E3%82%AC%E3%82%A4%E3%83%89%E3%83%A9%E3%82%A4%E3%83%B3)\n\n## 6. リスクに応じた脆弱性対応方針の策定\n### 概要\nシステムのアーキテクチャや扱う情報、サイバー攻撃のトレンドなどのリスクに応じて脆弱性の対応方針を決めよう\n\n### 状況\n* どの脆弱性に対応するべきか判断できない\n\n### 解決したい問題\n* 重大な脆弱性が残ったままの非セキュアなプロダクトがリリースされてしまう\n\n### 解決策\n* リスクの大きさの判断基準を決めましょう。具体的には次のような基準が挙げられます。\n * CVSSの算出方法でリスクの大きさの判断基準を設定する\n * 脆弱性の危険度（CVSS基本評価値）\n * 攻撃コードが出回っているかどうか（CVSS現状評価値）\n * システムにとって大きな影響がある脅威かどうかで判断する（CVSS環境評価値）\n * WAFなど緩和策が導入され、緩和可能な状態かどうか\n* 判断基準に応じたリスクの対応方針を決めましょう。\n * 例：CVSS7.0以上なら即日対応にする\n * 例：脆弱性の種類で対応方針を決める\n\n## 7. 脆弱性トリアージ\n\n### 概要\n発見した脆弱性をチケット管理し、対応の優先順位を決めよう\n\n### 状況\n* 脆弱性診断を始めたところ、スプリント内で捌ききれないほどの大量の脆弱性が発見される\n\n### 解決したい問題\n* 発見した脆弱性が多く対応しきれない\n* 発見した脆弱性をどれから対応したら良いのかわからない\n* 発見した脆弱性が多すぎて優先度付けできない\n* 発見した脆弱性の内、対処が必要なものの選別ができない\n\n### 解決策\n* 脆弱性のリスクを分析しましょう。\n * 参考：リスクに応じた脆弱性の対応方針を決めよう\n* 脆弱性をチケット管理しましょう。\n* 修正のためのコストを分析しましょう。\n\n### 参考資料\n* [セキュリティ対応組織の教科書（ISOG-J）](https://isog-j.org/output/2016/Textbook_soc-csirt_v1.0.pdf)\n\n# セキュリティテスト\n\n## 8. セキュリティテストの実施タイミングと方針検討\n\n### 概要\nプロジェクトの特性を考慮し、テストの実施タイミングや内容を計画しておき、開発したアプリや機能の安全性を適切に確認できるようにしよう\n\n### 状況\n* プロジェクト内でいつセキュリティテストを実施したら良いのかわからない\n\n### 解決したい問題\n* 適切ではないタイミングでテストを行ってしまい非効率な開発が行われる\n* セキュリティテストの計画が組み込まれていない。あるいは不十分である。\n* リリース前にまとめて実施となった場合にスケジュールに間に合わない\n* セキュリティテストを都度実施しなくていいか判断できない\n\n### 解決策\n* 開発者、テスターと話し合い、セキュリティテストのタイミングや実施するテストの種類、内容の概要を計画として明記します。\n* テストによっては設計・製造に組み込んだり、CI/CDツールで自動実行されるようにするほうが良いものもあれば、リリース直前に実施するほうが望ましいテストもあるため、これらを抽出します。\n* プロジェクト内でのセキュリティテスト戦略の一例\n * 開発前\n * プロダクトのリリースサイクルにあったセキュリティ診断の計画を立てる\n * リリース前の脆弱性診断を外注するかどうかを決める\n\n * スプリント中\n * スプリントの成果物が満たすべきセキュリティ要件通り実装されているか確認\n * DAST等のツールを用いる\n * DASTがカバーできない箇所を手動で診断する\n * リリース前\n * 脆弱性診断士による診断を実施する\n * 運用開始後\n * 環境の既知の脆弱性のスキャンを実施する\n\n## 9. スプリント内で実施するテスト内容の策定\n\n### 概要\nスプリントごとに行うテストを決めることで、セキュリティテストの実施漏れをなくす\n\n### 状況\n* スプリント内でどのようなセキュリティテストを実施したら良いのかわからない\n\n### 解決したい問題\n* 本来必要なセキュリティテストが行われていない\n* 不要なセキュリティテストが行われていてコストがかさんでいる\n\n### 解決策\n* 毎回のスプリントごとに実施するテストを決めましょう。スキャナーを使用するなど自動的に実施されるセキュリティテストを導入しましょう。この段階では、脆弱性をゼロにするのが目的ではなく、低減することが目的です。\n* スプリントで追加・修正した機能に応じて実施するテストを決めましょう。スキャナーがカバーしない認可制御やビジネスロジックのテストは手動で行ってください。脆弱性診断ガイドラインで、スプリントで作成項目に関連したセキュリテイテストの項目を明らかにした上で、スプリント内でどのテストを行うかを考えましょう。\n* モジュール単体で実行できるテストについては、スプリント単位でセキュリティテストが完了していることが理想的です。\n\n### 参考資料\n* https://owasp.org/www-pdf-archive/Owasp_stuttgart_agile_secure_20150803.pdf\n\n## 10. 利用環境の脆弱性管理\n\n### 概要\n自分たちが管理すべき環境（OS、フレームワーク、データベース、アプリケーション、ライブラリなど）に脆弱性がないかを確認し、対応状況を確認しよう\n\n### 状況\n* 現在利用している環境の状態が管理できていない\n* 運用開始後に脆弱性の最新情報の取得と管理が行われていない\n* 脆弱性の最新情報の取得と管理が一元化できていない\n\n### 解決したい問題\n* 既知の脆弱性が残ったままリリースされている\n\n### 解決策\n\n* 情報源を定期チェックしましょう。\n * JVN, JPCERT/CC, IPA、Mitre、各ベンダー\n* 脆弱性スキャナを定期的に利用しましょう。\n * 構成情報を作成、管理する\n * ソフトウェア・コンポジション解析（SCA）\n * Black Duck、Fortify SCA、CodeSentry、CAST Highlight、Contrast OSS、Checkmarx SCA、FlexNet Code Insight、Synk、VeraCode、ASoC\n * 脆弱性スキャナ\n * Vuls、Nessus、yamory、OpenVAS(GVM)\n * コンテナの脆弱性管理\n * Trivy、Tenable.io\n\n## 11. セキュリティテストの自動化\n\n### 概要\nセキュリティテストを効率よく実施するためには自動化ツールの導入が必要となります。開発環境、体制にとって適切な最適な自動化ツールを選択し、効率的に実施しよう\n\n### 状況\n* セキュリティテストに時間が掛かる\n* セキュリティテストをすべて手動で行っている\n* セキュリティテストを効率的に行えていない\n\n### 解決したい問題\n* スプリント内でWebアプリケーションの脆弱性が効率よく見つからない\n* スプリント内で必要なセキュリティテストが終わらない\n* セキュリティテストの品質にばらつきがでる\n\n### 解決策\n* すべての脆弱性がスキャナーで発見できる訳ではありませんが、スキャナーを利用することで一部の脆弱性発見について効率化が図れます。\n* 開発環境、体制、運用方法によって最適な自動化ツールは異なります。以下の観点で適切なツールを決定しましょう。\n * 自分たちの開発工程に組み込みやすいか\n * 脆弱性の誤検出が少ないか\n * 脆弱性のトリアージがしやすいか\n * 診断したい対象を診断できるか\n * 運用しやすいか・使いやすいか\n * 費用対効果に見合うか\n * ツールのサポート体制\n* DAST：脆弱性スキャナを利用しよう\n * オープンソース: OWASP ZAP\n * 商用:Vex(ユービーセキュア社)、AeyeScan(エーアイセキュリティラボ)、AppScan（HCL)\n * スプリント内で追加・修正があった機能に対して実施すると効率が良い\n* SASTを利用しよう\n\n### 参考文献\n* OWASP ZAP:https://www.zaproxy.org/\n* Vex: https://www.ubsecure.jp/vex\n* AeyeScan:https://www.aeyescan.jp/\n* AppScan: https://www.hcljapan.co.jp/software/products/appscan/\n* Burp Enterprise: https://portswigger.net/burp/enterprise\n\n# セキュリティ品質向上\n\n## 12. セキュリティの継続的向上のためのふりかえり\n\n### 概要\n反復的に繰り返される開発の中で、レトロスペクティブなどを活用し、セキュリティを実装するプロセスも見直しを行い、サービス・プロダクトのセキュリティを向上させよう\n\n### 状況\n* スプリントごとに同じような脆弱性が繰り返し作り込まれてしまう\n\n### 解決したい問題\n* セキュリティテストで検出される脆弱性を減らしたい\n* 脆弱性対応にかかるコストが減らない、あるいは増大していく\n* 手戻りの防止\n\n### 解決策\n* スプリントレトロスペクティブを活用し、スプリント内で実施されたセキュリティ実装・セキュリティテストを振り返ります。\n * 開発者が中心となって行い、スクラムマスターは支援します。\n* 例えば以下のテーマで、セキュリティに関係する部分も話し合い、次のスプリント以降で改善すべき項目を抽出し、実行していきます。\n * コーディングルールの見直し\n * テスト方法の見直し\n * メンバーの意識の見直し\n * 脆弱性対処基準の見直し\n * リソース配分の見直し\n"
},
{
"path": "skillmap_project/Security in Agile Software Development_EN.md",
"content": "# Security in Agile Development | Pattern Language\n\n# About this document\nThe [Vulnerability Assessment Skills Map Project](https://github.com/OWASP/www-chapter-japan/tree/master/skillmap_project) has created this document to provide tips on \"**How to Ensure Security in Agile Development**\" using pattern language based on past successes and other examples. \nIn waterfall development, the project defines security requirements during the requirements definition phase, followed by secure design and implementation, and finally, release after vulnerability assessment. In agile development, however, these phases are not always clear and sometimes neglect security. Developers can use this document to get hints on what to do to ensure security at what stage of agile development. We hope this document will help you to ensure security in agile development. \n\n本ドキュメントは[脆弱性診断士スキルマッププロジェクト](https://github.com/OWASP/www-chapter-japan/tree/master/skillmap_project)が作成した『**アジャイル開発においてセキュリティをどのように担保するか**』のヒントを過去の成功事例などを基にパターン・ランゲージを使って解説したものです。\n\nウォーターフォール開発では、要件定義のフェーズではセキュリティ要件があり、それに沿ったセキュアな設計や実装が行われ、脆弱性診断を行ってからリリースされます。しかし、アジャイル開発ではそれらのフェーズが明確でないこともあり、セキュリティを如何に担保するかということが疎かになることもあります。\n本ドキュメントを活用して頂くことで、アジャイル開発のどの段階でどういった取り組みをすることでセキュリティを担保できるかといったヒントを得ることができます。\n本ドキュメントがアジャイル開発においてセキュリティが担保される一助になればと願います。\n\n# Table of Contents\n- **Team Building**\n1. [Role definition and appointment of security champions](#1-Role-definition-and-appointment-of-security-champions)\n2. [Team building with each person responsible for security](#2-Team-building-with-each-person-responsible-for-security)\n3. [Establishment of rules to improve security](#3-Establishment-of-rules-to-improve-security)\n4. [Training for developers to improve their security skills](#4-Training-for-developers-to-improve-their-security-skills)\n- **Development and project planning**\n5. [Determine security requirements for sprint deliverables](#5-Determine-security-requirements-for-sprint-deliverables)\n6. [Develop risk-based vulnerability response policies](#6-Develop-risk-based-vulnerability-response-policies)\n7. [Vulnerability Triage](#7-Vulnerability-Triage)\n- **Security Testing**\n8. [Security testing timing and policy considerations](#8-Security-testing-timing-and-policy-considerations)\n9. [Formulation of test content to be conducted within the sprint](#9-Formulation-of-test-content-to-be-conducted-within-the-sprint)\n10. [Vulnerability management for your environment](#10-Vulnerability-management-for-your-environment)\n11. [Automated security testing](#11-Automated-security-testing)\n- **Security Quality Improvement**\n12. [Reflection on Continuous Improvement of Security](#12-Reflection-on-Continuous-Improvement-of-Security)\n\n- **チームビルディング**\n1. セキュリティ・チャンピオンの役割定義と任命\n2. 各自がセキュリティに責任を持ったチームビルディング\n3. セキュリティ向上のためのルール整備\n4. セキュリティスキル底上げのための開発者向けトレーニング\n- **開発計画・プロジェクト計画**\n5. スプリント成果物に必要なセキュリティ要件の決定\n6. リスクに応じた脆弱性対応方針の策定\n7. 脆弱性トリアージ\n- **セキュリティテスト**\n8. セキュリティテストの実施タイミングと方針検討\n9. スプリント内で実施するテスト内容の策定\n10. 利用環境の脆弱性管理\n11. セキュリティテストの自動化\n- **セキュリティ品質向上**\n12. セキュリティの継続的向上のためのふりかえり\n\n# Team Building\n## 1. Role definition and appointment of security champions\n\n### Summary\nCreate a DevSecOps culture where security is integrated into the development process by having a \"Security Champion\" on each product team who checks for security issues and acts as a bridge to developers.\n\n各プロダクトチームの中にセキュリティ上の問題をチェックし、開発者との橋渡しの役割を担う『セキュリティ・チャンピオン』を置くことで、セキュリティが開発工程の中に組み込まれるDevSecOpsの文化を創ろう\n\n### Situation\n* No culture of security considerations\n* None of the members care about security\n* No one proactively thinks about security\n\n* セキュリティを考慮する文化がない\n* セキュリティのことをメンバーの誰もが気にしていない\n* セキュリティを主体的に考える人が誰もいない\n\n### Problem to be solved\n* Prioritizing implementation over functionality only results in the release of an insecure product.\n\n* 機能優先のみで実装を行うことによる非セキュアなプロダクトがリリースされてしまう\n\n### Solution\n* When determining member roles at project launch, identify one of the development members on the team as the security champion. \n * The product owner defines specific roles, etc., and appoints the person in charge.\n* The Security Champion does not need to be a security expert, but as the person in charge of security on the development team.\n * The Security Champion must take a central leadership role in addressing security issues and threats in the product or service being developed. \n * The Champion must be able to take the lead in addressing security issues and threats to the products and services being developed. \n * If the team's internal resources are not available to address the issue, consider using an outside vendor or other resources.\n* Examples of specific roles are listed below. It is advisable to assemble a team that can.\n * Conducting security reviews\n * Conducting threat analysis on developments\n * Defining security requirements and coding conventions for development\n * Managing vulnerabilities detected, reporting problems, prioritizing countermeasures, etc.\n * Implementing, conducting, and verifying security testing and vulnerability scanning\n * Promoting standardization of security knowledge and security awareness within the team through education and information sharing\n * Selecting and controlling external security vendors\n\n* プロジェクト立ち上げの際にメンバーの役割を決めるとき、チーム内の開発メンバーの一人にセキュリティ・チャンピオンの役割を担わせる \n * プロダクトオーナーが具体的な役割などを定義し、担当者を任命\n* セキュリティ・チャンピオンはセキュリティの専門家である必要はありませんが、開発チームにおけるセキュリティの担当者として、開発している製品やサービスにおけるセキュリティ上の問題や脅威に対して、中心となってリーダーシップを発揮しながら対処を行わなければなりません。チーム内のリソースで対応できない場合、外部ベンダーなどの利用も検討してください。\n* 具体的な役割の例としては以下が挙げられ、実現可能なチームを編成することが望ましいです。\n * セキュリティレビューの実施\n * 開発物に対する脅威分析の実施\n * 開発におけるセキュリティ要件の定義やコーディング規約などの整備\n * 検出した脆弱性の管理や問題の報告、対策の優先順位付けなど\n * セキュリティテスト・脆弱性スキャンの導入・実施・検証\n * 教育や情報の共有などによって、チーム内のセキュリティ知識の標準化やセキュリティ意識の向上を促進\n * 外部セキュリティベンダーの選定やコントロール\n\n### Reference Materials\n* [Security Champions 2.0](https://owasp.org/www-pdf-archive/OWASP_Bucharest_2017_Antukh.pdf)\n* [security-champions-playbook](https://github.com/c0rdis/security-champions-playbook)\n* [「開発者セキュリティチャンピオン」がDevSecOps革命の鍵を握る - リックソフトブログ](https://www.ricksoft.jp/blog/articles/001301.html)\n* [Mercari’s Security Champion Program: Gamifying Security Education for a Safe and Secure Service | Mercan ](https://mercan.mercari.com/en/articles/19140/)\n\n## 2. Team building with each person responsible for security\n\n### Summary\nMake each person responsible for the security quality of the deliverables they develop.\n\n開発する成果物のセキュリティ面での品質に対して各自が責任を持つようにしよう\n\n### Situation\n* Members of the team other than the security champion do not care about security\n* Members do not understand the security functions for which they are responsible in their area of responsibility when conducting team building\n* None of the members care about security\n\n* セキュリティチャンピオン以外のメンバーがセキュリティのことを気にしていない\n* チームビルディングを実施するときに、自分の担当範囲で責任を持つセキュリティ機能を理解していない\n* セキュリティのことをメンバーの誰もが気にしていない\n\n### Problem to be solved\n* Concentrates the load on security personnel or security champions\n\n* セキュリティ担当者、もしくはセキュリティチャンピオンへの負荷の集中\n\n### Solution \n* Conduct security training to deepen understanding of risks, vulnerabilities, and countermeasures.\n* Share information with your teams, such as case studies of bugs introduced during development and the results of code reviews.\n* Discuss security at each phase of the project.\n * Identify risks during the requirements phase to minimize the possibility of the team creating vulnerabilities.\n * Consider in advance when to conduct vulnerability validation.\n* Avoid blaming individuals for security failures.\n * Value the spirit of HRT (Humility: Humility, Respect: Respect, Trust: Trust) toward your peers.\n\n* セキュリティ教育を実施し、リスクや脆弱性、対策方法に対する理解を深める様にしてください。\n* 開発時に混入したバグに関するケーススタディやコードレビューの結果などについて、チーム内で情報の共有を行いましょう。\n* セキュリティについての議論を各フェーズで実施しましょう。\n * 要件の段階で事前にリスクの洗い出しを行い、成果物に脆弱性が含まれる可能性を最小限にする。\n * 脆弱性検証を実施するタイミングを事前に検討しておく。\n* セキュリティの失敗で個人を責めないようにしましょう。\n * 仲間に対するHRT（Humility：謙虚、Respect：尊敬、信頼：Trust）の精神を大事にしよう。\n\n### Reference Materials\n* [Team Geek](https://www.oreilly.co.jp/books/9784873116303/)\n\n## 3. Establishment of rules to improve security\n\n### Summary\nInstead of leaving everything to the experts regarding security, let's discuss and develop rules that all developers can implement on the minimum points that need to be taken care of during development.\n\nセキュリティに関して専門家にすべてを任せるのではなく、開発時に気を付けなければならない最低限のポイントについて開発者全員が実施できるルールを話し合って整備しよう\n\n### Situation\n* Rely on individuals for security measures within the team\n\n* チーム内でのセキュリティ対策については個人に依存している\n\n### Problem to be solved\n* Different developers implement different security qualities.\n\n* 開発者によってセキュリティ面での品質が異なる実装が行われる\n\n### Solution\n* Discuss within your team and develop rules to ensure quality in terms of security.\n * Incorporate rules for handling vulnerabilities among those listed below.\n * Coding rules\n * Code review methodology\n * Approval flow\n * Deployment flow\n * Security testing rules\n * Response flow when vulnerabilities are discovered\n * Vulnerability management\n * Configuration management\n * Example:\n * Coding rules that developers should be aware of during development, such as escape processing for input values\n Incorporate into the vulnerability discovery response flow: * When vulnerabilities are detected, when and who responds to them, etc.\n\n* Make the rules known to the team and provide opportunities to review them if possible.\n\n* チーム内で話し合い、セキュリティ面での品質を担保するためのルールを整備しましょう。\n * 以下で列挙されているものの中に脆弱性の扱いに関するルールを組み込みましょう。\n * コーディングルール\n * コードレビュー手法\n * 承認フロー\n * デプロイまでのフロー\n * セキュリティテストのルール\n * 脆弱性発見時の対応フロー\n * 脆弱性管理\n * 構成管理\n * 例:\n * 入力値に対してエスケープ処理を実施するなど開発者が開発時に気を付けるポイントをコーディングルールとして組み込む\n * 脆弱性の検出時に、どのタイミングで誰が対応するかなどについて脆弱性発見時の対応フローに組み込む\n\n* 整備したルールはチーム内に周知し、可能であれば見直しの機会などを設けましょう。\n\n## 4. Training for developers to improve their security skills\n\n### Summary\nInstead of leaving everything to the experts regarding security, let's ensure that all developers understand the minimum points they need to be aware of during development through training.\n\nセキュリティに関して専門家にすべてを任せるのではなく、開発時に気を付けなければならない最低限のポイントについてはトレーニングを受けることで開発者全員が理解できるようになろう。\n\n### Situation\n* Developers have varying knowledge of security\n* Developers lack security knowledge\n\n* 開発者によってセキュリティに対する知識にばらつきがある\n* 開発者にセキュリティの知識がない\n\n### Problem to be solved\n* Different developers implement security qualities in different ways\n* Burden is concentrated on individuals who are knowledgeable about security\n\n* 開発者によってセキュリティ面での品質が異なる実装が行われる\n* セキュリティについて詳しい個人に負荷が集中する\n\n### Solution\n* Conduct security training that includes the following\n * Incident examples from other companies in your industry\n * Vulnerabilities that are likely to occur\n * About secure requirements definition, design, coding, and testing\n * Types of security testing (SAST, DAST...)\n* If you cannot conduct training in-house, use external content or attend training.\n\n* 次のようなセキュリティトレーニングを実施しましょう。\n * 同業他社のインシデント事例\n * 発生しやすい脆弱性について\n * セキュアな要件定義、設計、コーディング、テストについて\n * セキュリティテストの種類（SAST,DAST…）\n* 自社でトレーニングを実施できない場合には、外部のコンテンツを利用したり、トレーニングを受講しましょう。\n\n### Reference Materials\n* [OWASP Foundation \\| Open Source Foundation for Application Security](https://owasp.org/)\n* [ISOG\\-J Information Security Operation providers Group Japan](https://isog-j.org/e/index.html)\n* [Japan Network Security Association](https://www.jnsa.org/en/aboutus/)\n* [INFORMATION-TECHNOLOGY PROMOTION AGENCY, JAPAN](https://www.ipa.go.jp/index-e.html)\n* [JPCERT Coordination Center](https://www.jpcert.or.jp/english/)\n\n# Development and project planning\n\n## 5. Determine security requirements for sprint deliverables\n\n### Summary\nThe definition of the completion of the deliverables to be developed within the sprint period should include not only the functional requirements but also the security requirements that teams must implement and their test items!\n\nスプリント期間内に開発する成果物の完成の定義には、機能要件だけでなく、実装しておかなければいけないセキュリティ要件とそのテスト項目についても含めておこう\n\n### Situation\n* Sprints begin with unclear requirements for security\n\n* セキュリティについての要件が曖昧なままスプリントが始まる\n\n### Problem to be solved\n* Development proceeds without sufficient testing, and vulnerabilities are often discovered during vulnerability assessments, resulting in a lot of rework.\n* Insecure products with remaining vulnerabilities are released.\n\n* 十分なテストがされないまま開発が進み、脆弱性診断などで多くの脆弱性が発見され手戻りが多くなる\n* 脆弱性が残ったままの非セキュアなプロダクトがリリースされてしまう\n\n### Solution\n* When defining deliverable completion in sprint planning, specify the security requirements that the deliverables must implement. The following documents are helpful.\n * [Web システム／Web アプリケーションセキュリティ要件書](https://github.com/OWASP/www-chapter-japan/tree/master/skillmap_project#web%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0web%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E8%A6%81%E4%BB%B6%E6%9B%B8)\n * [OWASP Application Security Verification Standard](https://github.com/OWASP/ASVS/tree/v4.0.3)\n* These are written general security requirements and include items that may be irrelevant depending on the subject your team is developing in a sprint, so please select the things you need based on the issue you are creating.\n* For example, input value validation and output escaping will be necessary in any case. Authentication and session management, for example, will be required only for sprints that implement those functions.\n* Once you have determined the security requirements for your sprint, please also consider the corresponding test items. The following documents may be helpful.\n * [Webアプリケーション脆弱性診断ガイドライン](https://github.com/OWASP/www-chapter-japan/tree/master/skillmap_project#web%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E8%84%86%E5%BC%B1%E6%80%A7%E8%A8%BA%E6%96%AD%E3%82%AC%E3%82%A4%E3%83%89%E3%83%A9%E3%82%A4%E3%83%B3)\n\n* スプリントプランニングで成果物の完成の定義を検討するとき、[Web システム／Web アプリケーションセキュリティ要件書](https://github.com/OWASP/www-chapter-japan/tree/master/skillmap_project#web%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0web%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E8%A6%81%E4%BB%B6%E6%9B%B8)や[OWASP アプリケーションセキュリティ検証標準 4.0](https://www.saj.or.jp/documents/NEWS/pr/20200903_OWASP_ASVS4.0-ja.pdf)を参考に、成果物が実装しておかなければいけないセキュリティ要件を定義してください。\n* これらは一般的なセキュリティ要件が書かれており、スプリントで開発する対象によっては無関係な項目も含まれていますので、開発対象に応じて必要な項目を選定してください。\n* たとえば、入力値の検証や出力時のエスケープなどは、どのような場合でも必要になるでしょう。認証やセッション管理などは、それらの機能を実装するスプリントの場合にのみ必要になるでしょう。\n* スプリントのセキュリティ要件が決まったら、[Webアプリケーション脆弱性診断ガイドライン](https://github.com/OWASP/www-chapter-japan/tree/master/skillmap_project#web%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E8%84%86%E5%BC%B1%E6%80%A7%E8%A8%BA%E6%96%AD%E3%82%AC%E3%82%A4%E3%83%89%E3%83%A9%E3%82%A4%E3%83%B3)を参考に、それぞれに対応するテスト項目も併せて検討してください。\n\n### Reference Materials\n\n* [Web システム／Web アプリケーションセキュリティ要件書](https://github.com/OWASP/www-chapter-japan/tree/master/skillmap_project#web%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0web%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E8%A6%81%E4%BB%B6%E6%9B%B8)\n* [OWASP アプリケーションセキュリティ検証標準 4.0](https://www.saj.or.jp/documents/NEWS/pr/20200903_OWASP_ASVS4.0-ja.pdf)\n* [Webアプリケーション脆弱性診断ガイドライン](https://github.com/OWASP/www-chapter-japan/tree/master/skillmap_project#web%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E8%84%86%E5%BC%B1%E6%80%A7%E8%A8%BA%E6%96%AD%E3%82%AC%E3%82%A4%E3%83%89%E3%83%A9%E3%82%A4%E3%83%B3)\n\n## 6. Develop risk-based vulnerability response policies\n\n### Summary\nLet's decide on a vulnerability response policy based on the system architecture, information handled, cyber-attack trends, and other risks.\n\nシステムのアーキテクチャや扱う情報、サイバー攻撃のトレンドなどのリスクに応じて脆弱性の対応方針を決めよう\n\n### Situation\n* Unable to determine which vulnerabilities to address\n\n* どの脆弱性に対応するべきか判断できない\n\n### Problem to be solved\n* Non-secure products are released with critical vulnerabilities remaining.\n\n* 重大な脆弱性が残ったままの非セキュアなプロダクトがリリースされてしまう\n\n### Solution\n* Determine the criteria for determining the magnitude of the risk. Specifically, the following criteria are listed.\n * Set the criteria for judging the magnitude of risk using the CVSS calculation method.\n * Vulnerability risk (CVSS Base Metrics)\n * Whether the attack code is circulating or not (CVSS Temporal Metrics)\n * Whether the threat has a significant impact on the system or not (CVSS Environmental Metrics)\n * Whether countermeasures such as WAF are in place and can mitigate\n* Decide on a risk response policy according to the judging criteria.\n * ex. If the vulnerability risk is CVSS 7.0 or higher, make it an immediate response.\n * ex. Decide on a response policy based on the type of vulnerability.\n\n* リスクの大きさの判断基準を決めましょう。具体的には次のような基準が挙げられます。\n * CVSSの算出方法でリスクの大きさの判断基準を設定する\n * 脆弱性の危険度（CVSS基本評価値）\n * 攻撃コードが出回っているかどうか（CVSS現状評価値）\n * システムにとって大きな影響がある脅威かどうかで判断する（CVSS環境評価値）\n * WAFなど緩和策が導入され、緩和可能な状態かどうか\n* 判断基準に応じたリスクの対応方針を決めましょう。\n * 例：CVSS7.0以上なら即日対応にする\n * 例：脆弱性の種類で対応方針を決める\n\n## 7. Vulnerability Triage\n\n### Summary\nLet's manage tickets for discovered vulnerabilities and prioritize responses\n\n発見した脆弱性をチケット管理し、対応の優先順位を決めよう\n\n### Situation\n* When we started vulnerability assessment, we found a large number of vulnerabilities that we could not handle within the sprint.\n\n* 脆弱性診断を始めたところ、スプリント内で捌ききれないほどの大量の脆弱性が発見される\n\n### Problem to be solved\n* Too many vulnerabilities found to address\n* Not sure which vulnerabilities to address first\n* Unable to prioritize vulnerabilities found\n* Unable to sort out vulnerabilities that we need to address\n\n* 発見した脆弱性が多く対応しきれない\n* 発見した脆弱性をどれから対応したら良いのかわからない\n* 発見した脆弱性が多すぎて優先度付けできない\n* 発見した脆弱性の内、対処が必要なものの選別ができない\n\n### Solution\n* Analyze the risk of vulnerabilities.\n * Reference: Decide on a risk-based vulnerability response policy.\n* Manage tickets for vulnerabilities.\n* Analyze the cost of fixing it.\n\n* 脆弱性のリスクを分析しましょう。\n * 参考：リスクに応じた脆弱性の対応方針を決めよう\n* 脆弱性をチケット管理しましょう。\n* 修正のためのコストを分析しましょう。\n\n### Reference Materials\n* [セキュリティ対応組織の教科書（ISOG-J）](https://isog-j.org/output/2016/Textbook_soc-csirt_v1.0.pdf)\n\n# Security Testing\n\n## 8. Security testing timing and policy considerations\n\n### Summary\nConsidering the characteristics of the project, let's plan the timing and content of testing so that we can adequately check the safety of the developed apps and functions!\n\nプロジェクトの特性を考慮し、テストの実施タイミングや内容を計画しておき、開発したアプリや機能の安全性を適切に確認できるようにしよう\n\n### Situation\n* Not knowing when to conduct security testing within a project\n\n* プロジェクト内でいつセキュリティテストを実施したら良いのかわからない\n\n### Problem to be solved\n* Inefficient development due to testing at inappropriate times.\n* Security testing plans are not built-in or are inadequate. \n* Failure to meet the schedule when we perform security testing in batches before release.\n* Unable to determine if we need to perform security tests case by case.\n\n* 適切ではないタイミングでテストを行ってしまい非効率な開発が行われる\n* セキュリティテストの計画が組み込まれていない。あるいは不十分である。\n* リリース前にまとめて実施となった場合にスケジュールに間に合わない\n* セキュリティテストを都度実施しなくていいか判断できない\n\n### Solution\n* Discuss with developers and testers and specify a security testing plan. The plan should include a schedule and outline the types and content of tests.\n* Some tests may be better integrated into design and production or run automatically by CI/CD tools, while others may perform better just before release.\n* Here is an example of a security testing strategy within a project.\n * Pre-development\n * Planning security diagnostics that fit the release cycle of the product\n * Decide whether to outsource pre-release vulnerability testing\n * During a sprint\n * Ensure that we implement the sprint deliverables as per the security requirements.\n * Use tools such as DAST\n * Manually diagnose areas not covered by DAST\n * Before release\n * Perform vulnerability assessment by a vulnerability assessor\n * After the start of operation\n * Scan for known vulnerabilities in the environment\n\n* 開発者、テスターと話し合い、セキュリティテストのタイミングや実施するテストの種類、内容の概要を計画として明記します。\n* テストによっては設計・製造に組み込んだり、CI/CDツールで自動実行されるようにするほうが良いものもあれば、リリース直前に実施するほうが望ましいテストもあるため、これらを抽出します。\n* プロジェクト内でのセキュリティテスト戦略の一例\n * 開発前\n * プロダクトのリリースサイクルにあったセキュリティ診断の計画を立てる\n * リリース前の脆弱性診断を外注するかどうかを決める\n\n * スプリント中\n * スプリントの成果物が満たすべきセキュリティ要件通り実装されているか確認\n * DAST等のツールを用いる\n * DASTがカバーできない箇所を手動で診断する\n * リリース前\n * 脆弱性診断士による診断を実施する\n * 運用開始後\n * 環境の既知の脆弱性のスキャンを実施する\n\n## 9. Formulation of test content to be conducted within the sprint\n\n### Summary\nLet's eliminate omissions from security testing by deciding which tests to perform for each sprint!\n\nスプリントごとに行うテストを決めることで、セキュリティテストの実施漏れをなくす\n\n### Situation\n* Not sure what security tests to run within a sprint\n\n* スプリント内でどのようなセキュリティテストを実施したら良いのかわからない\n\n### Problem to be solved\n* Necessary security tests are not being performed.\n* Unnecessary security tests are being performed, resulting in high costs.\n\n* 本来必要なセキュリティテストが行われていない\n* 不要なセキュリティテストが行われていてコストがかさんでいる\n\n### Solution\n* Decide on a test to be performed for each sprint. Implement security tests that are performed automatically, such as using a scanner. The goal at this stage is not to reduce vulnerabilities to zero but to reduce them.\n* Decide which tests to perform depending on the functionality you have added or modified in each sprint. Test authorization controls and business logic are not covered by the scanner manually. After identifying the security test items related to the objects created in the sprint, consider which we performed in the sprint.\n* Ideally, security testing should be completed on a per-sprint basis for tests we can run on modules alone.\n\n* 毎回のスプリントごとに実施するテストを決めましょう。スキャナーを使用するなど自動的に実施されるセキュリティテストを導入しましょう。この段階では、脆弱性をゼロにするのが目的ではなく、低減することが目的です。\n* スプリントで追加・修正した機能に応じて実施するテストを決めましょう。スキャナーがカバーしない認可制御やビジネスロジックのテストは手動で行ってください。脆弱性診断ガイドラインで、スプリントで作成項目に関連したセキュリテイテストの項目を明らかにした上で、スプリント内でどのテストを行うかを考えましょう。\n* モジュール単体で実行できるテストについては、スプリント単位でセキュリティテストが完了していることが理想的です。\n\n### Reference Materials\n* https://owasp.org/www-pdf-archive/Owasp_stuttgart_agile_secure_20150803.pdf\n\n## 10. Vulnerability management for your environment\n\n### Summary\nLet's check our environment (OS, frameworks, databases, applications, libraries, etc.) for vulnerabilities that we should manage and check the status of our response!\n\n自分たちが管理すべき環境（OS、フレームワーク、データベース、アプリケーション、ライブラリなど）に脆弱性がないかを確認し、対応状況を確認しよう\n\n### Situation\n* The state of the environment currently in use is not being managed\n* No acquisition and management of the latest information on vulnerabilities after the start of operation\n* Not centrally managed and kept up-to-date on vulnerabilities\n\n* 現在利用している環境の状態が管理できていない\n* 運用開始後に脆弱性の最新情報の取得と管理が行われていない\n* 脆弱性の最新情報の取得と管理が一元化できていない\n\n### Problem to be solved\n* Known vulnerabilities remain in the release.\n\n* 既知の脆弱性が残ったままリリースされている\n\n### Solution\n* Check information sources regularly.\n * JVN, JPCERT/CC, IPA, Mitre, various vendors\n* Use vulnerability scanners regularly.\n * Create and maintain configuration information.\n * Software Composition Analysis (SCA)\n * Black Duck, Fortify SCA, CodeSentry, CAST Highlight, Contrast OSS, Checkmarx SCA, FlexNet Code Insight, Synk, VeraCode, ASoC\n * Vulnerability Scanners\n * Vuls, Nessus, yamory, OpenVAS (GVM)\n * Container vulnerability management\n * Trivy, Tenable.io\n\n* 情報源を定期チェックしましょう。\n * JVN, JPCERT/CC, IPA、Mitre、各ベンダー\n* 脆弱性スキャナを定期的に利用しましょう。\n * 構成情報を作成、管理する\n * ソフトウェア・コンポジション解析（SCA）\n * Black Duck、Fortify SCA、CodeSentry、CAST Highlight、Contrast OSS、Checkmarx SCA、FlexNet Code Insight、Synk、VeraCode、ASoC\n * 脆弱性スキャナ\n * Vuls、Nessus、yamory、OpenVAS(GVM)\n * コンテナの脆弱性管理\n * Trivy、Tenable.io\n\n## 11. Automated security testing\n\n### Summary\nIt is necessary to introduce automation tools for executing security testing efficiently. Let's select the best automation tool appropriate for your development environment and system and implement it efficiently!\n\nセキュリティテストを効率よく実施するためには自動化ツールの導入が必要となります。開発環境、体制にとって適切な最適な自動化ツールを選択し、効率的に実施しよう\n\n### Situation\n* Security testing is time-consuming\n* All security testing is done manually\n* Security testing is not done efficiently\n\n* セキュリティテストに時間が掛かる\n* セキュリティテストをすべて手動で行っている\n* セキュリティテストを効率的に行えていない\n\n### Problem to be solved\n* Web application vulnerabilities are not found efficiently within a sprint\n* Required security tests are not completed within a sprint\n* Security testing quality is inconsistent\n\n* スプリント内でWebアプリケーションの脆弱性が効率よく見つからない\n* スプリント内で必要なセキュリティテストが終わらない\n* セキュリティテストの品質にばらつきがでる\n\n### Solution\n* Scanners can find not all vulnerabilities, but scanners can improve efficiency in finding some vulnerabilities.\n* The best automation tool depends on the development environment, system, and operation method. The following considerations should be taken into account when determining the appropriate tool.\n * Is it easy to integrate into your development process?\n * Fewer false positives in vulnerability detection.\n * Ease of triage of vulnerabilities\n * Can it diagnose the target you want to diagnose?\n * Is it easy to operate and use?\n * Is it cost-effective?\n * Support system of the tool\n* DAST: Use a vulnerability scanner\n * Open source: OWASP ZAP\n * Commercial: Vex (UBsecure), AeyeScan (Aeye Security Lab), AppScan（HCL)\n * Efficient if performed on functions that were added or modified during the sprint\n* Let's use SAST.\n\n* すべての脆弱性がスキャナーで発見できる訳ではありませんが、スキャナーを利用することで一部の脆弱性発見について効率化が図れます。\n* 開発環境、体制、運用方法によって最適な自動化ツールは異なります。以下の観点で適切なツールを決定しましょう。\n * 自分たちの開発工程に組み込みやすいか\n * 脆弱性の誤検出が少ないか\n * 脆弱性のトリアージがしやすいか\n * 診断したい対象を診断できるか\n * 運用しやすいか・使いやすいか\n * 費用対効果に見合うか\n * ツールのサポート体制\n* DAST：脆弱性スキャナを利用しよう\n * オープンソース: OWASP ZAP\n * 商用:Vex(ユービーセキュア社)、AeyeScan(エーアイセキュリティラボ)、AppScan（HCL)\n * スプリント内で追加・修正があった機能に対して実施すると効率が良い\n* SASTを利用しよう\n\n### Reference Materials\n* [OWASP ZAP](https://www.zaproxy.org/)\n* [Vex](https://www.ubsecure.jp/vex)\n* [AeyeScan](https://www.aeyescan.jp/)\n* [AppScan](https://www.hcljapan.co.jp/software/products/appscan/)\n* [Burp Enterprise](https://portswigger.net/burp/enterprise)\n\n# Security Quality Improvement\n\n## 12. Reflection on Continuous Improvement of Security\n\n### Summary\nIn the iterative development process, let's also review the process of implementing security using retrospectives to improve the security of services and products!\n\n反復的に繰り返される開発の中で、レトロスペクティブなどを活用し、セキュリティを実装するプロセスも見直しを行い、サービス・プロダクトのセキュリティを向上させよう\n\n### Situation\n* The same vulnerabilities are repeatedly created in each sprint.\n\n* スプリントごとに同じような脆弱性が繰り返し作り込まれてしまう\n\n### Problem to be solved\n* Want to reduce the number of vulnerabilities detected by security tests\n* Cost of vulnerability response not decreasing or increasing\n* Prevent rework\n\n* セキュリティテストで検出される脆弱性を減らしたい\n* 脆弱性対応にかかるコストが減らない、あるいは増大していく\n* 手戻りの防止\n\n### Solution\n* Utilizing the Sprint Retrospective, review the security implementation and security tests conducted during the sprint.\n * The developers will take the lead, and the Scrum Master will assist.\n* The team will also discuss security-related aspects and identify and implement items to be improved in the next sprint and beyond. Here is an example.\n * Review of coding rules\n * Review of testing methods\n * Review of member awareness\n * Review of vulnerability handling criteria\n * Review of resource allocation\n\n* スプリントレトロスペクティブを活用し、スプリント内で実施されたセキュリティ実装・セキュリティテストを振り返ります。\n * 開発者が中心となって行い、スクラムマスターは支援します。\n* 例えば以下のテーマで、セキュリティに関係する部分も話し合い、次のスプリント以降で改善すべき項目を抽出し、実行していきます。\n * コーディングルールの見直し\n * テスト方法の見直し\n * メンバーの意識の見直し\n * 脆弱性対処基準の見直し\n * リソース配分の見直し\n\n"
},
{
"path": "skillmap_project/Vulnerability_Disclosure_Cheat_Sheet_ja.md",
"content": "このドキュメントは[Vulnerability Disclosure \\- OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html)の日本語訳です。\n\n脆弱性情報開示のためのチートシート\n===============\n\nはじめに\n----\n\nこのチートシートは、セキュリティ研究者と組織の両方に、脆弱性の公開プロセスに関するガイダンスを提供することを目的としています。これは、共同作業が非常に重要な分野ですが、両者の間に対立が生じることもよくあります。\n\n**研究者は**\n\n* すべてのテストが合法的で認可されていることを確認すること\n* 他人のプライバシーを尊重すること\n* 組織のセキュリティチームに連絡するための合理的な努力をすること\n* 脆弱性を検証・再現できるように、十分な詳細情報を提供すること\n* 確立されたバグバウンティプログラム以外で、脆弱性の報告に対して支払いや報酬を要求しないこと\n\n**組織は**\n\n* 研究者が脆弱性を安全に報告するための明確な方法を提供すること\n* バグバウンティプログラムの範囲と条件を明確に設定すること\n* 合理的な時間軸で報告に対応すること\n* 研究者とオープンにコミュニケーションをとること\n* 研究者に対して法的措置をとるようなことはしないこと\n* 必要に応じてCVE-IDの取得を要求すること\n* 明確なセキュリティアドバイザリと変更履歴を公開すること\n* 報酬やクレジット表記を提示すること\n\nディスクロージャー（情報開示）の方法\n------------\n\n脆弱性を開示する際には、いくつかの異なるモデルがあり、以下のセクションで紹介します。\n\n### プライベート・ディスクロージャー\n\nプライベート・ディスクロージャー・モデルでは、脆弱性は非公開で対象となる組織に限定して報告されます。組織は脆弱性の詳細を公開するかどうかを選択できます。しかしながら、この選択は研究者ではなく組織の判断で行われるため、多くの脆弱性が公開されることはありません。バグバウンティプログラムの大半は、研究者がこのモデルに従うことを要求しています。\n\nこのモデルの主な問題点は、ベンダーが対応しない場合や、脆弱性を修正しないことを決めた場合、その詳細が公表されない可能性があることです。歴史的には、企業が脆弱性を無視したり隠そうとしたりすることに研究者がうんざりして、完全公開のアプローチをとるようになりました。\n\n### フル・ディスクロージャー\n\nフル・ディスクロージャー・アプローチでは、脆弱性が発見され次第、その脆弱性の詳細情報が公開されます。つまり、攻撃者はパッチが提供される前に、脆弱性の詳細情報（時にはエクスプロイトコードを含む）を入手できることになります。フル・ディスクロージャー・アプローチは、主に報告された脆弱性を無視している組織に対して、修正プログラムの開発と公開を迫るために用いられます。\n\nこのため、フル・ディスクロージャー・アプローチには非常に議論の余地があり、多くの人から無責任だと思われています。一般的には他のすべての方法が失敗した場合や、エクスプロイトコードがすでに公開されている場合など、最後の手段としてのみ考慮されるべきです。\n\n### レスポンシブル・ディスクロージャー、あるいは、協調的な公開\n\nレスポンシブル・ディスクロージャーとは、上記2つのアプローチの中間的なものです。レスポンシブル・ディスクロージャーでは、最初の報告は非公開で行い、パッチが利用可能になった時点で脆弱性の詳細情報を公開します（パッチのインストールに時間を要する場合もあります）。\n\n多くの場合、研究者は、組織が報告に回答する、あるいは、パッチを提供するための期限も提示します。この期限が守られない場合、研究者はフル・ディスクロージャー・アプローチを採用し、その詳細を公表することがあります。\n\nGoogleの[Project Zero](https://googleprojectzero.blogspot.com/2020/01/policy-and-disclosure-2020-edition.html)も同様の手法を採用しており、組織がパッチを公開したかどうかに関わらず、90日経過後に脆弱性の詳細情報を公開しています。\n\n脆弱性の報告\n------\n\nこのセクションはセキュリティ研究者が組織に脆弱性を報告する方法についてのガイダンスを提供することを目的としています。\n\n### 警告と合法性について\n\nセキュリティ調査や脆弱性の報告を行う前に、**管轄の法律を知り、理解していることを確認**してください。このチートシートは**法律上のアドバイスではなく、そのように扱うべきではありません**。\n\n以下のポイントでは、検討すべきいくつかの分野を紹介しています。\n\n* バグバウンティや類似のプログラムの下でテストを実施する場合、組織は[セーフハーバー・ポリシー](https://disclose.io)を確立している可能性があり、**プログラムの対象範囲と規則の範囲内であれば**、合法的にテストを実施することができます。対象範囲を注意深く読むようにしてください。対象範囲や規則を逸脱すると、犯罪行為となる可能性があります。\n* 国によってはリバースエンジニアリングを制限する法律があるため、ローカルにインストールされたソフトウェアに対するテストが許可されない場合があります。\n* セキュリティの脆弱性に関する情報を提供する条件として、あるいはその詳細を公表したり業界の規制当局に報告したりしないことと引き換えに、支払いやその他の報酬を要求してはいけません。\n* バグバウンティの支払いを受けた場合、これらは一般的に所得とみなされ、課税対象となる可能性があります。この収入を報告し、適切な税金を支払うことは、**受け取った側の**責任です。\n* 業務の一環として、あるいは雇用者が所有する機器に脆弱性を発見した場合、雇用者はこれらを報告したり、バグ報奨金を請求したりすることを妨げる場合があります。契約書をよく読み、その前に法的なアドバイスを受けることを検討してください。\n\n### 連絡先情報の確認\n\n脆弱性を報告するための最初のステップは、適切な報告先を見つけることです。ディスクロージャーポリシーを明確に公開している組織もありますが、多くの組織では公開していないため、問題を報告する適切な場所を見つけるのは難しいでしょう。\n\n明確なディスクロージャーポリシーがない場合、以下の場所に連絡先がある場合があります。\n\n* [BugCrowd](https://bugcrowd.com/programs)、[HackerOne](https://hackerone.com/directory/programs)、[huntr.dev](https://huntr.dev/bounties)、[Open Bug Bounty](https://www.openbugbounty.org)、[Standoff](https://bugbounty.standoff365.com)などのバグバウンティプログラム\n* [RFC 9116](https://www.rfc-editor.org/rfc/rfc9116.html#name-location-of-the-securitytxt)に従い、ウェブサイトの`/.well-known/security.txt`に配置された[security.txt](https://securitytxt.org)ファイル\n* 既存のトラッキングシステム(issue tracking system)\n* `security@`または `abuse@` などのメールアドレス\n* ウェブサイトの一般的な「お問い合わせ」ページ\n* ソーシャルメディアプラットフォーム\n* 組織への電話連絡\n* コミュニティへの働きかけ\n\nセキュリティの専門家ではない人に（特にソーシャルメディア上で）連絡を取る場合、最初の連絡を受けた人に脆弱性の詳細を開示するのではなく、適切な連絡先スタッフの詳細を要求してください。\n\n組織に直接連絡できない場合は、国やセクターごとの[CERT](https://en.wikipedia.org/wiki/Computer_emergency_response_team)が支援してくれるかもしれません。\n\n追記：日本の場合は[IPA 独立行政法人 情報処理推進機構](https://www.ipa.go.jp/security/outline/todoke-top-j.html)への届出制度があります。\n\n### 最初の報告\n\nセキュリティ担当者が特定されたら、脆弱性の詳細について最初の報告を行う必要があります。この報告は、暗号化されたチャネル（PGPキーの使用など）で行うのが理想的ですが、多くの組織はこれをサポートしていません。\n\n最初の報告には、次を記載すべきです:\n\n* 脆弱性を理解し、再現できるように十分な詳細情報を提供すること\n* HTTPリクエストとレスポンス、HTMLスニペット、スクリーンショット、またはその他の裏付けとなる証拠\n * 報告する前に、個人情報を消去してください\n * 組織によっては、脆弱性が存在しなかったと主張する場合がありますので、脆弱性が存在したことを証明する十分な証拠を用意してください\n* プルーフ・オブ・コンセプト(PoC)コード（ある場合）\n* 脆弱性の影響\n* 適切と思われる参考文献など\n\n多くの場合、特に小規模な組織では、セキュリティのバックグラウンドを持たない開発者やITスタッフがセキュリティレポートを扱うことがあります。つまり、彼らは多くのセキュリティ概念や用語に精通していない可能性があるため、報告は明確かつシンプルな言葉で書くべきです。\n\nまた、その問題をどのようにして緩和したり解決したりするかについて、推奨事項を提示することも有益でしょう。しかし、システムやアプリケーションの詳細が分かっている場合や、推奨事項に非常に自信がある場合を除き、開発者にもっと一般的なガイダンス（OWASP チートシートなど）を紹介した方が良いかもしれません。\n\n脆弱性の詳細を一定期間後に公開することを計画している場合（一部の責任ある情報開示の方針に従った場合）、その旨を最初のメールで明確に伝える必要があります。ただし、受信者を脅しているように聞こえないようなトーンで伝えるようにしてください。\n\n確立されたバグバウンティプログラムを組織が持っていない場合、最初の連絡で支払いや報酬について尋ねることは避け、問題が認識される（あるいは理想的には修正される）まで待ってください。特に、**脆弱性の詳細を明らかにする前に支払いを要求してはいけません。** これは、よく言えば、会社を騙そうとしているように見え、悪く言えば、恐喝になるかもしれません。\n\n### 継続的なコミュニケーション\n\n単純な脆弱性であれば、最初の報告だけで解決できるかもしれませんが、多くの場合、研究者と組織の間で何度もメールのやり取りが行われます。特に、より複雑な脆弱性の場合、開発者や管理者は問題を解決するための追加情報や推奨事項を求めることがあります。また、修正プログラムが実行された後に、問題の再テストの支援を求められることもあります。この再テストを実施する義務はありませんが、要求が妥当である限り、修正プログラムに対するフィードバックを提供することは非常に有益です。\n\nまた、組織の反応が鈍い場合や、定められた脆弱性の公開期限が近づいている場合には、その組織に催促をする必要があるかもしれません。情報開示のプロセスが敵対的になると、どちらの当事者も利益を得られませんので、このコミュニケーションがプロフェッショナルでポジティブなものであることを確認してください。\n\n問題の解決に時間がかかっている場合は我慢してください。開発者は組織内のさまざまな人から大きなプレッシャーを受けており、完全にオープンなコミュニケーションをとることができないかもしれません。企業内での修正プログラムの試行、開発、レビュー、テスト、デプロイには、多くの研究者が予想している以上の**かなりの**時間がかかります。\n\n### あきらめるとき\n\nあらゆる努力をしても、組織によっては、セキュリティに関心がなかったり、連絡が取れなかったり、脆弱性を開示する研究者を積極的に敵視したりする場合があります。場合によっては、研究者に対して法的措置を取ると脅すことさえあります。このようなことが起こると、研究者は非常に落胆しますが、思い詰めないことが重要です。このような事態に陥った場合、いくつかの選択肢が考えられます。\n\n* 脆弱性を公開し、ネガティブな反応に対処し、訴訟に発展する可能性もあります。彼らは高価な弁護士を抱えており、あらゆる種類の法的措置を取るには費用と時間がかかります。この方法を取る前に、**本当にそれだけの価値があるのか**を自問してみてください。\n* 脆弱性を匿名で公開する。しかし、あなたが既にその組織と連絡を取り、脆弱性を報告しようとしていた場合、その開示の背後に誰がいるのかがかなり明らかになっている可能性があります。この方法を取る場合は、自分自身を守るために十分な運用上のセキュリティ対策を講じていることを確認してください。\n* 業界団体やデータ保護当局などの第三者に脆弱性を報告する。\n* 別のことに取り組みましょう。\n\nセキュリティに純粋な関心を持ち、セキュリティ研究者に対して非常にオープンで協力的な組織は数多くあります。脆弱性が極めて深刻なものでない限り、無関心な組織のために**自分のキャリアや生活を犠牲にしたり、リスクを負ったりする価値はありません。**\n\n### 公開時\n\n脆弱性にパッチが適用された（または適用されなかった）後、その詳細を公開するかどうかを決定する必要があります。これは、理想的にはベンダとの話し合いによって行われるべきであり、最低でもベンダには公開するつもりであることを通知し、公開された詳細へのリンクを提供する必要があります。開示内容は通常次の通りです。\n\n* 脆弱性とその影響についての高レベルの要約\n* どのバージョンに脆弱性があり、どのバージョンが修正されたかの詳細\n* 技術的な詳細、または概念実証のためのコード(PoC)\n* 緩和策やワークアラウンド\n* ベンダーが公開しているアドバイザリへのリンク\n* 発見、ベンダーとのコミュニケーション、リリースまでのタイムライン\n\n組織によっては詳細情報をまったく公開しないことや、ユーザーがセキュリティパッチをインストールするための時間を確保するために公開を遅らせることを要求する場合があります。組織との良好な関係を維持するためにも、この点について妥協点を探してみる価値はあるでしょう。\n\n動作するのPoC（または動作するエクスプロイトコード）を公開するかどうかは、議論の対象となります。これを攻撃者的な行動と捉え、犯罪者がユーザーを危険にさらすのを直接手助けしていると主張する人もいるでしょう。一方で、このコードは、システム管理者やペネトレーションテスト担当者がシステムをテストするために使用することができます。また、攻撃者は、その脆弱性が十分に価値のあるものであれば、実用的なエクスプロイトコードを開発したり、リバースエンジニアリングを行ったりすることができます。\n\n敵対的な状況（組織が無反応であったり、所定の期間が経過した後など）で詳細を公開した場合、脅迫や法的措置を受ける可能性があります。これに法的根拠があるかどうかは、管轄する地域や、その組織と何らかの秘密保持契約を結んでいるかどうかによって異なります。このような行為を行う前に、自分の法的立場を理解しておいてください。\n\n多くのバグバウンティプログラムでは、研究者が組織の同意なしに詳細を公開することを禁じていることに注意してください。公開した場合、報奨金の没収やプラットフォームからの追放につながる可能性がありますので、公開する前にプログラムのルールを確認してください。\n\n脆弱性レポートの受付\n----------\n\nこのセクションは、組織が脆弱性レポートをどのように受け入れ、受け取るかについてのガイダンスを提供することを目的としています。\n\n### バグバウンティプログラム\n\nバグバウンティプログラムは、研究者が脆弱性を発見し、組織に報告することを奨励するために、報酬を提供するものです。報酬は通常、金銭ですが、物品（記念品）の場合もあります。このプロセスは、[BugCrowd](https://bugcrowd.com/programs)や[HackerOne](https://hackerone.com/directory/programs)などの第三者機関によって管理されることが多く、研究者と組織の間を仲介します。\n\nバグバウンティプログラムを導入する際には、次の領域を明確に定義する必要があります:\n\n* どのようなシステムやアプリケーションが対象となるか\n * 本番環境かステージング/テスト環境か？\n * 第三者が管理・所有するシステムを除くか\n* どのような種類の脆弱性が報奨金の対象となるのか（SSL/TLSの問題？ HTTPセキュリティヘッダの欠落？ バージョンの公開？）\n* セーフハーバー・ポリシーなどの法的規定\n * [disclose.io](https://disclose.io)プロジェクトでは、いくつかのポリシー例を提供しています\n * 法的なアドバイスは、**このチートシートではなく**、弁護士から受けてください。\n* 報償金をいくらにするか、どのように決定するか\n * 膨大な数の脆弱性が発見された場合、このプログラムは非常に高価なものになる可能性があります\n * 少なすぎると研究者がプログラムに見向きもしないかもしれません\n* 初期対応、確認、支払い、問題解決までのタイムライン\n\n#### バグバウンティプログラムを導入するタイミングについて\n\nバグバウンティはマイクロソフトをはじめとする多くの大企業で採用されており、米国国防総省など、商業部門以外でも利用され始めています。しかし、小規模な組織にとってはバグバウンティは大きな課題をもたらし、時間とリソースに相当な投資が必要となります。これらの課題には以下のようなものがあります。\n\n* 報告に対応するための十分な時間とリソースがあること\n* 報告を効果的にトリアージするための十分なスキルを持ったスタッフがいること\n * レポートには大量の誤報が含まれている可能性があります\n * 管理されたバグバウンティプログラムは、（コストをかけて）初期のトリアージを行うことで役立つかもしれません\n* 大量の誤認識や無価値なレポートへの対応\n* 実稼働中のシステムを個人がテストすることによる影響（未熟な攻撃者が理解できない自動化ツールを実行することも含む）\n* 正当なテストトラフィックと悪意のある攻撃を区別できないこと\n* 研究者が対象範囲を超え、テストすべきではないシステムをテストしてしまうこと\n* プログラムを運営するための金銭的コスト（年間数十万ドルの報奨金を支払う企業もあります）\n* プログラムの運営方法に不満を持つ研究者への対応（報奨金の額に異議を唱えたり、報告された課題が重複していたり範囲外であったりすると怒るなど）\n\nこれらの潜在的な問題はありますが、バグバウンティプログラムは、アプリケーションやシステムの脆弱性を発見するための素晴らしい方法です。しかし、バグバウンティプログラムは、すでに成熟した脆弱性の開示プロセスを持ち、脆弱性を解決するための強力な内部プロセスに支えられている組織のみが利用すべきです。\n\n### 連絡先の公開\n\nプロセスの中で最も重要なステップは、セキュリティ・リサーチャーがあなたの組織に連絡する方法を提供することです。セキュリティ・リサーチャーが連絡を取りやすければ、セキュリティ・レポートを受け取る可能性が高くなります。以下のリストには、このために使用される一般的なメカニズムがいくつか含まれていますが、これらをより多く実装できると良いでしょう。\n\n* 「お問い合わせ」ページにセキュリティ専門の連絡先を設置\n* バグトラッカーでセキュリティ問題を報告するための専用の説明書\n* 一般的な `security@` のメールアドレス\n* [RFC 9116](https://www.rfc-editor.org/rfc/rfc9116.html#name-location-of-the-securitytxt)に従い、ウェブサイトの`/.well-known/security.txt`に[security.txt](https://securitytxt.org)ファイルを配置する\n* サードパーティのバグバウンティプログラムの利用\n\nまた、窓口のスタッフ（メインの連絡先、ウェブチャット、電話回線を監視するスタッフなど）が、セキュリティ問題の報告をどのように処理するか、また、その報告を組織内の誰にエスカレーションすべきかを認識していることが重要です。\n\n#### 報告書のガイドラインの提供\n\n連絡先に加えて、研究者が脆弱性を報告する際に従うべきガイドラインを提示するのも良いでしょう。これには次のようなものがあります。\n\n* 問題の確認と解決に役立つと思われる具体的な情報を要求すること\n* バグトラッカーで問題に特定のカテゴリを使用したり、機密扱いにしたりすること\n* 暗号化通信のためのPGPキーの提供\n* 初動対応とトリアージのためのタイムラインを確立\n* セーフハーバー規定の制定\n\n### 研究者とのコミュニケーション\n\n研究者と組織の間のコミュニケーションは、脆弱性開示プロセスの中でも最も難しい点の一つであり、双方が不満を抱き、プロセスに不満を持つことになりがちです。\n\n以下のアウトラインは、理想的なコミュニケーションプロセスの一例です。\n\n* 研究者が追加情報を提供するための明確な仕組みを持って、最初の連絡先の要求に応えること\n* 脆弱性の詳細を認識し、トリアージを実行するためのタイムラインを提供する\n* 必要に応じて、追加の説明や詳細を求める\n* 脆弱性を確認し、修正プログラムを導入するためのスケジュールを提示する\n * 提供される報酬や賞金の詳細を確認する\n* 必要であれば、研究者に脆弱性の再テストを依頼する\n* 脆弱性が解消されていることを確認する\n\nこのプロセスを通じて、現在の状況と、脆弱性をトリアージして修正するまでの予想されるタイムラインを定期的に更新します。たとえこれらのスケジュールが確定していなくても、継続的なコミュニケーションによって、脆弱性が忘れ去られていないという安心感を得ることができます。\n\n#### 支払いを求める研究者たち\n\n脆弱性を発見したと称して組織に近づき、その詳細を伝える前に支払いを要求する人物がいます。このような要求は正当なもの**かもしれません**が、多くの場合、単なる詐欺です。\n\n1つの選択肢は、仲介されたバグバウンティープラットフォームを通じて情報開示を行うよう依頼することです。これは詐欺師がこのようなプラットフォームを利用しようとする可能性が低いため、双方にとって一定の保護となります。\n\n### ディスクロージャー\n\n#### 商用およびオープンソースソフトウェア\n\n脆弱性が解決されたら（そして再テストされたら）、そのソフトウェアのセキュリティアドバイザリで詳細を公表しなければなりません。重要なことはセキュリティ問題の詳細を公表することは、**ベンダを悪者にするもの**ではないということです。すべてのソフトウェアにはセキュリティ上の脆弱性があり、それを処理し公開するための明確で確立されたプロセスを示すことは、問題を隠そうとするよりもはるかにソフトウェアのセキュリティに対する信頼性を高めることになります。\n\n少なくともセキュリティアドバイザリには以下の内容が含まれていなければなりません:\n\n* 脆弱性の影響を含む高レベルの要約\n* 脆弱性のあるバージョンの明確なリスト\n* パッチバージョンの明確なリスト\n* ソフトウェアに脆弱性がある場合の注意点（例えば、特定の構成のみが影響を受ける場合など）\n* 一時的な解決策として実施可能な回避策や緩和策\n* 脆弱性の[CVE](https://cve.mitre.org/cve/request_id.html)\n\n可能であれば、次も含めると良いでしょう:\n\n* 脆弱性開示プロセスのタイムライン\n* 脆弱性を発見した研究者のクレジット\n* 脆弱性の技術的詳細\n* IDS/IPSのシグネチャやその他の侵害された痕跡(IoC)\n\nセキュリティアドバイザリは、開発者やシステム管理者が簡単に見つけられるようにする必要があります。一般的な公開方法には次のようなものがあります。\n\n* ウェブサイトにある「セキュリティ」または「セキュリティ・アドバイザリ」の専用ページ\n* セキュリティ関連のメーリングリストやフォーラム\n* メインのchange logやリリースノートからのリンク\n\n研究者の中には、その脆弱性に関する独自のテクニカル・レポートを公開している場合があります。このレポートには、通常、その脆弱性を悪用するために必要な詳細情報（場合によっては、実際に動作するエクスプロイトコードも）が含まれています。より深刻な脆弱性の場合、エクスプロイトコードが利用可能になる前にシステム管理者がパッチをインストールする時間を確保するために、研究者に完全な詳細情報の公開を一定期間（1週間など）遅らせるよう依頼するのが賢明でしょう。しかし、パッチがリリースされれば、攻撃者はその脆弱性をリバースエンジニアリングして独自のエクスプロイトコードを開発することができるため、完全なリリースを遅らせることの価値は限られています。\n\n#### プライベートシステム\n\nプライベートなシステムの脆弱性については、その脆弱性が解決された後に詳細を公開するかどうかを決定する必要があります。ほとんどのバグバウンティプログラムでは、問題が解決された後に詳細を公開するかどうかの選択肢を組織に与えていますが、通常は必須ではありません。\n\nこれらの情報を公開することで、組織がセキュリティに対して積極的かつ透明性の高いアプローチをとっていることを示すことができますが、一方で、恥ずかしい不備や誤った設定が公開されてしまう可能性もあります。将来、情報漏洩やデータ流出が発生した場合には、組織内のセキュリティ文化が脆弱であることの証拠として使用される可能性もあります。さらに、内部の技術的な詳細が公開され、攻撃者が他の同様の問題を特定するのに役立つ可能性もあります。このように、この決定は慎重に検討されるべきであり、法的アドバイスを受けるのが賢明かもしれません。\n\n### 研究者に報いるには\n\n研究者がバグバウンティプログラム以外で脆弱性を発見して報告（基本的に無料のセキュリティテストを提供）し、脆弱性の公開プロセスを通じてプロフェッショナルで親切な行動をとった場合、今後もこのような積極的な交流を奨励するために、何らかの報酬を提供するのが良いでしょう。金銭的な報酬が不可能な場合は、以下のような他の多くのオプションを検討してください:\n\n* 組織が提供するサービスや製品の割引やクレジット\n* 仮想的な報酬（ゲーム内の特別なアイテム、カスタムアバターなど）\n* Tシャツやステッカーなどのノベルティ（記念品）\n* 殿堂入り、またはそれに類するもの\n\n参考文献\n-----\n\n* [The CERT Guide to Coordinated Vulnerability Disclosure（協調型脆弱性情報開示に関するCERTガイド）](https://vuls.cert.org/confluence/display/CVD/The+CERT+Guide+to+Coordinated+Vulnerability+Disclosure)\n* [HackerOneの脆弱性開示ガイドライン](https://www.hackerone.com/disclosure-guidelines)\n* [Disclose.ioの脆弱性開示条件](https://github.com/disclose/dioterms)\n"
},
{
"path": "skillmap_project/code_of_ethics.md",
"content": "# 脆弱性診断士倫理綱領\n[脆弱性診断士スキルマッププロジェクト](https://github.com/OWASP/www-chapter-japan/tree/master/skillmap_project)では、2021年に公開した「脆弱性診断士 倫理綱領」の改訂を2026年に行いました。\n改訂に伴い、ドキュメントの配置場所（URL）を変更しています。以下からご参照ください。\n* [脆弱性診断士 倫理綱領](https://wg1.isog-j.org/CodeofEthics/)\n"
},
{
"path": "tab_event.md",
"content": "---\ntitle: event\ndisplaytext: イベント \nlayout: col-sidebar\ntab: true\norder: 1\ntags: japan\n---\n\n# イベント\nOWASP Japanチャプターが主催/共催/協力するイベントを記載しています。\n主催イベントは、主にDoorkeeperの[「オワスプジャパン」ページ](https://owasp.doorkeeper.jp/)でお申し込みになれます。\n\n### WASNight 2026 Kick-Off (Collaboration Event)\n* 2025-01-27 18:00オープン / 18:30スタート at 渋谷カルチャーカルチャー\n* [WASNight Kick-Off 2026 ハードニング・トークライブ](https://owasp.doorkeeper.jp/events/194033)\n\n\n### スピーカー・出演者 募集（常時）\n> アプリケーション、システムのセキュリティ開発・運用にかかわる、経験、リサーチなどの話を共有するスピーチをしていただける方、短いスピーチでも歓迎です。モバイル、API、クラウド、開発運用、アジャイルでのセキュリティ実装なども歓迎です。 もしスピーカーになることにご関心のある方、イベント参加申し込み時に、あるいは個別にチャプターリーダーまでご提案をお知らせください。\n> \n> If you are willing to give a speech to share your experiences, research, or other stories related to the security development and operation of applications and systems, even a short speech is welcome. Mobile, APIs, Clouds, DevOps, agile security implementation, etc. are also welcome. If you are interested in becoming a speaker, or know someone who is, please feel free to let us know at riotaro at owasp.org.\n\n\n## 終了したイベント / Closed Event\n### OWASP Night 2025.03\n* 2025-03-04 18:00オープン / 18:30スタート at サイボウズ(東京 日本橋)\n* [OWASP Night 2025.03](https://owasp.doorkeeper.jp/events/182085)\n\n### WASNight 2025 Kick-Off (Collaboration Event)\n* 2025-01-28 18:00オープン / 18:30スタート at 渋谷カルチャーカルチャー\n* [WASNight Kick-Off 2025 ハードニング・トークライブ](https://hardening.doorkeeper.jp/events/180356)\n\n### オワスプナイト 2025/01\n* 2025-01-15 18:00オープン / 18:30スタート at SCSKセキュリティ(豊洲)\n* [OWASP Night 2025](https://owasp.doorkeeper.jp/events/180284)\n\n### Hardening 2024 Convolutions (Collaboration Event)\n* 2024-10-16 to 10-18\n* [Hardening 2024 Convolutions](https://wasforum.jp/2024/07/hardening-2024-convolutions-release/)\n\n### Hardening Designers Conference 2024 (Collaboration Event)\n* 2024-07-04 to 07-06\n* [registration doorkeeper](https://wasforum.jp/2024/06/hardening-designers-conference-2024-convolutions/)\n\n### Hardening 2024 First Attack! 〜 Micro Hardening & Meetup\n* 2024-05-23 to 05-24\n* [registration doorkeeper](https://hardening.doorkeeper.jp/events/172750)\n\n### 2024年！セキュリティにAiはあるのかい？ / WASNight 2024 Kick-Off = OWASP x Hardening Night\n* 2024-01-05 \n* [registration doorkeeper](https://owasp.doorkeeper.jp/events/167599)\n\n### Hardening 2023 Generatives (Collaboration Event)\n* 2023-10-04 to 10-28\n* [Hardening 2023 Generatives](https://wasforum.jp/2023/07/hardening-2023-generatives/)\n\n### Hardening Designers Conference 2023 (Collaboration Event)\n* 2023-05-18\n* [registration doorkeeper](https://hardening.doorkeeper.jp/events/155369)\n\n### WASNight 2023 Kick-off 2023/2 (OWASP Night x WASForum = WASNight)\n* 2023-02-13\n* [registration doorkeeper](https://owasp.doorkeeper.jp/events/150347)\n\n### オワスプナイト2022/10 - OWASP Top 10 A02:2021 – 暗号化の失敗\n* 2022-10-14 \n* [registration doorkeeper](https://owasp.doorkeeper.jp/events/143853)\n\n### オワスプナイト2022/09 - OWASP Top 10 A01:2021 – アクセス制御の不備\n* 2022-09-21 \n* [registration doorkeeper](https://owasp.doorkeeper.jp/events/143310)\n\n### Hardening Designers Conference 2022 (collaborative event)\n* 2022-09-01 to 09-03\n* [registration](https://hardening.doorkeeper.jp/events/139964)\n\n### OWASP Global AppSec APAC 2022 ご招待！ \n* 2022-08-31 to 09-01\n* [landing page for the registration guide](https://owasp.doorkeeper.jp/events/141645)\n[](https://owasp.doorkeeper.jp/events/141645)\n \n### OWASP Night 2022.05 OWASP Top 10 review/AppSec APAC?! \n* 2022-05-11\n* [registration doorkeeper](https://owasp.doorkeeper.jp/events/136795)\n* [meetup.com](https://www.meetup.com/ja-JP/japan-owasp-meetup-group/)\n\n\n### WASNight 2022 Kick-off! (OWASP Night x WASForum = WASNight)\n* 2022-01-14 / 18:30-21:30\n* OWASP Session\n * MC: 岡田良太郎・上野宣\n* Hardening Session\n* [registration doorkeeper.jp](https://owasp.doorkeeper.jp/events/131750)\n\n### OWASP Evening 2021.08 Container Security / Privacy by Design \n* 2021-08-12\n* [registration doorkeeper](https://owasp.doorkeeper.jp/events/125575)\n* [registration meetup.com](https://www.meetup.com/ja-JP/japan-owasp-meetup-group/events/279949214/)\n* Guest Speakers: Jun Yamadera(from OWASP Fukushima), Kohei Morita (from OWASP Fukuoka)\n\n### OWASP FUKUSHIMA (Privacy x Security by Designを考える）\n* 2021-04-24\n* 17:30-19:30 \n* [registration compass](https://owasp-fukushima.connpass.com/event/209957/)\n* [OWASP FUKUSHIMA chapter](https://owasp.org/www-chapter-fukushima/)\n\n### WASNight 2021 Kick-off! (OWASP Night x WASForum = WASNight)\n* 2021-01-15\n* 18:30-20:00 OWASP Session\n * MC: 岡田良太郎・根岸征史\n * BUILDERS': いまさら聞けないApache Guacamole 安田真悟(NICT)\n * BREAKERS': 攻撃しながら考えるKubernetesセキュリティ 藤井秀行\n * OWASP Chapter leaders!\n * DEFENDERS' TALK: 昨今のリスク情勢を理解する - そしてIRが涙して喜ぶこの実践ベスト3とは 中津留勇(セキュアワークス)・根岸征史(IIJ)・岡田良太郎 \n * Hardening Session!!\n* [registration doorkeeper.jp](https://owasp.doorkeeper.jp/events/116127)\n* [registration meetup.com](https://www.meetup.com/ja-JP/japan-owasp-meetup-group/events/275535039/)\n\n### Hardening 2020 H3DX (OWASP Japan supported Hardening Project)\n* 2020-11-13,14\n* [Application form](https://wasforum.jp/hardening-project/hardening-2020-H3DX/) \n\n### Deep Digital Dependence Conference(OWASP Japan supported Hardening Project) \n* 2020-09-04, 05\n* [registration](https://hardening.doorkeeper.jp/events/110009)\n\n### OWASP Chapters All Day - 世界をぐるっとリレープレゼン！(日本は日曜午前11時)\n* 2020-06-07\n* 場所: Online [Youtube Live](https://www.youtube.com/watch?v=yNqiibMN8nY)\n* Program: \n * Implementing CSIRT Based on Frameworks and Maturity Model/フレームワークと成熟度モデルに基づいたCSIRTの実装 伊藤彰嗣（@springmoon6）\n * How Our PSIRT Evolved/私たちのPSIRTはいかにして進化してきたか 大塚由里子(サイボウズ)\n * From OWASP Japan 岡田良太郎・上野宣(OWASP Japan)\n[registration](https://owasp.doorkeeper.jp/events/107496)\n\n\n### オワスプナイト2020/02 \n* 2020-02-05\n* 場所; Security Days内会場 D1-11 \n* Program: \n * Web媒介型サイバー攻撃の観測プロジェクト WarpDrive 中嶋淳 (セキュアブレイン)\n * ReDoS 再訪: ReDoS とサイドチャネル攻撃によるデータリーク手法の検討 米内 貴志 (Flatt Security)\n * OWASP Project Updates 岡田良太郎・上野宣(OWASP Japan)\n[registration](https://owasp.doorkeeper.jp/events/103020)\n\n### [past infos were listed on the old OWASP wiki](https://wiki.owasp.org/index.php/Japan#tab=NEWS) \n\n"
},
{
"path": "tab_example.md",
"content": "---\ntitle: Example\ndisplaytext:example \nlayout: null\ntab: false\norder: 2\ntags: example-tag\n---\n\n## Example\n\nPut whatever you like here: news, screenshots, features, supporters, or remove this file and don't use tabs at all.\n"
},
{
"path": "tab_skillmap_project.md",
"content": "---\ntitle: skillmap_project\ndisplaytext: 脆弱性診断士スキルマッププロジェクト\nlayout: col-sidebar\ntab: true\norder: 2\ntags: japan\n---\n\n# 脆弱性診断士スキルマッププロジェクト\n[特定非営利活動法人日本ネットワークセキュリティ協会](https://www.jnsa.org/)の[日本セキュリティオペレーション事業者協議会](https://isog-j.org/)のセキュリティオペレーションガイドラインWG（WG1）と、OWASP Japan主催の共同ワーキンググループである 「脆弱性診断士スキルマッププロジェクト （代表 上野宣）」では、脆弱性診断を行う個人の技術的な能力を具体的にすべく、脆弱性診断を行う技術者（以下、脆弱性診断士）のスキルマップと学習の指針となるシラバス、脆弱性診断を行うためのガイドライン、Webアプリケーションを安全に構築するために必要な要件定義書などを整備しています。\n\n本ワーキンググループに関心のある方は Project leader: [Sen UENO](mailto:sen.ueno@owasp.org) まで\n\n---\n# 成果物は下記のページから\n* [脆弱性診断士スキルマッププロジェクト](https://github.com/OWASP/www-chapter-japan/tree/master/skillmap_project)\n"
}
]