Executive
This template allows to analyze the findings, the density and the trends of specific teams and its projects within a configurable timeframe. It is mostly oriented to the C-level members.
Permissions
To be able to generate the executive report, the user have access to the team to which to and be associated to an Access Control role that has the generate-executive-report permission. Since this permission is not included in any of the default Access Control roles, you must create a new role or edited an existing role, to include the new permission.
KPIs
Total Teams Data
The Total Teams Data card shows details related to the teams included in the report, such as the total number of members, total number of projects, total number of files scanned and total number of scans (failed vs. successful).
 |
Filtered by
In the Filtered by card you can see which filters were applied for generating the report:
 |
Included: Data included in the report. All data available in the report is filtered according to the specified included filters.
Excluded: Data filtered out from the report.
Specific filters can be applied when generating the single team report to restrict and refine the data and the results to analyze.
The following filters can be defined when generating the report:
Projects: By default, all projects belonging to the team(s) are included.
Exclude the project names that you do not want to include in the report.
Severity: By default, Low and Information results are excluded.
Allowed values to be excluded from the report are: High, Medium, Low and Information.
Result State: By default, all Result States are included.
Allowed values to be excluded are: To Verify, Confirmed, Urgent, Proposed Not Exploitable, Not Exploitable.
Status: By default, only New and Recurrent are included.
Allowed values to be exclude are: New, Recurrent and Resolved.
What happens when Resolved Results are included?
Resolved Results section is displayed in the report.
All other KPI calculation (outside of Resolved Results section) are not affected by the Resolved Results.
What happens when Resolved Results are excluded?
Resolved Results section is not displayed in the report.
Timeframe: Defines the date range in the analysis and it is composed by a starting date and an ending date. The maximum allowed period to be defined is 1 year. In case the timeframe is not defined:
The Timeframe used is the teams lifetime.
If the teams lifetime extends over 1 year, the timeframe starts from the year prior to the last scan date.
Data Points: Allowed values are last or first. The default value is last.
last: means the last scan is considered.
first: means the first scan is considered.
Project Custom Fields: By default all projects are included in the report.
The allowed values to be included are based on a key-value pair, where the key is the custom field name and the value is its correspondent value in the project definition.
Total Results Overview
The Total Results Overview provides two different charts for the trend analysis over time:
By Severity
This KPI is based on the aggregated results for all the teams and their projects included in the report, grouped by Severity.
 |
By Result State
This card is based on the aggregated results for all the teams and their projects included in the report, grouped by Result State.
 |
For both KPIs, the values displayed in the Density cards are calculated based on the last full scan executed for each project within the timeframe under analysis.
The Preset Change indicators mark the dates when changes to the preset occurred to help you understand how they affect the total results and possible variations in the findings over time. The indicators are displayed only when all the projects share the same preset, otherwise it will not be displayed in the chart.
In the Total Results Overview chart, the dates on the timeline (x-axis) are based on the length of the timeframe and the report format (as described in Report Formats below). Each date value on the timeline indicates the end date of each data period.
Report Formats:
In PDF format, if the timeframe period is:
over 180 days, the data points are every 2 weeks.
over 30 days and under 180 days, the data points are per week.
under 30 days, the data points are per day.
In JSON format, the full scope of data is presented
Example: Monthly Timeframe
Timeframe: From 1st of January to 30th of January.
Data point: last scan.
Data points are displayed per week, where the first data point identified is the 7th of January and shows the results for the last scan executed between the 1st and the 7th.
The second data point is identified by 14th of January, the third by the 21st of January, the fourth by the 28th of January and the last would be identified by 5th of February (even if it extends the timeframe filter).
Example: One Year Timeframe
Timeframe: From 1st of January to 31st of December.
Data point: first scan.
Data points are displayed every 2 weeks, where the first data point identified is the 14th of January and shows the results for the first scan executed between the 1st and the 14th of January.
Latest Results Overview
The KPIs displayed in the Latest Results Overview are calculated based on the results of the last full scan executed for each project, during the specified timeframe.
By State
 |
The pie chart shows the number of results grouped according to each state. The total of results and its percentage is displayed for each State.
The KPIs show the aggregated results of all the teams and their projects included in the report.
By Status
 |
The pie chart shows the number of results grouped by Status (New vs Recurrent). For each status, the total of results and its percentage is displayed.
The KPIs show the aggregated results of all the teams and their projects included in the report.
By Severity
 |
This pie chart shows the scan results grouped by the Severity. For each severity, the total number of results, its percentage and the trend are displayed. The trend is calculated between the current timeframe and the previous one, meaning that if you are analyzing the last 3 months, the trend is the difference between the results within the timeframe currently under analysis and the results from 3 months ago. The main goal of the trend calculation is to help you understand if the results are decreasing or increasing with time.
The density and density trends are also available in this card.
The KPIs show the aggregated results of all the teams and their projects included in the report.
By Team and Project
 |
