Revert changes to made separately

Author: tghosth

.github/workflows/config/local-custom.txt

@@ -112,13 +112,4 @@ Alexandre
 Joly
 Vacarella
 Sebastien
-Gioria
-Hyun
-Yeong
-Wook
-Beom
-Seung
-Gyun
-Youn
-Hyun
-Jeong
+Gioria

4.0/en/0x90-Appendix-A_Glossary.md

@@ -33,7 +33,7 @@
 - **Public Key Infrastructure** (PKI) - An arrangement that binds public keys with respective identities of entities. The binding is established through a process of registration and issuance of certificates at and by a certificate authority (CA).
 - **Public Switched Telephone Network** (PSTN) - The traditional telephone network including both fixed-line telephones and mobile telephones.
 - **Relying Party** (RP) - Generally an application which is relying on a user having authenticated against a separate authentication provider. The application is relying on some sort of token or set of signed assertions provided by that authentication provider to trust that the user is who they say they are.
-- **Static application security testing** (SAST) - A set of technologies designed to analyze application source code, byte code and binaries for coding and design conditions that are indicative of security vulnerabilities. SAST solutions analyze an application from the “inside out” in a non-running state.
+- **Static application security testing** (SAST) - A set of technologies designed to analyze application source code, byte code and binaries for coding and design conditions that are indicative of security vulnerabilities. SAST solutions analyze an application from the “inside out” in a nonrunning state.
 - **Software development lifecycle** (SDLC) - The step by step process by which software is developed going from the initial requirements to deployment and maintainance.
 - **Security Architecture** – An abstraction of an application's design that identifies and describes where and how security controls are used, and also identifies and describes the location and sensitivity of both user and application data.
 - **Security Configuration** – The runtime configuration of an application that affects how security controls are used.

5.0/en/0x03-What-is-the-ASVS.md

@@ -170,11 +170,11 @@ The ASVS can be used to assess the security of an application and this is explor
 
 ### As Detailed Security Architecture Guidance
 
-One of the more common uses for the Application Security Verification Standard is as a resource for security architects. There are limited resources available for how to build a secure application architecture, especially with modern applications. ASVS can be used to fill in those gaps by allowing security architects to choose better controls for common problems, such as data protection patterns and input validation strategies. The architecture and documentation requirements will be particularly useful for this.
+One of the more common uses for the Application Security Verification Standard is as a resource for security architects. There are limited resources available for how to build a secure application archiecture, especially with modern applications. ASVS can be used to fill in those gaps by allowing security architects to choose better controls for common problems, such as data protection patterns and input validation strategies. The architecture and documentation requirements will be particularly useful for this.
 
 ### As a Specialized Secure Coding Reference
 
-The ASVS can be used as a basis for preparing a secure coding reference during application development, helping developers to make sure that they keep security in mind when they build software. Whilst the ASVS can be the base, organizations should prepare their own specific guidance which is clear and unified and ideally be prepared based on guidance from security engineers or security architects. As an extension to this, organizations are encouraged wherever possible to prepare approved security mechanisms and libraries that can be referenced in the guidance and used by developers.
+The ASVS can be used as a basis for preparing a secure coding reference during application development, helping developers to make sure that they keep security in mind when they build software. Whilst the ASVS can be the base, prganizations should prepare their own specific guidance which is clear and unified and ideally be prepared based on guidance from security engineers or security architects. As an extension to this, organizations are encouraged wherever possible to prepare approved security mechanisms and libraries that can be referenced in the guidance and used by developers.
 
 ### As a Guide for Automated Unit and Integration Tests
 

5.0/en/0x04-Assessment_and_Certification.md

@@ -8,11 +8,11 @@ Organizations may offer assurance services, provided they do not claim official
 
 ## How to Verify ASVS Compliance
 
-The ASVS is deliberately not prescriptive about exactly how to verify compliance at the level of a testing guide. However, it is important to highlight some key points.
+The ASVS is deliberately not presciptive about exactly how to verify compliance at the level of a testing guide. However, it is important to highlight some key points.
 
 ### Verification reporting
 
