はじめに
AWS Security Agentでは、設計書レビューやコードレビューの際に、基準となるセキュリティ要件に従ってレビューを行います。予めAWS側で用意されたマネージド要件に加え、独自の要件をカスタムセキュリティ要件として追加することも可能です。
しかし、このカスタムセキュリティ要件の登録が結構クセの強い仕様となっています。そのうえ、本記事執筆時点では公式ドキュメントにもあまり情報が無かったため、今回調査した内容をまとめておくことにしました。
AWS Security Agentの設計書レビュー・コードレビューは、本記事執筆時点（2026年7月29日）ではプレビュー機能です。関連設定であるカスタムセキュリティ要件の仕様についても、今後アップデートされる可能性があります。予めご承知おきください。
日本語のファイルをアップロードしても、要件は英語で登録される
カスタムセキュリティ要件は、手動設定以外に、セキュリティ要件が記載されたドキュメントをアップロードして登録することも可能です。AWS Security Agentがファイルの内容を読み取り、要件に落とし込みます。
詳細は以下の公式ドキュメントを参照ください。
日本語のファイルをアップロードしてもちゃんと読み取ってくれるのですが、登録される要件は全て英語となります。
実際に試してみます。以下のサンプルマークダウンを使います。日本語の要件が3つ記載されています。
# security requirment 01
## Security requirement name
認証の多要素化
## 適用性
ユーザー認証を必要とする全てのシステムに適用されます。
## 説明
不正アクセスのリスクを低減するため、多要素認証（MFA）を実装してください。
## コンプライアンス条件
準拠システムは、パスワードに加え、ワンタイムパスワード（OTP）、生体認証、ハードウェアトークン等の少なくとも1つの追加認証要素をサポートする必要があります。特に特権アカウントおよびリモートアクセスにおいてはMFAを必須とし、その実装方法と対象範囲を文書化する必要があります。
# security requirment 02
## Security requirement name
パスワードポリシーの適用
## 適用性
パスワードベースの認証を使用する全てのシステムに適用されます。
## 説明
強度の高いパスワードの使用を強制するポリシーを実装してください。
## コンプライアンス条件
準拠システムは、最小文字数（12文字以上）、大文字・小文字・数字・特殊文字の組み合わせ要件、パスワード履歴の管理（過去12回分の再利用禁止）、および定期的な変更要求（90日以内）を実装する必要があります。パスワードポリシーの設定内容と適用範囲を文書化する必要があります。
# security requirment 03
## Security requirement name
通信の暗号化
## 適用性
ネットワーク経由でデータを送受信する全てのシステムに適用されます。
## 説明
転送中のデータを盗聴や改ざんから保護するため、通信を暗号化してください。
## コンプライアンス条件
準拠システムは、TLS 1.2以上を使用して全ての通信を暗号化する必要があります。自己署名証明書の使用は本番環境では禁止し、信頼された認証局が発行した証明書を使用する必要があります。暗号化プロトコルのバージョン、暗号スイート、および証明書管理方法を文書化する必要があります。
このファイルを使って登録してみます。
2、3分待つと要件が作成されましたが、全て英語になっています。
肝心の内容ですが、ファイルの記載をちゃんと汲み取って反映してくれているようです。ただし直訳ではなく、AIが生成した文章になっています。
ちなみに、同じファイルをアップロードしても、作成される要件は毎回微妙に変わります。件数が1、2件変わったり、文章が少し変わったりします。
「同じ入力に対しても出力が変わる」のは生成AI全般に言える話ですが、Security Agentも例外ではありません。
公式ドキュメントに記載の無い上限値がある
カスタムセキュリティ要件の上限値については、以下の公式ドキュメントに記載があります。
2026年7月28日時点では、「アカウント/リージョン毎に20件」となっており、上限緩和不可となっています。
しかし、実際に登録してみると、もっと多くの要件が登録できました。また、もっと細かい粒度で上限の要素がありました。自分のアカウントで確認できた上限は以下です。（東京リージョンで確認）
| 種別 | 上限値 |
|---|---|
| カスタムセキュリティ要件パック | 20パック/リージョン |
| カスタムセキュリティ要件 | 30件/要件パック |
| ファイルアップロードで登録できる要件 | 20件/要件パック |
| 同時に有効にできる要件 | 150件/リージョン |
つまり、1リージョンに登録できるセキュリティ要件は最大で30件×20パック=600件となります。
ただし、そのうち同時に有効化できる要件は150件までです。
実際に確認した時のエビデンスを以下に記載します。
カスタムセキュリティ要件パック
適当な名前でセキュリティ要件パックを作成していきます。20パックまで作成できました。
どのパックにも、要件は1件も入っていない状態です。
この状態で、もう1パック追加しようとした所、「最大クォータに達しました」というエラーメッセージが表示されました。
カスタムセキュリティ要件
1つのカスタムセキュリティ要件パックに登録できる要件数の上限値です。
同じパック内に適当な名前の要件を追加していくと、30件まで登録できました。
この状態で、もう1要件追加しようとした所、やはり「最大クォータに達しました」というエラーメッセージが表示されました。
ファイルアップロードで登録できる要件
ファイルアップロードでは、20件までしか要件が登録されません。ファイル内に21件以上の要件が記載されていたとしても、20件分しか登録されないようです。
試しに、30件のセキュリティ要件が記載された、以下のマークダウンファイルをアップロードします。
サンプルセキュリティ要件ファイル
# security requirment 01
## Security requirement name
認証の多要素化
## 適用性
ユーザー認証を必要とする全てのシステムに適用されます。
## 説明
不正アクセスのリスクを低減するため、多要素認証（MFA）を実装してください。
## コンプライアンス条件
準拠システムは、パスワードに加え、ワンタイムパスワード（OTP）、生体認証、ハードウェアトークン等の少なくとも1つの追加認証要素をサポートする必要があります。特に特権アカウントおよびリモートアクセスにおいてはMFAを必須とし、その実装方法と対象範囲を文書化する必要があります。
# security requirment 02
## Security requirement name
パスワードポリシーの適用
## 適用性
パスワードベースの認証を使用する全てのシステムに適用されます。
## 説明
強度の高いパスワードの使用を強制するポリシーを実装してください。
## コンプライアンス条件
準拠システムは、最小文字数（12文字以上）、大文字・小文字・数字・特殊文字の組み合わせ要件、パスワード履歴の管理（過去12回分の再利用禁止）、および定期的な変更要求（90日以内）を実装する必要があります。パスワードポリシーの設定内容と適用範囲を文書化する必要があります。
# security requirment 03
## Security requirement name
通信の暗号化
## 適用性
ネットワーク経由でデータを送受信する全てのシステムに適用されます。
## 説明
転送中のデータを盗聴や改ざんから保護するため、通信を暗号化してください。
## コンプライアンス条件
準拠システムは、TLS 1.2以上を使用して全ての通信を暗号化する必要があります。自己署名証明書の使用は本番環境では禁止し、信頼された認証局が発行した証明書を使用する必要があります。暗号化プロトコルのバージョン、暗号スイート、および証明書管理方法を文書化する必要があります。
# security requirment 04
## Security requirement name
保存データの暗号化
## 適用性
機密データや個人情報を保存する全てのシステムに適用されます。
## 説明
保存されたデータへの不正アクセスに備え、データを暗号化して保存してください。
## コンプライアンス条件
準拠システムは、AES-256等の強力な暗号化アルゴリズムを使用して機密データを暗号化して保存する必要があります。暗号鍵の管理には専用の鍵管理サービス（KMS等）を使用し、鍵のローテーション、アクセス制御、およびバックアップ手順を文書化する必要があります。
# security requirment 05
## Security requirement name
最小権限の原則
## 適用性
アクセス制御を実装する全てのシステムに適用されます。
## 説明
ユーザーおよびサービスに対して、業務遂行に必要最小限の権限のみを付与してください。
## コンプライアンス条件
準拠システムは、ロールベースアクセス制御（RBAC）または属性ベースアクセス制御（ABAC）を実装し、各ロールに付与された権限が業務上の必要性に基づいていることを文書化する必要があります。権限の定期的な棚卸し（少なくとも四半期に1回）を実施し、不要な権限を速やかに削除するプロセスを確立する必要があります。
# security requirment 06
## Security requirement name
入力データのバリデーション
## 適用性
外部からのデータ入力を受け付ける全てのシステムに適用されます。
## 説明
インジェクション攻撃やデータ破損を防止するため、全ての入力データを検証してください。
## コンプライアンス条件
準拠システムは、サーバーサイドで全ての入力データに対してホワイトリスト方式のバリデーションを実装する必要があります。SQLインジェクション、XSS、コマンドインジェクション等の攻撃を防止するため、パラメータ化クエリの使用、出力エスケープ、および入力長・型・範囲の検証を実施する必要があります。バリデーションルールとその適用箇所を文書化する必要があります。
# security requirment 07
## Security requirement name
セッション管理
## 適用性
ユーザーセッションを管理する全てのWebアプリケーションに適用されます。
## 説明
セッションハイジャックやセッション固定攻撃を防止するため、適切なセッション管理を実装してください。
## コンプライアンス条件
準拠システムは、セッションIDの十分なランダム性の確保、認証成功後のセッションID再生成、適切なセッションタイムアウト（アイドル時15分以内、絶対時間8時間以内）、セキュアなCookie属性（Secure、HttpOnly、SameSite）の設定を実装する必要があります。セッション管理の設計と設定内容を文書化する必要があります。
# security requirment 08
## Security requirement name
脆弱性管理
## 適用性
ソフトウェアコンポーネントを使用する全てのシステムに適用されます。
## 説明
既知の脆弱性によるリスクを低減するため、定期的な脆弱性スキャンとパッチ適用を実施してください。
## コンプライアンス条件
準拠システムは、定期的な脆弱性スキャン（少なくとも月1回）を実施し、Critical/Highの脆弱性は発見から30日以内に修正する必要があります。使用する全てのサードパーティライブラリ・フレームワークの一覧（SBOM）を管理し、セキュリティアドバイザリの監視と迅速なパッチ適用プロセスを文書化する必要があります。
# security requirment 09
## Security requirement name
エラーハンドリングと情報漏洩防止
## 適用性
ユーザーにエラー情報を返す全てのシステムに適用されます。
## 説明
エラーメッセージを通じた機密情報の漏洩を防止してください。
## コンプライアンス条件
準拠システムは、ユーザーに表示するエラーメッセージにスタックトレース、データベース情報、内部パス、技術的詳細を含めてはなりません。詳細なエラー情報はサーバーサイドのログにのみ記録し、ユーザーにはユーザーフレンドリーな一般的エラーメッセージのみを返す必要があります。エラーハンドリングの方針を文書化する必要があります。
# security requirment 10
## Security requirement name
アカウントロックアウト
## 適用性
ユーザー認証を必要とする全てのシステムに適用されます。
## 説明
ブルートフォース攻撃を防止するため、アカウントロックアウト機能を実装してください。
## コンプライアンス条件
準拠システムは、連続した認証失敗（5回以内）が発生した場合にアカウントを一時的にロックする機能を実装する必要があります。ロックアウト期間（最低15分）、ロック解除条件、管理者による手動解除手順、およびロックアウトイベントの通知メカニズムを文書化する必要があります。
# security requirment 11
## Security requirement name
セキュリティヘッダーの実装
## 適用性
HTTPレスポンスを返す全てのWebアプリケーションに適用されます。
## 説明
ブラウザベースの攻撃を軽減するため、適切なセキュリティヘッダーを設定してください。
## コンプライアンス条件
準拠システムは、Content-Security-Policy、X-Content-Type-Options、X-Frame-Options、Strict-Transport-Security、X-XSS-Protection、Referrer-Policy等のセキュリティヘッダーを適切に設定する必要があります。各ヘッダーの設定値とその理由を文書化する必要があります。
# security requirment 12
## Security requirement name
APIセキュリティ
## 適用性
外部または内部にAPIを公開する全てのシステムに適用されます。
## 説明
APIの不正利用を防止するため、適切な認証・認可・レート制限を実装してください。
## コンプライアンス条件
準拠システムは、APIアクセスに対する認証（OAuth 2.0、APIキー等）、エンドポイントごとの認可チェック、レート制限（IPベースおよびユーザーベース）、リクエストサイズの制限を実装する必要があります。APIのセキュリティ設計、認証方式、レート制限の閾値を文書化する必要があります。
# security requirment 13
## Security requirement name
データバックアップと復旧
## 適用性
業務上重要なデータを保持する全てのシステムに適用されます。
## 説明
データ損失やランサムウェア攻撃に備え、定期的なバックアップと復旧手順を確立してください。
## コンプライアンス条件
準拠システムは、定期的な自動バックアップ（少なくとも日次）、バックアップデータの暗号化、オフサイト保管（3-2-1ルール）、および復旧手順のテスト（少なくとも四半期に1回）を実施する必要があります。RPO（目標復旧時点）とRTO（目標復旧時間）を定義し、バックアップ・復旧手順を文書化する必要があります。
# security requirment 14
## Security requirement name
ネットワークセグメンテーション
## 適用性
複数のシステムコンポーネントがネットワーク接続される全てのシステムに適用されます。
## 説明
侵害の横展開を防止するため、ネットワークをセグメント化してください。
## コンプライアンス条件
準拠システムは、DMZ、アプリケーション層、データベース層等を論理的または物理的に分離し、各セグメント間の通信を必要最小限に制限する必要があります。ファイアウォールルール、セキュリティグループ、ネットワークACLの設定内容と設計根拠を文書化する必要があります。
# security requirment 15
## Security requirement name
特権アクセス管理
## 適用性
管理者権限やシステム運用権限を持つアカウントが存在する全てのシステムに適用されます。
## 説明
特権アカウントの不正使用や侵害リスクを低減するため、特権アクセスを厳格に管理してください。
## コンプライアンス条件
準拠システムは、特権アカウントの一覧管理、共有アカウントの禁止、特権操作の承認ワークフロー、特権セッションの記録・監視、および特権アカウントの定期的なレビュー（少なくとも月1回）を実装する必要があります。特権アクセス管理のポリシーと手順を文書化する必要があります。
# security requirment 16
## Security requirement name
セキュアなソフトウェア開発ライフサイクル（SSDLC）
## 適用性
ソフトウェアを開発する全てのプロジェクトに適用されます。
## 説明
開発プロセス全体を通じてセキュリティを組み込むため、セキュアな開発ライフサイクルを実践してください。
## コンプライアンス条件
準拠プロジェクトは、セキュリティ要件の定義、脅威モデリング、セキュアコーディング規約の遵守、静的解析（SAST）の実施、コードレビューにおけるセキュリティ観点の確認、およびリリース前のセキュリティテストを実施する必要があります。各フェーズのセキュリティ活動とその実施結果を文書化する必要があります。
# security requirment 17
## Security requirement name
インシデント対応計画
## 適用性
本番環境で運用される全てのシステムに適用されます。
## 説明
セキュリティインシデント発生時に迅速かつ適切に対応するため、インシデント対応計画を策定してください。
## コンプライアンス条件
準拠組織は、インシデントの検知・分類・封じ込め・根絶・復旧・事後分析の各フェーズにおける手順、エスカレーションフロー、連絡体制、および外部報告要件を定義する必要があります。インシデント対応計画は少なくとも年1回のテスト（机上演習または実地訓練）を実施し、その結果に基づいて計画を更新する必要があります。
# security requirment 18
## Security requirement name
サードパーティリスク管理
## 適用性
外部のサービス、ライブラリ、またはベンダーを利用する全てのシステムに適用されます。
## 説明
サードパーティ経由のセキュリティリスクを管理するため、適切な評価と監視を実施してください。
## コンプライアンス条件
準拠システムは、サードパーティのセキュリティ評価（導入前および定期的）、契約におけるセキュリティ要件の明記、サードパーティアクセスの最小権限化、およびサードパーティのセキュリティインシデントへの対応手順を確立する必要があります。サードパーティの一覧と各社のリスク評価結果を文書化する必要があります。
# security requirment 19
## Security requirement name
データ分類とラベリング
## 適用性
複数の機密レベルのデータを取り扱う全てのシステムに適用されます。
## 説明
データの機密レベルに応じた適切な保護を実施するため、データ分類体系を定義してください。
## コンプライアンス条件
準拠システムは、データ分類体系（例：公開、社内限定、機密、極秘）を定義し、各分類レベルに応じたアクセス制御、暗号化、保存・廃棄ルールを実装する必要があります。データオーナーの割り当て、分類基準、および分類に基づく取り扱いルールを文書化する必要があります。
# security requirment 20
## Security requirement name
セキュリティ教育・意識向上
## 適用性
システムの開発・運用に関わる全ての要員に適用されます。
## 説明
人的リスクを低減するため、定期的なセキュリティ教育と意識向上活動を実施してください。
## コンプライアンス条件
準拠組織は、全従業員に対する年1回以上のセキュリティ意識向上研修、開発者向けのセキュアコーディング研修、フィッシング対策訓練、および新入社員向けセキュリティオリエンテーションを実施する必要があります。研修の実施計画、参加率、およびテスト結果を文書化する必要があります。
# security requirment 21
## Security requirement name
変更管理
## 適用性
本番環境に変更を加える全てのシステムに適用されます。
## 説明
無許可または不適切な変更によるセキュリティリスクを防止するため、変更管理プロセスを確立してください。
## コンプライアンス条件
準拠システムは、全ての変更に対する承認プロセス、変更前のセキュリティ影響評価、ロールバック手順の策定、変更後のセキュリティ検証、および変更履歴の記録を実施する必要があります。変更管理のポリシー、承認フロー、および緊急変更手順を文書化する必要があります。
# security requirment 22
## Security requirement name
ログの保護と保存
## 適用性
監査ログを生成する全てのシステムに適用されます。
## 説明
ログの改ざん・削除を防止し、インシデント調査に十分な期間保存してください。
## コンプライアンス条件
準拠システムは、ログの書き込み専用ストレージへの保存、ログ完全性の検証（ハッシュチェーン等）、アクセス制御によるログの改ざん防止、および法令・規制に基づく保存期間（最低1年間）の確保を実装する必要があります。ログの保存場所、保存期間、保護メカニズム、およびアーカイブ手順を文書化する必要があります。
# security requirment 23
## Security requirement name
CSRF対策
## 適用性
状態変更を伴うリクエストを受け付ける全てのWebアプリケーションに適用されます。
## 説明
クロスサイトリクエストフォージェリ攻撃を防止するため、適切な対策を実装してください。
## コンプライアンス条件
準拠システムは、CSRFトークンの生成と検証、SameSite Cookie属性の設定、Originヘッダーの検証、および重要な操作に対する再認証を実装する必要があります。CSRF対策の実装方法と適用範囲を文書化する必要があります。
# security requirment 24
## Security requirement name
シークレット管理
## 適用性
APIキー、パスワード、証明書等のシークレットを使用する全てのシステムに適用されます。
## 説明
シークレットの漏洩を防止するため、専用のシークレット管理ソリューションを使用してください。
## コンプライアンス条件
準拠システムは、ソースコードやバージョン管理システムへのシークレットの格納禁止、専用のシークレット管理サービス（AWS Secrets Manager、HashiCorp Vault等）の使用、シークレットの定期的なローテーション、およびシークレットへのアクセスの監査を実装する必要があります。シークレット管理のポリシー、ローテーション計画、およびアクセス権限を文書化する必要があります。
# security requirment 25
## Security requirement name
コンテナセキュリティ
## 適用性
コンテナ技術を使用する全てのシステムに適用されます。
## 説明
コンテナ環境におけるセキュリティリスクを低減するため、適切なセキュリティ対策を実装してください。
## コンプライアンス条件
準拠システムは、最小限のベースイメージの使用、コンテナイメージの脆弱性スキャン、非rootユーザーでの実行、コンテナ間のネットワーク分離、および信頼できるレジストリからのイメージ取得のみを実装する必要があります。コンテナセキュリティのポリシー、イメージ管理手順、およびランタイムセキュリティ設定を文書化する必要があります。
# security requirment 26
## Security requirement name
DDoS対策
## 適用性
インターネットに公開される全てのシステムに適用されます。
## 説明
分散型サービス拒否攻撃によるサービス停止を防止するため、適切な対策を実装してください。
## コンプライアンス条件
準拠システムは、CDN・WAF・レート制限等のDDoS緩和策の導入、トラフィックの異常検知、オートスケーリングの設定、およびDDoS攻撃発生時の対応手順を確立する必要があります。DDoS対策のアーキテクチャ、検知閾値、および対応手順を文書化する必要があります。
# security requirment 27
## Security requirement name
データの安全な廃棄
## 適用性
機密データを保存する全てのシステムおよびストレージ媒体に適用されます。
## 説明
データのライフサイクル終了時に、復元不可能な方法でデータを安全に廃棄してください。
## コンプライアンス条件
準拠システムは、データ保存期間の定義、保存期間満了後の確実な削除（暗号学的消去またはセキュアワイプ）、物理媒体の破壊手順、およびクラウド環境での論理的消去の確認を実施する必要があります。データ廃棄のポリシー、手順、および廃棄証明の記録方法を文書化する必要があります。
# security requirment 28
## Security requirement name
セキュリティ監視とアラート
## 適用性
本番環境で運用される全てのシステムに適用されます。
## 説明
セキュリティ脅威の早期検知と対応のため、リアルタイム監視とアラートを実装してください。
## コンプライアンス条件
準拠システムは、SIEM等を活用したログの集約・相関分析、異常検知ルールの定義、セキュリティイベントに対するアラートの即座の発報、およびアラートの優先度に応じた対応手順を確立する必要があります。監視対象、検知ルール、アラート条件、およびエスカレーションフローを文書化する必要があります。
# security requirment 29
## Security requirement name
開発環境と本番環境の分離
## 適用性
複数の環境（開発、ステージング、本番等）を持つ全てのシステムに適用されます。
## 説明
本番環境の安全性を確保するため、開発環境と本番環境を厳格に分離してください。
## コンプライアンス条件
準拠システムは、環境ごとに独立したインフラ・アカウント・認証情報を使用し、本番データの開発環境への持ち出し禁止（匿名化されたテストデータの使用）、環境間のネットワーク分離、および環境昇格時のセキュリティ検証プロセスを実装する必要があります。環境分離のアーキテクチャとデプロイフローを文書化する必要があります。
# security requirment 30
## Security requirement name
個人情報保護とプライバシー
## 適用性
個人情報（PII）を取り扱う全てのシステムに適用されます。
## 説明
法令（個人情報保護法、GDPR等）に準拠し、個人情報を適切に保護してください。
## コンプライアンス条件
準拠システムは、個人情報の収集目的の明示と同意取得、利用目的の制限、データ主体の権利行使（アクセス・訂正・削除）への対応、プライバシー影響評価の実施、および個人情報取り扱い台帳の管理を実装する必要があります。プライバシーポリシー、個人情報の取り扱い手順、およびデータフロー図を文書化する必要があります。
ファイルをアップロードして、「要件を作成」ボタンを押します。
数分待った後、セキュリティ要件が登録されましたが、20件しか登録されていません。
何度試しても20件しか登録されなかったものの、「そんな仕様ある？」と不安になったため、AWSサポートへ問い合わせました。するとやはり仕様であるとの回答でした。
ちなみに、ファイルアップロードを2回に分けて実施すれば30件登録出来そうに思えますが、ダメでした。ファイルアップロードをやり直すと、全ての要件が再生成されるためです。
つまり、ファイルアップロードだけで要件を登録したい場合、登録できる要件は20パック×20要件=400件までです。
同時に有効化できる件数
5つのセキュリティ要件パックに30個ずつセキュリティ要件を登録して、150件まで登録できています。すべてのセキュリティ要件が有効化された状態です。
この状態で、有効化済みのセキュリティパックに、要件を追加してみます。
まだ1件も要件が登録されていないパックにも関わらず、「最大クォータに達しました」というエラーが出ました。
ファイルアップロードも試してみます。
エラーになりましたが、「最大クォータに達しました」ではなく、「アップロードされたドキュメントからセキュリティ要件を生成できませんでした。ファイルをもう一度アップロードしてください。」というエラーが出ました。
ただし、要求通りに再度ファイルをアップロードしても、この状態では再度エラーになります。ファイルアップロードの場合は、エラーメッセージから上限に達したことが読み取れないのでご注意ください。
では、今度は同じパックを無効化した状態で、要件を追加してみます。
今度は追加できました。登録の上限ではなく、有効化数の上限に抵触していたことが分かります。
セキュリティ要件パックが有効化されていると、登録した要件も自動で全て有効化扱いになります。 登録の際は、パックのステータスにご注意ください。
(補足) 有効化の残件より多い要件が記載されたファイルをアップロードした場合
例えば、131件のカスタムセキュリティが有効化された状態（＝残り19件、要件を有効化可能な状態）で、20件以上セキュリティ要件が記載されたファイルをアップロードしたらどうなるでしょうか？
この場合は、1件も登録されずにエラーとなります。19件分だけ登録されるということはありませんでした。
実際に試してみます。まず、有効なセキュリティ要件が131件登録された状態を作ります。
有効化されたセキュリティパックに、先ほどの、セキュリティ要件が30件記載されたファイルをアップロードします。（実際には20件までしか登録できない）
19件分は登録の余地があるはずですが、1件も登録されることなくエラーになりました。
セキュリティパックを無効化した状態であれば、登録は成功します。
おわりに
以上、カスタムセキュリティ要件の登録に関するクセ強仕様の紹介でした。
設計書レビュー・コードレビューがプレビュー版なためか分かりませんが、公式にもあまり情報がなく、エラーメッセージも少しおかしかったりと、切り分けが少々大変でした。
ただ、設計書レビュー・コードレビューがGAされれば、ドキュメントや仕様もアップデートされていくかもしれません。
本記事は情報の有用性という意味では短命になるかもしれませんが、記事執筆時点でSecurity Agentのカスタムセキュリティ要件を扱う方のお役に立てば幸いです。