resolve #715

4.0/en/0x03-Using-ASVS.md

@@ -60,3 +60,20 @@ An application at ASVS Level 3 requires more in depth analysis of architecture,
 Different threats have different motivations. Some industries have unique information and technology assets and domain specific regulatory compliance requirements.
 
 Organizations are strongly encouraged to look deeply at their unique risk characteristics based on the nature of their business, and based upon that risk and business requirements determine the appropriate ASVS level.
+
+## How To Reference ASVS Requirements
+
+Each requirement has an identifier in the format `<chapter>.<section>.<requirement>` where each element is a number, for example: `1.11.3`.
+- The `<chapter>` value corresponds to the chapter from which the requirement comes, for example: all `1.#.#` requirements are from the `Architecture` chapter.
+- The `<section>` value corresponds to the section within that chapter where the requirement appears, for example: all `1.11.#` requirements are in the `Business Logic Architectural Requirements` section of the `Architecture` chapter.
+- The `<requirement>` value identifies the specific requirement within the chapter and section, for example: `1.11.3` which as of version 4.0.1 of this standard is:
+
+> Verify that all high-value business logic flows, including authentication, session management and access control are thread safe and resistant to time-of-check and time-of-use race conditions.
+
+The identifiers may change between versions of the standard therefore it is preferable that other documents, reports, or tools use the format: `v<version>-<chapter>.<section>.<requirement>`, where: 'version' is the ASVS version tag. For example: `v4.0.1-1.11.3` would be understood to mean specifically the 3rd requirement in the 'Business Logic Architectural Requirements' section of the 'Architecture' chapter from version 4.0.1. (This could be summarized as `v<version>-<requirement_identifier>`.)
+
+Note: The `v` preceding the version portion is to be lower case.
+
+If identifiers are used without including the `v<version>` element then they should be assumed to refer to the latest Application Security Verification Standard content. Obviously as the standard grows and changes this becomes problematic, which is why writers or developers should include the version element.
+
+ASVS requirement lists are made available in CSV, JSON, and other formats which may be useful for reference or programmatic use.

README.md

@@ -21,18 +21,18 @@ The requirements were developed with the following objectives in mind:
 * Assist organizations to benchmark application security tools by the percentage of coverage of the ASVS for dynamic, interactive, and static analysis tools
 * Minimize overlapping and competing requirements from other standards, by either aligning strongly with them (NIST 800-63), or being strict supersets (OWASP Top 10 2017, PCI DSS 3.2.1), which will help reduce compliance costs, effort, and time wasted in accepting unnecessary differences as risks.
 
-### How To Reference ASVS Requirements
+## How To Reference ASVS Requirements
 
-Each requirement has an identifier in the format `V<chapter>.<segment>.<requirement>` where each element is a number, for example: `V1.11.3`.
-- The `<chapter>` value corresponds to the chapter from which the requirement comes, for example: all `V1.#.#` requirements are from the `Architecture` chapter.
-- The `<segment>` value corresponds to the segment within that chapter where the requirement appears, for example: all `V1.11.#` requirements are in the `Business Logic Architectural Requirements` segment of the `Architecture` chapter.
-- The `<requirement>` value identifies the specific requirement within the chapter and segment, for example: `V1.11.3` which as of version 4.0.1 of this standard is:
+Each requirement has an identifier in the format `<chapter>.<section>.<requirement>` where each element is a number, for example: `1.11.3`.
+- The `<chapter>` value corresponds to the chapter from which the requirement comes, for example: all `1.#.#` requirements are from the `Architecture` chapter.
+- The `<section>` value corresponds to the section within that chapter where the requirement appears, for example: all `1.11.#` requirements are in the `Business Logic Architectural Requirements` section of the `Architecture` chapter.
+- The `<requirement>` value identifies the specific requirement within the chapter and section, for example: `1.11.3` which as of version 4.0.1 of this standard is:
 
 > Verify that all high-value business logic flows, including authentication, session management and access control are thread safe and resistant to time-of-check and time-of-use race conditions.
 
-The identifiers may change between versions of the standard therefore it is preferable that other documents, reports, or tools use the format: `v<version>-V<chapter>.<segment>.<requirement>`, where: 'version' is the ASVS version tag. For example: `v4.0.1-V1.11.3` would be understood to mean specifically the 3rd requirement in the 'Business Logic Architectural Requirements' segment of the 'Architecture' chapter from version 4.0.1. (This could be summarized as `v<version>-V<requirement_identifier>`.)
+The identifiers may change between versions of the standard therefore it is preferable that other documents, reports, or tools use the format: `v<version>-<chapter>.<section>.<requirement>`, where: 'version' is the ASVS version tag. For example: `v4.0.1-1.11.3` would be understood to mean specifically the 3rd requirement in the 'Business Logic Architectural Requirements' section of the 'Architecture' chapter from version 4.0.1. (This could be summarized as `v<version>-<requirement_identifier>`.)
 
-Note: The `v` preceding the version portion is to be lower case, while the `V` leading the requirement identifier is a capital.
+Note: The `v` preceding the version portion is to be lower case.
 
 If identifiers are used without including the `v<version>` element then they should be assumed to refer to the latest Application Security Verification Standard content. Obviously as the standard grows and changes this becomes problematic, which is why writers or developers should include the version element.