The table shows the total number of results by each team’s project and for each there is a breakdown by severity. Along with the team name, the first column also displays the project name and the preset configured.
The blue capsule shows how many new vulnerabilities appeared and how many were resolved between the current timeframe and the previous one. The Total Scans shows the number of successful scans executed and a trend that is a calculation of the difference between the New Vulnerabilities and the Resolved ones (New – Resolved).
By Severity and Result State
 |
The table shows the total number of results by results state and for each there is a breakdown by severity.
The blue capsule shows how many new vulnerabilities appeared and how many were resolved between the current timeframe and the previous one. The Scan Trend is the difference between the New Vulnerabilities and the Resolved ones (New – Resolved).
Top 10 Risky Projects
 |
From all the projects included in the report, the Top 10 Risky Projects are calculated based on the total number of results that each project has in the last full scan executed within the timeframe in analysis. The project having the most High results is considered as the most risky one. The last scan execution date and the team name are also displayed.
Top 10 Most Common Vulnerabilities
 |
Using all the included projects as a reference, this card displays the Top 10 Vulnerabilities having the most High results and the projects with those top vulnerabilities. For each project, the team name is also displayed.
Top 10 Oldest Vulnerabilities by Severity
 |
The aging is calculated restricted to the project you are analyzing, meaning that the first detection date for the vulnerability in this project is taken in consideration. The aging refers to the scan date where the vulnerability appeared and not to the project creation date.
Example:
Project A has vulnerability 1 that appeared in June 2021.
Project B has been created in July 2010 and share same code as Project A.
The first scan for Project B ran on August 2021 and a Scan Report was generated in September 2021. In the Report, the vulnerability 1 aging is 1 month (calculated based in the first scan).
Vulnerability 1 is resolved and disappears between September and December, then it re-appears in January (for same source code). If the report is generated in January, the aging is between September and January (4 months). In case it re-appears for different source code, the aging is calculated according to difference between the current and first detection dates.
State Transition Metrics
 |
For each transition detected from the project set, within the timeframe in analysis, you can see how many days the transition takes on average, and how many results have changed.
Resolved Results Overview
This section only appears if Resolved Results is included in the report (defined in the Filters).
 |
The Resolved Results Overview chart provides trend analysis over time, based on the aggregated resolved results for all the projects included in the report.
The Total Results line shows the number of results currently present in the projects, so you can compare the ratio between resolved and open results.
The labels for Data Retention, Preset Change, and Query Change mark the dates where these events occurred to help you understand changes in the total results and possible variations in the findings over time.
Top 10 Teams with Resolved Vulnerabilities by Severity
 |
The Top 10 Teams with Resolved Vulnerabilities by severity shows the teams which had the most High results resolved within the timeframe under analysis.
The display shows for each team, the total number of results resolved, arranged according to the severity. The date when a preset change occurred is also displayed to help understanding if the results were potentially fixed by changes on the queries available in the preset or by fixing the source code.
Top 10 Resolved Vulnerabilities by Severity
 |
The Top 10 Resolved Vulnerabilities by severity shows the vulnerabilities which had more results resolved within the timeframe under analysis. For each vulnerability, the total number of results resolved is displayed.
Average (in days) from any transition to Resolved
A vulnerability that disappears between two consecutive scans S1 and S2 of the same project, is considered resolved in scan B.
When a vulnerability does not appear in a new scan, the state transition considers the vulnerability’s most recent state, regardless of the previous states.
For each transition detected in the project, within the timeframe in analysis, you can see how many days the transition takes on average, the maximum of days, the minimum of days, and how many results have changed. All these details are displayed and grouped by severity.
Severity proportions on the graph are calculated based on how many transitions were made on each severity.
This KPI considers full scans only.
 |
Example:
Only results as To Verify were Resolved a total of 40 results.
21 High results were resolved.
On average, fixing a High vulnerability takes 1 day.
The minimum number of days is 0 and the maximum is 14.
How are the transitions identified?
Example:
Scan S1 has the vulnerability V1 as a result, having state = Confirmed
Scan S1 has the vulnerability V1 as a result, having state = To Verify
V1 state is updated from To Verify to Urgent
The source code is fixed
Scan S2 is executed and V1 and V1 are not flagged anymore → V1 and V2 are Resolved vulnerabilities
Two transitions to Resolved are identified:
For V1: Confirmed → Resolved
For V1: Urgent → Resolved
What is the behavior when a resolved result reappears?
If a result reappears after being resolved, and it is resolved once again, the two transitions will be considered in two different timelines.
Example:
Vulnerability V1 is marked as Confirmed in January 2023
Vulnerability V1 is Resolved in February 2023
Vulnerability V1 reappears in March 2023 To Verify
Vulnerability V1 is Resolved in April 2023
Timeframe applied to generate the report is between January 1st and the end of February
Only the transition Confirmed → Resolved is considered
Timeframe applied to generate the report is between March 1st and the end of April
Only the transition To Verify → Resolved is considered
Timeframe applied to generate the report is between January 1st and May 1st. The following transitions are considered:
Confirmed → Resolved
To Verify → Resolved