Metrics
Security Reviewer suite uses a set of Metrics to evaluate your software:
ISO 25010 Characteristics (Testability, Reliability, Changeability, Availability, Efficiency, Maintanability, Portability). Our product checks for Agile Alliance’s Best Practices, with 5500+ Rules.
Quality Metrics (McCabe, SEI-Software Engineering Institute, Chidamber & Kemerer, Mood, Halstead) for Complexity (Cyclomatic, Cognitive and Essential Complexity), Maintanability, Size and Object-Oriented metrics
Anti-Patterns (Architecture AP, Software Development AP). See: Anti-Patterns
Security Level (average of 110 security rules for each of 79 supported languages, plus 25 SQL dialects, plus 36 NoSQL and 15 Mobile SQL dialects)
Code Duplication. Duplicated files, classes, methods/functions, blocks, lines. See: https://securityreviewer.atlassian.net/wiki/x/JYBpyQ
Test Coverage. It is automatically done during Static Analysis. Further than analyzing source code, a sandbox-based analysis is executed on-the-fly to the compiled code, obtaining the test coverage, thank to our proprietary algorithm named Dynamic Syntax Tree. See: Our Approach. Using our Universal Importer, you can import third-party testing data, to enrich your coverage. See: Integrations.
Effort Metrics. OMG’s Automated Function Points (AFP) and SNAP-Points are calculated during the Static Analysis. Further we provide an Effort Estimation module.
Such Metrics are applied on both new and existing code, and are summarized in different Risk Indicators:
OWASP
OWASP Indicator shows Compliant or Not Compliant. It means there are significant Security Issues or Not. You can drill-down the see a dashboard showing the Risk of being out-of-compliance with international standards, like OWASP Top 10, CWE-SANS Top 25, PCI-DSS as well as the Top 10 most severe vulnerabilities and the Top 10 Worst Files
Quality
You can directly understand the Quality of the analyzed app by watching the logo as an Indicator:
| Means SEI-Maintanability Index MI4 is higher than 84 |
| Means SEI-Maintanability Index MI4 is lower than 85 |
You can drill-down the see a dashboard showing all Quality details, like Violations, McCabe, Halstead, OOP Metrics (Chidamber & Kemerer, Mood) and Anti-Patterns:
See: Quality Reviewer
SQALE
The SQALE Risk Indicator (aka SQALE Rating) is a KPI based on Technical Debt. The SQALE Method assesses source code by converting code quality and security violations into an estimated time for remediation, allowing organizations to quantify and manage technical debt in time/financial terms. The rating is expressed on an alphabetical scale from A (best) to E (worst).
See: SQALE
A-Rating means a theoretically No-Risk. It is required on at Military-level, and in the civil world you can achieve it mostly for small apps only.
B-Rating is considered the perfect balance between a clean code and its Quality and Security Characteristics. It is normally the Target every enterprise wants to reach for its apps.
C-Rating is an Average Rating, that is the borderline for a medium quality app. Some fixes are mandatory anyway. This rating is overly-broad and represent most of Development Team painful activity.
D-Rating means you have to re-engineering the app.
E-Rating means you have to make a decision on refactoring or rewriting the app.
You can drill-down the see a dashboard showing all SQALE details:
For each file you can see a brief list of ISO 25010 Characteristics / Sub-Charateristics that need attention, with the violated Requirement, the Development Time, the Remediation Cost, the Rating, the Violation number and the file SLOC/LOC (size in statements).
SQALE Configuration
The A-E Rating are calculated with the Agile Alliance defaults, and a SuperUser can customize them:
SQALE Rating
SQALE Rating normalizes the Quality and Security results in a one KPI only. Quality grid differs from Security one because it is in Defect Rating format and takes in consideration the SLOC.
The default Rating grids are as follows:
Security
Based on:
8500 Security Rules
25 SQL Dialects
15 Mobile SQL dialects
Rating | Range in % | Numeric Range |
|---|---|---|
A | >= 90% | 0.01-1.00 |
B | >= 80% and <90% | 1.01-2.00 |
C | >= 60% and <80% | 2.01-4.00 |
D | >= 20% and <60% | 4.01-8.00 |
E | < 20% | 8.01-10.00 |
Security ranges represent the % of non-conformity to the above mentioned Rules.
Quality
Quality Defect Density based on:
ISO 25010 Quality Characteristics (Testability, Reliability, Changeability, Availability, Efficiency, Maintanability, Portability)
35 Anti-Patterns, plus your Custom Anti-Patterns
Rating | Range in % | Numeric Range |
|---|---|---|
A | <=10% | 0.00-0.10 |
B | 11-20% | 0.11-0.20 |
C | 21-30% | 0.21-0.30 |
D | 31-50% | 0.31-0.50 |
E | >50% | 0.51-1.00 |
The Quality grid is different from the Security one, because the ranges are in Defect Density format, ranging 0.00 to 1.00, calculated as follows:
Where:
Total Number of Defects: number of non-conformities respect than ISO 25010 Quality Characteristics (Testability, Reliability, Changeability, Availability, Efficiency, Maintanability, Portability), applying Quality Metrics, Dead Code and Best Practices rules as well as Anti-Patterns.
Size of the Software Component: SLOC (Source Lines of Code) of the entire application.
The resulting Defect Density is normalized to range 0.00 to 1.00.
Quality Targets
The default Quality Targets (aka Quality Gates) are the following:
Characteristic | Target in % | Numeric Target |
|---|---|---|
Changeability | >= 80% | >= 2.00 |
Maintanability | >= 85% | >= 1.50 |
Availability | >= 80% | >= 2.00 |
Testability | >= 75% | >= 2.50 |
Efficiency | >= 65% | >= 3.50 |
Security | >= 80% | >= 2.00 |
Portability | >= 65% | >= 3.50 |
Additional Rating Parameters
Fix SQALE Rating. For SQALE Rating calculation, you may define some exceptions for small code apps, for example having Source Lines Of Code SLOC < 500 (default).
Higher Risks are relevant. In case in the same app you have different risk levels, selecting this option only the higher will be taken into account.
Technical Debt Interest
Technical Debt Interest refers to the increased effort, time, and complexity incurred over time due to past shortcuts in software development, much like how financial debt accrues interest, making it harder and more expensive to maintain the software's overall quality and develop new features. This "interest" slows down development, increases the cost of future work, and can lead to more bugs and decreased stability if not addressed.
For calculating such Interest, we provide some customizations:
Average hours per workday. Some tools use 8 hours per day. We default a more realistic 6 hour per day of working, assumed when the Technical Debt is shown in days. 6 hour are coming from COCOMO 152 hours per Person-Month definition.
N.of workdays per year. Used for Technical Debt Interest calculation. If the Technical Debt in days is > this value, Interest will be applied. Default = 240 workdays/year.
Technical Debt includes A-Rating. Except for Military-level apps, it is suggested to skip A-Rating issues on Technical debt calculation. A-Rating issues should be solved anyway, but should not affect the Technical Debt.
Technical Debt Interest-Severity matrix. You can calculate a different Interest for each Severity level. The values are in SQALE numeric format. Changing those values you can see the related hh:mm:ss time format.
The following is the default Interest-Security matrix:
Severity | Interest Value | Interest Time |
|---|---|---|
Blocker | 96.00 | 10:00:00 |
Critical | 19.20 | 02:00:00 |
Major | 3.20 | 00:20:00 |
Minor | 0.32 | 00:02:00 |
Info | 0.16 | 00:01:00 |
Project Summary
Automated Function Points (AFP) view is configurable, and is associated to both Total Technical Debt and Security Technical Debt.