4.2 アプリケーションセキュリティ

概要と動機

アプリケーションセキュリティは、抽象的な脅威が具体的なコードと出会う場所です。見出しになる侵害のほとんどは、アプリケーション層の欠陥にさかのぼります。インジェクション、壊れた認証フロー、露出したシークレット、侵害された依存関係。多くのサービスを出荷する大きなチームにとって、難しいのは、これらの欠陥が存在することを知ることではありません。何年にもわたって数千の手で書かれた広大なコードベース全体で、一貫してそれらを防ぐことです。

企業にとって、アプリケーションセキュリティは、顧客の信頼と規制上の義務の問題です。ログインフローや決済経路の欠陥は、不正、罰金、義務的な侵害の開示を引き起こしえます。政府のシステムは、同じ技術的リスクに、より賭け金の高いデータで直面します。給付の受給資格、税の記録、刑事司法のデータ、国の基盤。どちらの設定でも、アプリケーションは玄関口であり、攻撃者はそれを絶え間なく自動的に探ります。

本章は、アプリケーションを強靭に保つ実践を扱います。一般的な脆弱性のクラスを知って防御すること、入力を検証し出力をエンコードすること、認証と認可を正しく行うこと、シークレットを管理すること、そして実際の攻撃面をますます決めるソフトウェアサプライチェーンを保護すること。

関連項目: 4.1章(セキュリティの基礎、脅威モデリング、セキュアな開発ライフサイクル)、10.3章(オープンソースのサプライチェーンとライセンス)、10.2章(SBOM、リスク、保証)。

主要原則

入力を決して信頼しない。 信頼の境界を越えるすべてのデータを、検証されるまで敵対的なものとして扱います。
セキュアな既定。 安全な道は易しい道であるべきで、安全でない振る舞いには、意図した、目に見える労力を要するべきです。
閉じて失敗する。 セキュリティのチェックが完了できないとき、アクセスを許すのではなく拒否します。
アプリケーション層での多層防御。 検証、エンコード、パラメータ化、フレームワークの保護を組み合わせます。一つに頼ってはいけません。
アイデンティティとトークンの最小権限。 資格情報のスコープを狭くし、素早く期限切れにします。
依存関係はあなたのコードです。 サードパーティやオープンソースの構成要素を含め、出荷するすべてのセキュリティに責任があります。
即興より標準。 自前のセキュリティ統制を発明するのではなく、OWASP(Open Worldwide Application Security Project)のASVSのような検証済みのフレームワークを使います。

推奨事項

OWASP Top 10を知って防御し、ASVSで検証する

OWASP Top 10は、最も重大なウェブアプリケーションのリスクの、業界の基準リストです。壊れたアクセス制御、暗号の失敗、インジェクション、安全でない設計、セキュリティの誤設定、脆弱なコンポーネント、認証の失敗、データの完全性の失敗、ログの失敗、サーバーサイドリクエストフォージェリ。コンプライアンスの参照として仕舞い込むだけでなく、すべてのエンジニアの必須の知識として扱ってください。

厳密でテスト可能な標準としては、OWASP Application Security Verification Standard(ASVS) を採用します。ASVSは、三つの保証レベルでセキュリティ要件を定義し、設計しテストする対象となる、具体的で監査可能な統制を与えます。各アプリケーションのリスクに合うレベルを選び、それに対して検証してください。

入力を検証し、出力をエンコードする

インジェクションの欠陥は、導入するのがあまりに易しいからこそ、最も損害の大きいものの一つであり続けます。層をなす統制で防御します。

厳格な許可リスト(期待される型、長さ、形式、範囲)に対して入力を検証します。できる所では、無害化するのではなく拒否します。
すべてのデータベースアクセスにパラメータ化クエリとプリペアドステートメントを使い、文字列の連結でSQLを決して組み立てません。安全なクエリビルダーとORM(オブジェクト・リレーショナル・マッパー)を正しく使います。
出力を文脈に応じてエンコードします。HTML、HTMLの属性、JavaScript、URL、CSSは、それぞれ異なるエンコードを要します。フレームワークの自動エスケープに頼り、その限界を理解します。
出力のエンコードに加え、第二の層として強力なコンテンツセキュリティポリシーで、クロスサイトスクリプティング(XSS)を防ぎます。
信頼できないデータでシェルを呼び出すのを避け、ロジックのない、あるいはサンドボックス化されたテンプレートを使うことで、コマンドとテンプレートのインジェクションを防ぎます。

