...
Security Reviewer SRA is a Static analysis solution that can be used to perform application resiliency testing on large, complex, and multi-technology applications, regardless of the language, to provide development process improvement opportunities. SRA analyzes source and binary code and architecture to identify vulnerabilities and verify architecture or coding standards adherence. This creates a bottom-up view of software risks and real-time information for remediation or software quality improvement.
...
SQALE
Security Reviewer is an Official SQALE Tool. See SQALE in this site.
...
Software Quality Characteristics from ISO/IEC 25010 with CISQ focal areas highlighted.
The following is an example of Reliability Checklist:
...
This analysis certifies the level of quality measured in this application when measured against the CISQ Quality Characteristic Measures developed by the Consortium for IT Software Quality and adopted as standards by the Object Management Group (OMG). These measures are developed from counting the number of times critical rules of good architectural and coding practice for each characteristic have been violated. Since structural quality analysis tools differ in the violations of good architectural and coding practices they can detect, the analysis will only include results for practices that were evaluated and are the basis for this certification. For each architectural or coding practice within each quality characteristic, the results present both the number of times each practice was violated and the number of opportunities for the practice to have been violated within the application. When aggregated over the all violations, these numbers provide the basis for a 6-sigma ranking for each quality characteristic and the aggregated characteristics. That is, the σ level representing the number of violations per million opportunities. This analysis provides an evidence-based assessment of the risk this application poses to the business operations it supports or its cost of ownership.
...
The total number of occurrences detected for the weaknesses included in a CISQ measure is then transformed into weaknesses per million opportunities to determine the Sigma level for that measure. The thresholds for each Sigma level are as follows:
• 1σ - 697,672 weaknesses per million opportunities - 69.7672 % defective
• 2σ - 308,537 weaknesses per million opportunities - 30.8537 % defective
• 3σ - 66,807 weaknesses per million opportunities - 6.6807 % defective
• 4σ - 6,210 weaknesses per million opportunities - .6210 % defective
• 5σ - 233 weaknesses per million opportunities - .0233 % defective
• 6σ - 3.4 weaknesses per million opportunities - .0003% defective
...
The following is an example of Reliability Checklist:
...
In general, applications below the 3σ level should be considered unacceptable and of high risk. In practice, it will be difficult for applications to achieve 5 or 6 Sigma scores, and this level of quality may be beyond the requirements for many applications, or beyond the cost-benefits of striving for this level of quality. However, there are violations such as SQL injection for which the tolerance level should be ‘0 occurrences’ since the Security risks posed by this weakness can be disastrous. The appropriate quality range for most business applications will be a certification between 3 and 4 Sigma.
...
For those reasons a dedicated Software Resilience Index was created. Refer to previous Threshold section for the possible values.
Root Cause Analysis
Root Cause Analysis (RCA), a common practice throughout the software industry, does not provide any value in preventing future incidents in complex software systems. Instead, it reinforces hierarchical structures that confer blame, and this inhibits learning, creativity, and psychological safety. In short, RCA is an inhumane practice.
A common misconception that encourages the embrace of RCA is that without understanding the ‘root cause,’ you can’t fix what is wrong. Let’s differentiate between the ‘root cause’ and Least Effort to Remediate (LER). As long as an incident is ongoing, LER is absolutely the right thing to pursue. When the building is on fire, put the fire out as quickly as possible. Unfortunately it is all-too-common to assume that whatever undoes the damage must also point to what caused it. One branch of research in particular, Resilience Engineering, has made its way into the software industry.
Complex software systems will not lose their complexity. RCA will only hinder our ability to navigate them with fairness and grace. Resilience Engineering may hold the key to take back our dignity as knowledge workers, overcome naive notions like ‘root cause,’ and learn to navigate our complex systems better.
Resilience Engineering
Despite ever-accelerating technology advances over the past decade, achieving application stability is still fraught with complexity and prohibitively high costs. Resilient applications provide much more than reliability: they help to build a continuous innovation process by predicting the failure paths and design for failure to move fast and stay ahead of availability goals to build always-available systems and provide continuous service to customers. To get there, IT organizations must assess the current cultural situation, and change behavior and mindsets to enable their business, process, tools and technology to deliver enhanced quality of service to users inside and outside the enterprise.
...
Post implementation of resilience features in their IT organization, the following benefits were measured:
• 20% reduction in number of non-functional incidents year to date (YTD).
• 32% reduction in incident duration (MTTR), YTD.COPYRIGHT (C) 2014-2021 SECURITY REVIEWER SRL. ALL RIGHTS RESERVED.