OWASP ASVS 4.0 の変更点

• 追加された行はこの色です。
• 削除された行はこの色です。
• OWASP ASVS 4.0 へ行く。
• OWASP ASVS 4.0 の差分を削除

#author("2020-09-16T15:49:02+09:00","","")
[[情報システム開発契約のセキュリティ仕様作成のためのガイドライン（案）]]
#author("2020-12-22T14:34:36+09:00","","")
[[情報システム開発契約のセキュリティ仕様作成のためのガイドライン]]

*はじめに [#c252218c]
本項では、Web アプリケーションのセキュアコーディングを確立するため、OWASP Application Security Verification Standard JA （公式日本語版、邦訳：Software 2020/8）を掲載し、推奨ガイドラインとします。~
OWSP ASVS は、[[序文]]や[[ASVSの使い方]] にもあるように、現代の Web アプリケーションおよび Webサービスを設計、開発、テストする際に必要となる、機能的および非機能的なセキュリティ管理策の定義に焦点を当てた、セキュリティ要件および管理策のフレームワークであり、①組織がセキュアなアプリケーションを開発および保守するのに役立つこと、②セキュリティサービスベンダ、セキュリティツールベンダ、および利用者が、各々の要件とプロダクトを調整できるようにすること、を目的に作られています。~
ASVSと活用することで、要件定義段階でのアプリケーションに対する非機能要件の洗い出しや、外部設計から詳細設計におけるセキュリティ開発標準として活用でき、また、結合テストや運用テストでのペネトレーションテストの項目の洗い出しに利用できます。~
また、ASVSをソフトウェアサプライチェーンでのセキュアコーディングガイドラインとして位置づけ、ベンダーに遵守を要求することで、各工程のセキュリティに関する品質の違いを、ある程度、均質にすることが可能となります。~
セキュリティに詳しくないユーザーにとって、ASVSはセキュリティ品質を確保するための優れた教科書として参考することができ、加えてベンダーとともにASVSの各項目が、作成するシステムに該当するか否か、該当する場合のセキュリティリスクの回避方法を具体的にを検討できます。~
リスクコミュニケーションのプラットフォームとして、ASVSを活用し、正しいセキュリティ品質要求、正しいセキュリティ実装、正しいセキュリティ品質テストを実現しましょう。~
https://github.com/OWASP/ASVS/tree/master/4.0 から、完全版PDF（邦訳 Software ISAC 2020年8月）を入手できます。



*OWASP アプリケーションセキュリティ検証標準 4.0 [#d756d6b8]
Application Security Verification Standard 4.0~
最終版~
2019年3月

-[[口絵]]
-[[序文]]
-[[ASVSの使い方]]
-[[監査と認証]]
-[[V1 アーキテクチャ、設計、脅威モデリングの要件]]
-[[V2 認証検証の要件]]
-[[V3 セッション管理検証要件]]
-[[V4 アクセス制御検証の要件]]
-[[V5 検証、サニタイズ、エンコーディング検証の要件]]
-[[V6 保存された暗号検証の要件]]
-[[V7 エラー処理とロギング検証の要件]]
-[[V8 データ保護検証の要件]]
-[[V9 通信検証の要件]]
-[[V10 悪意のあるコードの検証要件]]
-[[V11 ビジネスロジック検証の要件]]
-[[V12 ファイルとリソースの検証要件]]
-[[V13 APIおよびWebサービス検証の要件]]
-[[V14 構成検証の要件]]
-[[Appendix A 用語集]]
-[[Appendix B 参考情報]]
-[[Appendix C IoT検証要件]]
*ASVS利用にあたっての注意事項][#gab8d876]
ASVSはNIST SP800-63に準拠していますが、SP800-63 と全く同じとはいえません。例えば、パスワードの最低文字数は12文字であり､SP800-63 が規程した8文字とは異なり、厳しい設定値を推奨しています。また、パスワードハッシュの手法についても、SP800-63とは異なる見解をのべていますが、いずれも、SP800-63を最低限の基準とみなし、よりリスクを受容しない方向で規程していると考えられます。~
従って、仕様策定の際は、初めにASVSの規定値で標準仕様を検討し、ユーザービリティやシステム特性を加味した上で、SP800-63の基準でもリスク受容できると判断された場合は、その理由を文書化し、ダウングレードすることをお勧めします。