認証と認可を正しく行う

認証は、ユーザーが誰かを証明します。認可は、何をしてよいかを決めます。どちらも頻繁に失敗するので、正しく行ってください。

確立されたプロトコルを好みます。委任された認可にはOAuth 2.0、認証にはOpenID Connect(OIDC)。ゼロから作ってはいけません。
特に特権と管理のアクセスには、多要素認証(MFA) を徹底します。
パスワードは、現代的で遅く、メモリ困難なアルゴリズム(Argon2やbcryptなど)を使った、ソルト付きのハッシュとしてのみ保存します。平文の資格情報を保存したりログに出したりしてはいけません。
セッションを慎重に管理します。暗号学的に強いトークンを生成し、SecureとHttpOnlyのクッキーのフラグを設定し、権限の変更時にローテーションし、アイドルのセッションを期限切れにします。
すべてのリクエストでサーバー上で認可を徹底し、認証された主体が特定のリソースを所有するか、アクセスしてよいかを確認します。壊れたオブジェクトレベルの認可(IDを変えて他のユーザーのレコードにアクセスする)は、最もよくある重大なAPIの欠陥の一つです。
実用的な所では認可のロジックを集中させ、方針が一貫して監査可能になるようにします。

シークレットを管理し、鍵をローテーションする

ソースコードにハードコードされたシークレットは、侵害の永遠の原因です。シークレット管理を中心に規律ある習慣を築いてください。

シークレットは、専用のシークレットマネージャーやボルトに保存し、ソース、設定ファイル、バージョン管理にチェックインされた環境変数には決して置きません。
コミットとリポジトリを、漏洩したシークレットについて自動的にスキャンし、それを導入するマージをブロックします。
鍵と資格情報を定期的に、そして漏洩の疑いがあれば直ちにローテーションします。長寿命の静的なものより、短命で自動的に発行される資格情報を好みます。
すべてのシークレットに最小権限を適用します。必要とするものにちょうどスコープを絞ります。
シークレットを保存時と転送中に暗号化し、そのアクセスを監査します。

ソフトウェアサプライチェーンを保護する

現代のアプリケーションは、ほとんどがサードパーティの構成要素から組み立てられるので、サプライチェーンは主要な攻撃面になります。

すべてのアプリケーションにソフトウェア部品表(SBOM) を維持し、何を出荷しているかを正確に知り、新しい脆弱性が現れたときに素早く対応できるようにします。
依存関係を継続的にスキャンし(ソフトウェア構成分析、SCA)、既知の脆弱なコンポーネントを速やかに是正します。
依存関係のバージョンを固定して検証します。ロックファイルと信頼されたレジストリを使います。
ビルドの完全性を高めるためにSLSA(Supply-chain Levels for Software Artifacts)を採用し、成果物がどうビルドされたかを説明する来歴の証明を生成します。
成果物に署名し、デプロイ前に署名を検証して、動いているものがビルドしたものだと信頼できるようにします。
ビルドシステム自体を保護します。侵害されたCIパイプラインは、下流のすべての利用者に悪意のあるコードを注入しえます。

トレードオフ: 長所と短所

決定	長所	短所
アイデンティティプロバイダー(OIDC)を買う/採用する	実戦で鍛えられている。MFAが組み込み。守るコードが少ない	ベンダー依存。統合の労力。コスト
独自の認証を作る	完全な制御。外部依存なし	間違えるのが極めて易しい。保守が重い
厳格な許可リストによる検証	脆弱性のクラス全体をブロックする	正当なエッジケースを壊しうる。事前の仕事が増える
短命の資格情報	小さな侵害の窓。自動的な失効	堅牢な発行インフラが必要
積極的な依存関係の更新	既知の脆弱性が減る	変動。壊れる変更の可能性。テストの負担
SBOM + 署名 + 来歴	速いインシデント対応。検証可能な信頼	ツールと手続きへの投資。文化の変化

繰り返されるトレードオフは、事前の厳密さ対継続的な露出です。独自の認証を築いたり依存関係の衛生を飛ばしたりすることは、今日は速く感じられ、後で莫大なコストになります。検証済みの標準と自動化されたサプライチェーンの統制を採用することは、今は労力がかかりますが、限りなく予測不能なリスクを、管理された有界のものに変えます。大きなチームにとっては、自動化の乗数が最も重要です。舗装された道のテンプレートに一度適用された統制は、それを使うすべてのサービスを守ります。