-Traditional penetration testing reports issues “by exception,” only listing failures. However, an ASVS certification report should include scope, a summary of all requirements checked, the requirements where exceptions were noted, and guidance on resolving issues. Some requirements may be non-applicable (e.g., session management in stateless APIs), and this must be noted in the report.
+Traditional penetration testing reports issues “by exception,” only listing failures. However, an ASVS certification report should include scope, a summary of all requirements checked, the requirements where execptions were noted, and guidance on resolving issues. Some requirements may be non-applicable (e.g., session management in stateless APIs), and this must be noted in the report.
 
 ### Scope of Verification
 
@@ -32,7 +32,7 @@ The use of automation to verify ASVS requirements is a topic that is constantly
 
 When automated security testing tools such as Dynamic and Static Application Security Testing tools (DAST and SAST) are correctly implemented in the build pipeline, they may be able to identify some security issues that should never exist. However, without careful configuration and tuning they will not provide the required coverage and the level of noise will prevent real security issues from being identified and mitigated.
 
-Whilst this may provide coverage of some of the more basic and straightforward technical requirements such as those relating to output encoding or sanitization, it is critical to note that these tools will be unable entirely to verify many of the more complicated ASVS requirements or those that relate to business logic and access control.
+Whilst this may provide coverage of some of the more basic and straightforward technical requirements such as those relating to output encoding or sanitiation, it is critical to note that these tools will be unable entirely to verify many of the more complicated ASVS requirements or those that relate to business logic and access control.
 
 For less straightforward requirements, it is likely that automation can still be utilized but application specific verifications will need to be written to achieve this. These may be similar to unit and integration tests that the organization may already be using. It may therefore be possible to use this existing test automation infrastructure to write these ASVS specific tests. Whilst doing this will require short term investment, the long term benefits being able to continually verify these ASVS requirements will be significant.
 

5.0/en/0x21-V12-Secure-Communication.md

@@ -8,7 +8,7 @@ The general concepts promoted by this chapter include:
 
 * Ensuring that communications are encrypted externally, and ideally internally as well.
 * Configuring encryption mechanisms using the latest guidance, including preferred algorithms and ciphers.
-* Using signed certificates to ensure that communications are not being intercepted by unauthorized parties.
+* Ensuring that communications are not being intercepted by unauthorized parties through the use of signed certificates.
 
 In addition to outlining general principles and best practices, the ASVS also provides more in-depth technical information about cryptographic strength in Appendix C - Cryptography Standards.
 

5.0/en/0x90-Appendix-A_Glossary.md

@@ -57,7 +57,7 @@
 * **Self-Contained Token** – A token that encapsulates one or more attributes that do not rely on server-side state or other external storage. These tokens ensure the authenticity and integrity of their contained attributes, enabling secure, "stateless" information exchange across systems. Self-contained tokens are generally secured using cryptographic techniques, such as digital signatures or message authentication codes (MACs), to ensure the authenticity, integrity, and in some cases the confidentiality of its data. Common examples include SAML Assertions and JWTs.
 * **Server-side Request Forgery** (SSRF) – An attack that abuses functionality on the server to read or update internal resources. The attacker supplies or modifies a URL, which the code running on the server will read or submit data to.
 * **Session Description Protocol** (SDP) – A message format for setting up multimedia session (used for example in WebRTC). Defined in RFC 4566.
-* **Session Identifier** or **Session ID** – A key which identifies a stateful session stored at the back end. Will be transferred to and from the client either as or inside a "Reference Token".
+* **Session Identifier** or **Session ID** – A key which identifies a stateful session stored at the back end. Will be transfered to and from the client either as or inside a "Reference Token".
 * **Session Token** – A "catch-all" phrase used in this standard to refer to the token or value used in either stateless session mechanisms (which use a self-contained token) or stateful session mechanisms (which use a reference token).
 * **Session Traversal Utilities for NAT** (STUN) – A protocol used to assist NAT traversal in order to establish peer-to-peer communications. Defined in RFC 3489.
 * **Single-factor authenticator** – A mechanism to check that a user is authenticated. It should either be something you know (memorized secrets, passwords, passphrases, PINs), something you are (biometrics, fingerprint, face scans), or something you have (OTP tokens, a cryptographic device such as a smart card).
@@ -68,7 +68,7 @@
 * **SQL Injection** (SQLi) – A code injection technique used to attack data-driven applications, in which malicious SQL statements are inserted into an entry point.
 * **Stateful Session Mechanism** – In a stateful session mechanism, the application retains session state at the backend which typically corresponds to a session token, generated using a cryptographically secure pseudo-random number generator (CSPRNG), which is issued to the end user.
 * **Stateless Session Mechanism** – A stateless session mechanism will use a self-contained token which is passed to clients, and contains session information that is not necessarily stored within the service which then receives and validates the token. In reality, a service will need to have access to some session information (such as a JWT revocation list) in order to be able to enforce required security controls.
