これは何？
ASVSっていうアプリケーションを作成する際のセキュリティ基準を書いてる文書です。
ちなみにこれをやり始めた理由は興味半分、趣味半分です。(完全に私利私欲)
以下のリンクの文書を読み込んでいこうと思います。
OWASP ASVS v4.0.3 PDF（直接ダウンロード注意）
個人的な備忘録なため誤った理解などもあると思います。
コメントなどでご指摘いただけると幸いです。
また本記事は以下の構成で作成しています。
ASVS本文
ChatGPTによる日本語翻訳
V1: **Architecture, Design and Threat Modeling Requirements Control Objective
Security architecture has almost become a lost art in many organizations.
The days of the enterprise architect have passed in the age of DevSecOps.
The application security field must catch up and adopt agile security principles while re-introducing leading security architecture principles to software practitioners.
日本語訳
V1：アーキテクチャ、設計、および脅威モデリングの要件
【コントロール目的】
セキュリティアーキテクチャは、多くの組織で失われつつある技術になってしまっている。
エンタープライズアーキテクトが活躍した時代は終わり、今はDevSecOpsの時代。
アプリケーションセキュリティの分野は、その変化に追いついて、
アジャイルなセキュリティの考え方を取り入れると同時に、
ソフトウェア開発者に対して正統派のセキュリティ設計原則を改めて伝えていく必要がある。
要約すると：
DevSecOpsが主流な現在だからこそ昔ながらの本質的な設計を持ち込んで尚且つ、新しい考え方もしっかり取り入れようね
次の章から要約はまとめて箇条書きでやります。
先に要約まとめ：
- V1.1: 開発段階を網羅的にセキュリティを考えたSDLCの考え方が入っているか
- V1.2:高リスクを扱うアプリに対して脅威モデリングが継続的に実施されているか
- V1.3:高リスクを扱うアプリに対してアーキテクチャを専門家にレビューしてもらって全てのセキュリティ対策が特定され文書化されているか
- V1.4:アプリのコンポーネントが特定されており既知の脆弱性が無いかを定期的に確認しているか
- V1.5:セキュアな実績のある設計パターンを利用しているか(自己流のアーキテクチャで設計してないか)
- V1.6:フレームワークごとのセキュアなコーディングルールを適用して開発メンバーはそれに対して訓練されているのか
- V1.7:セキュリティやプライバシーに関する設計要件が明確に文書化されており、脅威モデリングと整合性が取れているか
- V1.8:セキュリティコントロールがちゃんとセキュリティの要件を満たしているのか
- V1.9:攻撃対象範囲(アタッカーサーフェス)を最小限に設計できているか
- V1.10:セキュリティ要件がビジネスの目的に一致しており、セキュリティがどのようにビジネスに影響を与えるか理解しているか
- V1.11:重要な設計書が最新で常にあり、セキュリティコントロールの実装を支援できる十分な詳細が書いてありステークホルダがアクセスできるか
- V1.12:ソフトウェア開発ライフサイクルにおける各段階でセキュリティをしっかり考えているか
- V1.13:該当するセキュリティ標準やフレームワークなどがセキュリティコントロールに実際に使用されているのか
以下に原文と翻訳結果を置いてます。
一読することをお勧めします。
V1.1: Verify the use of a secure software development lifecycle that addresses security in all stages of development.
開発のすべての段階においてセキュリティを考慮した、安全なソフトウェア開発ライフサイクル（SDLC）が使われていることを確認する。
V1.2: Verify that threat modeling is performed and maintained for high-risk applications, particularly for those with any sensitive data, authentication, access control, or other security concerns.
日本語訳：
V1.2：
高リスクなアプリケーションに対して、
特に**機密データ・認証・アクセス制御・その他のセキュリティ懸念**がある場合、
脅威モデリング（threat modeling）が実施され、継続的に維持されていることを確認する。
V1.3: Verify that architectures of high-risk applications are reviewed by security professionals and all applicable security controls are identified and documented.
日本語訳：
1.3：
高リスクなアプリケーションについては、セキュリティの専門家がアーキテクチャをレビューし、
適用可能なすべてのセキュリティコントロールが特定され、文書化されていることを確認する。
V1.4: Verify that all application components are identified and are checked for known vulnerabilities on a periodic basis.
日本語訳：
V1.4：
すべてのアプリケーションコンポーネントが特定されていて、
それらに既知の脆弱性がないかを定期的に確認していることを検証する。
※ コンポーネントの範囲的には
- 自作モジュール
- 外部ライブラリ、フレームワーク(OSSも)
- サードパーティのツール
V1.5: Verify that secure design patterns or reference architectures are used for all major architectural components.
日本語訳：
V1.5：
すべての主要なアーキテクチャコンポーネントに対して、
セキュアな設計パターンまたはリファレンスアーキテクチャが使用されていることを確認する。
V1.6: Verify that a secure coding standard is defined, aligned to the selected development framework, and that teams are trained to understand and apply it.
日本語訳：
V1.6：
選択された開発フレームワークに合わせたセキュアコーディング規約が定義されており、
開発チームがそれ理解し、適用できるようにトレーニングされているこを確認する。
V1.7: Verify that security and privacy design requirements are clearly documented and are aligned with the threat model.
日本語訳：
V1.7：
セキュリティおよびプライバシーに関する設計要件が明確に文書化されており、
かつ脅威モデリングと整合性が取れていることを確認する。
ひとこと：
アプリで何を守る必要があるか、どうやって守るか？
脅威モデリングと整合性をとってちゃんと明確な文書としてまとめとけよ的な感じ
※ 脅威モデリング → アプリケーションのセキュリティ設計上の欠損を特定や把握して緩和策を検討するプロセス
V1.8: Verify that security controls are designed to meet the security requirements.
日本語訳：
V1.8：
セキュリティコントロール（具体的な対策）が、セキュリティ要件を満たすように設計されていることを確認する。
V1.9: Verify that the attack surface is minimized by design.
日本語訳：
V1.9：
設計の段階で、攻撃対象領域（アタックサーフェス）が最小化されていることを確認する。
V1.10: Verify that security objectives are aligned with business objectives, and that the business impact is identified and clearly understood.
日本語訳：
V1.10：
セキュリティ上の目的が、ビジネスの目的と一致しており、
かつ、セキュリティに関する影響がビジネスにどう関わるかを明確に把握していることを確認する。
ひとこと：
簡単に言えばビジネスのゴールに対してセキュリティが過剰になって無いかって感じかね。
例えば 「これが止まれば〇〇万円吹っ飛ぶ」ってことに対して「冗長構成とかDDos対策打つ」ってことをして可用性を上げおくとして、それらが合理性(脅威に他するコストが過剰でないか、緩すぎないか)が取れているかってこと
V1.11: Verify that key design documentation is up to date, has sufficient detail to support security control implementation, and is accessible to relevant stakeholders.
日本語訳：
V1.11：
重要な設計ドキュメントが最新であり、
セキュリティコントロールの実装をサポートできるだけの十分な詳細が書かれていて、
関係者がちゃんとアクセスできる状態にあるかを確認する。
V1.12: Verify that security is considered in the software development lifecycle from requirements to design to implementation.
日本語訳：
V1.12：
ソフトウェア開発ライフサイクル（SDLC）の「要件定義→設計→実装」まで、各段階でセキュリティが考慮されていることを確認する。
ひとこと：
それぞれのプロセスで取り決めるセキュリティ要件は違うと思います。
それを意識してね〜って感じのニュアンスですよね
例えば、要件定義だとどのようなデータを守るかとかコーディング時だったらちゃんと設計の「どう守るか？」が反映されているかなどの
V1.13: Verify that relevant security standards or frameworks have been used to design and implement security controls, as applicable.
日本語訳：
V1.13：
該当するセキュリティ標準やフレームワークが、セキュリティコントロールの設計・実装において使用されていることを確認する。
ひとこと：
まぁ改めて自己流でやってないかの再確認ですね。
これだけ強調して自己流でやるなって言ってるので相当大事です。
最後に
ここまでのご閲覧ありがとうございます
以上,V1でした。
まだまだ続いていくので気長にお待ちください。
関連リンク