チームで議論すべき問い

どのASVSの統制を舗装された道のフレームワークに焼き込み、エンジニアが無料で得られるようにしますか。 大きなチームにとって最もてこの効く動きは、安全な道を既定にすることで、共有のフレームワークに一度書かれた統制が、それを採用するすべてのサービスを守るようにします。どのASVSの要件(パラメータ化クエリ、出力のエンコード、セキュアなセッションのフラグ、サーバーサイドの認可のチェック)が、各エンジニアの記憶ではなくテンプレートに属するかを決めてください。企業と政府のポートフォリオでは、どのアプリケーションがASVSのレベル2を、どれがレベル3を必要とするかも決め、それぞれが触れるデータの機微さに結びつけます。サービスの一覧を持ち込み、すでにこれらの既定を引き継いでいるものと、セキュリティを手作業で再実装しているものに印を付けてください。手作りのものこそ、インジェクションと壊れたアクセス制御が隠れる所だからです。セキュアな既定がwikiのページにしか存在しないなら、デリバリーの圧力のもとで飛ばされるので、コードに置いてください。
新しいものだけでなく、すべてのAPIにわたって、壊れたオブジェクトレベルの認可をどう見つけて直しますか。 IDを変えて他のユーザーのレコードにアクセスすることは、最もよくある重大なAPIの欠陥の一つで、現在の標準より前の古いエンドポイントに潜みます。すべてのリクエストとすべてのオブジェクトでのサーバーサイドの認可がルールですが、難しいのは、多くの手で書かれた何年も前の広大なコードベース全体でそれが成り立つことを検証することです。認可のロジックを集中させるか、テナントをまたぐアクセスを試みる自動化されたテストを加えるか、最もリスクの高いAPIに最初に的を絞ったテストを実行するかを決めてください。オブジェクトの識別子を公開するエンドポイントの一覧を持ち込み、それらが返すものの機微さでランク付けします。意図した一斉点検がなければ、この欠陥を出荷し続け、研究者か攻撃者が見つけたときにしか発見しません。
次の広範な依存関係の脆弱性への計画は何で、影響を受けるすべてのサービスをどれだけ速く見つけてパッチを当てられますか。 人気のあるライブラリに重大な欠陥が現れたとき、正確なSBOMを持つ企業は影響を受けるサービスを数時間で特定し、他は数週間を探して費やします。その速度のギャップが、受ける損害を決めます。すべての成果物にソフトウェア部品表を作るか、すべてのパイプラインで依存関係のスキャンが動くか、緊急のパッチの決定を誰が所有するかを、今決めてください。規制対象と政府の買い手にとって、SBOMと署名された来歴はますます取引の条件になっているので、この備えは収益も守ります。演習への誠実な答えを持ち込んでください。広く使うライブラリを一つ選び、それを出荷するすべてのサービスを列挙するのにかかる時間を計ります。答えが日数で測られるなら、次のインシデントが強いる前に、目録と署名に投資してください。
長寿命の静的なシークレットから、短命で自動的に発行される資格情報へどう移り、今日それを妨げているシステムはどれですか。 ハードコードされた長寿命のシークレットは侵害の永遠の原因で、その修正である、オンデマンドで発行される短命の資格情報は、古いシステムがしばしば使えない発行インフラに依存します。大きなチームにとって危険は不均一な採用です。現代的なプラットフォームが鍵を毎時ローテーションする一方で、レガシーのサービスは設定ファイルに静的なデータベースのパスワードを出荷し続ける。どのワークロードが今シークレットマネージャーやワークロードアイデンティティのシステムを使えるか、どれが先に投資を要するか、鍵の漏洩が疑われた瞬間にローテーションのランブックを誰が所有するかを決めてください。使用中のすべての資格情報の目録、その寿命、露出したときの影響範囲、コミットのスキャンがマージ前にそれを捉えるかを持ち込みます。企業と政府の設定では、これを監査に結びつけてください。審査官はますます、すべてのシークレットについてのローテーション、スコープされたアクセス、アクセスログの証拠を期待し、ダウンタイムなしにローテーションできない静的な資格情報は、書かれるのを待っている指摘です。
自前の、あるいは一貫しない認証をまだどこで動かしていて、検証済みのプロトコルに統合する計画は何ですか。 認証を築くことは、微妙で悪用可能な欠陥を導入する最も易しい方法の一つですが、ほとんどの大きな資産群は、OAuth 2.0とOIDCに標準化するという決定より前の、少なくとも一つのレガシーのログインフローを抱えています。相反する圧力は本物です。古いフローの移行は既存のユーザーと統合を壊すリスクがあり、そのままにしておくと、価値の高い標的を防御不足のままにします。単一のアイデンティティプロバイダーに統合し、MFAを一様に徹底し、オーダーメイドのフローそれぞれを廃止する期限を設定するか、補償統制を伴う文書化された例外を受け入れるかを決めてください。フリートのすべての認証経路の地図を持ち込み、どれがMFAを徹底し、どれが現代的なメモリ困難のハッシュでパスワードを保存し、どれが独自かを示します。企業と政府のポートフォリオでは、コンプライアンスの角度を加えてください。NIST SP 800-63のような標準は、アイデンティティ保証についての具体的な期待を定めており、それを示せない自前のフローは、監査や運用認可のレビューを生き延びません。
これらの統制が本番で実際に成り立っていることをどう検証し、主張ではなく証拠でそれを証明できますか。 セキュアな既定を書くことは、すべてのサービスがそれを守り続けていると知ることとは違い、コードが変わり、例外が積み上がり、新しいエンドポイントが出荷されるにつれて、統制は静かに腐ります。大きなチームにとっての問いはカバレッジです。どのサービスが静的解析、依存関係のスキャン、動的あるいはペネトレーションテストを実行し、それらを飛ばすものが最もリスクの高いアプリケーションではないとどう知りますか。パイプラインで何の検証が必須で何が定期的か、誰が発見をトリアージするか、統制が特定の日にテストされ合格していたことを示す、どんな証拠を保持するかを決めてください。現在のカバレッジの地図、重大度ごとの是正までの平均時間、最近のテストがないアプリケーションの一覧を持ち込みます。規制対象と政府の文脈では、この証拠は任意ではありません。監査人、認可官、侵害の調査員はみな、統制が検証されたことの証明を求め、テストの記録のない方針が彼らを満足させることはめったにありません。

