これは、有料でもいいと思いました。

ここがすごい

• 系統立てられた文書かつ不要な情報がほぼないため、視覚的に見やすい

• ユースケースが考慮されており、記載しているのが現場の人感がすごい（セキュリティは理想論になりがち）

細かすぎるけど伝わってほしい脆弱性診断手法ドキュメント

Introduction | WebApp Testing (webapppentestguidelines.github.io)

項目は以下

• NoSQL Injection

• OAuth/OpenID Connect

• Prototype Pollution

• TOCTOU/レースコンディション

• クラウドサービスにおけるWebサービスにまつわる脆弱性

  • IDaaSの活用に起因する脆弱性とその悪用

    • EDoS(Economic Denial of Sustainability) - IDaaS

    • アプリケーションの権限に関するカスタム属性の変更 - IDaaS

    • デフォルトエラーに起因するユーザーの開示 - IDaaS

    • 意図しないサインアップ経路の存在 - IDaaS

  • FaaSにおける設定不備と脆弱性の悪用

  • Webアプリケーションの脆弱性を利用した認証情報の窃取

  • クラウドストレージサービスにおける設定不備

• Web Cache Poisoning

活用方法

私は業務上クラウドサービス関連に関わることが多いですが、このまま内部で管理し、ルール化する文書として利用可能です。
多くのガイドラインはかなり広いスコープを対象にしているので、あいまいな表現になりがちなのに対してこの文書は地に足のついた記載となっているため、本当に重要な記載が書いてあると感じました。

地に足のついた記載の例

• FaaSにおける設定不備と脆弱性の悪用

を例に読み上げます。

観点
もしIAMを顧客から受け取っている場合は、FaaSの環境変数に認証情報が含まれていないことを確認してください。 また、下記のいずれかの脆弱性を有している場合、FaaSに設定された認証情報を取得できる場合があるので、認証情報が含まれていないことを確認をしてください。

• Injection攻撃: FaaS上で任意のコマンドやコードを実行可能なOSコマンドやサーバサイドテンプレート等のInjection攻撃が存在する場合、アプリケーションそのものや、構成要素としてFaaSを利用している可能性を考慮して診断してください

• 任意のファイルを読み取ることの可能な攻撃: LFI等のパスに関わる攻撃が存在する場合、アプリケーションそのものや、構成要素としてFaaSを利用している可能性を考慮して診断してください

影響
認証情報が漏洩し、攻撃者等に悪用される可能性があります。

対策
FaaSで動作するアプリケーションの実装時も、通常のアプリケーション同様の脆弱性対策が必要です。 また、クラウドがFaaSに付与しているIAMの認証情報に関しては、FaaSの特性上、環境変数からアクセスを行うため完全な保護は難しい状況にあります。漏洩した場合のリスクを最小化するために、付与する権限は最小限化したうえで、操作元をそのFaaSのみに設定してください。

他の文書と異なる点

• 主語が小さいため、現場レベルに利活用できる

• どのようなリスクがあるか明確に記載されており、受け取り手にこのリスクは受容できるか、を考える猶予がある

所感

今回は、べき論の部分を主に記載させていただきました。
実運用においては以下のような、べき論通りできない場合向けの考慮事項等があり、参考にすべきです。

失敗例から学ぶ Security Hub と GuardDuty の導入時の考慮事項 【資料公開】 | DevelopersIO (classmethod.jp)