Document Comparison
PCI-Secure-Software-Standard-v1_2.pdf
→
PCI-Secure-Software-Standard-v1_2_1.pdf
57% similar
109 → 110
Pages
39040 → 39234
Words
69
Content Changes
Content Changes
69 content changes. 110 administrative changes (dates, page numbers) hidden.
Added
p. 7
PCI Software Security Framework
• Technical FAQs for Secure Software Standard (“Secure Software Technical FAQs”) Technical Frequently Asked Questions (FAQs) provide a mechanism to address questions related to the interpretation and application of the associated PCI Standard and Program. Technical FAQs are considered ‘normative,’ and they must be fully considered within the scope of assessment activity for the associated Standard.
• Technical FAQs for Secure Software Standard (“Secure Software Technical FAQs”) Technical Frequently Asked Questions (FAQs) provide a mechanism to address questions related to the interpretation and application of the associated PCI Standard and Program. Technical FAQs are considered ‘normative,’ and they must be fully considered within the scope of assessment activity for the associated Standard.
Added
p. 10
− All payment functions.
− Inputs and outputs.
− Handling of error conditions.
− Interfaces and connections to other files, systems, and/or software.
− Inputs and outputs.
− Handling of error conditions.
− Interfaces and connections to other files, systems, and/or software.
Added
p. 35
• Something you are, such as a biometric.
Modified
p. 1
Payment Card Industry (PCI) Software Security Framework Secure Software Requirements and Assessment Procedures Version 1.2
Payment Card Industry (PCI) Software Security Framework Secure Software Requirements and Assessment Procedures Version 1.2.1
Modified
p. 9 → 10
− Security mechanisms, controls, and countermeasures, such as authentication, authorization, validation, parameterization, segmentation, logging, and so on.
Modified
p. 9 → 10
− The configuration options available that can impact the security of payment software, including those of the execution environment and related system components.
− All configuration options available that can impact the security of payment software, including those of the execution environment and related system components.
Modified
p. 9 → 10
− Cannot be controlled by the payment software vendor, provider, or developer after the software is installed in a production environment; or − Are the responsibility of the implementing entity and not the software vendor, provider, or developer.
− Cannot be controlled by the payment software vendor, provider, or developer after the software is installed in a production environment.
Modified
p. 11 → 12
Requirement Frequency and Rigor Given the nature of PCI SSC’s objective-based approach to security requirements, many security requirements do not specify the level of rigor or frequency for periodic or recurring activities, such as the maximum period in which a security update must be provided to fix known vulnerabilities. In such cases, the software vendor may define the level of rigor or frequency appropriate for its business needs. The level of rigor or frequency chosen, however, must be supported by …
Requirement Frequency and Rigor Given the nature of PCI SSC’s objective-based approach to security requirements, many security requirements do not specify the level of rigor or frequency for periodic or recurring activities, such as the maximum period in which a security update must be provided to fix known vulnerabilities. In such cases, the software vendor may define the level of rigor or frequency appropriate for its business needs. The level of rigor or frequency chosen, however, must be supported by …
Modified
p. 13 → 14
Reliance on Third-Party Testing All test requirements are expected to be performed by the assessor. An assessor may choose, however, to rely on testing performed by a third- party to satisfy a test requirement, including the software provider. The assessor retains full responsibility for the testing activities and results regardless of whether the testing is performed by the assessor, the software provider, or a third-party. Where third-party testing is relied upon by the assessor, the assessor must document and justify …
Reliance on Third-Party Testing All test requirements are expected to be performed by the assessor. An assessor may choose, however, to rely on testing performed by a third- party to satisfy a test requirement, including the software provider. The assessor retains full responsibility for the testing activities and results, regardless of whether the testing is performed by the assessor, by the software provider, or by a third-party. Where third-party testing is relied upon by the assessor, the assessor must document …
Modified
p. 16 → 17
1.1.g The assessor shall examine evidence and test the software to identify the accounts and authentication credentials supported by the software (including both default and user created accounts) and to confirm that these accounts and credentials are supported by the evidence examined in Test Requirements 1.1.a through 1.1.c.
1.1.g The assessor shall examine evidence and test the software to identify the accounts and authentication credentials supported by the software (including both default and user- created accounts) and to confirm that these accounts and credentials are supported by the evidence examined in Test Requirements 1.1.a through 1.1.c.
Modified
p. 19 → 20
• The risks posed by the use of known vulnerable protocols, functions, or ports is documented.
• The risks posed by the use of known vulnerable protocols, functions, or ports are documented.
Modified
p. 24 → 25
3.1.c The assessor shall examine evidence and test the software to determine whether the software facilitates the storage of persistent sensitive data for the purposes of debugging, error finding or testing of systems, and to confirm that such data is protected during storage in accordance with Control Objective 6.1. Any function that allows for storage of sensitive data for these purposes must be explicitly enabled through an interface that requires interaction and authorization by the user and retains the data …
3.1.c The assessor shall examine evidence and test the software to determine whether the software facilitates the storage of persistent sensitive data for the purposes of debugging, error finding or testing of systems, and to confirm that such data is protected during storage in accordance with Control Objective 6.1. Any function that allows for the storage of sensitive data for these purposes must be explicitly enabled through an interface that requires interaction and authorization by the user and retains the …
Modified
p. 25 → 26
3.2.c The assessor shall examine evidence and test the software to determine whether the software facilitates the storage of transient sensitive data for the purposes of debugging, error finding or testing of systems, and to confirm that such data is protected in accordance with Control Objective 6.1. Any function that allows for the storage of transient sensitive data for these purposes must be explicitly enabled through an interface that requires interaction and authorization by the user. Closure of the software …
3.2.c The assessor shall examine evidence and test the software to determine whether the software facilitates the storage of transient sensitive data for the purposes of debugging, error finding or testing of systems, and to confirm that such data is protected in accordance with Control Objective 6.1. Any function that allows for the storage of transient sensitive data for these purposes must be explicitly enabled through an interface that requires interaction and authorization by the user. Closure of the software …
Modified
p. 26 → 27
3.3.a The assessor shall examine the evidence to identify the methods implemented to protect sensitive data during storage and transmission.
3.3.a The assessor shall examine the evidence to identify the methods implemented to protect sensitive data during storage.
Modified
p. 26 → 27
3.3.c Where protection methods use cryptography, the assessor shall examine vendor evidence and test the software to confirm that the cryptographic implementation complies with Control Objective 7 of this standard.
3.3.c Where protection methods use cryptography, the assessor shall examine evidence and test the software to confirm that the cryptographic implementation complies with Control Objective 7 of this standard.
Modified
p. 27 → 28
3.4.a The assessor shall examine evidence to identify the methods implemented to render non-transient sensitive data irretrievable and to confirm that sensitive data is rendered unrecoverable after the process is complete.
3.4.a The assessor shall examine evidence to identify the methods implemented to render persistent sensitive data irretrievable and to confirm that sensitive data is rendered unrecoverable after the process is complete.
Modified
p. 27 → 28
3.4.b The assessor shall examine evidence and test the software to identify any platform or implementation level issues that complicate the secure deletion of non-transient sensitive data and to confirm that any non-transient sensitive data is securely deleted using a method that ensures that the data is rendered unrecoverable. Methods may include (but are not necessarily limited to) overwriting the data, deletion of cryptographic keys (of sufficient strength) that have been used to encrypt the data, or platform specific functions …
3.4.b The assessor shall examine evidence and test the software to identify any platform or implementation level issues that complicate the secure deletion of non-transient sensitive data and to confirm that any non-transient sensitive data is securely deleted using a method that ensures that the data is rendered unrecoverable. Methods may include (but are not necessarily limited to) overwriting the data, deletion of cryptographic keys (of sufficient strength) that have been used to encrypt the data, or platform-specific functions that …
Modified
p. 31 → 32
When the software relies on execution environment security controls, the software vendor should review and reference the implementation documentation for the platform (such as Security Policies for PCI- approved POI devices or FIPS140-2 or 140-3 approved cryptographic modules) and should confirm that the software and its associated documentation correctly and completely accommodate the guidance in these documents.
Modified
p. 32 → 33
• All critical assets managed and all sensitive resources used by the system are documented.
• All critical assets managed, and all sensitive resources used by the system are documented.
Modified
p. 34 → 35
• Something you know, such as a password or passphrase
• Something you know, such as a password or passphrase.
Modified
p. 34 → 35
• Something you have, such as a token device or smart card
• Something you have, such as a token device or smart card.
Modified
p. 34 → 35
To ensure that the implemented authentication mechanisms are adequate to address the risk of unauthorized access to sensitive data or sensitive resources, or misuse of a sensitive function, the vendor should analyze threats and identify the required level of authentication for all types of users and roles.
Modified
p. 36 → 37
5.3.b The assessor shall examine evidence to confirm that the implemented authentication methods are robust, and that the robustness of the authentication methods was evaluated using industry-accepted methods.
5.3.b The assessor shall examine evidence to confirm that the implemented authentication methods are robust and the robustness of the authentication methods was evaluated using industry-accepted methods.
Modified
p. 39 → 40
6.1.f Where protection methods rely on security properties of third-party software, the assessor shall examine evidence and test the software to confirm that there are no unmitigated vulnerabilities or issues with the software providing the security properties.
6.1.f Where protection methods rely on the security properties of third-party software, the assessor shall examine evidence and test the software to confirm that there are no unmitigated vulnerabilities or issues with the software providing the security properties.
Modified
p. 41 → 42
• Only documented cryptographic algorithms and modes of operation are used in the software.
• Only documented cryptographic algorithms and modes of operation are used in the software, and
Modified
p. 43 → 44
• All keys have a defined crypto-period aligned with industry standards, and methods are implemented to retire and/or update each key at the end of the defined crypto-period.
• All keys have a defined cryptoperiod aligned with industry standards, and methods are implemented to retire and/or update each key at the end of the defined cryptoperiod.
Modified
p. 43 → 44
• Generation of strong cryptographic keys
• The generation of strong cryptographic keys.
Modified
p. 43 → 44
• Secure cryptographic key distribution
• Secure cryptographic key distribution.
Modified
p. 43 → 44
• Secure cryptographic key storage
• Secure cryptographic key storage.
Modified
p. 43 → 44
• Cryptographic key changes for keys that have reached the end of their cryptoperiod
• Cryptographic key changes for keys that have reached the end of their cryptoperiod.
Modified
p. 43 → 44
• Retirement or replacement of keys
• The retirement or replacement of keys.
Modified
p. 43 → 44
• Enforcement of split knowledge and dual control (when the software supports manual clear-text cryptographic key-management operations)
• The enforcement of split knowledge and dual control (when the software supports manual clear-text cryptographic key-management operations).
Modified
p. 43 → 44
• Prevention of unauthorized substitution of cryptographic keys
• The prevention of unauthorized substitution of cryptographic keys.
Modified
p. 43 → 44
• Provision of a mechanism to render irretrievable any cryptographic key material or cryptogram stored by the payment software This requirement applies to keys used to encrypt sensitive data and any respective key-encrypting keys.
• The implementation of a mechanism to render irretrievable any cryptographic key material or cryptogram stored by the payment software.
Modified
p. 49 → 50
In order to identify anomalous behavior and to enable forensic investigation upon suspicion of potential software or data compromise, the software must provide for the retention of detailed activity records either through native means (within the software itself) or support integration with other solutions such as centralized log servers, cloud-based logging solutions, or a back-end monitoring solutions.
In order to identify anomalous behavior and to enable forensic investigation upon suspicion of potential software or data compromise, the software must provide for the retention of detailed activity records either through native means (within the software itself) or support integration with other solutions such as centralized log servers, cloud-based logging solutions, or back-end monitoring solutions.
Modified
p. 51 → 52
• The software applies, where possible, suitable file privileges to assist with maintaining the integrity of the tracking dataset (such as applying an append only access control to a dataset once created). Where the software does not apply such controls, the assessor shall confirm reasonable justification exists describing why this is the case, why the behavior is sufficient, and what additional mitigations are applied to maintain the integrity of the tracking data.
• The software applies, where possible, suitable file privileges to assist with maintaining the integrity of the tracking dataset (such as applying an append-only access control to a dataset once created). Where the software does not apply such controls, the assessor shall confirm reasonable justification exists describing why this is the case, why the behavior is sufficient, and what additional mitigations are applied to maintain the integrity of the tracking data.
Modified
p. 55 → 56
Software should be developed and tested in a manner that minimizes the existence of any vulnerabilities and detects those that emerge over time, such that the vulnerabilities may be addressed before the software is released or updated. Techniques to avoid the introduction of vulnerabilities during development include the use of security coding practices, testing code during each phase of the development lifecycle using automated tools such as static/dynamic analysis tools and interactive security testing tools, and standardizing the use of …
Software should be developed and tested in a manner that minimizes the existence of any vulnerabilities and detects those that emerge over time, such that the vulnerabilities may be addressed before the software is released or updated. Techniques to avoid the introduction of vulnerabilities during development include the use of security coding practices, testing code during each phase of the development lifecycle using automated tools (such as static/dynamic analysis tools and interactive security testing tools), and the use of known …
Modified
p. 56 → 57
11.2.a The assessor shall examine evidence to confirm that the method(s) by which the vendor releases software updates maintains the integrity of the software code during transmission and installation.
11.2.a The assessor shall examine evidence to confirm that the method(s) by which the vendor releases software updates maintain the integrity of the software code during transmission and installation.
Modified
p. 62 → 63
• Non-volatile memory, including non-volatile cache
• Non-volatile memory (including non-volatile cache)
Modified
p. 75 → 76
Many payment terminals enforce logical separation between software applications. In the context of this module, software applications are logical entities that do not meet the PTS definition of “firmware”.
Many payment terminals enforce logical separation between software applications. In the context of this module, software applications are logical entities that do not meet the PTS definition of “firmware.” Logical application segmentation controls are intended to prevent one application on the payment terminal from interfering or tampering with other applications. However, these logical segregation controls are not intended to prevent applications from sharing data. They are mainly intended to prevent applications from modifying the structure or function of other applications …
Modified
p. 78 → 79
Any terminal software functions that accept externally supplied data (directly or indirectly) is a potential attack vector, particularly where the data is processed by an interpreter.
Any terminal software functions that accept externally supplied data (directly or indirectly) is a potential attack vector, particularly when the data is processed by an interpreter.
Removed
p. 83
• The unintended storage, transmission, or output of any clear-text account data.
Modified
p. 86 → 87
C.1: Web Software Components & Services C.2: Web Software Access Controls C.3: Web Software Attack Mitigation C.4: Web Software Communications Purpose and Scope This section (hereinafter referred to as the “Web Software Module” or “this module”) defines security requirements and assessment procedures for payment software and applications that use Internet technologies, protocols, and languages for the purposes of initiating or supporting electronic payment transactions. This includes both traditional (monolithic) and cloud-native payment applications, APIs, web services, microservices, serverless functions, gRPC, …
C.1: Web Software Components & Services C.2: Web Software Access Controls C.3: Web Software Attack Mitigation C.4: Web Software Communications Purpose and Scope This section (hereinafter referred to as the “Web Software Module” or “this module”) defines security requirements and assessment procedures for payment software and applications that use Internet technologies, protocols, and languages for the purposes of initiating or supporting electronic payment transactions. This includes both traditional (monolithic) and cloud-native payment applications, APIs, web services, microservices, serverless functions, GRPC, …
Modified
p. 87 → 88
A Software Bill of Materials or “SBOM” serves this purpose by documenting information about the software components and versions used to create a software product, their suppliers, and any third-party code that may also be embedded in these components. NIST refers to this information as “provenance data” and there are numerous standards and frameworks available, such as CycloneDX, SPDX and SWID, that describe how this information should be structured. For more information, refer to those standards and frameworks.
A Software Bill of Materials or “SBOM” services this purpose by documenting information about the software components and versions used to create a software product, their suppliers, and any third-party code that may also be embedded in these components. NIST refers to this information as “provenance data” and there are numerous standards and frameworks available, such as CycloneDX, SPDX and SWID, that describe how this information should be structured. For more information, refer to those standards and frameworks.
Modified
p. 88 → 89
If circumstances exist that complicate or prevent the identification of secondary transitive component relationships and dependencies, then such circumstances should be documented and reasonable justification should be maintained to explain why these dependencies are not accurately reflected in the SBOM. Examples of such circumstances may include third-party APIs, where transparency into nested third-party components called by or embedded into those APIs is not provided by the API provider.
If circumstances exist that complicate or prevent the identification of secondary transitive component relationships and dependencies, then such circumstances should be documented, and reasonable justification should be maintained to explain why these dependencies are not accurately reflected in the SBOM. Examples of such circumstances may include third-party APIs, where transparency into nested third-party components called by or embedded into those APIs is not provided by the API provider.
Modified
p. 92 → 93
C.2.1 User access to sensitive functions and sensitive resources exposed through Internet accessible interfaces is authenticated.
C.2.1 User access to sensitive functions and sensitive resources exposed through Internet-accessible interfaces is authenticated.
Modified
p. 92 → 93
C.2.1 Using information obtained in Test Requirements 1.2.a and 2.1.a in the Core Requirements, the assessor shall examine evidence to identify all sensitive functions and sensitive resources exposed through Internet accessible interfaces.
C.2.1 Using information obtained in Test Requirements 1.2.a and 2.1.a in the Core Requirements, the assessor shall examine evidence to identify all sensitive functions and sensitive resources exposed through Internet-accessible interfaces.
Modified
p. 93 → 94
C.2.1.1.c Where sessions are used to authenticate user access to sensitive functions and sensitive resources, the assessor shall examine evidence to confirm that the sessions are handled in accordance with industry recognized standards and best practices for secure session management.
C.2.1.1.c Where sessions are used to authenticate user access to sensitive functions and sensitive resources, the assessor shall examine evidence to confirm that the sessions are handled in accordance with industry-recognized standards and best practices for secure session management.
Modified
p. 93 → 94
C.2.1.1.d Where tokens (for example, access tokens and refresh tokens) are used to authenticate user access to sensitive functions and sensitive resources, the assessor shall examine evidence to confirm that the tokens are handled in accordance with industry recognized standards and best practices for secure token management.
C.2.1.1.d Where tokens (for example, access tokens and refresh tokens) are used to authenticate user access to sensitive functions and sensitive resources, the assessor shall examine evidence to confirm that the tokens are handled in accordance with industry-recognized standards and best practices for secure token management.
Modified
p. 94 → 95
(continued on next page) C.2.2.b The assessor shall examine evidence to identify all methods used to authorize access to Internet accessible interfaces.
(continued on next page) C.2.2.b The assessor shall examine evidence to identify all methods used to authorize access to Internet-accessible interfaces.
Modified
p. 95 → 96
• Is implemented correctly;
• implemented correctly;
Modified
p. 95 → 96
• Is appropriate for the types of users expected to use the interface; and
• appropriate for the types of users expected to use the interface; and
Modified
p. 95 → 96
• Does not expose known vulnerabilities.
• does not expose known vulnerabilities.
Modified
p. 95 → 96
C.2.2.d Where the methods used to authorize access to Internet accessible interfaces is user configurable, or otherwise requires user input or interaction, the assessor shall examine evidence to confirm that appropriate guidance is made available to stakeholders in accordance with Control Objective 12.1 that describes the configurable options available and how to configure each method securely.
C.2.2.d Where the methods used to authorize access to Internet-accessible interfaces is user configurable, or otherwise requires user input or interaction, the assessor shall examine evidence to confirm that appropriate guidance is made available to stakeholders in accordance with Control Objective 12.1 that describes the configurable options available and how to configure each method securely.
Modified
p. 95 → 96
C.2.2.e Where the methods used to authorize access to Internet accessible interfaces are configured and controlled by the assessed entity, the assessor shall examine evidence to confirm that access to Internet accessible interfaces is restricted to an appropriate set of explicitly authorized users (or entities).
C.2.2.e Where the methods used to authorize access to Internet-accessible interfaces are configured and controlled by the assessed entity, the assessor shall examine evidence to confirm that access to Internet-accessible interfaces is restricted to an appropriate set of explicitly authorized users (or entities).
Modified
p. 95 → 96
C.2.2.f The assessor shall examine evidence and test the software to confirm that access to all Internet accessible interfaces is restricted to explicitly authorized users only.
C.2.2.f The assessor shall examine evidence and test the software to confirm that access to all Internet-accessible interfaces is restricted to explicitly authorized users only.
Modified
p. 95 → 96
C.2.3 Access to all software functions and resources exposed through Internet accessible interfaces is restricted to explicitly authorized users only.
C.2.3 Access to all software functions and resources exposed through Internet-accessible interfaces is restricted to explicitly authorized users only.
Modified
p. 95 → 96
C.2.3 Using information obtained in Test Requirement C.2.2.a, the assessor shall examine evidence to identify all software functions and resources that are exposed, or that can be configured in a way that exposes them, through Internet accessible interfaces.
C.2.3 Using information obtained in Test Requirement C.2.2.a, the assessor shall examine evidence to identify all software functions and resources that are exposed, or that can be configured in a way that exposes them, through Internet- accessible interfaces.
Modified
p. 96 → 97
• Does not expose known vulnerabilities.
• does not expose known vulnerabilities.
Modified
p. 96 → 97
C.2.3.1.a Using information obtained in Test Requirement C.2.3, the assessor shall examine evidence to determine how the software controls access to individual functions and resources exposed (or potentially exposed) through Internet accessible interfaces.
C.2.3.1.a Using information obtained in Test Requirement C.2.3, the assessor shall examine evidence to determine how the software controls access to individual functions and resources exposed (or potentially exposed) through Internet-accessible interfaces.
Modified
p. 96 → 97
(continued on next page) C.2.3.1.b The assessor shall then examine evidence to identify the methods used to restrict access to the functions and resources exposed (or potentially exposed) through Internet accessible interfaces and to confirm that each of these methods:
(continued on next page) C.2.3.1.b The assessor shall then examine evidence to identify the methods used to restrict access to the functions and resources exposed (or potentially exposed) through Internet- accessible interfaces and to confirm that each of these methods is:
Modified
p. 96 → 97
• Is implemented correctly.
• implemented correctly;
Modified
p. 96 → 97
• Is appropriate for the type of function(s) and resource(s) provided.
• appropriate for the type of function(s) and resource(s) provided; and
Modified
p. 96 → 97
C.2.3.1.c Where the methods used to authorize access to the functions and resources exposed (or potentially exposed) through Internet accessible interfaces is user configurable or otherwise requires user input or interaction, the assessor shall examine evidence to confirm that guidance is made available to stakeholders in accordance with Control Objective 12.1 that describes the mechanisms and configurable options available to restrict access to the functions and resources exposed through these interfaces, and how to configure such mechanisms.
C.2.3.1.c Where the methods used to authorize access to the functions and resources exposed (or potentially exposed) through Internet-accessible interfaces are user configurable or otherwise requires user input or interaction, the assessor shall examine evidence to confirm that guidance is made available to stakeholders in accordance with Control Objective 12.1 that describes the mechanisms and configurable options available to restrict access to the functions and resources exposed through these interfaces, and how to configure such mechanisms.
Modified
p. 97 → 98
C.2.3.1.e The assessor shall examine evidence and test the software to confirm that the methods used to restrict access to the functions and resources exposed (or potentially exposed) through Internet accessible interfaces require users to be explicitly authorized prior to being granted such access.
C.2.3.1.e The assessor shall examine evidence and test the software to confirm that the methods used to restrict access to the functions and resources exposed (or potentially exposed) through Internet-accessible interfaces require users to be explicitly authorized prior to being granted such access.
Modified
p. 97 → 98
C.2.3.2 Authorization rules are enforced upon each user request to access software functions and resources through Internet accessible interfaces.
C.2.3.2 Authorization rules are enforced upon each user request to access software functions and resources through Internet- accessible interfaces.
Modified
p. 97 → 98
C.2.3.2.a Using information obtained in Test Requirement C.2.3.1.a, the assessor shall examine evidence to confirm that authorization checks are performed each time users request access to a function or resource exposed (or potentially exposed) through Internet accessible interfaces to verify they are authorized for the function, resource, and type of access requested.
C.2.3.2.a Using information obtained in Test Requirement C.2.3.1.a, the assessor shall examine evidence to confirm that authorization checks are performed each time users request access to a function or resource exposed (or potentially exposed) through Internet-accessible interfaces to verify they are authorized for the function, resource, and type of access requested.
Modified
p. 97 → 98
C.2.3.2.b The assessor shall examine evidence and test the software to confirm that access control rules are enforced each time a user attempts to access a function or resource exposed (or potentially exposed) through Internet accessible interfaces.
C.2.3.2.b The assessor shall examine evidence and test the software to confirm that access control rules are enforced each time a user attempts to access a function or resource exposed (or potentially exposed) through Internet-accessible interfaces.
Modified
p. 100 → 101
To protect against these and other types of related attacks, input data must never be trusted and software security controls must be implemented to ensure input data is validated, rendered safe, or otherwise handled in a manner that mitigates the likelihood and/or impacts of executing malicious input data.
To protect against these and other types of related attacks, input data must never be trusted, and software security controls must be implemented to ensure input data is validated, rendered safe, or otherwise handled in a manner that mitigates the likelihood and/or impacts of executing malicious input data.