セクター別の視点

スタートアップ。 二、三人のエンジニアでセキュリティの専門家がいないなら、あなたのてこは、セキュリティを築くのではなく引き継ぐことです。マネージドなOIDCのアイデンティティプロバイダーを採用し、ORMが既定でクエリをパラメータ化するフレームワークに頼り、シークレットは、チームメイトが誤ってコミットしかねない.envファイルではなく、プラットフォームのシークレットマネージャーに保ってください。パッチのプルリクエストを開く自動の依存関係スキャンをオンにし、今はそれで十分と見なします。独自の認証や暗号を作ってはいけません。たった一つのインジェクションされたクエリや一つの漏洩した鍵が、顧客を得る前に会社を終わらせうるからです。

小規模事業者。 おそらくアプリケーションセキュリティの専門家はおらず予算も厳しいので、専任の機能に人員を置くのではなく、すでに払っているツールとプラットフォームに組み込まれた統制を買ってください。MFA込みのホスト型のアイデンティティプロバイダー、パラメータ化されたアクセスに誘導してくれるマネージドなデータベース、最初から漏洩したシークレットをコミットでスキャンするリポジトリのホスト。乏しい注意を、実際の侵害のほとんどを引き起こすOWASP Top 10の基本に集中させ、気軽にオフにできないセキュアな既定を出荷するベンダーを好んでください。

大企業。 多くのチームにわたって、課題は一貫性です。ASVSの統制を舗装された道のフレームワークに焼き込み、すべての新しいサービスが、パラメータ化クエリ、出力のエンコード、セキュアなセッション、サーバーサイドの認可を無料で引き継ぐようにします。正確なSBOMとフリート全体の依存関係スキャンを運用し、次の広範なライブラリの脆弱性が数週間ではなく数時間の問題になるようにし、テナントをまたぐアクセスがテスト可能になるよう認可の方針を集中させます。MFAを徹底した単一のアイデンティティプロバイダーに標準化し、アプリケーションセキュリティを、リスク階層化されたASVSのレベルと監査された証拠を持つ、統治されたポートフォリオとして管理します。