-* **Static application security testing** (SAST) – A set of technologies designed to analyze application source code, byte code and binaries for coding and design conditions that are indicative of security vulnerabilities. SAST solutions analyze an application from the “inside out” in a non-running state.
+* **Static application security testing** (SAST) – A set of technologies designed to analyze application source code, byte code and binaries for coding and design conditions that are indicative of security vulnerabilities. SAST solutions analyze an application from the “inside out” in a nonrunning state.
 * **Threat Modeling** – A technique consisting of developing increasingly refined security architectures to identify threat agents, security zones, security controls, and important technical and business assets.
 * **Time-of-check to time-of-use** (TOCTOU) – A situation where an application checks the state of a resource before using that resource, but the resource's state can be changed between the check and the use. This can invalidate the results of the check and cause a situation where the application performs invalid actions due to this state mismatch.
 * **Time based One-time Passwords** (TOTPs) - A method of generating an OTP where the current time acts as part of the algorithm to generate the password.

5.0/en/0x92-Appendix-C_Cryptography.md

@@ -5,7 +5,7 @@ The "Cryptography" chapter goes beyond simply defining best practices. It aims t
 This appendix defines the level of approval for different cryptographic mechanisms:
 
 * Approved (A) mechanisms can be used in applications.
-* Legacy mechanisms (L) should not be used in applications but might still be used for compatibility with existing legacy applications or code only. While the usage of such these mechanisms is currently not considered to be a vulnerability in itself, they should be replaced by more secure and future-proof mechanisms as soon as possible.
+* Legacy mechanisms (L) should not be used in applications but might still be used for compatibility with existing legacy applications or code onyly. While the usage of such these mechanisms is currently not considered to be a vulnerability in itself, they should be replaced by more secure and future-proof mechanisms as soon as possible.
 * Disallowed mechanisms (D) must not be used because they are currently considered broken or do not provide sufficient security.
 
 This list may be overridden in the context of a given application for various reasons including:
@@ -27,7 +27,7 @@ It is important to ensure that all cryptographic assets, such as algorithms, key
 
 The relative security strengths for various cryptographic systems are in this table (from [NIST SP 800-57 Part 1](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final), p.71):
 
-| Security Strength | Symmetric Key Algorithms | Finite Field | Integer Factorization | Elliptic Curve |
+| Security Strength | Symmetric Key Algorithms | Finite Field | Integer Factorisation | Elliptic Curve |
 |--|--|--|--|--|
 | <= 80 | 2TDEA | L = 1024 <br> N = 160 | k = 1024 | f = 160-223 |
 | 112 | 3TDEA   | L = 2048 <br> N = 224 | k = 2048 | f = 224-255 |
@@ -38,7 +38,7 @@ The relative security strengths for various cryptographic systems are in this ta
 Example of applications:
 
 * Finite Field Cryptography: DSA, FFDH, MQV
-* Integer Factorization Cryptography: RSA
+* Integer Factorisation Cryptography: RSA
 * Elliptic Curve Cryptography: ECDSA, EdDSA, ECDH, MQV
 
 Note: that this section assumes that no quantum computer exists; if such a computer would exist, the estimates for the last 3 columns would be no longer valid.
@@ -153,7 +153,7 @@ The following table lists hash functions approved in general cryptographic use c
 
 * Approved hash functions provide strong collision resistance and are suitable for high-security applications.
 * Some of these algorithms offer strong resistance to attacks when used with proper cryptographic key management, and so are additionally approved for HMAC, KDF, and RBG functions.
-* Hash function with less than 254 bit of output have insufficient collision resistance and must not be used for digital signature or other applications requiring collision resistance. For other usages, they might be used for compatibility and verification ONLY with legacy systems but must not be used in new designs.
+* Hash function with less than 254 bit of output have insufficient collision resistancea and must not be used for digital signature or other applications requiring collision resistance. For other usages, they might be used for compatibility and verification ONLY with legacy systems but must not be used in new designs.
 
 | Hash function | Reference | Status | Restrictions |
 | ------ | ----------- |:-:| ---------- |
