SAMMY works best on screens 1024px wide or larger.
Cloud Controls Matrix
Browse Cloud Controls...
AIS-07: Application Vulnerability Remediation
Application Vulnerability Remediation
AIS-07: Are application security vulnerabilities remediated following defined processes?

Application security remediation should adhere to the following guidelines:
a. Follow defined remediation processes, designed, tested, and implemented by security and application teams.
b. Remediate risks as early in the SDLC as possible, such as during the design or development stages.
c. Have defined roles and responsibilities, including escalation paths for application security incident response and remediation.
d. Follow a risk-based approach to address high-risk incidents that significantly impact application availability, integrity, or confidentiality.
e. Leverage automation when possible to increase remediation efficiency and accuracy.


Processes, roles, responsibilities, and documentation established for application security remediation should be reviewed periodically by management.


Example:
• GitOps-based remediation of application vulnerabilities.
• Automated remediation efficacy metric: total number of remediations of active critical/high vulnerabilities performed through Git for the given period.
• Total number of active critical/ high vulnerabilities identified for the given period.


Not applicable - A “N/A” answer indicates that the portion of the control in question is out of scope of the assessment. The “SSRM control ownership” column is to be left blank (e.g., greyed out), and optionally the CSP may explain why it is the case (“CSP Implementation Description”).
No - A “No” answer indicates that the portion of the control in question is not implemented, while in scope of the assessment. The CSP has to assign the implementation responsibility of the control to the relevant party under column “SSRM control ownership”, and optionally elaborate on the “why” (has not been implemented), and “what” has to be done for its implementation by that party.
Yes - A “Yes” answer indicates that the portion of the control in question is implemented. The CSP indicates the responsible and accountable parties (SSRM control ownership), and optionally elaborates on the implementation “how-to” per relevant party CSP and/or CSC.
CSP-owned - The CSP is entirely responsible and accountable for the CCM control implementation.
CSC-owned - The Cloud Service Customer (CSC) is entirely responsible and accountable for the CCM control implementation.
Third-party - The third-party CSP in the supply chain (e.g., an IaaS provider) is responsible for CCM control implementation, while the CSP is fully accountable.
Shared CSP and CSC - Both the CSP and CSC share CCM control implementation responsibility and accountability.
Shared CSP and third party - Any CCM control implementation responsibility is shared between CSP and the third party, but the CSP remains fully accountable.
Description

Define and implement a process to remediate application security vulnerabilities, automating remediation when possible.

Application Vulnerability Remediation
AIS-07: Is the remediation of application security vulnerabilities automated when possible?

Application security remediation should adhere to the following guidelines:
a. Follow defined remediation processes, designed, tested, and implemented by security and application teams.
b. Remediate risks as early in the SDLC as possible, such as during the design or development stages.
c. Have defined roles and responsibilities, including escalation paths for application security incident response and remediation.
d. Follow a risk-based approach to address high-risk incidents that significantly impact application availability, integrity, or confidentiality.
e. Leverage automation when possible to increase remediation efficiency and accuracy.


Processes, roles, responsibilities, and documentation established for application security remediation should be reviewed periodically by management.


Example:
• GitOps-based remediation of application vulnerabilities.
• Automated remediation efficacy metric: total number of remediations of active critical/high vulnerabilities performed through Git for the given period.
• Total number of active critical/ high vulnerabilities identified for the given period.


Not applicable - A “N/A” answer indicates that the portion of the control in question is out of scope of the assessment. The “SSRM control ownership” column is to be left blank (e.g., greyed out), and optionally the CSP may explain why it is the case (“CSP Implementation Description”).
No - A “No” answer indicates that the portion of the control in question is not implemented, while in scope of the assessment. The CSP has to assign the implementation responsibility of the control to the relevant party under column “SSRM control ownership”, and optionally elaborate on the “why” (has not been implemented), and “what” has to be done for its implementation by that party.
Yes - A “Yes” answer indicates that the portion of the control in question is implemented. The CSP indicates the responsible and accountable parties (SSRM control ownership), and optionally elaborates on the implementation “how-to” per relevant party CSP and/or CSC.
CSP-owned - The CSP is entirely responsible and accountable for the CCM control implementation.
CSC-owned - The Cloud Service Customer (CSC) is entirely responsible and accountable for the CCM control implementation.
Third-party - The third-party CSP in the supply chain (e.g., an IaaS provider) is responsible for CCM control implementation, while the CSP is fully accountable.
Shared CSP and CSC - Both the CSP and CSC share CCM control implementation responsibility and accountability.
Shared CSP and third party - Any CCM control implementation responsibility is shared between CSP and the third party, but the CSP remains fully accountable.
Description

Define and implement a process to remediate application security vulnerabilities, automating remediation when possible.