SAMMY UI is optimized for resolutions with a width 1024px and higher.
Cloud Controls Matrix
Browse Cloud Controls...
AIS-03: Application Security Metrics
Application Security Metrics
AIS-03: Are technical and operational metrics defined and implemented according to business objectives, security requirements, and compliance obligations?
Actionable metrics should be defined with consideration to business goals, the criticality of service, security requirements, and compliance obligations.

Example technical metrics include:
• Count or percentage of vulnerabilities by weakness.
• Count or percentage of vulnerabilities by severity.
• Count or percentage of vulnerabilities by detection source (design review, code review, SAST, DAST, penetration test, VDP, or bug bounty).
• Count or percentage of vulnerabilities by environment detected (pre-production vs. production).
• Average time to resolution.
• Count exceeding remediation service level objectives (SLOs).

Example operational metrics include:
• Count or percentage of applications using automated security testing by test type (SAST, DAST, SCA).
• Count or percentage of applications have completed penetration testing in the last “n” months.
• Count or percentage of development teams or individuals who have completed application security training in the last “n” months.
• Count of proactive engagements by development and business teams.
• Results from surveys delivered to application security customers, such as business and development teams.

Reporting:
Reporting should be designed with various users in mind. For example, security professionals, engineering teams, business stakeholders, and executives will often have different interests requiring specialized views, filtering, and delivery mechanisms.

a. The collection, visualization, and distribution of reporting data should be automated.
b. Data may be further analyzed using application criticality, business units, platforms, languages, and other factors relevant to the viewer.
c. Compare actual metrics to standards to evaluate performance.
d. Enable comparisons over time to identify trends.
e. Enable correlations, such as relating a reduction in vulnerabilities of a specific type after new tools or training.
Control implemented
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.
Control ownership
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 technical and operational metrics in alignment with business objectives, security requirements, and compliance obligations.