@@ -306,6 +306,6 @@ Signature schemes MUST use approved key sizes and parameters per [NIST SP 800-57
 
 ## Post-Quantum Encryption Standards
 
-Post-quantum cryptography (PQC) implementations should follow [FIPS-203](https://csrc.nist.gov/pubs/fips/203/ipd), [FIPS-204](https://csrc.nist.gov/pubs/fips/204/ipd), and [FIPS-205](https://csrc.nist.gov/pubs/fips/205/ipd). At this time, there are not many hardened code examples or reference implementations available for these standards. For further details, see the [NIST announcement of the first three finalized post-quantum encryption standards (August 2024)](https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards).
+PQC implementations must be in line with [FIPS-203](https://csrc.nist.gov/pubs/fips/203/ipd)/[204](https://csrc.nist.gov/pubs/fips/204/ipd)/[205](https://csrc.nist.gov/pubs/fips/205/ipd) as there is minimal hardened code nor implementation reference yet. https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards
 
 The proposed [mlkem768x25519](https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/03/) post-quantum hybrid TLS key agreement method is supported by major browsers such as [Firefox release 132](https://www.mozilla.org/en-US/firefox/132.0/releasenotes/) and [Chrome release 131](https://security.googleblog.com/2024/09/a-new-path-for-kyber-on-web.html). It may be used in cryptographic testing environments or when available within industry- or government-approved libraries.

5.0/en/0x94-Appendix-E_Contributors.md

@@ -20,7 +20,7 @@ If you are aware of any mistakes or would like your name to appear differently,
 | Roel Storms ([roelstorms](https://github.com/roelstorms)) | Jeroen Willemsen ([commjoen](https://github.com/commjoen)) | [anonymous-31](https://github.com/anonymous-31) | Kamran Saifullah ([deFr0ggy](https://github.com/deFr0ggy))  |
 | Steve Springett ([stevespringett](https://github.com/stevespringett)) | Spyros ([northdpole](https://github.com/northdpole)) | Hans Herrera ([hansphp](https://github.com/hansphp)) | [Marx314](https://github.com/Marx314)  |
 | [CarlosAllendes](https://github.com/CarlosAllendes) | Yonah Russ ([yruss972](https://github.com/yruss972)) | Sander Maijers ([sanmai-NL](https://github.com/sanmai-NL)) | Luboš Bretschneider  ([bretik](https://github.com/bretik))  |
-| Eva Sarafianou ([esarafianou](https://github.com/esarafianou)) | Ata Seren [ataseren](https://github.com/ataseren) | Steve Thomas ([Sc00bz](https://github.com/Sc00bz)) | Dominique RIGHETTO ([righettod](https://github.com/righettod))  |
+| Eva Sarafianou ([esarafianou](https://github.com/esarafianou)) | [ataseren](https://github.com/ataseren) | Steve Thomas ([Sc00bz](https://github.com/Sc00bz)) | Dominique RIGHETTO ([righettod](https://github.com/righettod))  |
 | Steven van der Baan ([svdb-ncc](https://github.com/svdb-ncc)) | Michael Vacarella ([Aif4thah](https://github.com/Aif4thah)) | Tonimir Kisasondi ([tkisason](https://github.com/tkisason)) | Stefan Streichsbier ([streichsbaer](https://github.com/streichsbaer))  |
 | [hi-unc1e](https://github.com/hi-unc1e) | sb3k ([starbuck3000](https://github.com/starbuck3000)) | [mario-platt](https://github.com/mario-platt) | Devdatta Akhawe ([devd](https://github.com/devd))  |
 | Michael Gissing ([scolytus](https://github.com/scolytus)) | Jet Anderson ([thatsjet](https://github.com/thatsjet)) | Dave Wichers ([davewichers](https://github.com/davewichers)) | Jonny Schnittger ([JonnySchnittger](https://github.com/JonnySchnittger))  |

5.0/languages.txt

@@ -1 +1 @@
-en tr ru fr ko
+en tr ru fr

5.0/mappings/README.md

@@ -2,7 +2,7 @@
 
 Versions:
 
-* v4.0.3 - latest v4 release
+* v4.0.3 - latest v4 ralease
 * v5.0.be - "bleeding edge" version for v5.0 development, where all v4.0 structure and numbers were kept directly or as placeholders
 * v5.0 - v5.0 after re-structuring and re-numbering everything