From a8602cdcaf0a59cac67479bcc34b4216493ab41b Mon Sep 17 00:00:00 2001
From: marq <classicvector63@gmail.com>
Date: Fri, 27 Feb 2026 23:36:49 +0530
Subject: [PATCH] feat: Enrich ASVS mapping with Description and Level

---
 scripts/convert_capec_map_to_asvs_map.py      |   89 +-
 source/webapp-asvs-3.0.yaml                   | 1522 +++++++++++++++++
 .../convert_capec_map_to_asvs_map_utest.py    |  270 ++-
 3 files changed, 1877 insertions(+), 4 deletions(-)

diff --git a/scripts/convert_capec_map_to_asvs_map.py b/scripts/convert_capec_map_to_asvs_map.py
index 6da1a63b7..d85f35597 100644
--- a/scripts/convert_capec_map_to_asvs_map.py
+++ b/scripts/convert_capec_map_to_asvs_map.py
@@ -1,6 +1,7 @@
 #!/usr/bin/env python3
 # This script converts the CAPEC mappings from webapp-mappings YAML files
 # to a consolidated CAPEC-to-ASVS mapping file and a ASVS-to-CAPEC mapping file in source dir.
+import json
 import argparse
 import logging
 import sys
@@ -13,6 +14,10 @@
 class ConvertVars:
     TEMPLATE_FILE_NAME: str = "EDITION-TEMPLATE-VERSION.yaml"
     DEFAULT_INPUT_PATH = Path(__file__).parent / "../source/webapp-mappings-3.0.yaml"
+    DEFAULT_ASVS_JSON_PATH = (
+        Path(__file__).parent
+        / "../cornucopia.owasp.org/data/asvs-5.0/en/OWASP_Application_Security_Verification_Standard_5.0.0_en.json"
+    )
     DEFAULT_OUTPUT_PATH = Path(__file__).parent / "../source"
     args: argparse.Namespace
 