政府。 調達規則、透明性、公的な説明責任が、単に実装するだけでなく示さなければならない統制を形づくります。市民向けのサービスを、データの機微さに合ったレベルでOWASP ASVSに対して検証し、サプライチェーンの義務を満たすために、デプロイされるすべての成果物に署名してSLSAに従って来歴を証明し、完全なアクセスログとともに、中央のボルトから短命の資格情報を発行します。監査人と認可官に、ソースから本番までの文書化された証拠の連鎖を示すことを期待し、アイデンティティ保証をNIST SP 800-63のような公表された標準に合わせてください。

事例

スタートアップ。 3人のエンジニアのSaaSチームは、自前のログインを築くことをやめ、初日にマネージドなOIDCプロバイダーを採用し、間違えるわけにいかないセキュリティ上決定的なコードを書かずに、MFAと安全なパスワードのリセットを得ます。フレームワークのORMに頼るので、クエリは既定でパラメータ化され、シークレットはチームメイトが誤ってコミットしかねない.envファイルではなくプラットフォームのシークレットマネージャーに置かれ、ライブラリにパッチが必要になるとプルリクエストを開く自動の依存関係スキャンがオンになっています。これのどれもチームを遅くせず、一つの漏洩した鍵や一つのインジェクションされたクエリが、顧客を得る前に会社を終わらせることはありません。

大企業。 数千万の買い物客に仕える小売プラットフォームは、単一のアイデンティティプロバイダーを通じて、認証をOIDCに標準化し、従業員にMFAを、価値の高いアカウントの変更にステップアップ認証を徹底します。すべてのデータベースアクセスは、クエリをパラメータ化するよう設定されたORMを通り、コンテンツセキュリティポリシーが出力のエンコードを裏打ちします。人気のあるログのライブラリの広く報じられた脆弱性の後、会社のSBOMにより、影響を受けるすべてのサービスを数時間で特定して2日でパッチを当てられましたが、目録のない競合は数週間を探して費やしました。

政府。 連邦の給付機関は、市民向けのサービスをOWASP ASVSのレベル2に対して検証して築き、最も機微な記録を扱う構成要素にはレベル3を適用します。シークレットは、短命の資格情報を発行する中央のボルトに置かれ、コミットのスキャンが漏洩した鍵をブロックします。デプロイされるすべての成果物は署名され、その来歴はSLSAに従って証明され、検証可能なソフトウェアサプライチェーンの連邦の義務を満たし、監査人にソースから本番までの明確な証拠の連鎖を与えます。

ビジネスケース: 動機、ROI、TCO

アプリケーションセキュリティへの支出は、最も可能性が高く最も高価な種類の侵害を買い下げます。総所有コストには、ツール(スキャナー、シークレットマネージャー、アイデンティティプロバイダー)、発見を是正するエンジニアの時間、セキュアな既定のささやかな摩擦が含まれます。それに対して、飛ばすコストを量ってください。インジェクションと壊れたアクセス制御の侵害は、日常的に数百万のレコードを露出させ、規制上の罰金、義務的な通知、不正による損失、是正のスプリント、何年も収益を抑える評判の損害を引き起こします。

ROIは、統制が自動化され再利用されるときに最も強くなります。よく設定された一つのアイデンティティの統合、共有フレームワークの強化された一つのクエリ層、脆弱な依存関係をブロックする一つのパイプラインが、サービスあたりの限界コストでフリート全体を守ります。特にサプライチェーンの統制は、任意から不可欠になりました。侵害された依存関係は、すべての顧客を被害者に変ええますし、規制当局と企業の買い手は、取引の条件として、ますますSBOMと署名された来歴を求めています。リーダーシップに論拠を示すときは、投資を、特定の名前のあるリスクと、満たさなければ収益をブロックする調達とコンプライアンスの要件に結びつけてください。

アンチパターンと落とし穴

暗号や認証の自前実装。 ほとんど常に、微妙で悪用可能な欠陥を生みます。
クライアント側だけの検証。 簡単に回避されます。サーバーはすべてを再検証しなければなりません。
ブロックリストによる無害化。 良い文字を許可リストにするのではなく「悪い」文字を取り除こうとすること。攻撃者はギャップを見つけます。
ソースや環境ファイルのシークレット。 資格情報の漏洩の、単一で最も一般的な原因。
オブジェクトアクセスの認可の無視。 認証されたユーザーが、IDを推測できるどんなオブジェクトにもアクセスしてよいと想定すること。
設定して忘れる依存関係。 侵害が強いるまで、サードパーティの構成要素を決して更新しないこと。
Top 10をゴールと見なす。 それは床であって、包括的な標準ではありません。深さにはASVSを使います。
機微なデータのログ出力。 パスワード、トークン、ログの中のPII(個人を特定できる情報)は、起こるのを待っている侵害になります。

