これは何？
ASVSっていうアプリケーションを作成する際のセキュリティ基準を書いてる文書です。
完全に備忘録なんで見にくいかもしれないです。(すみません)
以下のリンクの文書を読み込んでいこうと思います。
OWASP ASVS v4.0.3 PDF（直接ダウンロード注意）
本記事を生成形に投げて要約してもらうことをお勧めします。
また本記事は以下の構成で作成しています。
ASVS本文
ChatGPTによる日本語翻訳
私なりの解釈、要約
Preface(序文)
これが作成されるモチベーションとしては
We expect that there will most likely never be 100% agreement on the contents of any web application standard, including the ASVS.
Risk analysis is always subjective to some extent, which creates a challenge when attempting to generalize in a one-size-fits-all standard.
However, we hope that the latest updates made in this version are a step in the right direction, and enhance the concepts introduced in this critical industry standard.
どんなWebアプリケーション標準であっても、
その内容について"100%の合意"が得られることはまずないだろうと考えています。
リスク分析はどうしても主観的な部分を含むため、
すべてに適合する「万能な標準」を作るのは難しいのです。
それでも、このバージョンで加えた最新の更新が、
正しい方向への一歩となり、この重要な業界標準の概念をより強化できることを願っています。
という翻訳ができます。
要約すると：
セキュリティに絶対安全はない。でも、それぞれの状況でより良い選択を積み重ねることで、この業界標準（ASVS）もより強固なものに育っていくと思ってるよー
What's new in 4.0(ASVS 4.0について)
ASVSはこれまでに何回か改訂されており、現在のバージョンは4.0です。
What’s new in 4.0
The most significant change in this version is the adoption of the NIST 800-63-3 Digital Identity Guidelines, introducing modern, evidence based, and advanced authentication controls.
Although we expect some pushback on aligning with an advanced authentication standard, we feel that it is essential for standards to be aligned, mainly when another well-regarded application security standard is evidence-based.
日本語訳
4.0の新要素
このバージョンで最も重要な変更点は、
"NIST 800-63-3 デジタルアイデンティティガイドライン"を取り入れ、
現代的でエビデンスに基づいた高度な認証コントロールを導入したことです。
先進的な認証基準に合わせることに対しては、
多少の反発があることも想定していますが、
他の高く評価されているアプリケーションセキュリティ標準も証拠に基づいて作られている以上、
基準同士が整合していることは非常に重要だと私たちは考えています。
要約すると：
超重要なガイドライン(NIST 800-63-3)を取り入れたよー
でも、取り入れたけど前のままとかでもいいって反発もあるかもだけど、業界標準にガイドラインを合わせるのは重要なことって考えてるよ〜
※ NIST 800-63-3とはアメリカ国立標準技術研究所が制定した認証ガイドライン
詳しくは
ここを見てね
Information security standards should try to minimize the number of unique requirements, so that complying organizations do not have to decide on competing or incompatible controls.
The OWASP Top 10 2017 and now the OWASP Application Security Verification Standard have now aligned with NIST 800-63 for authentication and session management.
We encourage other standards-setting bodies to work with us, NIST, and others to come to a generally accepted set of application security controls to maximize security and minimize compliance costs.
日本語訳
情報セキュリティ標準は、
独自仕様の要件数をできる限り減らすべきです。
そうすれば、対応する組織は、競合したり矛盾したりするコントロールをいちいち選ぶ必要がなくなります。
OWASP Top 10 2017も、今回のASVSも、
認証とセッション管理についてNIST 800-63に揃えました。
私たちは、他の標準化団体にも、
私たち（OWASP）やNISTと協力して、
より広く受け入れられるアプリケーションセキュリティコントロールを作り上げ、
セキュリティを最大化しつつ、コンプライアンスコストを最小化することを推奨しています。
要約すると(あんまり必要ないかも)：
セキュリティ要件はオリジナルを組み込むべきではない。そうするなら競合や矛盾が発生する場合があるから。だから、認証とセッション管理についてのセキュリティ要件はNIST 800-63に揃えた。(つまり：余計なことせずに王道に従え)
ASVS 4.0 has been wholly renumbered from start to finish.
The new numbering scheme allowed us to close up gaps from long-vanished chapters, and to allow us to segment longer chapters to minimize the number of controls that a developer or team have to comply.
For example, if an application does not use JWT, the entire section on JWT in session management is not applicable.
日本語訳
ASVS 4.0では、最初から最後まで番号付けを完全にやり直しました。
新しい番号体系によって、
過去に消えてしまった章の隙間を埋めたり、
長すぎた章を分割して、開発者やチームが対応すべきコントロールの数を減らすことができました。
たとえば、あるアプリケーションがJWT（JSON Web Token）を使っていなければ、
セッション管理に関するJWTセクション全体は適用対象外になります。
要約すると：
ASVS4.0は最初から最後まで番号振りをやり直したよー
それに伴って長い章を分割したり、不要なコントロールを避けて適応範囲を明確化したよー
セッション管理に関するJWTセクション全体は適用対象外になるけど
New in 4.0 is a comprehensive mapping to the Common Weakness Enumeration (CWE), one of the most commonly desired feature requests we’ve had over the last decade.
CWE mapping allows tool manufacturers and those using vulnerability management software to match up results from other tools and previous ASVS versions to 4.0 and later.
To make room for the CWE entry, we’ve had to retire the “Since” column, which as we completely renumbered, makes less sense than in previous versions of the ASVS.
日本語訳
4.0で新たに追加されたのは、Common Weakness Enumeration（CWE）への包括的な対応付けです。
これは、ここ10年間で最も多く要望された機能の一つでした。
CWE対応により、ツール開発者や脆弱性管理ソフトウェアを使う人たちが、
他のツールの結果や、これまでのASVSバージョンの結果を、
今回の4.0以降と簡単に対応付けできるようになりました。
CWEを表示するために、これまで使っていた「Since（追加された時期）」の列は廃止しました。
完全に番号を振り直したため、以前のように「いつ追加されたか」を示す意味が薄れたからです。
要約すると：
Common Weakness Enumerationへここ１０年間で対応して〜って言われてたからついに対応したよー。これによってツール開発者や脆弱性管理ソフトを使う人たちがASVSと対応が簡単になって嬉しいよねぇってこと
We have worked to comprehensively meet and exceed the requirements for addressing the OWASP Top 10 2017 and the OWASP Proactive Controls 2018.
As the OWASP Top 10 2018 is the bare minimum to avoid negligence, we have deliberately made all but specific logging Top 10 requirements Level 1 controls, making it easier for OWASP Top 10 adopters to step up to an actual security standard.
日本語訳
私たちは、OWASP Top 10 2017とOWASP Proactive Controls 2018の要件を、
網羅的に満たし、さらに上回るように取り組みました。
OWASP Top 10 2018は、過失を避けるための最低ラインにすぎないため、
特定のロギング要件を除き、Top 10に関連するすべての項目をLevel 1コントロールにしました。
これによって、OWASP Top 10に準拠している組織が、
より本格的なセキュリティ標準（ASVS）にステップアップしやすくなります。
要約すると：
OWASPのTop10の要件を守ってもそれではものたらないところもあるので、ASVS それらを守ってる企業がスムーズにASVS Level 1にまで実行できるようにした。
※ OWASP Top10の要件とは
-
アクセス制御の不備（Broken Access Control）
-
暗号の失敗（Cryptographic Failures）
-
インジェクション（Injection）
-
設計上の不備（Insecure Design）
-
セキュリティ設定のミス（Security Misconfiguration）
-
脆弱で古くなったコンポーネント（Vulnerable and Outdated Components）
-
識別と認証の失敗（Identification and Authentication Failures）
-
ソフトウェアとデータの整合性の失敗（Software and Data Integrity Failures）
-
セキュリティログとモニタリングの失敗（Security Logging and Monitoring Failures）
-
サーバーサイドリクエストフォージェリ（Server-Side Request Forgery, SSRF）
2025年上半期に最新版が出ると言われてるらしい
We set out to ensure that the ASVS 4.0 Level 1 is a comprehensive superset of PCI DSS 3.2.1 Sections 6.5, for application design, coding, testing, secure code reviews, and penetration tests.
This necessitated covering buffer overflow and unsafe memory operations in V5, and unsafe memory-related compilation flags in V14, in addition to existing industry-leading application and web service verification requirements.
日本語訳
私たちは、ASVS 4.0のLevel 1が、
PCI DSS 3.2.1のセクション6.5（アプリケーション設計・コーディング・テスト・セキュアコードレビュー・ペネトレーションテスト）を
**包括的に上回る**ものになることを目指しました。
そのために、
V5にバッファオーバーフローや安全でないメモリ操作の対策を、
V14にメモリ関連のコンパイルフラグの対策を、
加える必要がありました。
これらは、既存の業界トップレベルのアプリケーションやWebサービスの検証要件に加えたものです。
要約すると：
ASVS 4.0 Level 1の方が、PCI DSS(クレジット業界のセキュリティ基準)よりもカバー範囲を大きくして、「バッファオーバーフロー対策」みたいなメモリー管理まで低レイヤーも抑えているよーってこと
We have completed the shift of the ASVS from monolithic server-side only controls, to providing security controls for all modern applications and APIs.
In the days of functional programming, server-less API, mobile, cloud, containers, CI/CD and DevSecOps, federation and more, we cannot continue to ignore modern application architecture.
Modern applications are designed very differently to those built when the original ASVS was released in 2009.
The ASVS must always look far into the future so that we provide sound advice for our primary audience - developers.
日本語訳
ASVSは、昔のような**モノリシックなサーバーサイド専用コントロール**だけの基準から、
**現代のあらゆるアプリケーションやAPI向けのセキュリティコントロール**へと完全にシフトしました。
関数型プログラミング、サーバーレスAPI、モバイル、クラウド、コンテナ、CI/CD、DevSecOps、フェデレーション（連携認証）など、
現代のアプリケーションアーキテクチャは急速に進化しています。
もはや、昔ながらのサーバー中心の考え方を続けるわけにはいきません。
今のアプリケーションは、2009年に最初のASVSが出たころとは設計思想がまったく違っています。
だからASVSも、**未来を見据えて、主な対象である開発者たちに、確かなアドバイスを届け続けなければならない**のです。
要約すると：
ASVSが出た2009年よりも開発要件が変わっており、サーバーを中心にした考え方が古くなっています。だから、未来を見据えて開発者たちに確かなアドバイスを届け続けていく必要があるよー
要約一覧
セキュリティに絶対安全はない。
でも、それぞれの状況でより良い選択を積み重ねることで、この業界標準（ASVS）もより強固なものに育っていくと思ってるよー。
超重要なガイドライン（NIST 800-63-3）を取り入れたよー。
でも、取り入れたけど前のままとかでもいいって反発もあるかもだけど、
業界標準にガイドラインを合わせるのは重要なことって考えてるよ〜。
セキュリティ要件はオリジナルを組み込むべきではない。
そうするなら競合や矛盾が発生する場合があるから。
だから、認証とセッション管理についてのセキュリティ要件はNIST 800-63に揃えた。（つまり：余計なことせずに王道に従え）
ASVS 4.0は最初から最後まで番号振りをやり直したよー。
それに伴って長い章を分割したり、不要なコントロールを回避して適応範囲を明確にしたよー。
セッション管理に関するJWTセクション全体は適用対象外になるけど。
Common Weakness Enumerationへここ10年間で対応して〜って言われてたからついに対応したよー。
これによってツール開発者や脆弱性管理ソフトを使う人たちがASVSと対応が簡単になって嬉しいよねぇってこと。
OWASPのTop10の要件を守ってもそれではものたらないところもあるので、
ASVSではそれらを守ってる企業がスムーズにASVS Level 1にまで実行できるようにした。
ASVS 4.0 Level 1の方が、PCI DSS（クレジット業界のセキュリティ基準）よりもカバー範囲を大きくして、
「バッファオーバーフロー対策」みたいなメモリー管理まで低レイヤーも抑えているよーってこと。
ASVSが出た2009年よりも開発要件が変わっており、サーバーを中心にした考え方が古くなってきているので、
未来を見据えて開発者たちに確かなアドバイスを届け続けていく必要があるよー。
ってこと。
最後に
この調子でセクションごとに読み込んでいこうと思います。
よろしくお願いします。
続報は以下に貼っていきますので、気長にお待ちください。
関連リンク