@@ -123,7 +128,10 @@ def _extract_and_add_asvs_requirements(
 
 
 def convert_to_output_format(
-    capec_map: dict[Any, set[str]], parameter: str = "owasp_asvs", meta: dict[str, Any] | None = None
+    capec_map: dict[Any, set[str]],
+    parameter: str = "owasp_asvs",
+    meta: dict[str, Any] | None = None,
+    enrichment_data: dict[str, dict[str, str]] | None = None,
 ) -> Dict[str, Any]:
     """
     Convert the internal mapping format to the output YAML format.
@@ -133,7 +141,13 @@ def convert_to_output_format(
         output["meta"] = meta
 
     for code, asvs_set in sorted(capec_map.items()):
-        output[code] = {parameter: sorted(list(asvs_set))}
+        entry: dict[str, Any] = {parameter: sorted(list(asvs_set))}
+
+        # Enrich with extra data if available (e.g., Description, L)
+        if enrichment_data and code in enrichment_data:
+            entry.update(enrichment_data[code])
+
+        output[code] = entry
 
     return output
 
@@ -156,6 +170,24 @@ def load_yaml_file(filepath: Path) -> dict[str, Any]:
         return {}
 
 
+def load_json_file(filepath: Path) -> dict[str, Any]:
+    """Load and parse a JSON file."""
+    try:
+        with open(filepath, "r", encoding="utf-8") as f:
+            data = json.load(f)
+        logging.info("Successfully loaded JSON file: %s", filepath)
+        return data if data else {}
+    except FileNotFoundError:
+        logging.error("File not found: %s", filepath)
+        return {}
+    except json.JSONDecodeError as e:
+        logging.error("Error parsing JSON file %s: %s", filepath, str(e))
+        return {}
+    except Exception as e:
+        logging.error("Error loading JSON file %s: %s", filepath, str(e))
+        return {}
+
+
 def save_yaml_file(filepath: Path, data: Dict[str, Any]) -> bool:
     """Save data as YAML file."""
     try:
@@ -209,6 +241,12 @@ def parse_arguments(input_args: list[str]) -> argparse.Namespace:
         default=ConvertVars.DEFAULT_OUTPUT_PATH,
         help="Directory to save converted CAPEC-to-ASVS mapping YAML files",
     )
+    parser.add_argument(
+        "--asvs-json",
+        type=validate_filepath_arg,
+        default=ConvertVars.DEFAULT_ASVS_JSON_PATH,
+        help="Path to ASVS JSON file for enrichment",
+    )
     parser.add_argument(
         "-d",
         "--debug",
@@ -223,6 +261,38 @@ def parse_arguments(input_args: list[str]) -> argparse.Namespace:
     return args
 
 
+def extract_asvs_details(asvs_data: dict[str, Any]) -> dict[str, dict[str, str]]:
+    """
+    Recursively walk the ASVS JSON structure to find requirements and extract their
+    Description and L (level).
+
+    Returns a dict mapping shortcode (e.g. '1.1.1') to details dict.
+    """
+    details = {}
+
+    def _walk(node: Any) -> None:
+        if isinstance(node, dict):
+            # Check if this node is a requirement item
+            if "Shortcode" in node and "Description" in node and "L" in node:
+                # Remove leading 'V' from Shortcode if present
+                code = node["Shortcode"]
+                if code.startswith("V"):
+                    code = code[1:]
+
+                details[code] = {"description": node["Description"], "level": node["L"]}
+
+            # Recurse into children
+            for key, value in node.items():
+                _walk(value)
+        elif isinstance(node, list):
+            for item in node:
+                _walk(item)
+
+    _walk(asvs_data)
+    logging.info("Extracted details for %d ASVS requirements", len(details))
+    return details
+
+
 def main() -> None:
     """Main execution function."""
     convert_vars.args = parse_arguments(sys.argv[1:])
@@ -260,6 +330,16 @@ def main() -> None:
         logging.error("Failed to load input data or file is empty")
         sys.exit(1)
 
+    # Load ASVS JSON for enrichment
+    asvs_details = {}
+    if convert_vars.args.asvs_json:
+        asvs_json_path = Path(convert_vars.args.asvs_json).resolve()
+        asvs_data = load_json_file(asvs_json_path)
+        if asvs_data:
+            asvs_details = extract_asvs_details(asvs_data)
+        else:
+            logging.warning("Failed to load ASVS JSON, skipping enrichment")
+
     # Extract meta information
     meta = data.get("meta", {}).copy()
     if meta:
@@ -282,7 +362,10 @@ def main() -> None:
     logging.info("Total CAPEC codes processed: %d", len(output_data) - (1 if meta else 0))
 
     asvs_to_capec_map = extract_asvs_to_capec_mappings(data)
-    output_data_asvs = convert_to_output_format(asvs_to_capec_map, parameter="capec_codes", meta=meta)
+    # Pass enrichment data here
+    output_data_asvs = convert_to_output_format(
+        asvs_to_capec_map, parameter="capec_codes", meta=meta, enrichment_data=asvs_details
+    )
     # Save output YAML
     if not save_yaml_file(asvs_output_path, output_data_asvs):
         logging.error("Failed to save asvs output file")
diff --git a/source/webapp-asvs-3.0.yaml b/source/webapp-asvs-3.0.yaml
index 5ec82f86e..c97c614f0 100644
--- a/source/webapp-asvs-3.0.yaml
+++ b/source/webapp-asvs-3.0.yaml
@@ -42,6 +42,11 @@ meta:
   - '79'
   - '80'
   - '88'
+  description: Verify that input is decoded or unescaped into a canonical form only
+    once, it is only decoded when encoded data in that form is expected, and that
+    this is done before processing the input further, for example it is not performed
+    after input validation or sanitization.
+  level: '2'
 1.1.2:
   capec_codes:
   - '120'
@@ -58,6 +63,10 @@ meta:
   - '79'
   - '80'
   - '88'
+  description: Verify that the application performs output encoding and escaping either
+    as a final step before being used by the interpreter for which it is intended
+    or by the interpreter itself.
+  level: '2'
 1.2.1:
   capec_codes:
   - '152'
@@ -69,6 +78,11 @@ meta:
   - '28'
   - '43'
   - '63'
+  description: Verify that output encoding for an HTTP response, HTML document, or
+    XML document is relevant for the context required, such as encoding the relevant
+    characters for HTML elements, HTML attributes, HTML comments, CSS, or HTTP header
+    fields, to avoid changing the message or document structure.
+  level: '1'
 1.2.10:
   capec_codes:
   - '153'
@@ -81,6 +95,13 @@ meta:
   - '441'
   - '52'
   - '549'
+  description: Verify that the application is protected against CSV and Formula Injection.
+    The application must follow the escaping rules defined in RFC 4180 sections 2.6
+    and 2.7 when exporting CSV content. Additionally, when exporting to CSV or other
+    spreadsheet formats (such as XLS, XLSX, or ODF), special characters (including
+    '=', '+', '-', '@', '\t' (tab), and '\0' (null character)) must be escaped with
+    a single quote if they appear as the first character in a field value.
+  level: '3'
 1.2.2:
   capec_codes:
   - '137'
@@ -97,6 +118,11 @@ meta:
   - '63'
   - '64'
   - '72'
+  description: 'Verify that when dynamically building URLs, untrusted data is encoded
+    according to its context (e.g., URL encoding or base64url encoding for query or
+    path parameters). Ensure that only safe URL protocols are permitted (e.g., disallow
+    javascript: or data:).'
+  level: '1'
 1.2.3:
   capec_codes:
   - '122'
@@ -111,6 +137,10 @@ meta:
   - '63'
   - '636'
   - '93'
+  description: Verify that output encoding or escaping is used when dynamically building
+    JavaScript content (including JSON), to avoid changing the message or document
+    structure (to avoid JavaScript and JSON injection).
+  level: '1'
 1.2.4:
   capec_codes:
   - '153'
@@ -122,6 +152,11 @@ meta:
   - '66'
   - '676'
   - '93'
+  description: Verify that data selection or database queries (e.g., SQL, HQL, NoSQL,
+    Cypher) use parameterized queries, ORMs, entity frameworks, or are otherwise protected
+    from SQL Injection and other database injection attacks. This is also relevant
+    when writing stored procedures.
+  level: '1'
 1.2.5:
   capec_codes:
   - '153'
@@ -131,6 +166,10 @@ meta:
   - '441'
   - '549'
   - '88'
+  description: Verify that the application protects against OS command injection and
+    that operating system calls use parameterized OS queries or use contextual command
+    line output encoding.
+  level: '1'
 1.2.6:
   capec_codes:
   - '136'
@@ -140,6 +179,9 @@ meta:
   - '248'
   - '441'
   - '549'
+  description: Verify that the application protects against LDAP injection vulnerabilities,
+    or that specific security controls to prevent LDAP injection have been implemented.
+  level: '2'
 1.2.7:
   capec_codes:
   - '153'
@@ -150,6 +192,9 @@ meta:
   - '441'
   - '549'
   - '83'
+  description: Verify that the application is protected against XPath injection attacks
+    by using query parameterization or precompiled queries.
+  level: '2'
 1.2.8:
   capec_codes:
   - '153'
@@ -158,6 +203,10 @@ meta:
   - '248'
   - '441'
   - '549'
+  description: Verify that LaTeX processors are configured securely (such as not using
+    the "--shell-escape" flag) and an allowlist of commands is used to prevent LaTeX
+    injection attacks.
+  level: '2'
 1.2.9:
   capec_codes:
   - '120'
@@ -178,6 +227,9 @@ meta:
   - '78'
   - '79'
   - '80'
+  description: Verify that the application escapes special characters in regular expressions
+    (typically using a backslash) to prevent them from being misinterpreted as metacharacters.
+  level: '2'
 1.3.1:
   capec_codes:
   - '152'
@@ -188,6 +240,10 @@ meta:
   - '267'
   - '28'
   - '63'
+  description: Verify that all untrusted HTML input from WYSIWYG editors or similar
+    is sanitized using a well-known and secure HTML sanitization library or framework
+    feature.
+  level: '1'
 1.3.10:
   capec_codes:
   - '135'
@@ -204,6 +260,9 @@ meta:
   - '441'
   - '549'
   - '88'
+  description: Verify that format strings which might resolve in an unexpected or
+    malicious way when used are sanitized before being processed.
+  level: '2'
 1.3.11:
   capec_codes:
   - '152'
@@ -219,6 +278,9 @@ meta:
   - '28'
   - '441'
   - '549'
+  description: Verify that the application sanitizes user input before passing to
+    mail systems to protect against SMTP or IMAP injection.
+  level: '2'
 1.3.12:
   capec_codes:
   - '130'
@@ -227,6 +289,10 @@ meta:
   - '242'
   - '272'
   - '28'
+  description: Verify that regular expressions are free from elements causing exponential
+    backtracking, and ensure untrusted input is sanitized to mitigate ReDoS or Runaway
+    Regex attacks.
+  level: '3'
 1.3.2:
   capec_codes:
   - '152'
@@ -245,6 +311,11 @@ meta:
   - '549'
   - '586'
   - '63'
+  description: Verify that the application avoids the use of eval() or other dynamic
+    code execution features such as Spring Expression Language (SpEL). Where there
+    is no alternative, any user input being included must be sanitized before being
+    executed.
+  level: '1'
 1.3.3:
   capec_codes:
   - '126'
@@ -268,6 +339,10 @@ meta:
   - '66'
   - '676'
   - '88'
+  description: Verify that data being passed to a potentially dangerous context is
+    sanitized beforehand to enforce safety measures, such as only allowing characters
+    which are safe for this context and trimming input which is too long.
+  level: '2'
 1.3.4:
   capec_codes:
   - '152'
@@ -283,6 +358,11 @@ meta:
   - '272'
   - '28'
   - '63'
+  description: Verify that user-supplied Scalable Vector Graphics (SVG) scriptable
+    content is validated or sanitized to contain only tags and attributes (such as
+    draw graphics) that are safe for the application, e.g., do not contain scripts
+    and foreignObject.
+  level: '2'
 1.3.5:
   capec_codes:
   - '152'
@@ -298,6 +378,10 @@ meta:
   - '272'
   - '28'
   - '63'
+  description: Verify that the application sanitizes or disables user-supplied scriptable
+    or expression template language content, such as Markdown, CSS or XSL stylesheets,
+    BBCode, or similar.
+  level: '2'
 1.3.6:
   capec_codes:
   - '152'
@@ -318,6 +402,11 @@ meta:
   - '549'
   - '63'
   - '664'
+  description: Verify that the application protects against Server-side Request Forgery
+    (SSRF) attacks, by validating untrusted data against an allowlist of protocols,
+    domains, paths and ports and sanitizing potentially dangerous characters before
+    using the data to call another service.
+  level: '2'
 1.3.7:
   capec_codes:
   - '152'
@@ -332,6 +421,11 @@ meta:
   - '272'
   - '28'
   - '63'
+  description: Verify that the application protects against template injection attacks
+    by not allowing templates to be built based on untrusted input. Where there is
+    no alternative, any untrusted input being included dynamically during template
+    creation must be sanitized or strictly validated.
+  level: '2'
 1.3.8:
   capec_codes:
   - '152'
@@ -348,6 +442,10 @@ meta:
   - '441'
   - '549'
   - '586'
+  description: Verify that the application appropriately sanitizes untrusted input
+    before use in Java Naming and Directory Interface (JNDI) queries and that JNDI
+    is configured securely to prevent JNDI injection attacks.
+  level: '2'
 1.3.9:
   capec_codes:
   - '141'
@@ -355,6 +453,9 @@ meta:
   - '242'
   - '272'
   - '28'
+  description: Verify that the application sanitizes content before it is sent to
+    memcache to prevent injection attacks.
+  level: '2'
 1.4.1:
   capec_codes:
   - '128'
@@ -365,6 +466,9 @@ meta:
   - '207'
   - '242'
   - '25'
+  description: Verify that the application uses memory-safe string, safer memory copy
+    and pointer arithmetic to detect or prevent stack, buffer, or heap overflows.
+  level: '2'
 1.4.2:
   capec_codes:
   - '128'
@@ -378,6 +482,9 @@ meta:
   - '25'
   - '272'
   - '28'
+  description: Verify that sign, range, and input validation techniques are used to
+    prevent integer overflows.
+  level: '2'
 1.4.3:
   capec_codes:
   - '129'
@@ -386,6 +493,10 @@ meta:
   - '184'
   - '207'
   - '242'
+  description: Verify that dynamically allocated memory and resources are released,
+    and that references or pointers to freed memory are removed or set to null to
+    prevent dangling pointers and use-after-free vulnerabilities.
+  level: '2'
 1.5.1:
   capec_codes:
   - '19'
@@ -395,12 +506,21 @@ meta:
   - '250'
   - '271'
   - '66'
+  description: Verify that the application configures XML parsers to use a restrictive
+    configuration and that unsafe features such as resolving external entities are
+    disabled to prevent XML eXternal Entity (XXE) attacks.
+  level: '1'
 1.5.2:
   capec_codes:
   - '19'
   - '231'
   - '242'
   - '250'
+  description: Verify that deserialization of untrusted data enforces safe input handling,
+    such as using an allowlist of object types or restricting client-defined object
+    types, to prevent deserialization attacks. Deserialization mechanisms that are
+    explicitly defined as insecure must not be used with untrusted input.
+  level: '2'
 1.5.3:
   capec_codes:
   - '126'
@@ -419,6 +539,13 @@ meta:
   - '64'
   - '66'
   - '664'
+  description: Verify that different parsers used in the application for the same
+    data type (e.g., JSON parsers, XML parsers, URL parsers), perform parsing in a
+    consistent way and use the same character encoding mechanism to avoid issues such
+    as JSON Interoperability vulnerabilities or different URI or file parsing behavior
+    being exploited in Remote File Inclusion (RFI) or Server-side Request Forgery
+    (SSRF) attacks.
+  level: '3'
 1.7.1:
   capec_codes:
   - '182'
@@ -434,6 +561,10 @@ meta:
   - '554'
   - '57'
   - '633'
+  description: Verify that tokens are only sent to components that strictly need them.
+    For example, when using a backend-for-frontend pattern for browser-based JavaScript
+    applications, access and refresh tokens shall only be accessible for the backend.
+  level: '2'
 10.1.2:
   capec_codes:
   - '115'
@@ -443,6 +574,14 @@ meta:
   - '554'
   - '57'
   - '633'
+  description: Verify that the client only accepts values from the authorization server
+    (such as the authorization code or ID Token) if these values result from an authorization
+    flow that was initiated by the same user agent session and transaction. This requires
+    that client-generated secrets, such as the proof key for code exchange (PKCE)
+    'code_verifier', 'state' or OIDC 'nonce', are not guessable, are specific to the
+    transaction, and are securely bound to both the client and the user agent session
+    in which the transaction was started.
+  level: '2'
 10.2.1:
   capec_codes:
   - '115'
@@ -450,10 +589,21 @@ meta:
   - '554'
   - '62'
   - '633'
+  description: Verify that, if the code flow is used, the OAuth client has protection
+    against browser-based request forgery attacks, commonly known as cross-site request
+    forgery (CSRF), which trigger token requests, either by using proof key for code
+    exchange (PKCE) functionality or checking the 'state' parameter that was sent
+    in the authorization request.
+  level: '2'
 10.2.2:
   capec_codes:
   - '154'
   - '633'
+  description: Verify that, if the OAuth client can interact with more than one authorization
+    server, it has a defense against mix-up attacks. For example, it could require
+    that the authorization server return the 'iss' parameter value and validate it
+    in the authorization response and the token response.
+  level: '2'
 10.2.3:
   capec_codes:
   - '122'
@@ -469,6 +619,9 @@ meta:
   - '633'
   - '75'
   - '87'
+  description: Verify that the OAuth client only requests the required scopes (or
+    other authorization parameters) in requests to the authorization server.
+  level: '3'
 10.3.1:
   capec_codes:
   - '180'
@@ -477,24 +630,44 @@ meta:
   - '39'
   - '57'
   - '633'
+  description: Verify that the resource server only accepts access tokens that are
+    intended for use with that service (audience). The audience may be included in
+    a structured access token (such as the 'aud' claim in JWT), or it can be checked
+    using the token introspection endpoint.
+  level: '2'
 10.3.2:
   capec_codes:
   - '180'
   - '21'
   - '57'
   - '633'
+  description: Verify that the resource server enforces authorization decisions based
+    on claims from the access token that define delegated authorization. If claims
+    such as 'sub', 'scope', and 'authorization_details' are present, they must be
+    part of the decision.
+  level: '2'
 10.3.3:
   capec_codes:
   - '180'
   - '21'
   - '57'
   - '633'
+  description: Verify that if an access control decision requires identifying a unique
+    user from an access token (JWT or related token introspection response), the resource
+    server identifies the user from claims that cannot be reassigned to other users.
+    Typically, it means using a combination of 'iss' and 'sub' claims.
+  level: '2'
 10.3.4:
   capec_codes:
   - '180'
   - '21'
   - '57'
   - '633'
+  description: Verify that, if the resource server requires specific authentication
+    strength, methods, or recentness, it verifies that the presented access token
+    satisfies these constraints. For example, if present, using the OIDC 'acr', 'amr'
+    and 'auth_time' claims respectively.
+  level: '2'
 10.3.5:
   capec_codes:
   - '180'
@@ -502,17 +675,29 @@ meta:
   - '22'
   - '57'
   - '633'
+  description: Verify that the resource server prevents the use of stolen access tokens
+    or replay of access tokens (from unauthorized parties) by requiring sender-constrained
+    access tokens, either Mutual TLS for OAuth 2 or OAuth 2 Demonstration of Proof
+    of Possession (DPoP).
+  level: '3'
 10.4.1:
   capec_codes:
   - '21'
   - '22'
   - '39'
   - '633'
+  description: Verify that the authorization server validates redirect URIs based
+    on a client-specific allowlist of pre-registered URIs using exact string comparison.
+  level: '1'
 10.4.10:
   capec_codes:
   - '21'
   - '22'
   - '633'
+  description: Verify that confidential client is authenticated for client-to-authorized
+    server backchannel requests such as token requests, pushed authorization requests
+    (PAR), and token revocation requests.
+  level: '2'
 10.4.11:
   capec_codes:
   - '179'
@@ -520,27 +705,50 @@ meta:
   - '21'
   - '22'
   - '633'
+  description: Verify that the authorization server configuration only assigns the
+    required scopes to the OAuth client.
+  level: '2'
 10.4.12:
   capec_codes:
   - '21'
   - '22'
   - '633'
+  description: Verify that for a given client, the authorization server only allows
+    the 'response_mode' value that this client needs to use. For example, by having
+    the authorization server validate this value against the expected values or by
+    using pushed authorization request (PAR) or JWT-secured Authorization Request
+    (JAR).
+  level: '3'
 10.4.13:
   capec_codes:
   - '21'
   - '22'
   - '633'
+  description: Verify that grant type 'code' is always used together with pushed authorization
+    requests (PAR).
+  level: '3'
 10.4.14:
   capec_codes:
   - '21'
   - '22'
   - '57'
   - '633'
+  description: Verify that the authorization server issues only sender-constrained
+    (Proof-of-Possession) access tokens, either with certificate-bound access tokens
+    using mutual TLS (mTLS) or DPoP-bound access tokens (Demonstration of Proof of
+    Possession).
+  level: '3'
 10.4.15:
   capec_codes:
   - '21'
   - '22'
   - '633'
+  description: Verify that, for a server-side client (which is not executed on the
+    end-user device), the authorization server ensures that the 'authorization_details'
+    parameter value is from the client backend and that the user has not tampered
+    with it. For example, by requiring the usage of pushed authorization request (PAR)
+    or JWT-secured Authorization Request (JAR).
+  level: '3'
 10.4.16:
   capec_codes:
   - '195'
@@ -554,6 +762,11 @@ meta:
   - '543'
   - '633'
   - '98'
+  description: Verify that the client is confidential and the authorization server
+    requires the use of strong client authentication methods (based on public-key
+    cryptography and resistant to replay attacks), such as mutual TLS ('tls_client_auth',
+    'self_signed_tls_client_auth') or private key JWT ('private_key_jwt').
+  level: '3'
 10.4.2:
   capec_codes:
   - '151'
@@ -561,6 +774,12 @@ meta:
   - '21'
   - '50'
   - '633'
+  description: Verify that, if the authorization server returns the authorization
+    code in the authorization response, it can be used only once for a token request.
+    For the second valid request with an authorization code that has already been
+    used to issue an access token, the authorization server must reject a token request
+    and revoke any issued tokens related to the authorization code.
+  level: '1'
 10.4.3:
   capec_codes:
   - '151'
@@ -568,11 +787,19 @@ meta:
   - '21'
   - '50'
   - '633'
+  description: Verify that the authorization code is short-lived. The maximum lifetime
+    can be up to 10 minutes for L1 and L2 applications and up to 1 minute for L3 applications.
+  level: '1'
 10.4.4:
   capec_codes:
   - '21'
   - '22'
   - '633'
+  description: Verify that for a given client, the authorization server only allows
+    the usage of grants that this client needs to use. Note that the grants 'token'
+    (Implicit flow) and 'password' (Resource Owner Password Credentials flow) must
+    no longer be used.
+  level: '1'
 10.4.5:
   capec_codes:
   - '151'
@@ -581,6 +808,14 @@ meta:
   - '22'
   - '50'
   - '633'
+  description: Verify that the authorization server mitigates refresh token replay
+    attacks for public clients, preferably using sender-constrained refresh tokens,
+    i.e., Demonstrating Proof of Possession (DPoP) or Certificate-Bound Access Tokens
+    using mutual TLS (mTLS). For L1 and L2 applications, refresh token rotation may
+    be used. If refresh token rotation is used, the authorization server must invalidate
+    the refresh token after usage, and revoke all refresh tokens for that authorization
+    if an already used and invalidated refresh token is provided.
+  level: '1'
 10.4.6:
   capec_codes:
   - '195'
@@ -591,6 +826,13 @@ meta:
   - '543'
   - '633'
   - '98'
+  description: Verify that, if the code grant is used, the authorization server mitigates
+    authorization code interception attacks by requiring proof key for code exchange
+    (PKCE). For authorization requests, the authorization server must require a valid
+    'code_challenge' value and must not accept a 'code_challenge_method' value of
+    'plain'. For a token request, it must require validation of the 'code_verifier'
+    parameter.
+  level: '2'
 10.4.7:
   capec_codes:
   - '21'
@@ -598,6 +840,12 @@ meta:
   - '523'
   - '549'
   - '633'
+  description: Verify that if the authorization server supports unauthenticated dynamic
+    client registration, it mitigates the risk of malicious client applications. It
+    must validate client metadata such as any registered URIs, ensure the user's consent,
+    and warn the user before processing an authorization request with an untrusted
+    client application.
+  level: '2'
 10.4.8:
   capec_codes:
   - '195'
@@ -607,6 +855,9 @@ meta:
   - '593'
   - '633'
   - '98'
+  description: Verify that refresh tokens have an absolute expiration, including if
+    sliding refresh token expiration is applied.
+  level: '2'
 10.4.9:
   capec_codes:
   - '151'
@@ -614,50 +865,104 @@ meta:
   - '21'
   - '50'
   - '633'
+  description: Verify that refresh tokens and reference access tokens can be revoked
+    by an authorized user using the authorization server user interface, to mitigate
+    the risk of malicious clients or stolen tokens.
+  level: '2'
 10.5.1:
   capec_codes:
   - '180'
   - '633'
+  description: Verify that the client (as the relying party) mitigates ID Token replay
+    attacks. For example, by ensuring that the 'nonce' claim in the ID Token matches
+    the 'nonce' value sent in the authentication request to the OpenID Provider (in
+    OAuth2 refereed to as the authorization request sent to the authorization server).
+  level: '2'
 10.5.2:
   capec_codes:
   - '180'
   - '633'
+  description: Verify that the client uniquely identifies the user from ID Token claims,
+    usually the 'sub' claim, which cannot be reassigned to other users (for the scope
+    of an identity provider).
+  level: '2'
 10.5.3:
   capec_codes:
   - '180'
   - '633'
+  description: Verify that the client rejects attempts by a malicious authorization
+    server to impersonate another authorization server through authorization server
+    metadata. The client must reject authorization server metadata if the issuer URL
+    in the authorization server metadata does not exactly match the pre-configured
+    issuer URL expected by the client.
+  level: '2'
 10.5.4:
   capec_codes:
   - '180'
   - '39'
   - '57'
   - '633'
+  description: Verify that the client validates that the ID Token is intended to be
+    used for that client (audience) by checking that the 'aud' claim from the token
+    is equal to the 'client_id' value for the client.
+  level: '2'
 10.5.5:
   capec_codes:
   - '180'
   - '2'
   - '39'
   - '633'
+  description: Verify that, when using OIDC back-channel logout, the relying party
+    mitigates denial of service through forced logout and cross-JWT confusion in the
+    logout flow. The client must verify that the logout token is correctly typed with
+    a value of 'logout+jwt', contains the 'event' claim with the correct member name,
+    and does not contain a 'nonce' claim. Note that it is also recommended to have
+    a short expiration (e.g., 2 minutes).
+  level: '2'
 10.6.1:
   capec_codes:
   - '22'
   - '633'
+  description: Verify that the OpenID Provider only allows values 'code', 'ciba',
+    'id_token', or 'id_token code' for response mode. Note that 'code' is preferred
+    over 'id_token code' (the OIDC Hybrid flow), and 'token' (any Implicit flow) must
+    not be used.
+  level: '2'
 10.6.2:
   capec_codes:
   - '2'
   - '633'
+  description: Verify that the OpenID Provider mitigates denial of service through
+    forced logout. By obtaining explicit confirmation from the end-user or, if present,
+    validating parameters in the logout request (initiated by the relying party),
+    such as the 'id_token_hint'.
+  level: '2'
 10.7.1:
   capec_codes:
   - '548'
   - '633'
+  description: Verify that the authorization server ensures that the user consents
+    to each authorization request. If the identity of the client cannot be assured,
+    the authorization server must always explicitly prompt the user for consent.
+  level: '2'
 10.7.2:
   capec_codes:
   - '548'
   - '633'
+  description: Verify that when the authorization server prompts for user consent,
+    it presents sufficient and clear information about what is being consented to.
+    When applicable, this should include the nature of the requested authorizations
+    (typically based on scope, resource server, Rich Authorization Requests (RAR)
+    authorization details), the identity of the authorized application, and the lifetime
+    of these authorizations.
+  level: '2'
 10.7.3:
   capec_codes:
   - '548'
   - '633'
+  description: Verify that the user can review, modify, and revoke consents which
+    the user has granted through the authorization server.
+  level: '2'
 11.1.1:
   capec_codes:
   - '155'
@@ -668,6 +973,12 @@ meta:
   - '548'
   - '57'
   - '639'
+  description: Verify that there is a documented policy for management of cryptographic
+    keys and a cryptographic key lifecycle that follows a key management standard
+    such as NIST SP 800-57. This should include ensuring that keys are not overshared
+    (for example, with more than two entities for shared secrets and more than one
+    entity for private keys).
+  level: '2'
 11.1.2:
   capec_codes:
   - '155'
@@ -678,6 +989,11 @@ meta:
   - '548'
   - '57'
   - '639'
+  description: Verify that a cryptographic inventory is performed, maintained, regularly
+    updated, and includes all cryptographic keys, algorithms, and certificates used
+    by the application. It must also document where keys can and cannot be used in
+    the system, and the types of data that can and cannot be protected using the keys.
+  level: '2'
 11.1.3:
   capec_codes:
   - '155'
@@ -688,6 +1004,10 @@ meta:
   - '548'
   - '57'
   - '639'
+  description: Verify that cryptographic discovery mechanisms are employed to identify
+    all instances of cryptography in the system, including encryption, hashing, and
+    signing operations.
+  level: '3'
 11.1.4:
   capec_codes:
   - '155'
@@ -697,6 +1017,10 @@ meta:
   - '548'
   - '57'
   - '639'
+  description: Verify that a cryptographic inventory is maintained. This must include
+    a documented plan that outlines the migration path to new cryptographic standards,
+    such as post-quantum cryptography, in order to react to future threats.
+  level: '3'
 11.2.1:
   capec_codes:
   - '112'
@@ -719,6 +1043,9 @@ meta:
   - '620'
   - '94'
   - '97'
+  description: Verify that industry-validated implementations (including libraries
+    and hardware-accelerated implementations) are used for cryptographic operations.
+  level: '2'
 11.2.2:
   capec_codes:
   - '112'
@@ -726,6 +1053,14 @@ meta:
   - '461'
   - '473'
   - '97'
+  description: Verify that the application is designed with crypto agility such that
+    random number, authenticated encryption, MAC, or hashing algorithms, key lengths,
+    rounds, ciphers and modes can be reconfigured, upgraded, or swapped at any time,
+    to protect against cryptographic breaks. Similarly, it must also be possible to
+    replace keys and passwords and re-encrypt data. This will allow for seamless upgrades
+    to post-quantum cryptography (PQC), once high-assurance implementations of approved
+    PQC schemes or standards are widely available.
+  level: '2'
 11.2.3:
   capec_codes:
   - '112'
@@ -743,6 +1078,11 @@ meta:
   - '620'
   - '94'
   - '97'
+  description: Verify that all cryptographic primitives utilize a minimum of 128-bits
+    of security based on the algorithm, key size, and configuration. For example,
+    a 256-bit ECC key provides roughly 128 bits of security where RSA requires a 3072-bit
+    key to achieve 128 bits of security.
+  level: '2'
 11.2.4:
   capec_codes:
   - '112'
@@ -764,6 +1104,10 @@ meta:
   - '620'
   - '94'
   - '97'
+  description: Verify that all cryptographic operations are constant-time, with no
+    'short-circuit' operations in comparisons, calculations, or returns, to avoid
+    leaking information.
+  level: '3'
 11.2.5:
   capec_codes:
   - '112'
@@ -788,6 +1132,10 @@ meta:
   - '620'
   - '94'
   - '97'
+  description: Verify that all cryptographic modules fail securely, and errors are
+    handled in a way that does not enable vulnerabilities, such as Padding Oracle
+    attacks.
+  level: '3'
 11.3.1:
   capec_codes:
   - '112'
@@ -810,6 +1158,9 @@ meta:
   - '620'
   - '94'
   - '97'
+  description: Verify that insecure block modes (e.g., ECB) and weak padding schemes
+    (e.g., PKCS#1 v1.5) are not used.
+  level: '1'
 11.3.2:
   capec_codes:
   - '112'
@@ -833,6 +1184,9 @@ meta:
   - '620'
   - '94'
   - '97'
+  description: Verify that only approved ciphers and modes such as AES with GCM are
+    used.
+  level: '1'
 11.3.3:
   capec_codes:
   - '112'
@@ -864,6 +1218,10 @@ meta:
   - '75'
   - '94'
   - '97'
+  description: Verify that encrypted data is protected against unauthorized modification
+    preferably by using an approved authenticated encryption method or by combining
+    an approved encryption method with an approved MAC algorithm.
+  level: '2'
 11.3.4:
   capec_codes:
   - '112'
@@ -884,6 +1242,10 @@ meta:
   - '620'
   - '94'
   - '97'
+  description: Verify that nonces, initialization vectors, and other single-use numbers
+    are not used for more than one encryption key and data-element pair. The method
+    of generation must be appropriate for the algorithm being used.
+  level: '3'
 11.3.5:
   capec_codes:
   - '112'
@@ -906,6 +1268,9 @@ meta:
   - '620'
   - '94'
   - '97'
+  description: Verify that any combination of an encryption algorithm and a MAC algorithm
+    is operating in encrypt-then-MAC mode.
+  level: '3'
 11.4.1:
   capec_codes:
   - '112'
@@ -930,6 +1295,11 @@ meta:
   - '68'
   - '94'
   - '97'
+  description: Verify that only approved hash functions are used for general cryptographic
+    use cases, including digital signatures, HMAC, KDF, and random bit generation.
+    Disallowed hash functions, such as MD5, must not be used for any cryptographic
+    purpose.
+  level: '1'
 11.4.2:
   capec_codes:
   - '112'
@@ -939,6 +1309,12 @@ meta:
   - '473'
   - '55'
   - '97'
+  description: Verify that passwords are stored using an approved, computationally
+    intensive, key derivation function (also known as a "password hashing function"),
+    with parameter settings configured based on current guidance. The settings should
+    balance security and performance to make brute-force attacks sufficiently challenging
+    for the required level of security.
+  level: '2'
 11.4.3:
   capec_codes:
   - '112'
@@ -967,6 +1343,12 @@ meta:
   - '75'
   - '94'
   - '97'
+  description: Verify that hash functions used in digital signatures, as part of data
+    authentication or data integrity are collision resistant and have appropriate
+    bit-lengths. If collision resistance is required, the output length must be at
+    least 256 bits. If only resistance to second pre-image attacks is required, the
+    output length must be at least 128 bits.
+  level: '2'
 11.4.4:
   capec_codes:
   - '112'
@@ -976,6 +1358,11 @@ meta:
   - '473'
   - '55'
   - '97'
+  description: Verify that the application uses approved key derivation functions
+    with key stretching parameters when deriving secret keys from passwords. The parameters
+    in use must balance security and performance to prevent brute-force attacks from
+    compromising the resulting cryptographic key.
+  level: '2'
 11.5.1:
   capec_codes:
   - '112'
@@ -993,6 +1380,11 @@ meta:
   - '620'
   - '94'
   - '97'
+  description: Verify that all random numbers and strings which are intended to be
+    non-guessable must be generated using a cryptographically secure pseudo-random
+    number generator (CSPRNG) and have at least 128 bits of entropy. Note that UUIDs
+    do not respect this condition.
+  level: '2'
 11.5.2:
   capec_codes:
   - '112'
@@ -1010,6 +1402,9 @@ meta:
   - '620'
   - '94'
   - '97'
+  description: Verify that the random number generation mechanism in use is designed
+    to work securely, even under heavy demand.
+  level: '3'
 11.6.1:
   capec_codes:
   - '112'
@@ -1029,6 +1424,11 @@ meta:
   - '68'
   - '94'
   - '97'
+  description: Verify that only approved cryptographic algorithms and modes of operation
+    are used for key generation and seeding, and digital signature generation and
+    verification. Key generation algorithms must not generate insecure keys vulnerable
+    to known attacks, for example, RSA keys which are vulnerable to Fermat factorization.
+  level: '2'
 11.6.2:
   capec_codes:
   - '112'
@@ -1048,14 +1448,26 @@ meta:
   - '68'
   - '94'
   - '97'
+  description: Verify that approved cryptographic algorithms are used for key exchange
+    (such as Diffie-Hellman) with a focus on ensuring that key exchange mechanisms
+    use secure parameters. This will prevent attacks on the key establishment process
+    which could lead to adversary-in-the-middle attacks or cryptographic breaks.
+  level: '3'
 11.7.1:
   capec_codes:
   - '116'
   - '204'
+  description: Verify that full memory encryption is in use that protects sensitive
+    data while it is in use, preventing access by unauthorized users or processes.
+  level: '3'
 11.7.2:
   capec_codes:
   - '116'
   - '204'
+  description: Verify that data minimization ensures the minimal amount of data is
+    exposed during processing, and ensure that data is encrypted immediately after
+    use or as soon as feasible.
+  level: '3'
 116.3.3:
   capec_codes:
   - '217'
@@ -1075,6 +1487,10 @@ meta:
   - '620'
   - '65'
   - '94'
+  description: Verify that only the latest recommended versions of the TLS protocol
+    are enabled, such as TLS 1.2 and TLS 1.3. The latest version of the TLS protocol
+    must be the preferred option.
+  level: '1'
 12.1.2:
   capec_codes:
   - '102'
@@ -1089,6 +1505,10 @@ meta:
   - '620'
   - '65'
   - '94'
+  description: Verify that only recommended cipher suites are enabled, with the strongest
+    cipher suites set as preferred. L3 applications must only support cipher suites
+    which provide forward secrecy.
+  level: '2'
 12.1.3:
   capec_codes:
   - '102'
@@ -1104,6 +1524,9 @@ meta:
   - '633'
   - '65'
   - '94'
+  description: Verify that the application validates that mTLS client certificates
+    are trusted before using the certificate identity for authentication or authorization.
+  level: '2'
 12.1.4:
   capec_codes:
   - '102'
@@ -1119,6 +1542,9 @@ meta:
   - '65'
   - '89'
   - '94'
+  description: Verify that proper certification revocation, such as Online Certificate
+    Status Protocol (OCSP) Stapling, is enabled and configured.
+  level: '3'
 12.1.5:
   capec_codes:
   - '102'
@@ -1128,6 +1554,10 @@ meta:
   - '65'
   - '89'
   - '94'
+  description: Verify that Encrypted Client Hello (ECH) is enabled in the application's
+    TLS settings to prevent exposure of sensitive metadata, such as the Server Name
+    Indication (SNI), during TLS handshake processes.
+  level: '3'
 12.2.1:
   capec_codes:
   - '102'
@@ -1145,6 +1575,10 @@ meta:
   - '65'
   - '89'
   - '94'
+  description: Verify that TLS is used for all connectivity between a client and external
+    facing, HTTP-based services, and does not fall back to insecure or unencrypted
+    communications.
+  level: '1'
 12.2.2:
   capec_codes:
   - '102'
@@ -1160,6 +1594,8 @@ meta:
   - '65'
   - '89'
   - '94'
+  description: Verify that external facing services use publicly trusted TLS certificates.
+  level: '1'
 12.3.1:
   capec_codes:
   - '102'
@@ -1177,6 +1613,12 @@ meta:
   - '620'
   - '65'
   - '94'
+  description: Verify that an encrypted protocol such as TLS is used for all inbound
+    and outbound connections to and from the application, including monitoring systems,
+    management tools, remote access and SSH, middleware, databases, mainframes, partner
+    systems, or external APIs. The server must not fall back to insecure or unencrypted
+    protocols.
+  level: '2'
 12.3.2:
   capec_codes:
   - '102'
@@ -1193,6 +1635,9 @@ meta:
   - '65'
   - '89'
   - '94'
+  description: Verify that TLS clients validate certificates received before communicating
+    with a TLS server.
+  level: '2'
 12.3.3:
   capec_codes:
   - '102'
@@ -1210,6 +1655,10 @@ meta:
   - '620'
   - '65'
   - '94'
+  description: Verify that TLS or another appropriate transport encryption mechanism
+    used for all connectivity between internal, HTTP-based services within the application,
+    and does not fall back to insecure or unencrypted communications.
+  level: '2'
 12.3.4:
   capec_codes:
   - '102'
@@ -1225,6 +1674,11 @@ meta:
   - '620'
   - '65'
   - '94'
+  description: Verify that TLS connections between internal services use trusted certificates.
+    Where internally generated or self-signed certificates are used, the consuming
+    service must be configured to only trust specific internal CAs and specific self-signed
+    certificates.
+  level: '2'
 12.3.5:
   capec_codes:
   - '102'
@@ -1241,22 +1695,47 @@ meta:
   - '620'
   - '65'
   - '94'
+  description: Verify that services communicating internally within a system (intra-service
+    communications) use strong authentication to ensure that each endpoint is verified.
+    Strong authentication methods, such as TLS client authentication, must be employed
+    to ensure identity, using public-key infrastructure and mechanisms that are resistant
+    to replay attacks. For microservice architectures, consider using a service mesh
+    to simplify certificate management and enhance security.
+  level: '3'
 13.1.1:
   capec_codes:
   - '154'
   - '176'
   - '240'
   - '481'
+  description: Verify that all communication needs for the application are documented.
+    This must include external services which the application relies upon and cases
+    where an end user might be able to provide an external location to which the application
+    will then connect.
+  level: '2'
 13.1.2:
   capec_codes:
   - '125'
   - '227'
+  description: Verify that for each service the application uses, the documentation
+    defines the maximum number of concurrent connections (e.g., connection pool limits)
+    and how the application behaves when that limit is reached, including any fallback
+    or recovery mechanisms, to prevent denial of service conditions.
+  level: '3'
 13.1.3:
   capec_codes:
   - '125'
   - '227'
   - '603'
   - '607'
+  description: Verify that the application documentation defines resource‑management
+    strategies for every external system or service it uses (e.g., databases, file
+    handles, threads, HTTP connections). This should include resource‑release procedures,
+    timeout settings, failure handling, and where retry logic is implemented, specifying
+    retry limits, delays, and back‑off algorithms. For synchronous HTTP request–response
+    operations it should mandate short timeouts and either disable retries or strictly
+    limit retries to prevent cascading delays and resource exhaustion.
+  level: '3'
 13.1.4:
   capec_codes:
   - '155'
@@ -1266,6 +1745,10 @@ meta:
   - '548'
   - '57'
   - '639'
+  description: Verify that the application's documentation defines the secrets that
+    are critical for the security of the application and a schedule for rotating them,
+    based on the organization's threat model and business requirements.
+  level: '3'
 13.2.1:
   capec_codes:
   - '113'
@@ -1281,6 +1764,13 @@ meta:
   - '57'
   - '633'
   - '87'
+  description: Verify that communications between backend application components that
+    don't support the application's standard user session mechanism, including APIs,
+    middleware, and data layers, are authenticated. Authentication must use individual
+    service accounts, short-term tokens, or certificate-based authentication and not
+    unchanging credentials such as passwords, API keys, or shared accounts with privileged
+    access.
+  level: '2'
 13.2.2:
   capec_codes:
   - '1'
@@ -1309,6 +1799,10 @@ meta:
   - '58'
   - '75'
   - '87'
+  description: Verify that communications between backend application components,
+    including local or operating system services, APIs, middleware, and data layers,
+    are performed with accounts assigned the least necessary privileges.
+  level: '2'
 13.2.3:
   capec_codes:
   - '115'
@@ -1324,6 +1818,10 @@ meta:
   - '560'
   - '57'
   - '70'
+  description: Verify that if a credential has to be used for service authentication,
+    the credential being used by the consumer is not a default credential (e.g., root/root
+    or admin/admin).
+  level: '2'
 13.2.4:
   capec_codes:
   - '154'
@@ -1331,16 +1829,30 @@ meta:
   - '240'
   - '481'
   - '57'
+  description: Verify that an allowlist is used to define the external resources or
+    systems with which the application is permitted to communicate (e.g., for outbound
+    requests, data loads, or file access). This allowlist can be implemented at the
+    application layer, web server, firewall, or a combination of different layers.
+  level: '2'
 13.2.5:
   capec_codes:
   - '154'
   - '240'
   - '481'
   - '57'
+  description: Verify that the web or application server is configured with an allowlist
+    of resources or systems to which the server can send requests or load data or
+    files from.
+  level: '2'
 13.2.6:
   capec_codes:
   - '125'
   - '227'
+  description: Verify that where the application connects to separate services, it
+    follows the documented configuration for each connection, such as maximum parallel
+    connections, behavior when maximum allowed connections is reached, connection
+    timeouts, and retry strategies.
+  level: '3'
 13.3.1:
   capec_codes:
   - '116'
@@ -1364,6 +1876,14 @@ meta:
   - '57'
   - '639'
   - '68'
+  description: Verify that a secrets management solution, such as a key vault, is
+    used to securely create, store, control access to, and destroy backend secrets.
+    These could include passwords, key material, integrations with databases and third-party
+    systems, keys and seeds for time-based tokens, other internal secrets, and API
+    keys. Secrets must not be included in application source code or included in build
+    artifacts. For an L3 application, this must involve a hardware-backed solution
+    such as an HSM.
+  level: '2'
 13.3.2:
   capec_codes:
   - '1'
@@ -1387,6 +1907,9 @@ meta:
   - '58'
   - '639'
   - '68'
+  description: Verify that access to secret assets adheres to the principle of least
+    privilege.
+  level: '2'
 13.3.3:
   capec_codes:
   - '155'
@@ -1405,6 +1928,10 @@ meta:
   - '57'
   - '639'
   - '68'
+  description: Verify that all cryptographic operations are performed using an isolated
+    security module (such as a vault or hardware security module) to securely manage
+    and protect key material from exposure outside of the security module.
+  level: '3'
 13.3.4:
   capec_codes:
   - '151'
@@ -1414,6 +1941,9 @@ meta:
   - '511'
   - '554'
   - '633'
+  description: Verify that secrets are configured to expire and be rotated based on
+    the application's documentation.
+  level: '3'
 13.4.1:
   capec_codes:
   - '11'
@@ -1431,6 +1961,10 @@ meta:
   - '37'
   - '497'
   - '54'
+  description: Verify that the application is deployed either without any source control
+    metadata, including the .git or .svn folders, or in a way that these folders are
+    inaccessible both externally and to the application itself.
+  level: '1'
 13.4.2:
   capec_codes:
   - '116'
@@ -1448,6 +1982,9 @@ meta:
   - '523'
   - '54'
   - '541'
+  description: Verify that debug modes are disabled for all components in production
+    environments to prevent exposure of debugging features and information leakage.
+  level: '2'
 13.4.3:
   capec_codes:
   - '116'
@@ -1458,6 +1995,9 @@ meta:
   - '169'
   - '497'
   - '54'
+  description: Verify that web servers do not expose directory listings to clients
+    unless explicitly intended.
+  level: '2'
 13.4.4:
   capec_codes:
   - '116'
@@ -1467,6 +2007,9 @@ meta:
   - '224'
   - '54'
   - '541'
+  description: Verify that using the HTTP TRACE method is not supported in production
+    environments, to avoid potential information leakage.
+  level: '2'
 13.4.5:
   capec_codes:
   - '116'
@@ -1483,6 +2026,9 @@ meta:
   - '541'
   - '69'
   - '87'
+  description: Verify that documentation (such as for internal APIs) and monitoring
+    endpoints are not exposed unless explicitly intended.
+  level: '2'
 13.4.6:
   capec_codes:
   - '116'
@@ -1495,6 +2041,9 @@ meta:
   - '310'
   - '54'
   - '541'
+  description: Verify that the application does not expose detailed version information
+    of backend components.
+  level: '3'
 13.4.7:
   capec_codes:
   - '11'
@@ -1513,6 +2062,10 @@ meta:
   - '497'
   - '54'
   - '541'
+  description: Verify that the web tier is configured to only serve files with specific
+    file extensions to prevent unintentional information, configuration, and source
+    code leakage.
+  level: '3'
 14.1.1:
   capec_codes:
   - '116'
@@ -1523,6 +2076,13 @@ meta:
   - '37'
   - '55'
   - '94'
+  description: Verify that all sensitive data created and processed by the application
+    has been identified and classified into protection levels. This includes data
+    that is only encoded and therefore easily decoded, such as Base64 strings or the
+    plaintext payload inside a JWT. Protection levels need to take into account any
+    data protection and privacy regulations and standards which the application is
+    required to comply with.
+  level: '2'
 14.1.2:
   capec_codes:
   - '116'
@@ -1533,6 +2093,13 @@ meta:
   - '37'
   - '55'
   - '94'
+  description: Verify that all sensitive data protection levels have a documented
+    set of protection requirements. This must include (but not be limited to) requirements
+    related to general encryption, integrity verification, retention, how the data
+    is to be logged, access controls around sensitive data in logs, database-level
+    encryption, privacy and privacy-enhancing technologies to be used, and other confidentiality
+    requirements.
+  level: '2'
 14.2.1:
   capec_codes:
   - '117'
@@ -1543,6 +2110,10 @@ meta:
   - '61'
   - '633'
   - '94'
+  description: Verify that sensitive data is only sent to the server in the HTTP message
+    body or header fields, and that the URL and query string do not contain sensitive
+    information, such as an API key or session token.
+  level: '1'
 14.2.2:
   capec_codes:
   - '116'
@@ -1550,10 +2121,18 @@ meta:
   - '31'
   - '37'
   - '593'
+  description: Verify that the application prevents sensitive data from being cached
+    in server components, such as load balancers and application caches, or ensures
+    that the data is securely purged after use.
+  level: '2'
 14.2.3:
   capec_codes:
   - '117'
   - '94'
+  description: Verify that defined sensitive data is not sent to untrusted parties
+    (e.g., user trackers) to prevent unwanted collection of data outside of the application's
+    control.
+  level: '2'
 14.2.4:
   capec_codes:
   - '1'
@@ -1578,17 +2157,34 @@ meta:
   - '690'
   - '75'
   - '94'
+  description: Verify that controls around sensitive data related to encryption, integrity
+    verification, retention, how the data is to be logged, access controls around
+    sensitive data in logs, privacy and privacy-enhancing technologies, are implemented
+    as defined in the documentation for the specific data's protection level.
+  level: '2'
 14.2.5:
   capec_codes:
   - '116'
   - '204'
   - '548'
+  description: Verify that caching mechanisms are configured to only cache responses
+    which have the expected content type for that resource and do not contain sensitive,
+    dynamic content. The web server should return a 404 or 302 response when a non-existent
+    file is accessed rather than returning a different, valid file. This should prevent
+    Web Cache Deception attacks.
+  level: '3'
 14.2.6:
   capec_codes:
   - '117'
   - '508'
   - '548'
   - '94'
+  description: Verify that the application only returns the minimum required sensitive
+    data for the application's functionality. For example, only returning some of
+    the digits of a credit card number and not the full number. If the complete data
+    is required, it should be masked in the user interface unless the user specifically
+    views it.
+  level: '3'
 14.2.7:
   capec_codes:
   - '116'
@@ -1596,11 +2192,18 @@ meta:
   - '204'
   - '548'
   - '94'
+  description: Verify that sensitive information is subject to data retention classification,
+    ensuring that outdated or unnecessary data is deleted automatically, on a defined
+    schedule, or as the situation requires.
+  level: '3'
 14.2.8:
   capec_codes:
   - '116'
   - '204'
   - '548'
+  description: Verify that sensitive information is removed from the metadata of user-submitted
+    files unless storage is consented to by the user.
+  level: '3'
 14.3.1:
   capec_codes:
   - '116'
@@ -1608,6 +2211,12 @@ meta:
   - '204'
   - '37'
   - '508'
+  description: Verify that authenticated data is cleared from client storage, such
+    as the browser DOM, after the client or session is terminated. The 'Clear-Site-Data'
+    HTTP response header field may be able to help with this but the client-side should
+    also be able to clear up if the server connection is not available when the session
+    is terminated.
+  level: '1'
 14.3.2:
   capec_codes:
   - '116'
@@ -1615,12 +2224,20 @@ meta:
   - '204'
   - '37'
   - '508'
+  description: 'Verify that the application sets sufficient anti-caching HTTP response
+    header fields (i.e., Cache-Control: no-store) so that sensitive data is not cached
+    in browsers.'
+  level: '2'
 14.3.3:
   capec_codes:
   - '116'
   - '117'
   - '37'
   - '508'
+  description: Verify that data stored in browser storage (such as localStorage, sessionStorage,
+    IndexedDB, or cookies) does not contain sensitive data, with the exception of
+    session tokens.
+  level: '2'
 15.1.1:
   capec_codes:
   - '169'
@@ -1638,6 +2255,10 @@ meta:
   - '554'
   - '673'
   - '691'
+  description: Verify that application documentation defines risk based remediation
+    time frames for 3rd party component versions with vulnerabilities and for updating
+    libraries in general, to minimize the risk from these components.
+  level: '1'
 15.1.2:
   capec_codes:
   - '169'
@@ -1655,10 +2276,21 @@ meta:
   - '554'
   - '673'
   - '691'
+  description: Verify that an inventory catalog, such as software bill of materials
+    (SBOM), is maintained of all third-party libraries in use, including verifying
+    that components come from pre-defined, trusted, and continually maintained repositories.
+  level: '2'
 15.1.3:
   capec_codes:
   - '125'
   - '130'
+  description: Verify that the application documentation identifies functionality
+    which is time-consuming or resource-demanding. This must include how to prevent
+    a loss of availability due to overusing this functionality and how to avoid a
+    situation where building a response takes longer than the consumer's timeout.
+    Potential defenses may include asynchronous processing, using queues, and limiting
+    parallel processes per user and per application.
+  level: '2'
 15.1.4:
   capec_codes:
   - '184'
@@ -1672,6 +2304,9 @@ meta:
   - '549'
   - '673'
   - '691'
+  description: Verify that application documentation highlights third-party libraries
+    which are considered to be "risky components".
+  level: '3'
 15.1.5:
   capec_codes:
   - '184'
@@ -1685,6 +2320,9 @@ meta:
   - '549'
   - '673'
   - '691'
+  description: Verify that application documentation highlights parts of the application
+    where "dangerous functionality" is being used.
+  level: '3'
 15.2.1:
   capec_codes:
   - '184'
@@ -1699,10 +2337,17 @@ meta:
   - '549'
   - '673'
   - '691'
+  description: Verify that the application only contains components which have not
+    breached the documented update and remediation time frames.
+  level: '1'
 15.2.2:
   capec_codes:
   - '125'
   - '130'
+  description: Verify that the application has implemented defenses against loss of
+    availability due to functionality which is time-consuming or resource-demanding,
+    based on the documented security decisions and strategies for this.
+  level: '2'
 15.2.3:
   capec_codes:
   - '116'
@@ -1720,6 +2365,10 @@ meta:
   - '54'
   - '541'
   - '546'
+  description: Verify that the production environment only includes functionality
+    that is required for the application to function, and does not expose extraneous
+    functionality such as test code, sample snippets, and development functionality.
+  level: '2'
 15.2.4:
   capec_codes:
   - '115'
@@ -1739,6 +2388,10 @@ meta:
   - '554'
   - '673'
   - '691'
+  description: Verify that third-party components and all of their transitive dependencies
+    are included from the expected repository, whether internally owned or an external
+    source, and that there is no risk of a dependency confusion attack.
+  level: '3'
 15.2.5:
   capec_codes:
   - '176'
@@ -1759,6 +2412,13 @@ meta:
   - '673'
   - '68'
   - '691'
+  description: Verify that the application implements additional protections around
+    parts of the application which are documented as containing "dangerous functionality"
+    or using third-party libraries considered to be "risky components". This could
+    include techniques such as sandboxing, encapsulation, containerization or network
+    level isolation to delay and deter attackers who compromise one part of an application
+    from pivoting elsewhere in the application.
+  level: '3'
 15.3.1:
   capec_codes:
   - '122'
@@ -1767,6 +2427,10 @@ meta:
   - '261'
   - '28'
   - '58'
+  description: Verify that the application only returns the required subset of fields
+    from a data object. For example, it should not return an entire data object, as
+    some individual fields should not be accessible to users.
+  level: '1'
 15.3.2:
   capec_codes:
   - '137'
@@ -1776,6 +2440,9 @@ meta:
   - '261'
   - '28'
   - '481'
+  description: Verify that where the application backend makes calls to external URLs,
+    it is configured to not follow redirects unless it is intended functionality.
+  level: '2'
 15.3.3:
   capec_codes:
   - '113'
@@ -1786,11 +2453,23 @@ meta:
   - '212'
   - '261'
   - '28'
+  description: Verify that the application has countermeasures to protect against
+    mass assignment attacks by limiting allowed fields per controller and action,
+    e.g., it is not possible to insert or update a field value when it was not intended
+    to be part of that action.
+  level: '2'
 15.3.4:
   capec_codes:
   - '113'
   - '137'
   - '28'
+  description: Verify that all proxying and middleware components transfer the user's
+    original IP address correctly using trusted data fields that cannot be manipulated
+    by the end user, and the application and web server use this correct value for
+    logging and security decisions such as rate limiting, taking into account that
+    even the original IP address may not be reliable due to dynamic IPs, VPNs, or
+    corporate firewalls.
+  level: '2'
 15.3.5:
   capec_codes:
   - '137'
@@ -1801,6 +2480,11 @@ meta:
   - '261'
   - '267'
   - '28'
+  description: Verify that the application explicitly ensures that variables are of
+    the correct type and performs strict equality and comparator operations. This
+    is to avoid type juggling or type confusion vulnerabilities caused by the application
+    code making an assumption about a variable type.
+  level: '2'
 15.3.5 15.3.6:
   capec_codes:
   - '113'
@@ -1814,6 +2498,9 @@ meta:
   - '261'
   - '267'
   - '28'
+  description: Verify that JavaScript code is written in a way that prevents prototype
+    pollution, for example, by using Set() or Map() instead of object literals.
+  level: '2'
 15.3.7:
   capec_codes:
   - '113'
@@ -1823,15 +2510,31 @@ meta:
   - '261'
   - '28'
   - '39'
+  description: Verify that the application has defenses against HTTP parameter pollution
+    attacks, particularly if the application framework makes no distinction about
+    the source of request parameters (query string, body parameters, cookies, or header
+    fields).
+  level: '2'
 15.4.1:
   capec_codes:
   - '131'
   - '212'
   - '26'
+  description: Verify that shared objects in multi-threaded code (such as caches,
+    files, or in-memory objects accessed by multiple threads) are accessed safely
+    by using thread-safe types and synchronization mechanisms like locks or semaphores
+    to avoid race conditions and data corruption.
+  level: '3'
 15.4.2:
   capec_codes:
   - '212'
   - '26'
+  description: Verify that checks on a resource's state, such as its existence or
+    permissions, and the actions that depend on them are performed as a single atomic
+    operation to prevent time-of-check to time-of-use (TOCTOU) race conditions. For
+    example, checking if a file exists before opening it, or verifying a user’s access
+    before granting it.
+  level: '3'
 15.4.3:
   capec_codes:
   - '124'
@@ -1841,6 +2544,11 @@ meta:
   - '469'
   - '603'
   - '607'
+  description: Verify that locks are used consistently to avoid threads getting stuck,
+    whether by waiting on each other or retrying endlessly, and that locking logic
+    stays within the code responsible for managing the resource to ensure locks cannot
+    be inadvertently or maliciously modified by external classes or code.
+  level: '3'
 15.4.4:
   capec_codes:
   - '124'
@@ -1850,6 +2558,10 @@ meta:
   - '469'
   - '603'
   - '607'
+  description: Verify that resource allocation policies prevent thread starvation
+    by ensuring fair access to resources, such as by leveraging thread pools, allowing
+    lower-priority threads to proceed within a reasonable timeframe.
+  level: '3'
 16.1.1:
   capec_codes:
   - '151'
@@ -1858,6 +2570,11 @@ meta:
   - '49'
   - '50'
   - '600'
+  description: Verify that an inventory exists documenting the logging performed at
+    each layer of the application's technology stack, what events are being logged,
+    log formats, where that logging is stored, how it is used, how access to it is
+    controlled, and for how long logs are kept.
+  level: '2'
 16.2.1:
   capec_codes:
   - '151'
@@ -1866,6 +2583,10 @@ meta:
   - '49'
   - '50'
   - '600'
+  description: Verify that each log entry includes necessary metadata (such as when,
+    where, who, what) that would allow for a detailed investigation of the timeline
+    when an event happens.
+  level: '2'
 16.2.2:
   capec_codes:
   - '151'
@@ -1874,6 +2595,11 @@ meta:
   - '49'
   - '50'
   - '600'
+  description: Verify that time sources for all logging components are synchronized,
+    and that timestamps in security event metadata use UTC or include an explicit
+    time zone offset. UTC is recommended to ensure consistency across distributed
+    systems and to prevent confusion during daylight saving time transitions.
+  level: '2'
 16.2.3:
   capec_codes:
   - '151'
@@ -1882,6 +2608,9 @@ meta:
   - '49'
   - '50'
   - '600'
+  description: Verify that the application only stores or broadcasts logs to the files
+    and services that are documented in the log inventory.
+  level: '2'
 16.2.4:
   capec_codes:
   - '151'
@@ -1890,6 +2619,9 @@ meta:
   - '49'
   - '50'
   - '600'
+  description: Verify that logs can be read and correlated by the log processor that
+    is in use, preferably by using a common logging format.
+  level: '2'
 16.2.5:
   capec_codes:
   - '116'
@@ -1906,6 +2638,11 @@ meta:
   - '54'
   - '593'
   - '600'
+  description: Verify that when logging sensitive data, the application enforces logging
+    based on the data's protection level. For example, it may not be allowed to log
+    certain data, such as credentials or payment details. Other data, such as session
+    tokens, may only be logged by being hashed or masked, either in full or partially.
+  level: '2'
 16.3.1:
   capec_codes:
   - '114'
@@ -1922,6 +2659,10 @@ meta:
   - '68'
   - '70'
   - '75'
+  description: Verify that all authentication operations are logged, including successful
+    and unsuccessful attempts. Additional metadata, such as the type of authentication
+    or factors used, should also be collected.
+  level: '2'
 16.3.2:
   capec_codes:
   - '1'
@@ -1964,6 +2705,10 @@ meta:
   - '75'
   - '87'
   - '95'
+  description: Verify that failed authorization attempts are logged. For L3, this
+    must include logging all authorization decisions, including logging when sensitive
+    data is accessed (without logging the sensitive data itself).
+  level: '2'
 16.3.3:
   capec_codes:
   - '1'
@@ -2086,6 +2831,10 @@ meta:
   - '94'
   - '95'
   - '97'
+  description: Verify that the application logs the security events that are defined
+    in the documentation and also logs attempts to bypass the security controls, such
+    as input validation, business logic, and anti-automation.
+  level: '2'
 16.3.4:
   capec_codes:
   - '105'
@@ -2143,6 +2892,9 @@ meta:
   - '691'
   - '83'
   - '94'
+  description: Verify that the application logs unexpected errors and security control
+    failures such as backend TLS failures.
+  level: '2'
 16.4.1:
   capec_codes:
   - '120'
@@ -2155,6 +2907,9 @@ meta:
   - '28'
   - '88'
   - '93'
+  description: Verify that all logging components appropriately encode data to prevent
+    log injection.
+  level: '2'
 16.4.2:
   capec_codes:
   - '116'
@@ -2163,6 +2918,9 @@ meta:
   - '215'
   - '268'
   - '54'
+  description: Verify that logs are protected from unauthorized access and cannot
+    be modified.
+  level: '2'
 16.4.3:
   capec_codes:
   - '151'
@@ -2171,6 +2929,10 @@ meta:
   - '49'
   - '50'
   - '600'
+  description: Verify that logs are securely transmitted to a logically separate system
+    for analysis, detection, alerting, and escalation. The aim is to ensure that if
+    the application is breached, the logs are not compromised.
+  level: '2'
 16.5.1:
   capec_codes:
   - '116'
@@ -2211,6 +2973,10 @@ meta:
   - '83'
   - '88'
   - '93'
+  description: Verify that a generic message is returned to the consumer when an unexpected
+    or security-sensitive error occurs, ensuring no exposure of sensitive internal
+    system data such as stack traces, queries, secret keys, and tokens.
+  level: '2'
 16.5.2:
   capec_codes:
   - '100'
@@ -2230,6 +2996,10 @@ meta:
   - '50'
   - '603'
   - '607'
+  description: Verify that the application continues to operate securely when external
+    resource access fails, for example, by using patterns such as circuit breakers
+    or graceful degradation.
+  level: '2'
 16.5.3:
   capec_codes:
   - '100'
@@ -2258,6 +3028,10 @@ meta:
   - '554'
   - '70'
   - '77'
+  description: Verify that the application fails gracefully and securely, including
+    when an exception occurs, preventing fail-open conditions such as processing a
+    transaction despite errors resulting from validation logic.
+  level: '2'
 16.5.4:
   capec_codes:
   - '151'
@@ -2266,26 +3040,54 @@ meta:
   - '21'
   - '24'
   - '50'
+  description: Verify that a "last resort" error handler is defined which will catch
+    all unhandled exceptions. This is both to avoid losing error details that must
+    go to log files and to ensure that an error does not take down the entire application
+    process, leading to a loss of availability.
+  level: '3'
 17.1.1:
   capec_codes:
   - '116'
   - '169'
   - '224'
   - '54'
+  description: Verify that the Traversal Using Relays around NAT (TURN) service only
+    allows access to IP addresses that are not reserved for special purposes (e.g.,
+    internal networks, broadcast, loopback). Note that this applies to both IPv4 and
+    IPv6 addresses.
+  level: '2'
 17.1.2:
   capec_codes:
   - '125'
+  description: Verify that the Traversal Using Relays around NAT (TURN) service is
+    not susceptible to resource exhaustion when legitimate users attempt to open a
+    large number of ports on the TURN server.
+  level: '3'
 17.2.1:
   capec_codes:
   - '474'
+  description: Verify that the key for the Datagram Transport Layer Security (DTLS)
+    certificate is managed and protected based on the documented policy for management
+    of cryptographic keys.
+  level: '2'
 17.3.1:
   capec_codes:
   - '125'
+  description: Verify that the signaling server is able to continue processing legitimate
+    incoming signaling messages during a flood attack. This should be achieved by
+    implementing rate limiting at the signaling level.
+  level: '2'
 17.3.2:
   capec_codes:
   - '125'
   - '603'
   - '607'
+  description: Verify that the signaling server is able to continue processing legitimate
+    signaling messages when encountering malformed signaling message that could cause
+    a denial of service condition. This could include implementing input validation,
+    safely handling integer overflows, preventing buffer overflows, and employing
+    other robust error-handling techniques.
+  level: '2'
 2.1.1:
   capec_codes:
   - '113'
@@ -2314,6 +3116,11 @@ meta:
   - '78'
   - '79'
   - '80'
+  description: Verify that the application's documentation defines input validation
+    rules for how to check the validity of data items against an expected structure.
+    This could be common data formats such as credit card numbers, email addresses,
+    telephone numbers, or it could be an internal data format.
+  level: '1'
 2.1.2:
   capec_codes:
   - '137'
@@ -2321,6 +3128,10 @@ meta:
   - '153'
   - '19'
   - '28'
+  description: Verify that the application's documentation defines how to validate
+    the logical and contextual consistency of combined data items, such as checking
+    that suburb and ZIP code match.
+  level: '2'
 2.1.3:
   capec_codes:
   - '137'
@@ -2331,6 +3142,9 @@ meta:
   - '28'
   - '43'
   - '77'
+  description: Verify that expectations for business logic limits and validations
+    are documented, including both per-user and globally across the application.
+  level: '2'
 2.2.1:
   capec_codes:
   - '113'
@@ -2364,6 +3178,13 @@ meta:
   - '78'
   - '79'
   - '80'
+  description: Verify that input is validated to enforce business or functional expectations
+    for that input. This should either use positive validation against an allow list
+    of values, patterns, and ranges, or be based on comparing the input to an expected
+    structure and logical limits according to predefined rules. For L1, this can focus
+    on input which is used to make specific business or security decisions. For L2
+    and up, this should apply to all input.
+  level: '1'
 2.2.2:
   capec_codes:
   - '113'
@@ -2393,6 +3214,10 @@ meta:
   - '586'
   - '77'
   - '87'
+  description: Verify that the application is designed to enforce input validation
+    at a trusted service layer. While client-side validation improves usability and
+    should be encouraged, it must not be relied upon as a security control.
+  level: '1'
 2.2.3:
   capec_codes:
   - '113'
@@ -2402,6 +3227,9 @@ meta:
   - '153'
   - '19'
   - '28'
+  description: Verify that the application ensures that combinations of related data
+    items are reasonable according to the pre-defined rules.
+  level: '2'
 2.3.1:
   capec_codes:
   - '113'
@@ -2413,6 +3241,9 @@ meta:
   - '28'
   - '39'
   - '74'
+  description: Verify that the application will only process business logic flows
+    for the same user in the expected sequential step order and without skipping steps.
+  level: '1'
 2.3.2:
   capec_codes:
   - '113'
@@ -2430,6 +3261,9 @@ meta:
   - '43'
   - '469'
   - '77'
+  description: Verify that business logic limits are implemented per the application's
+    documentation to avoid business logic flaws being exploited.
+  level: '2'
 2.3.3:
   capec_codes:
   - '113'
@@ -2441,6 +3275,10 @@ meta:
   - '28'
   - '43'
   - '77'
+  description: Verify that transactions are being used at the business logic level
+    such that either a business logic operation succeeds in its entirety or it is
+    rolled back to the previous correct state.
+  level: '2'
 2.3.4:
   capec_codes:
   - '162'
@@ -2450,6 +3288,10 @@ meta:
   - '26'
   - '39'
   - '74'
+  description: Verify that business logic level locking mechanisms are used to ensure
+    that limited quantity resources (such as theater seats or delivery slots) cannot
+    be double-booked by manipulating the application's logic.
+  level: '2'
 2.3.5:
   capec_codes:
   - '162'
@@ -2458,6 +3300,11 @@ meta:
   - '212'
   - '39'
   - '74'
+  description: Verify that high-value business logic flows require multi-user approval
+    to prevent unauthorized or accidental actions. This could include but is not limited
+    to large monetary transfers, contract approvals, access to classified information,
+    or safety overrides in manufacturing.
+  level: '3'
 2.4.1:
   capec_codes:
   - '125'
@@ -2467,6 +3314,11 @@ meta:
   - '215'
   - '227'
   - '469'
+  description: Verify that anti-automation controls are in place to protect against
+    excessive calls to application functions that could lead to data exfiltration,
+    garbage-data creation, quota exhaustion, rate-limit breaches, denial-of-service,
+    or overuse of costly resources.
+  level: '2'
 2.4.2:
   capec_codes:
   - '125'
@@ -2475,6 +3327,9 @@ meta:
   - '227'
   - '26'
   - '469'
+  description: Verify that business logic flows require realistic human timing, preventing
+    excessively rapid transaction submissions.
+  level: '3'
 3.1.1:
   capec_codes:
   - '104'
@@ -2494,6 +3349,13 @@ meta:
   - '63'
   - '87'
   - '89'
+  description: Verify that application documentation states the expected security
+    features that browsers using the application must support (such as HTTPS, HTTP
+    Strict Transport Security (HSTS), Content Security Policy (CSP), and other relevant
+    HTTP security mechanisms). It must also define how the application must behave
+    when some of these features are not available (such as warning the user or blocking
+    access).
+  level: '3'
 3.2.1:
   capec_codes:
   - '103'
@@ -2504,6 +3366,14 @@ meta:
   - '242'
   - '569'
   - '63'
+  description: 'Verify that security controls are in place to prevent browsers from
+    rendering content or functionality in HTTP responses in an incorrect context (e.g.,
+    when an API, a user-uploaded file or other resource is requested directly). Possible
+    controls could include: not serving the content unless HTTP request header fields
+    (such as Sec-Fetch-\*) indicate it is the correct context, using the sandbox directive
+    of the Content-Security-Policy header field or using the attachment disposition
+    type in the Content-Disposition header field.'
+  level: '1'
 3.2.2:
   capec_codes:
   - '152'
@@ -2514,6 +3384,10 @@ meta:
   - '28'
   - '43'
   - '63'
+  description: Verify that content intended to be displayed as text, rather than rendered
+    as HTML, is handled using safe rendering functions (such as createTextNode or
+    textContent) to prevent unintended execution of content such as HTML or JavaScript.
+  level: '1'
 3.2.3:
   capec_codes:
   - '152'
@@ -2522,12 +3396,21 @@ meta:
   - '242'
   - '267'
   - '63'
+  description: Verify that the application avoids DOM clobbering when using client-side
+    JavaScript by employing explicit variable declarations, performing strict type
+    checking, avoiding storing global variables on the document object, and implementing
+    namespace isolation.
+  level: '3'
 3.3.1:
   capec_codes:
   - '22'
   - '31'
   - '39'
   - '593'
+  description: Verify that cookies have the 'Secure' attribute set, and if the '\__Host-'
+    prefix is not used for the cookie name, the '__Secure-' prefix must be used for
+    the cookie name.
+  level: '1'
 3.3.2:
   capec_codes:
   - '103'
@@ -2537,6 +3420,11 @@ meta:
   - '39'
   - '593'
   - '62'
+  description: Verify that each cookie's 'SameSite' attribute value is set according
+    to the purpose of the cookie, to limit exposure to user interface redress attacks
+    and browser-based request forgery attacks, commonly known as cross-site request
+    forgery (CSRF).
+  level: '2'
 3.3.3:
   capec_codes:
   - '22'
@@ -2544,6 +3432,9 @@ meta:
   - '39'
   - '593'
   - '61'
+  description: Verify that cookies have the '__Host-' prefix for the cookie name unless
+    they are explicitly designed to be shared with other hosts.
+  level: '2'
 3.3.4:
   capec_codes:
   - '21'
@@ -2552,9 +3443,19 @@ meta:
   - '39'
   - '593'
   - '61'
+  description: Verify that if the value of a cookie is not meant to be accessible
+    to client-side scripts (such as a session token), the cookie must have the 'HttpOnly'
+    attribute set and the same value (e. g. session token) must only be transferred
+    to the client via the 'Set-Cookie' header field.
+  level: '2'
 3.3.5:
   capec_codes:
   - '39'
+  description: Verify that when the application writes a cookie, the cookie name and
+    value length combined are not over 4096 bytes. Overly large cookies will not be
+    stored by the browser and therefore not sent with requests, preventing the user
+    from using application functionality which relies on that cookie.
+  level: '3'
 3.4.1:
   capec_codes:
   - '157'
@@ -2569,6 +3470,11 @@ meta:
   - '620'
   - '89'
   - '94'
+  description: Verify that a Strict-Transport-Security header field is included on
+    all responses to enforce an HTTP Strict Transport Security (HSTS) policy. A maximum
+    age of at least 1 year must be defined, and for L2 and up, the policy must apply
+    to all subdomains as well.
+  level: '1'
 3.4.2:
   capec_codes:
   - '104'
@@ -2577,6 +3483,12 @@ meta:
   - '22'
   - '233'
   - '466'
+  description: 'Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin
+    header field is a fixed value by the application, or if the Origin HTTP request
+    header field value is used, it is validated against an allowlist of trusted origins.
+    When ''Access-Control-Allow-Origin: *'' needs to be used, verify that the response
+    does not include any sensitive information.'
+  level: '1'
 3.4.3:
   capec_codes:
   - '103'
@@ -2594,6 +3506,13 @@ meta:
   - '446'
   - '63'
   - '89'
+  description: Verify that HTTP responses include a Content-Security-Policy response
+    header field which defines directives to ensure the browser only loads and executes
+    trusted content or resources, in order to limit execution of malicious JavaScript.
+    As a minimum, a global policy must be used which includes the directives object-src
+    'none' and base-uri 'none' and defines either an allowlist or uses nonces or hashes.
+    For an L3 application, a per-response policy with nonces or hashes must be defined.
+  level: '2'
 3.4.4:
   capec_codes:
   - '152'
@@ -2603,10 +3522,24 @@ meta:
   - '569'
   - '63'
   - '690'
+  description: 'Verify that all HTTP responses contain an ''X-Content-Type-Options:
+    nosniff'' header field. This instructs browsers not to use content sniffing and
+    MIME type guessing for the given response, and to require the response''s Content-Type
+    header field value to match the destination resource. For example, the response
+    to a request for a style is only accepted if the response''s Content-Type is ''text/css''.
+    This also enables the use of the Cross-Origin Read Blocking (CORB) functionality
+    by the browser.'
+  level: '2'
 3.4.5:
   capec_codes:
   - '22'
   - '569'
+  description: Verify that the application sets a referrer policy to prevent leakage
+    of technically sensitive data to third-party services via the 'Referer' HTTP request
+    header field. This can be done using the Referrer-Policy HTTP response header
+    field or via HTML element attributes. Sensitive data could include path and query
+    data in the URL, and for internal non-public applications also the hostname.
+  level: '2'
 3.4.6:
   capec_codes:
   - '103'
@@ -2622,6 +3555,12 @@ meta:
   - '242'
   - '446'
   - '63'
+  description: Verify that the web application uses the frame-ancestors directive
+    of the Content-Security-Policy header field for every HTTP response to ensure
+    that it cannot be embedded by default and that embedding of specific resources
+    is allowed only when necessary. Note that the X-Frame-Options header field, although
+    supported by browsers, is obsolete and may not be relied upon.
+  level: '2'
 3.4.7:
   capec_codes:
   - '103'
@@ -2639,6 +3578,9 @@ meta:
   - '446'
   - '63'
   - '89'
+  description: Verify that the Content-Security-Policy header field specifies a location
+    to report violations.
+  level: '3'
 3.4.8:
   capec_codes:
   - '104'
@@ -2651,18 +3593,39 @@ meta:
   - '543'
   - '569'
   - '63'
+  description: Verify that all HTTP responses that initiate a document rendering (such
+    as responses with Content-Type text/html), include the Cross‑Origin‑Opener‑Policy
+    header field with the same-origin directive or the same-origin-allow-popups directive
+    as required. This prevents attacks that abuse shared access to Window objects,
+    such as tabnabbing and frame counting.
+  level: '3'
 3.5.1:
   capec_codes:
   - '173'
   - '21'
   - '22'
   - '62'
+  description: Verify that, if the application does not rely on the CORS preflight
+    mechanism to prevent disallowed cross-origin requests to use sensitive functionality,
+    these requests are validated to ensure they originate from the application itself.
+    This may be done by using and validating anti-forgery tokens or requiring extra
+    HTTP header fields that are not CORS-safelisted request-header fields. This is
+    to defend against browser-based request forgery attacks, commonly known as cross-site
+    request forgery (CSRF).
+  level: '1'
 3.5.2:
   capec_codes:
   - '104'
   - '173'
   - '233'
   - '62'
+  description: Verify that, if the application relies on the CORS preflight mechanism
+    to prevent disallowed cross-origin use of sensitive functionality, it is not possible
+    to call the functionality with a request which does not trigger a CORS-preflight
+    request. This may require checking the values of the 'Origin' and 'Content-Type'
+    request header fields or using an extra header field that is not a CORS-safelisted
+    header-field.
+  level: '1'
 3.5.3:
   capec_codes:
   - '104'
@@ -2670,6 +3633,13 @@ meta:
   - '233'
   - '446'
   - '62'
+  description: Verify that HTTP requests to sensitive functionality use appropriate
+    HTTP methods such as POST, PUT, PATCH, or DELETE, and not methods defined by the
+    HTTP specification as "safe" such as HEAD, OPTIONS, or GET. Alternatively, strict
+    validation of the Sec-Fetch-* request header fields can be used to ensure that
+    the request did not originate from an inappropriate cross-origin call, a navigation
+    request, or a resource load (such as an image source) where this is not expected.
+  level: '1'
 3.5.4:
   capec_codes:
   - '104'
@@ -2684,6 +3654,11 @@ meta:
   - '61'
   - '62'
   - '63'
+  description: Verify that separate applications are hosted on different hostnames
+    to leverage the restrictions provided by same-origin policy, including how documents
+    or scripts loaded by one origin can interact with resources from another origin
+    and hostname-based restrictions on cookies.
+  level: '2'
 3.5.5:
   capec_codes:
   - '104'
@@ -2696,6 +3671,10 @@ meta:
   - '446'
   - '62'
   - '63'
+  description: Verify that messages received by the postMessage interface are discarded
+    if the origin of the message is not trusted, or if the syntax of the message is
+    invalid.
+  level: '2'
 3.5.6:
   capec_codes:
   - '104'
@@ -2707,6 +3686,9 @@ meta:
   - '446'
   - '62'
   - '63'
+  description: Verify that JSONP functionality is not enabled anywhere across the
+    application to avoid Cross-Site Script Inclusion (XSSI) attacks.
+  level: '3'
 3.5.7:
   capec_codes:
   - '104'
@@ -2723,6 +3705,10 @@ meta:
   - '63'
   - '74'
   - '77'
+  description: Verify that data requiring authorization is not included in script
+    resource responses, like JavaScript files, to prevent Cross-Site Script Inclusion
+    (XSSI) attacks.
+  level: '3'
 3.5.8:
   capec_codes:
   - '104'
@@ -2734,6 +3720,13 @@ meta:
   - '569'
   - '62'
   - '63'
+  description: Verify that authenticated resources (such as images, videos, scripts,
+    and other documents) can be loaded or embedded on behalf of the user only when
+    intended. This can be accomplished by strict validation of the Sec-Fetch-* HTTP
+    request header fields to ensure that the request did not originate from an inappropriate
+    cross-origin call, or by setting a restrictive Cross-Origin-Resource-Policy HTTP
+    response header field to instruct the browser to block returned content.
+  level: '3'
 3.6.1:
   capec_codes:
   - '104'
@@ -2749,18 +3742,33 @@ meta:
   - '446'
   - '475'
   - '63'
+  description: Verify that client-side assets, such as JavaScript libraries, CSS,
+    or web fonts, are only hosted externally (e.g., on a Content Delivery Network)
+    if the resource is static and versioned and Subresource Integrity (SRI) is used
+    to validate the integrity of the asset. If this is not possible, there should
+    be a documented security decision to justify this for each resource.
+  level: '3'
 3.7.1:
   capec_codes:
   - '181'
   - '21'
   - '242'
   - '446'
+  description: Verify that the application only uses client-side technologies which
+    are still supported and considered secure. Examples of technologies which do not
+    meet this requirement include NSAPI plugins, Flash, Shockwave, ActiveX, Silverlight,
+    NACL, or client-side Java applets.
+  level: '2'
 3.7.2:
   capec_codes:
   - '173'
   - '21'
   - '242'
   - '569'
+  description: Verify that the application will only automatically redirect the user
+    to a different hostname or domain (which is not controlled by the application)
+    where the destination appears on an allowlist.
+  level: '2'
 3.7.3:
   capec_codes:
   - '173'
@@ -2768,6 +3776,10 @@ meta:
   - '242'
   - '569'
   - '62'
+  description: Verify that the application shows a notification when the user is being
+    redirected to a URL outside of the application's control, with an option to cancel
+    the navigation.
+  level: '3'
 3.7.4:
   capec_codes:
   - '157'
@@ -2783,6 +3795,12 @@ meta:
   - '620'
   - '89'
   - '94'
+  description: Verify that the application's top-level domain (e.g., site.tld) is
+    added to the public preload list for HTTP Strict Transport Security (HSTS). This
+    ensures that the use of TLS for the application is built directly into the main
+    browsers, rather than relying only on the Strict-Transport-Security response header
+    field.
+  level: '3'
 3.7.5:
   capec_codes:
   - '103'
@@ -2798,6 +3816,10 @@ meta:
   - '63'
   - '87'
   - '89'
+  description: Verify that the application behaves as documented (such as warning
+    the user or blocking access) if the browser used to access the application does
+    not support the expected security features.
+  level: '3'
 4.1.1:
   capec_codes:
   - '152'
@@ -2807,6 +3829,11 @@ meta:
   - '272'
   - '43'
   - '63'
+  description: Verify that every HTTP response with a message body contains a Content-Type
+    header field that matches the actual content of the response, including the charset
+    parameter to specify safe character encoding (e.g., UTF-8, ISO-8859-1) according
+    to IANA Media Types, such as "text/", "/+xml" and "/xml".
+  level: '1'
 4.1.2:
   capec_codes:
   - '157'
@@ -2814,16 +3841,31 @@ meta:
   - '594'
   - '620'
   - '94'
+  description: Verify that only user-facing endpoints (intended for manual web-browser
+    access) automatically redirect from HTTP to HTTPS, while other services or endpoints
+    do not implement transparent redirects. This is to avoid a situation where a client
+    is erroneously sending unencrypted HTTP requests, but since the requests are being
+    automatically redirected to HTTPS, the leakage of sensitive data goes undiscovered.
+  level: '2'
 4.1.3:
   capec_codes:
   - '194'
   - '22'
   - '39'
   - '690'
+  description: Verify that any HTTP header field used by the application and set by
+    an intermediary layer, such as a load balancer, a web proxy, or a backend-for-frontend
+    service, cannot be overridden by the end-user. Example headers might include X-Real-IP,
+    X-Forwarded-*, or X-User-ID.
+  level: '2'
 4.1.4:
   capec_codes:
   - '272'
   - '28'
+  description: Verify that only HTTP methods that are explicitly supported by the
+    application or its API (including OPTIONS during preflight requests) can be used
+    and that unused methods are blocked.
+  level: '3'
 4.1.5:
   capec_codes:
   - '145'
@@ -2845,24 +3887,44 @@ meta:
   - '75'
   - '94'
   - '98'
+  description: Verify that per-message digital signatures are used to provide additional
+    assurance on top of transport protections for requests or transactions which are
+    highly sensitive or which traverse a number of systems.
+  level: '3'
 4.2.1:
   capec_codes:
   - '105'
   - '220'
   - '272'
   - '33'
+  description: Verify that all application components (including load balancers, firewalls,
+    and application servers) determine boundaries of incoming HTTP messages using
+    the appropriate mechanism for the HTTP version to prevent HTTP request smuggling.
+    In HTTP/1.x, if a Transfer-Encoding header field is present, the Content-Length
+    header must be ignored per RFC 2616. When using HTTP/2 or HTTP/3, if a Content-Length
+    header field is present, the receiver must ensure that it is consistent with the
+    length of the DATA frames.
+  level: '2'
 4.2.2:
   capec_codes:
   - '105'
   - '220'
   - '272'
   - '33'
+  description: Verify that when generating HTTP messages, the Content-Length header
+    field does not conflict with the length of the content as determined by the framing
+    of the HTTP protocol, in order to prevent request smuggling attacks.
+  level: '3'
 4.2.3:
   capec_codes:
   - '105'
   - '220'
   - '272'
   - '33'
+  description: Verify that the application does not send nor accept HTTP/2 or HTTP/3
+    messages with connection-specific header fields such as Transfer-Encoding to prevent
+    response splitting and header injection attacks.
+  level: '3'
 4.2.4:
   capec_codes:
   - '105'
@@ -2870,42 +3932,74 @@ meta:
   - '272'
   - '28'
   - '33'
+  description: Verify that the application only accepts HTTP/2 and HTTP/3 requests
+    where the header fields and values do not contain any CR (\r), LF (\n), or CRLF
+    (\r\n) sequences, to prevent header injection attacks.
+  level: '3'
 4.2.5:
   capec_codes:
   - '100'
   - '227'
   - '25'
   - '28'
+  description: Verify that, if the application (backend or frontend) builds and sends
+    requests, it uses validation, sanitization, or other mechanisms to avoid creating
+    URIs (such as for API calls) or HTTP request header fields (such as Authorization
+    or Cookie), which are too long to be accepted by the receiving component. This
+    could cause a denial of service, such as when sending an overly long request (e.g.,
+    a long cookie header field), which results in the server always responding with
+    an error status.
+  level: '3'
 4.3.1:
   capec_codes:
   - '100'
   - '130'
+  description: Verify that a query allowlist, depth limiting, amount limiting, or
+    query cost analysis is used to prevent GraphQL or data layer expression Denial
+    of Service (DoS) as a result of expensive, nested queries.
+  level: '2'
 4.3.2:
   capec_codes:
   - '116'
   - '169'
   - '224'
   - '54'
+  description: Verify that GraphQL introspection queries are disabled in the production
+    environment unless the GraphQL API is meant to be used by other parties.
+  level: '2'
 4.4.1:
   capec_codes:
   - '102'
   - '117'
   - '383'
   - '94'
+  description: Verify that WebSocket over TLS (WSS) is used for all WebSocket connections.
+  level: '1'
 4.4.2:
   capec_codes:
   - '383'
   - '62'
+  description: Verify that, during the initial HTTP WebSocket handshake, the Origin
+    header field is checked against a list of origins allowed for the application.
+  level: '2'
 4.4.3:
   capec_codes:
   - '21'
   - '383'
   - '49'
   - '633'
+  description: Verify that, if the application's standard session management cannot
+    be used, dedicated tokens are being used for this, which comply with the relevant
+    Session Management security requirements.
+  level: '2'
 4.4.4:
   capec_codes:
   - '115'
   - '383'
+  description: Verify that dedicated WebSocket session management tokens are initially
+    obtained or validated through the previously authenticated HTTPS session when
+    transitioning an existing HTTPS session to a WebSocket channel.
+  level: '2'
 5.1.1:
   capec_codes:
   - '126'
@@ -2924,12 +4018,21 @@ meta:
   - '549'
   - '636'
   - '66'
+  description: Verify that the documentation defines the permitted file types, expected
+    file extensions, and maximum size (including unpacked size) for each upload feature.
+    Additionally, ensure that the documentation specifies how files are made safe
+    for end-users to download and process, such as how the application behaves when
+    a malicious file is detected.
+  level: '2'
 5.2.1:
   capec_codes:
   - '126'
   - '130'
   - '165'
   - '572'
+  description: Verify that the application will only accept files of a size which
+    it can process without causing a loss of performance or a denial of service attack.
+  level: '1'
 5.2.2:
   capec_codes:
   - '126'
@@ -2946,15 +4049,32 @@ meta:
   - '549'
   - '636'
   - '66'
+  description: Verify that when the application accepts a file, either on its own
+    or within an archive such as a zip file, it checks if the file extension matches
+    an expected file extension and validates that the contents correspond to the type
+    represented by the extension. This includes, but is not limited to, checking the
+    initial 'magic bytes', performing image re-writing, and using specialized libraries
+    for file content validation. For L1, this can focus just on files which are used
+    to make specific business or security decisions. For L2 and up, this must apply
+    to all files being accepted.
+  level: '1'
 5.2.3:
   capec_codes:
   - '126'
   - '165'
   - '23'
   - '66'
+  description: Verify that the application checks compressed files (e.g., zip, gz,
+    docx, odt) against maximum allowed uncompressed size and against maximum number
+    of files before uncompressing the file.
+  level: '2'
 5.2.4:
   capec_codes:
   - '165'
+  description: Verify that a file size quota and maximum number of files per user
+    are enforced to ensure that a single user cannot fill up the storage with too
+    many files, or excessively large files.
+  level: '3'
 5.2.5:
   capec_codes:
   - '126'
@@ -2962,11 +4082,18 @@ meta:
   - '165'
   - '23'
   - '66'
+  description: Verify that the application does not allow uploading compressed files
+    containing symlinks unless this is specifically required (in which case it will
+    be necessary to enforce an allowlist of the files that can be symlinked to).
+  level: '3'
 5.2.6:
   capec_codes:
   - '130'
   - '165'
   - '572'
+  description: Verify that the application rejects uploaded images with a pixel size
+    larger than the maximum allowed, to prevent pixel flood attacks.
+  level: '3'
 5.3.1:
   capec_codes:
   - '126'
@@ -2984,6 +4111,10 @@ meta:
   - '549'
   - '636'
   - '66'
+  description: Verify that files uploaded or generated by untrusted input and stored
+    in a public folder, are not executed as server-side program code when accessed
+    directly with an HTTP request.
+  level: '1'
 5.3.2:
   capec_codes:
   - '126'
@@ -3004,6 +4135,12 @@ meta:
   - '636'
   - '66'
   - '664'
+  description: Verify that when the application creates file paths for file operations,
+    instead of user-submitted filenames, it uses internally generated or trusted data,
+    or if user-submitted filenames or file metadata must be used, strict validation
+    and sanitization must be applied. This is to protect against path traversal, local
+    or remote file inclusion (LFI, RFI), and server-side request forgery (SSRF) attacks.
+  level: '1'
 5.3.3:
   capec_codes:
   - '126'
@@ -3015,6 +4152,10 @@ meta:
   - '253'
   - '48'
   - '66'
+  description: Verify that server-side file processing, such as file decompression,
+    ignores user-provided path information to prevent vulnerabilities such as zip
+    slip.
+  level: '3'
 5.4.1:
   capec_codes:
   - '126'
@@ -3037,6 +4178,10 @@ meta:
   - '636'
   - '64'
   - '66'
+  description: Verify that the application validates or ignores user-submitted filenames,
+    including in a JSON, JSONP, or URL parameter and specifies a filename in the Content-Disposition
+    header field in the response.
+  level: '2'
 5.4.2:
   capec_codes:
   - '126'
@@ -3061,6 +4206,10 @@ meta:
   - '636'
   - '64'
   - '66'
+  description: Verify that file names served (e.g., in HTTP response header fields
+    or email attachments) are encoded or sanitized (e.g., following RFC 6266) to preserve
+    document structure and prevent injection attacks.
+  level: '2'
 5.4.3:
   capec_codes:
   - '122'
@@ -3078,6 +4227,9 @@ meta:
   - '549'
   - '636'
   - '66'
+  description: Verify that files obtained from untrusted sources are scanned by antivirus
+    scanners to prevent serving of known malicious content.
+  level: '2'
 6.1.1:
   capec_codes:
   - '114'
@@ -3088,11 +4240,22 @@ meta:
   - '49'
   - '50'
   - '70'
+  description: Verify that application documentation defines how controls such as
+    rate limiting, anti-automation, and adaptive response, are used to defend against
+    attacks such as credential stuffing and password brute force. The documentation
+    must make clear how these controls are configured and prevent malicious account
+    lockout.
+  level: '1'
 6.1.2:
   capec_codes:
   - '114'
   - '115'
   - '49'
+  description: Verify that a list of context-specific words is documented in order
+    to prevent their use in passwords. The list could include permutations of organization
+    names, product names, system identifiers, project codenames, department or role
+    names, and similar.
+  level: '2'
 6.1.3:
   capec_codes:
   - '113'
@@ -3101,14 +4264,25 @@ meta:
   - '151'
   - '179'
   - '50'
+  description: Verify that, if the application includes multiple authentication pathways,
+    these are all documented together with the security controls and authentication
+    strength which must be consistently enforced across them.
+  level: '2'
 6.2.1:
   capec_codes:
   - '49'
+  description: Verify that user set passwords are at least 8 characters in length
+    although a minimum of 15 characters is strongly recommended.
+  level: '1'
 6.2.10:
   capec_codes:
   - '151'
   - '49'
   - '560'
+  description: Verify that a user's password stays valid until it is discovered to
+    be compromised or the user rotates it. The application must not require periodic
+    credential rotation.
+  level: '2'
 6.2.11:
   capec_codes:
   - '151'
@@ -3116,6 +4290,9 @@ meta:
   - '49'
   - '560'
   - '70'
+  description: Verify that the documented list of context specific words is used to
+    prevent easy to guess passwords being created.
+  level: '2'
 6.2.12:
   capec_codes:
   - '151'
@@ -3123,14 +4300,22 @@ meta:
   - '49'
   - '560'
   - '70'
+  description: Verify that passwords submitted during account registration or password
+    changes are checked against a set of breached passwords.
+  level: '2'
 6.2.2:
   capec_codes:
   - '116'
   - '70'
+  description: Verify that users can change their password.
+  level: '1'
 6.2.3:
   capec_codes:
   - '114'
   - '50'
+  description: Verify that password change functionality requires the user's current
+    and new password.
+  level: '1'
 6.2.4:
   capec_codes:
   - '151'
@@ -3139,21 +4324,41 @@ meta:
   - '50'
   - '560'
   - '70'
+  description: Verify that passwords submitted during account registration or password
+    change are checked against an available set of, at least, the top 3000 passwords
+    which match the application's password policy, e.g. minimum length.
+  level: '1'
 6.2.5:
   capec_codes:
   - '49'
+  description: Verify that passwords of any composition can be used, without rules
+    limiting the type of characters permitted. There must be no requirement for a
+    minimum number of upper or lower case characters, numbers, or special characters.
+  level: '1'
 6.2.6:
   capec_codes:
   - '508'
+  description: Verify that password input fields use type=password to mask the entry.
+    Applications may allow the user to temporarily view the entire masked password,
+    or the last typed character of the password.
+  level: '1'
 6.2.7:
   capec_codes:
   - '508'
+  description: Verify that "paste" functionality, browser password helpers, and external
+    password managers are permitted.
+  level: '1'
 6.2.8:
   capec_codes:
   - '49'
+  description: Verify that the application verifies the user's password exactly as
+    received from the user, without any modifications such as truncation or case transformation.
+  level: '1'
 6.2.9:
   capec_codes:
   - '49'
+  description: Verify that passwords of at least 64 characters are permitted.
+  level: '2'
 6.3.1:
   capec_codes:
   - '114'
@@ -3162,6 +4367,10 @@ meta:
   - '2'
   - '49'
   - '70'
+  description: Verify that controls to prevent attacks such as credential stuffing
+    and password brute force are implemented according to the application's security
+    documentation.
+  level: '1'
 6.3.2:
   capec_codes:
   - '114'
@@ -3172,6 +4381,9 @@ meta:
   - '49'
   - '560'
   - '70'
+  description: Verify that default user accounts (e.g., "root", "admin", or "sa")
+    are not present in the application or are disabled.
+  level: '1'
 6.3.3:
   capec_codes:
   - '114'
@@ -3186,11 +4398,24 @@ meta:
   - '568'
   - '654'
   - '68'
+  description: Verify that either a multi-factor authentication mechanism or a combination
+    of single-factor authentication mechanisms, must be used in order to access the
+    application. For L3, one of the factors must be a hardware-based authentication
+    mechanism which provides compromise and impersonation resistance against phishing
+    attacks while verifying the intent to authenticate by requiring a user-initiated
+    action (such as a button press on a FIDO hardware key or a mobile phone). Relaxing
+    any of the considerations in this requirement requires a fully documented rationale
+    and a comprehensive set of mitigating controls.
+  level: '2'
 6.3.4:
   capec_codes:
   - '114'
   - '115'
   - '151'
+  description: Verify that, if the application includes multiple authentication pathways,
+    there are no undocumented pathways and that security controls and authentication
+    strength are enforced consistently.
+  level: '2'
 6.3.5:
   capec_codes:
   - '114'
@@ -3200,6 +4425,12 @@ meta:
   - '49'
   - '50'
   - '600'
+  description: Verify that users are notified of suspicious authentication attempts
+    (successful or unsuccessful). This may include authentication attempts from an
+    unusual location or client, partially successful authentication (only one of multiple
+    factors), an authentication attempt after a long period of inactivity or a successful
+    authentication after several unsuccessful attempts.
+  level: '3'
 6.3.6:
   capec_codes:
   - '114'
@@ -3207,6 +4438,9 @@ meta:
   - '151'
   - '50'
   - '633'
+  description: Verify that email is not used as either a single-factor or multi-factor
+    authentication mechanism.
+  level: '3'
 6.3.7:
   capec_codes:
   - '114'
@@ -3215,6 +4449,9 @@ meta:
   - '49'
   - '50'
   - '600'
+  description: Verify that users are notified after updates to authentication details,
+    such as credential resets or modification of the username or email address.
+  level: '3'
 6.3.8:
   capec_codes:
   - '116'
@@ -3223,11 +4460,21 @@ meta:
   - '49'
   - '560'
   - '70'
+  description: Verify that valid users cannot be deduced from failed authentication
+    challenges, such as by basing on error messages, HTTP response codes, or different
+    response times. Registration and forgot password functionality must also have
+    this protection.
+  level: '3'
 6.4.1:
   capec_codes:
   - '151'
   - '49'
   - '633'
+  description: Verify that system generated initial passwords or activation codes
+    are securely randomly generated, follow the existing password policy, and expire
+    after a short period of time or after they are initially used. These initial secrets
+    must not be permitted to become the long term password.
+  level: '1'
 6.4.2:
   capec_codes:
   - '114'
@@ -3237,6 +4484,9 @@ meta:
   - '49'
   - '560'
   - '70'
+  description: Verify that password hints or knowledge-based authentication (so-called
+    "secret questions") are not present.
+  level: '1'
 6.4.3:
   capec_codes:
   - '114'
@@ -3244,18 +4494,28 @@ meta:
   - '151'
   - '49'
   - '50'
+  description: Verify that a secure process for resetting a forgotten password is
+    implemented, that does not bypass any enabled multi-factor authentication mechanisms.
+  level: '2'
 6.4.4:
   capec_codes:
   - '114'
   - '115'
   - '151'
   - '50'
+  description: Verify that if a multi-factor authentication factor is lost, evidence
+    of identity proofing is performed at the same level as during enrollment.
+  level: '2'
 6.4.5:
   capec_codes:
   - '518'
   - '519'
   - '603'
   - '607'
+  description: Verify that renewal instructions for authentication mechanisms which
+    expire are sent with enough time to be carried out before the old authentication
+    mechanism expires, configuring automated reminders if necessary.
+  level: '3'
 6.4.6:
   capec_codes:
   - '416'
@@ -3265,6 +4525,10 @@ meta:
   - '548'
   - '603'
   - '607'
+  description: Verify that administrative users can initiate the password reset process
+    for the user, but that this does not allow them to change or choose the user's
+    password. This prevents a situation where they know the user's password.
+  level: '3'
 6.5.1:
   capec_codes:
   - '114'
@@ -3272,21 +4536,39 @@ meta:
   - '49'
   - '50'
   - '633'
+  description: Verify that lookup secrets, out-of-band authentication requests or
+    codes, and time-based one-time passwords (TOTPs) are only successfully usable
+    once.
+  level: '2'
 6.5.2:
   capec_codes:
   - '114'
   - '151'
   - '49'
+  description: Verify that, when being stored in the application's backend, lookup
+    secrets with less than 112 bits of entropy (19 random alphanumeric characters
+    or 34 random digits) are hashed with an approved password storage hashing algorithm
+    that incorporates a 32-bit random salt. A standard hash function can be used if
+    the secret has 112 bits of entropy or more.
+  level: '2'
 6.5.3:
   capec_codes:
   - '114'
   - '151'
   - '49'
+  description: Verify that lookup secrets, out-of-band authentication code, and time-based
+    one-time password seeds, are generated using a Cryptographically Secure Pseudorandom
+    Number Generator (CSPRNG) to avoid predictable values.
+  level: '2'
 6.5.4:
   capec_codes:
   - '114'
   - '151'
   - '49'
+  description: Verify that lookup secrets and out-of-band authentication codes have
+    a minimum of 20 bits of entropy (typically 4 random alphanumeric characters or
+    6 random digits is sufficient).
+  level: '2'
 6.5.5:
   capec_codes:
   - '114'
@@ -3294,6 +4576,11 @@ meta:
   - '49'
   - '50'
   - '633'
+  description: Verify that out-of-band authentication requests, codes, or tokens,
+    as well as time-based one-time passwords (TOTPs) have a defined lifetime. Out
+    of band requests must have a maximum lifetime of 10 minutes and for TOTP a maximum
+    lifetime of 30 seconds.
+  level: '2'
 6.5.6:
   capec_codes:
   - '114'
@@ -3304,17 +4591,27 @@ meta:
   - '568'
   - '633'
   - '654'
+  description: Verify that any authentication factor (including physical devices)
+    can be revoked in case of theft or other loss.
+  level: '3'
 6.5.7:
   capec_codes:
   - '114'
   - '151'
   - '49'
+  description: Verify that biometric authentication mechanisms are only used as secondary
+    factors together with either something you have or something you know.
+  level: '3'
 6.5.8:
   capec_codes:
   - '114'
   - '151'
   - '50'
   - '633'
+  description: Verify that time-based one-time passwords (TOTPs) are checked based
+    on a time source from a trusted service and not from an untrusted or client provided
+    time.
+  level: '3'
 6.6.1:
   capec_codes:
   - '114'
@@ -3322,22 +4619,41 @@ meta:
   - '151'
   - '50'
   - '633'
+  description: Verify that authentication mechanisms using the Public Switched Telephone
+    Network (PSTN) to deliver One-time Passwords (OTPs) via phone or SMS are offered
+    only when the phone number has previously been validated, alternate stronger methods
+    (such as Time based One-time Passwords) are also offered, and the service provides
+    information on their security risks to users. For L3 applications, phone and SMS
+    must not be available as options.
+  level: '2'
 6.6.2:
   capec_codes:
   - '114'
   - '151'
   - '50'
   - '633'
+  description: Verify that out-of-band authentication requests, codes, or tokens are
+    bound to the original authentication request for which they were generated and
+    are not usable for a previous or subsequent one.
+  level: '2'
 6.6.3:
   capec_codes:
   - '114'
   - '151'
   - '49'
+  description: Verify that a code based out-of-band authentication mechanism is protected
+    against brute force attacks by using rate limiting. Consider also using a code
+    with at least 64 bits of entropy.
+  level: '2'
 6.6.4:
   capec_codes:
   - '114'
   - '151'
   - '49'
+  description: Verify that, where push notifications are used for multi-factor authentication,
+    rate limiting is used to prevent push bombing attacks. Number matching may also
+    mitigate this risk.
+  level: '3'
 6.7.1:
   capec_codes:
   - '114'
@@ -3358,13 +4674,25 @@ meta:
   - '690'
   - '75'
   - '94'
+  description: Verify that the certificates used to verify cryptographic authentication
+    assertions are stored in a way protects them from modification.
+  level: '3'
 6.7.2:
   capec_codes:
   - '114'
+  description: Verify that the challenge nonce is at least 64 bits in length, and
+    statistically unique or unique over the lifetime of the cryptographic device.
+  level: '3'
 6.8.1:
   capec_codes:
   - '114'
   - '115'
+  description: Verify that, if the application supports multiple identity providers
+    (IdPs), the user's identity cannot be spoofed via another supported identity provider
+    (eg. by using the same user identifier). The standard mitigation would be for
+    the application to register and identify the user using a combination of the IdP
+    ID (serving as a namespace) and the user's ID in the IdP.
+  level: '2'
 6.8.2:
   capec_codes:
   - '114'
@@ -3372,6 +4700,10 @@ meta:
   - '268'
   - '473'
   - '475'
+  description: Verify that the presence and integrity of digital signatures on authentication
+    assertions (for example on JWTs or SAML assertions) are always validated, rejecting
+    any assertions that are unsigned or have invalid signatures.
+  level: '2'
 6.8.3:
   capec_codes:
   - '114'
@@ -3379,15 +4711,32 @@ meta:
   - '151'
   - '50'
   - '633'
+  description: Verify that SAML assertions are uniquely processed and used only once
+    within the validity period to prevent replay attacks.
+  level: '2'
 6.8.4:
   capec_codes:
   - '114'
   - '115'
+  description: Verify that, if an application uses a separate Identity Provider (IdP)
+    and expects specific authentication strength, methods, or recentness for specific
+    functions, the application verifies this using the information returned by the
+    IdP. For example, if OIDC is used, this might be achieved by validating ID Token
+    claims such as 'acr', 'amr', and 'auth_time' (if present). If the IdP does not
+    provide this information, the application must have a documented fallback approach
+    that assumes that the minimum strength authentication mechanism was used (for
+    example, single-factor authentication using username and password).
+  level: '2'
 7.1.1:
   capec_codes:
   - '21'
   - '464'
   - '593'
+  description: Verify that the user's session inactivity timeout and absolute maximum
+    session lifetime are documented, are appropriate in combination with other controls,
+    and that the documentation includes justification for any deviations from NIST
+    SP 800-63B re-authentication requirements.
+  level: '2'
 7.1.2:
   capec_codes:
   - '195'
@@ -3398,6 +4747,10 @@ meta:
   - '543'
   - '593'
   - '98'
+  description: Verify that the documentation defines how many concurrent (parallel)
+    sessions are allowed for one account as well as the intended behaviors and actions
+    to be taken when the maximum number of active sessions is reached.
+  level: '2'
 7.1.3:
   capec_codes:
   - '195'
@@ -3409,6 +4762,11 @@ meta:
   - '543'
   - '593'
   - '98'
+  description: Verify that all systems that create and manage user sessions as part
+    of a federated identity management ecosystem (such as SSO systems) are documented
+    along with controls to coordinate session lifetimes, termination, and any other
+    conditions that require re-authentication.
+  level: '2'
 7.2.1:
   capec_codes:
   - '115'
@@ -3419,29 +4777,46 @@ meta:
   - '554'
   - '59'
   - '61'
+  description: Verify that the application performs all session token verification
+    using a trusted, backend service.
+  level: '1'
 7.2.2:
   capec_codes:
   - '21'
   - '31'
   - '59'
   - '61'
+  description: Verify that the application uses either self-contained or reference
+    tokens that are dynamically generated for session management, i.e. not using static
+    API secrets and keys.
+  level: '1'
 7.2.3:
   capec_codes:
   - '196'
   - '21'
   - '31'
   - '59'
+  description: Verify that if reference tokens are used to represent user sessions,
+    they are unique and generated using a cryptographically secure pseudo-random number
+    generator (CSPRNG) and possess at least 128 bits of entropy.
+  level: '1'
 7.2.4:
   capec_codes:
   - '21'
   - '31'
   - '59'
   - '593'
+  description: Verify that the application generates a new session token on user authentication,
+    including re-authentication, and terminates the current session token.
+  level: '1'
 7.3.1:
   capec_codes:
   - '21'
   - '464'
   - '593'
+  description: Verify that there is an inactivity timeout such that re-authentication
+    is enforced according to risk analysis and documented security decisions.
+  level: '2'
 7.3.2:
   capec_codes:
   - '195'
@@ -3452,6 +4827,10 @@ meta:
   - '543'
   - '593'
   - '98'
+  description: Verify that there is an absolute maximum session lifetime such that
+    re-authentication is enforced according to risk analysis and documented security
+    decisions.
+  level: '2'
 7.4.1:
   capec_codes:
   - '195'
@@ -3463,20 +4842,38 @@ meta:
   - '543'
   - '593'
   - '98'
+  description: Verify that when session termination is triggered (such as logout or
+    expiration), the application disallows any further use of the session. For reference
+    tokens or stateful sessions, this means invalidating the session data at the application
+    backend. Applications using self-contained tokens will need a solution such as
+    maintaining a list of terminated tokens, disallowing tokens produced before a
+    per-user date and time or rotating a per-user signing key.
+  level: '1'
 7.4.2:
   capec_codes:
   - '21'
   - '593'
+  description: Verify that the application terminates all active sessions when a user
+    account is disabled or deleted (such as an employee leaving the company).
+  level: '1'
 7.4.3:
   capec_codes:
   - '21'
   - '593'
+  description: Verify that the application gives the option to terminate all other
+    active sessions after a successful change or removal of any authentication factor
+    (including password change via reset or recovery and, if present, an MFA settings
+    update).
+  level: '2'
 7.4.4:
   capec_codes:
   - '21'
   - '31'
   - '464'
   - '593'
+  description: Verify that all pages that require authentication have easy and visible
+    access to logout functionality.
+  level: '2'
 7.4.5:
   capec_codes:
   - '195'
@@ -3488,6 +4885,9 @@ meta:
   - '543'
   - '593'
   - '98'
+  description: Verify that application administrators are able to terminate active
+    sessions for an individual user or for all users.
+  level: '2'
 7.5.1:
   capec_codes:
   - '114'
@@ -3495,6 +4895,11 @@ meta:
   - '151'
   - '21'
   - '50'
+  description: Verify that the application requires full re-authentication before
+    allowing modifications to sensitive account attributes which may affect authentication
+    such as email address, phone number, MFA configuration, or other information used
+    in account recovery.
+  level: '2'
 7.5.2:
   capec_codes:
   - '151'
@@ -3507,6 +4912,9 @@ meta:
   - '543'
   - '593'
   - '98'
+  description: Verify that users are able to view and (having authenticated again
+    with at least one factor) terminate any or all currently active sessions.
+  level: '2'
 7.5.3:
   capec_codes:
   - '114'
@@ -3515,6 +4923,10 @@ meta:
   - '21'
   - '49'
   - '50'
+  description: Verify that the application requires further authentication with at
+    least one factor or secondary verification before performing highly sensitive
+    transactions or operations.
+  level: '3'
 7.6.1:
   capec_codes:
   - '195'
@@ -3526,9 +4938,18 @@ meta:
   - '543'
   - '593'
   - '98'
+  description: Verify that session lifetime and termination between Relying Parties
+    (RPs) and Identity Providers (IdPs) behave as documented, requiring re-authentication
+    as necessary such as when the maximum time between IdP authentication events is
+    reached.
+  level: '2'
 7.6.2:
   capec_codes:
   - '416'
+  description: Verify that creation of a session requires either the user's consent
+    or an explicit action, preventing the creation of new application sessions without
+    user interaction.
+  level: '2'
 8.1.1:
   capec_codes:
   - '1'
@@ -3552,6 +4973,10 @@ meta:
   - '58'
   - '75'
   - '87'
+  description: Verify that authorization documentation defines rules for restricting
+    function-level and data-specific access based on consumer permissions and resource
+    attributes.
+  level: '1'
 8.1.2:
   capec_codes:
   - '122'
@@ -3559,6 +4984,11 @@ meta:
   - '212'
   - '554'
   - '58'
+  description: Verify that authorization documentation defines rules for field-level
+    access restrictions (both read and write) based on consumer permissions and resource
+    attributes. Note that these rules might depend on other attribute values of the
+    relevant data object, such as state or status.
+  level: '2'
 8.1.3:
   capec_codes:
   - '114'
@@ -3573,6 +5003,11 @@ meta:
   - '593'
   - '633'
   - '98'
+  description: Verify that the application's documentation defines the environmental
+    and contextual attributes (including but not limited to, time of day, user location,
+    IP address, or device) that are used in the application to make security decisions,
+    including those pertaining to authentication and authorization.
+  level: '3'
 8.1.4:
   capec_codes:
   - '1'
@@ -3594,6 +5029,12 @@ meta:
   - '633'
   - '75'
   - '98'
+  description: Verify that authentication and authorization documentation defines
+    how environmental and contextual factors are used in decision-making, in addition
+    to function-level, data-specific, and field-level authorization. This should include
+    the attributes evaluated, thresholds for risk, and actions taken (e.g., allow,
+    challenge, deny, step-up authentication).
+  level: '3'
 8.2.1:
   capec_codes:
   - '1'
@@ -3608,6 +5049,9 @@ meta:
   - '554'
   - '58'
   - '75'
+  description: Verify that the application ensures that function-level access is restricted
+    to consumers with explicit permissions.
+  level: '1'
 8.2.2:
   capec_codes:
   - '122'
@@ -3615,6 +5059,10 @@ meta:
   - '212'
   - '383'
   - '58'
+  description: Verify that the application ensures that data-specific access is restricted
+    to consumers with explicit permissions to specific data items to mitigate insecure
+    direct object reference (IDOR) and broken object level authorization (BOLA).
+  level: '1'
 8.2.3:
   capec_codes:
   - '122'
@@ -3622,6 +5070,10 @@ meta:
   - '212'
   - '383'
   - '58'
+  description: Verify that the application ensures that field-level access is restricted
+    to consumers with explicit permissions to specific fields to mitigate broken object
+    property level authorization (BOPLA).
+  level: '2'
 8.2.4:
   capec_codes:
   - '176'
@@ -3635,6 +5087,12 @@ meta:
   - '593'
   - '633'
   - '98'
+  description: Verify that adaptive security controls based on a consumer's environmental
+    and contextual attributes (such as time of day, location, IP address, or device)
+    are implemented for authentication and authorization decisions, as defined in
+    the application's documentation. These controls must be applied when the consumer
+    tries to start a new session and also during an existing session.
+  level: '3'
 8.3.1:
   capec_codes:
   - '1'
@@ -3654,12 +5112,23 @@ meta:
   - '554'
   - '74'
   - '95'
+  description: Verify that the application enforces authorization rules at a trusted
+    service layer and doesn't rely on controls that an untrusted consumer could manipulate,
+    such as client-side JavaScript.
+  level: '1'
 8.3.2:
   capec_codes:
   - '156'
   - '176'
   - '554'
   - '593'
+  description: Verify that changes to values on which authorization decisions are
+    made are applied immediately. Where changes cannot be applied immediately, (such
+    as when relying on data in self-contained tokens), there must be mitigating controls
+    to alert when a consumer performs an action when they are no longer authorized
+    to do so and revert the change. Note that this alternative would not mitigate
+    information leakage.
+  level: '3'
 8.3.3:
   capec_codes:
   - '156'
@@ -3670,10 +5139,21 @@ meta:
   - '30'
   - '554'
   - '69'
+  description: Verify that access to an object is based on the originating subject's
+    (e.g. consumer's) permissions, not on the permissions of any intermediary or service
+    acting on their behalf. For example, if a consumer calls a web service using a
+    self-contained token for authentication, and the service then requests data from
+    a different service, the second service will use the consumer's token, rather
+    than a machine-to-machine token from the first service, to make permission decisions.
+  level: '3'
 8.4.1:
   capec_codes:
   - '1'
   - '180'
+  description: Verify that multi-tenant applications use cross-tenant controls to
+    ensure consumer operations will never affect tenants with which they do not have
+    permissions to interact.
+  level: '2'
 8.4.2:
   capec_codes:
   - '1'
@@ -3691,6 +5171,12 @@ meta:
   - '554'
   - '69'
   - '75'
+  description: Verify that access to administrative interfaces incorporates multiple
+    layers of security, including continuous consumer identity verification, device
+    security posture assessment, and contextual risk analysis, ensuring that network
+    location or trusted endpoints are not the sole factors for authorization even
+    though they may reduce the likelihood of unauthorized access.
+  level: '3'
 9.1.1:
   capec_codes:
   - '145'
@@ -3699,6 +5185,9 @@ meta:
   - '475'
   - '57'
   - '94'
+  description: Verify that self-contained tokens are validated using their digital
+    signature or MAC to protect against tampering before accepting the token's contents.
+  level: '1'
 9.1.2:
   capec_codes:
   - '145'
@@ -3707,6 +5196,12 @@ meta:
   - '475'
   - '57'
   - '94'
+  description: Verify that only algorithms on an allowlist can be used to create and
+    verify self-contained tokens, for a given context. The allowlist must include
+    the permitted algorithms, ideally only either symmetric or asymmetric algorithms,
+    and must not include the 'None' algorithm. If both symmetric and asymmetric must
+    be supported, additional controls will be needed to prevent key confusion.
+  level: '1'
 9.1.3:
   capec_codes:
   - '145'
@@ -3716,6 +5211,12 @@ meta:
   - '475'
   - '57'
   - '94'
+  description: Verify that key material that is used to validate self-contained tokens
+    is from trusted pre-configured sources for the token issuer, preventing attackers
+    from specifying untrusted sources and keys. For JWTs and other JWS structures,
+    headers such as 'jku', 'x5u', and 'jwk' must be validated against an allowlist
+    of trusted sources.
+  level: '1'
 9.2.1:
   capec_codes:
   - '151'
@@ -3723,15 +5224,36 @@ meta:
   - '21'
   - '50'
   - '633'
+  description: Verify that, if a validity time span is present in the token data,
+    the token and its content are accepted only if the verification time is within
+    this validity time span. For example, for JWTs, the claims 'nbf' and 'exp' must
+    be verified.
+  level: '1'
 9.2.2:
   capec_codes:
   - '21'
   - '39'
+  description: Verify that the service receiving a token validates the token to be
+    the correct type and is meant for the intended purpose before accepting the token's
+    contents. For example, only access tokens can be accepted for authorization decisions
+    and only ID Tokens can be used for proving user authentication.
+  level: '2'
 9.2.3:
   capec_codes:
   - '21'
   - '39'
+  description: Verify that the service only accepts tokens which are intended for
+    use with that service (audience). For JWTs, this can be achieved by validating
+    the 'aud' claim against an allowlist defined in the service.
+  level: '2'
 9.2.4:
   capec_codes:
   - '21'
   - '39'
+  description: Verify that, if a token issuer uses the same private key for issuing
+    tokens to different audiences, the issued tokens contain an audience restriction
+    that uniquely identifies the intended audiences. This will prevent a token from
+    being reused with an unintended audience. If the audience identifier is dynamically
+    provisioned, the token issuer must validate these audiences in order to make sure
+    that they do not result in audience impersonation.
+  level: '2'
diff --git a/tests/scripts/convert_capec_map_to_asvs_map_utest.py b/tests/scripts/convert_capec_map_to_asvs_map_utest.py
index 2de3cd92a..44831ede6 100644
--- a/tests/scripts/convert_capec_map_to_asvs_map_utest.py
+++ b/tests/scripts/convert_capec_map_to_asvs_map_utest.py
@@ -342,16 +342,34 @@ def test_parse_edition_parameter(self):
         args = capec_map.parse_arguments(["-e", "webapp"])
         self.assertEqual(args.edition, "webapp")
 
+    def test_parse_asvs_json_argument(self):
+        """Test parsing with asvs-json argument"""
+        args = capec_map.parse_arguments(["--asvs-json", "asvs.json"])
+        self.assertEqual(args.asvs_json, "asvs.json")
+
     def test_parse_all_arguments(self):
         """Test parsing with all arguments"""
         args = capec_map.parse_arguments(
-            ["-i", "input.yaml", "-o", ConvertVars.OUTPUT_FILE, "-v", "3.0", "-e", "webapp", "-d"]
+            [
+                "-i",
+                "input.yaml",
+                "-o",
+                ConvertVars.OUTPUT_FILE,
+                "-v",
+                "3.0",
+                "-e",
+                "webapp",
+                "-d",
+                "--asvs-json",
+                "asvs.json",
+            ]
         )
 
         self.assertEqual(args.input_path, "input.yaml")
         self.assertEqual(args.output_path, ConvertVars.OUTPUT_FILE)
         self.assertEqual(args.version, "3.0")
         self.assertEqual(args.edition, "webapp")
+        self.assertEqual(args.asvs_json, "asvs.json")
         self.assertTrue(args.debug)
 
     def test_parse_long_form_arguments(self):
@@ -366,6 +384,8 @@ def test_parse_long_form_arguments(self):
                 "3.0",
                 "--edition",
                 "webapp",
+                "--asvs-json",
+                "asvs.json",
                 "--debug",
             ]
         )
@@ -374,6 +394,7 @@ def test_parse_long_form_arguments(self):
         self.assertEqual(args.output_path, ConvertVars.OUTPUT_FILE)
         self.assertEqual(args.version, "3.0")
         self.assertEqual(args.edition, "webapp")
+        self.assertEqual(args.asvs_json, "asvs.json")
         self.assertTrue(args.debug)
 
 
@@ -412,6 +433,7 @@ def test_main_successful_execution(self, mock_exit, mock_parse_args, mock_load,
             output_path=Path(ConvertVars.OUTPUT_FILE),
             version="3.0",
             edition="webapp",
+            asvs_json=None,
             debug=False,
         )
         mock_load.return_value = {"suits": [{"cards": [{"capec_map": {54: {"owasp_asvs": ["4.3.2"]}}}]}]}
@@ -434,6 +456,7 @@ def test_main_no_data_loaded(self, mock_exit, mock_parse_args, mock_load):
             output_path=Path(ConvertVars.OUTPUT_DIR + "nonexistent2.yaml"),
             version="3.0",
             edition="webapp",
+            asvs_json=None,
             debug=False,
         )
         mock_load.return_value = {}
@@ -458,6 +481,7 @@ def test_main_save_fails(self, mock_exit2, mock_parse_args, mock_load, mock_save
             output_path=Path(ConvertVars.OUTPUT_DIR + "nonexistent3.yaml"),
             version="3.0",
             edition="webapp",
+            asvs_json=None,
             debug=False,
         )
         mock_load.return_value = {"suits": [{"cards": [{"capec_map": {54: {"owasp_asvs": ["4.3.2"]}}}]}]}
@@ -472,6 +496,250 @@ def test_main_save_fails(self, mock_exit2, mock_parse_args, mock_load, mock_save
         last_call = mock_exit2.call_args_list[-1]
         self.assertEqual(last_call[0][0], 1)
 
+    @patch("scripts.convert_capec_map_to_asvs_map.save_yaml_file")
+    @patch("scripts.convert_capec_map_to_asvs_map.load_json_file")
+    @patch("scripts.convert_capec_map_to_asvs_map.load_yaml_file")
+    @patch("scripts.convert_capec_map_to_asvs_map.parse_arguments")
+    @patch("sys.exit")
+    def test_main_with_asvs_json(self, mock_exit, mock_parse_args, mock_load_yaml, mock_load_json, mock_save):
+        """Test main execution with asvs_json argument"""
+        mock_parse_args.return_value = argparse.Namespace(
+            input_path=Path("input.yaml"),
+            output_path=Path(ConvertVars.OUTPUT_FILE),
+            version="3.0",
+            edition="webapp",
+            asvs_json="asvs.json",
+            debug=False,
+        )
+        mock_load_yaml.return_value = {
+            "meta": {"edition": "webapp"},
+            "suits": [
+                {
+                    "cards": [
+                        {
+                            "capec_map": {54: {"owasp_asvs": ["4.3.2"]}},
+                            "asvs_map": {"4.3.2": {"capec_codes": [54]}},
+                        }
+                    ]
+                }
+            ],
+        }
+        mock_load_json.return_value = {
+            "Requirements": [{"Shortcode": "V4.3.2", "Description": "Test description", "L": "L1"}]
+        }
+        mock_save.return_value = True
+
+        capec_map.main()
+
+        mock_load_json.assert_called_once()
+        self.assertEqual(mock_save.call_count, 2)
+        mock_exit.assert_not_called()
+
+    @patch("scripts.convert_capec_map_to_asvs_map.save_yaml_file")
+    @patch("scripts.convert_capec_map_to_asvs_map.load_json_file")
+    @patch("scripts.convert_capec_map_to_asvs_map.load_yaml_file")
+    @patch("scripts.convert_capec_map_to_asvs_map.parse_arguments")
+    @patch("sys.exit")
+    def test_main_with_asvs_json_load_fails(
+        self, mock_exit, mock_parse_args, mock_load_yaml, mock_load_json, mock_save
+    ):
+        """Test main execution when asvs_json file fails to load"""
+        mock_parse_args.return_value = argparse.Namespace(
+            input_path=Path("input.yaml"),
+            output_path=Path(ConvertVars.OUTPUT_FILE),
+            version="3.0",
+            edition="webapp",
+            asvs_json="bad_asvs.json",
+            debug=False,
+        )
+        mock_load_yaml.return_value = {"suits": [{"cards": [{"capec_map": {54: {"owasp_asvs": ["4.3.2"]}}}]}]}
+        mock_load_json.return_value = {}
+        mock_save.return_value = True
+
+        capec_map.main()
+
+        mock_load_json.assert_called_once()
+        self.assertEqual(mock_save.call_count, 2)
+        mock_exit.assert_not_called()
+
+    @patch("scripts.convert_capec_map_to_asvs_map.save_yaml_file")
+    @patch("scripts.convert_capec_map_to_asvs_map.load_yaml_file")
+    @patch("scripts.convert_capec_map_to_asvs_map.parse_arguments")
+    @patch("sys.exit")
+    def test_main_no_input_path(self, mock_exit, mock_parse_args, mock_load, mock_save):
+        """Test main when input_path is None (uses default path construction)"""
+        mock_parse_args.return_value = argparse.Namespace(
+            input_path=None,
+            output_path=Path(ConvertVars.OUTPUT_FILE),
+            version="3.0",
+            edition="webapp",
+            asvs_json=None,
+            debug=False,
+        )
+        mock_load.return_value = {"suits": [{"cards": [{"capec_map": {54: {"owasp_asvs": ["4.3.2"]}}}]}]}
+        mock_save.return_value = True
+
+        capec_map.main()
+
+        mock_load.assert_called_once()
+        self.assertEqual(mock_save.call_count, 2)
+        mock_exit.assert_not_called()
+
+    @patch("scripts.convert_capec_map_to_asvs_map.save_yaml_file")
+    @patch("scripts.convert_capec_map_to_asvs_map.load_yaml_file")
+    @patch("scripts.convert_capec_map_to_asvs_map.parse_arguments")
+    @patch("sys.exit")
+    def test_main_asvs_save_fails(self, mock_exit, mock_parse_args, mock_load, mock_save):
+        """Test main when the second save (ASVS output) fails"""
+        mock_parse_args.return_value = argparse.Namespace(
+            input_path=Path("input.yaml"),
+            output_path=Path(ConvertVars.OUTPUT_FILE),
+            version="3.0",
+            edition="webapp",
+            asvs_json=None,
+            debug=False,
+        )
+        mock_load.return_value = {"suits": [{"cards": [{"capec_map": {54: {"owasp_asvs": ["4.3.2"]}}}]}]}
+        # First save succeeds, second save fails
+        mock_save.side_effect = [True, False]
+
+        with self.assertLogs(logging.getLogger(), logging.ERROR):
+            capec_map.main()
+
+        self.assertTrue(mock_exit.called)
+        last_call = mock_exit.call_args_list[-1]
+        self.assertEqual(last_call[0][0], 1)
+
+
+class TestLoadJsonFile(unittest.TestCase):
+    """Test load_json_file function"""
+
+    @patch("builtins.open", mock_open(read_data='{"key": "value"}'))
+    def test_load_valid_json(self):
+        """Test loading a valid JSON file"""
+        result = capec_map.load_json_file(Path("test.json"))
+        self.assertEqual(result, {"key": "value"})
+
+    @patch("builtins.open", side_effect=FileNotFoundError)
+    def test_load_file_not_found(self, mock_file):
+        """Test loading non-existent file"""
+        with self.assertLogs(logging.getLogger(), logging.ERROR):
+            result = capec_map.load_json_file(Path("nonexistent.json"))
+        self.assertEqual(result, {})
+
+    @patch("builtins.open", mock_open(read_data="not valid json"))
+    def test_load_json_error(self):
+        """Test loading file with JSON parse error"""
+        with self.assertLogs(logging.getLogger(), logging.ERROR):
+            result = capec_map.load_json_file(Path("bad.json"))
+        self.assertEqual(result, {})
+
+    @patch("builtins.open", mock_open(read_data="null"))
+    def test_load_empty_json(self):
+        """Test loading JSON file that returns None"""
+        result = capec_map.load_json_file(Path("empty.json"))
+        self.assertEqual(result, {})
+
+    @patch("builtins.open", side_effect=PermissionError("Access denied"))
+    def test_load_json_generic_error(self, mock_file):
+        """Test loading JSON file with a generic exception"""
+        with self.assertLogs(logging.getLogger(), logging.ERROR):
+            result = capec_map.load_json_file(Path("noperm.json"))
+        self.assertEqual(result, {})
+
+
+class TestExtractAsvsDetails(unittest.TestCase):
+    """Test extract_asvs_details function"""
+
+    def test_extract_simple_requirement(self):
+        """Test extracting a single requirement"""
+        data = {"Requirements": [{"Shortcode": "V1.1.1", "Description": "Test req", "L": "L1"}]}
+        result = capec_map.extract_asvs_details(data)
+        self.assertEqual(result, {"1.1.1": {"description": "Test req", "level": "L1"}})
+
+    def test_extract_multiple_requirements(self):
+        """Test extracting multiple requirements"""
+        data = {
+            "Requirements": [
+                {"Shortcode": "V1.1.1", "Description": "First", "L": "L1"},
+                {"Shortcode": "V2.2.2", "Description": "Second", "L": "L2"},
+            ]
+        }
+        result = capec_map.extract_asvs_details(data)
+        self.assertEqual(len(result), 2)
+        self.assertEqual(result["1.1.1"]["description"], "First")
+        self.assertEqual(result["2.2.2"]["description"], "Second")
+
+    def test_extract_nested_structure(self):
+        """Test extracting from nested structure"""
+        data = {"chapter": {"sections": [{"items": [{"Shortcode": "V3.3.3", "Description": "Nested", "L": "L3"}]}]}}
+        result = capec_map.extract_asvs_details(data)
+        self.assertEqual(result, {"3.3.3": {"description": "Nested", "level": "L3"}})
+
+    def test_extract_shortcode_without_v_prefix(self):
+        """Test extracting requirement without V prefix"""
+        data = {"Requirements": [{"Shortcode": "4.4.4", "Description": "No V", "L": "L1"}]}
+        result = capec_map.extract_asvs_details(data)
+        self.assertEqual(result, {"4.4.4": {"description": "No V", "level": "L1"}})
+
+    def test_extract_empty_data(self):
+        """Test extracting from empty dict"""
+        result = capec_map.extract_asvs_details({})
+        self.assertEqual(result, {})
+
+    def test_extract_data_without_requirements(self):
+        """Test extracting from data without requirement fields"""
+        data = {"something": [{"other": "data"}]}
+        result = capec_map.extract_asvs_details(data)
+        self.assertEqual(result, {})
+
+    def test_extract_ignores_partial_requirements(self):
+        """Test that nodes missing required fields are skipped"""
+        data = {
+            "Requirements": [
+                {"Shortcode": "V1.1.1", "Description": "Valid", "L": "L1"},
+                {"Shortcode": "V2.2.2", "Description": "Missing L"},
+                {"Shortcode": "V3.3.3", "L": "L1"},
+            ]
+        }
+        result = capec_map.extract_asvs_details(data)
+        self.assertEqual(len(result), 1)
+        self.assertIn("1.1.1", result)
+
+
+class TestConvertToOutputFormatWithEnrichment(unittest.TestCase):
+    """Test convert_to_output_format function with enrichment_data"""
+
+    def test_convert_with_enrichment_data(self):
+        """Test converting with enrichment data"""
+        capec_map_data = {"1.1.1": {"4.3.2"}}
+        enrichment = {"1.1.1": {"description": "Test desc", "level": "L1"}}
+        result = capec_map.convert_to_output_format(capec_map_data, parameter="capec_codes", enrichment_data=enrichment)
+        self.assertIn("1.1.1", result)
+        self.assertEqual(result["1.1.1"]["description"], "Test desc")
+        self.assertEqual(result["1.1.1"]["level"], "L1")
+        self.assertEqual(result["1.1.1"]["capec_codes"], ["4.3.2"])
+
+    def test_convert_with_partial_enrichment(self):
+        """Test converting when enrichment data is missing for some keys"""
+        capec_map_data = {"1.1.1": {"4.3.2"}, "2.2.2": {"5.5.5"}}
+        enrichment = {"1.1.1": {"description": "Only first", "level": "L1"}}
+        result = capec_map.convert_to_output_format(capec_map_data, parameter="capec_codes", enrichment_data=enrichment)
+        self.assertIn("description", result["1.1.1"])
+        self.assertNotIn("description", result["2.2.2"])
+
+    def test_convert_with_meta_and_enrichment(self):
+        """Test converting with both meta and enrichment data"""
+        capec_map_data = {"1.1.1": {"4.3.2"}}
+        enrichment = {"1.1.1": {"description": "Desc", "level": "L2"}}
+        meta = {"edition": "webapp"}
+        result = capec_map.convert_to_output_format(
+            capec_map_data, parameter="capec_codes", meta=meta, enrichment_data=enrichment
+        )
+        self.assertIn("meta", result)
+        self.assertEqual(result["meta"]["edition"], "webapp")
+        self.assertEqual(result["1.1.1"]["description"], "Desc")
+
 
 if __name__ == "__main__":
     unittest.main()