成熟度モデル

レベル1: 開始。 アプリケーションセキュリティは個々の開発者の知識に依存し、インシデントの後にだけ反応します。標準の統制はありません。シークレットはソースにあります。依存関係はめったに更新されません。認証は独自でその場しのぎで、インジェクションや壊れたアクセス制御の欠陥は、プロセスではなく運で見つかります。

レベル2: 発展。 基本的な実践が現れますが、チームごとに異なります。OWASP Top 10の認識が広がり、フレームワークレベルの保護の一部が整い、シークレットマネージャーは存在しますが不均一に使われます。依存関係のスキャンはときどき実行されます。新しいシステムは標準のアイデンティティプロバイダーを採用しますが、古いサービスは自前のログインフローに手をつけずに保ちます。

レベル3: 標準化。 統制が文書化され、組織全体で徹底されています。ASVSに基づく要件がリスク階層ごとに設定され、パラメータ化クエリと出力のエンコードが標準で、MFAを備えた中央のアイデンティティプロバイダーが必須です。シークレットは自動的に管理されスキャンされ、SBOMが作られ、依存関係のスキャンがすべてのパイプラインで動きます。

レベル4: 管理。 実践が、ベースラインに対して測定され、制御されています。スキャンとテストのカバレッジ、重大度ごとの是正までの平均時間、舗装された道の既定を引き継ぐサービスの割合、資格情報とシークレットのローテーションの経過日数、ASVSへの適合が、すべてダッシュボードで追跡されます。例外は期限付きで記録され、ベースラインからのずれは行動を引き起こし、リリースは判断ではなく、定義されたセキュリティの閾値でゲートされます。

レベル5: オーケストレーション。 セキュリティは、組織全体で継続的に改善され、統合されています。セキュアな既定が舗装された道のフレームワークに組み込まれて安全な道が自動的になり、短命の資格情報があらゆる所で使われ、署名と来歴(SLSA)を伴う完全なサプライチェーンの保証が標準です。検証は継続的で、新しい脆弱性への対応は迅速で測定され、各インシデントが共有のテンプレートにフィードバックされるので、一つの修正がフリート全体を強化します。

議論のためのアイデア

多くのサービスにわたって一貫して保守可能であるために、認可のロジックはどこに住むべきですか。
露出と変動のトレードオフを考えると、依存関係をどれだけ積極的に更新すべきですか。
ポートフォリオの各クラスのアプリケーションに、どのASVSのレベルが適切ですか。
脆いスキャン発行インフラを作らずに、長寿命のシークレットをどう排除しますか。
すべての成果物のSBOMと来歴を、あなたの組織が作り、消費するには何が必要ですか。
デリバリーの圧力のもとで、セキュアな既定がオフにされるのをどう防ぎますか。

要点

OWASP Top 10は必須の知識で、ASVSがテスト可能な標準を与えます。
入力の検証、パラメータ化、出力のエンコードを重ね、インジェクションとXSSを打ち負かします。
検証済みのプロトコル(OAuth 2.0、OIDC)を使ってMFAを徹底し、認証をゼロから作ってはいけません。
すべてのリクエストとすべてのオブジェクトで、サーバー側で認可を徹底します。
シークレットをソースの外に置き、中央で管理し、短命の資格情報にローテーションします。
サプライチェーンは主要な攻撃面です。SBOM、SCA、署名、来歴(SLSA)を使います。
自動化され再利用可能な統制は、サービスあたりの限界コストでフリート全体を守ります。

参考文献とさらなる読み物

OWASP, Top 10 Web Application Security Risks
OWASP, Application Security Verification Standard (ASVS)
OWASP, Cheat Sheet Series (Input Validation, Authentication, Authorisation, Secrets Management)
Dafydd Stuttard and Marcus Pinto, The Web Application Hacker’s Handbook
Aaron Parecki, OAuth 2.0 Simplified
National Institute of Standards and Technology, SP 800-63: Digital Identity Guidelines
Cloud Native Computing Foundation and OpenSSF, SLSA framework and Supply-chain Security guidance