Overview

Reporting module is a place where you can easily and quickly access reports on-demand, in any available reporting template, to save time & effort on manually creating or adjusting reports.

Using the Reporting module, you can:

• download individual reports for your projects in PDF, DOCX, HTML, CSV & JSON formats

• download individual ZIP archives for each of your projects

• download multiple individual reports in one go for each of your projects using ReportGen

• download consolidated group report which contains all your data for multiple projects in one single report

JSON export contains all the data in the on-demand reports. This is also used by AttackForge ReportGen tool to create custom reports using your own DOCX template, or if you need to integrate AttackForge project & vulnerability data into other systems.

The ZIP archive contains all evidence which has been uploaded to the vulnerabilities on the project. It is useful if the customer needs high-resolution screenshots, or access to evidence which is not an image format and as such not already included in the reports - for example scripts, videos, etc.

Customizing Standard Reports

Standard reports can be customized by users within the application by clicking on Customize Reports from the page menu. This allows users to create content within the reports which is relevant to the reader.

For example, if the report needs to go to an Executive - they may not have the time to read through hundreds of pages of technical analysis. You can create a report that is structured to provide only the information the Executive cares about.

Another example is when reports need to be provided to 3rd parties or auditors. Considering vulnerability reports contain sensitive data on how to exploit issues, this information may need to be redacted before it is sent to the party. You can create a report that will omit any screenshots, steps to reproduce findings, etc. which may be deemed too sensitive to share with external parties.

For more information on how to customize reports - check Getting Started.

AttackForge ReportGen

AttackForge ReportGen helps you to create fully customized reports using your own DOCX templates. You can style and structure the reports however you need.

For Enterprise customers, you can access pre-existing report templates loaded by your Administrators & Project Coordinators.

!IMPORTANT ReportGen reports will be generated based on the meta tags included in the template. They do not work with your custom reporting options as they are already fit-for-purpose.

Administrators & Project Coordinators can:

• Access Template Library - download pre-defined templates to make custom reporting fast & easy.

• Upload New Templates - they will be made available to all users to download custom reports for their projects.

• Access Available Templates - includes all the custom templates which have been uploaded and are available to use on projects.

• Download ReportGen Tool - this tool can be used to manually create a custom report based on a template and project data (JSON file).

Other users can:

• Download reports on their project using any of the available reporting options, including custom templates. Reports are on-demand and will be created per request, in the users' browser.

Downloading Individual Reports

• Step 1: Select the projects you wish to download an individual report

• Step 2: Select the template you wish to use, and click on Download Individual Report button

A report will be created for each selected project using the selected template.

Downloading Group Reports

• Step 1: Select the projects you wish to combine into a single report

• Step 2: Select the template you wish to use, and click on Download Group Report button

A single report will be created which contains all the data for the selected projects.

De-duplication is performed automatically to help reduce report size.

Creating a New Template

If you are an Administrator or Project Coordinator, start by first downloading a base template from the Template Library

The Template Library contains different reporting templates that provide a foundation for your custom reports.

Each template is suitable for a particular audience and includes ReportGen compatible tags which makes it easy to adjust to suit to your own requirements.

Try downloading an example report to see what the end result will look like.

Once you have selected a template, try downloading the template itself and also test data (JSON file). You can then use these two files, along with the ReportGen tool, to start developing & testing your own custom report.

After you have downloaded a template, open it in a Word Processor and start making changes.

Each template will contain a section for Individual Reports:

Some templates will also include a section for Combined/Group Reports:

After you have made your changes to the template, save your DOCX template.

Now you can upload it to AttackForge using the page menu and selecting Upload New Template

After your template is uploaded, it will show in the Available Templates section. You can now download reports using the new template.

All templates are global so keep this in mind. Any user can download reports using any ReportGen template uploaded.

Updating a Template

You can create and upload as many templates as you need.

To update a template, first Delete the existing template using the actions menu and selecting Delete Template. The template will be removed from the table.

Then using the page menu, selecting Upload New Template. Your new template will be uploaded and will be immediately shown in the table at bottom of screen.

Troubleshooting

‌If you are experiencing issues generating the report(s) e.g. it won't download - download theOffline ReportGen Tool from the Reporting Module and try checking your browser console to see what the error is. AttackForge ReportGen has verbose errors enabled to help you identify the root cause of your problem.

To identify where an issue might be in your DOCX template, try downloading a template from the Template Library and modify it step-by-step until it matches your report style, testing it as you go to identify where it is breaking.

AttackForge ReportGen is built on DOCXTemplater. They also include useful information on how the meta tags work, especially when it comes to loops and nesting.

We have included details below on how the tags work, to help you with creating your custom templates:

Reminder: ReportGen only works with AttackForge JSON Reports.

General Syntax rules

{<tag>} - displays value of the tag {#<tag>} - opens a for-loop for a tag. Used if accessing nested data e.g. a list or array {.} - display values of string array e.g. ['hello', 'sir', 'how', 'are', 'you?'] will translate to: hello sir how are you? {/<tag>} - closes a for-loop for a tag. You can also use {/}. {^<tag>}{/<tag>} - where tag is not defined, display following e.g. {^<tag>} Tag Not Defined / Value Not Found {/<tag>} {%<tag>} - display image

The following information is taken from DOCXTemplater help site. It is recommended to visit their site directly for the latest updates and for more information.

Example:

{user.name}

To access the nested name property in the following data :

{
    user: {
        name: 'John'
    }
}

You can also use +, -, *, /, >, < operators.

Options

RemoveDuplicatePOCs

This option can be set at the beginning of your template in order to remove duplicate Proof-of-Concepts/Steps to Reproduce for vulnerabilities which have multiple affected assets and each affected asset has the same POC & Notes.

{#$optionRemoveDuplicatePOCs}{/}

This option is useful to reduce duplicate entries where the POCs/Notes are the same, significantly reducing report size and making content more useful to the reader. It requires use of the {#assets_equally_affected} tag in order to inform the reader that there are other affected assets with the same POC/Notes, and here is the list.

How it works:

1. For the first affected asset on a vulnerability, it will include the POC & Notes using the {#proof_of_concept} & {#notes} tags.

2. It will check if there are other affected assets for this vulnerability with the same POC/Notes, and if so, it will add them to the {#assets_equally_affected} list for the current affected asset.

3. The assets in the {#assets_equally_affected} list are removed from the loop to avoid displaying duplicate entries in the report.

Example:

!IMPORTANT: You must include {#$optionRemoveDuplicatePOCs}{/} tag at the beginning of your template file.

{#$optionRemoveDuplicatePOCs}{/}
...
{#vulnerabilities}
{title}
{#proof_of_concept}
{text}{%inlineScreenshot}
{/proof_of_concept}
{#assets_equally_affected_title}
ASSETS EQUALLY AFFECTED
{/assets_equally_affected_title}
{#assets_equally_affected}
1.	{.}
{/assets_equally_affected}
{/vulnerabilities}

RemoveDuplicateEvidence

This option can be set at the beginning of your template in order to remove duplicate Evidence for vulnerabilities which have already used/included the evidence within the Proof-of-Concept or Notes for any of affected assets, for example the screenshots have already appeared in-line within the Proof-of-Concept or Notes.

{#$optionRemoveDuplicateEvidence}{/}

This option is useful to reduce duplicate evidence displaying, significantly reducing report size and making content more useful to the reader.

How it works:

1. When looping over {#affected_assets} - if the {#proof_of_concept} or {#notes} includes an {%inlineScreenshot} - this screenshot will be removed from the {#evidence} section (to avoid duplication of displaying the same evidence file).

Example:

!IMPORTANT: You must include {#$optionRemoveDuplicateEvidence}{/} tag at the beginning of your template file.

{#$optionRemoveDuplicateEvidence}{/}
...
{#vulnerabilities}
{title}
{#notes}
{note}{%inlineScreenshot}
{/notes}
{#proof_of_concept}
{text}{%inlineScreenshot}
{/proof_of_concept}
{#evidence}
{%fileBase64}
{fileName}
{/evidence}
{/vulnerabilities}

Conditions

{#users.length>1}
There are multiple users
{/}
​
{#userName == "John"}
Hello John, welcome back
{/}

The first condition will render the section only if there are 2 or more users.

The second condition will render the section only if the userName is the string “John”.

It also handles the boolean operators AND &&, OR ||, +, -, the ternary operator a ? b : c, operator precedence with parenthesis (a && b) || c, and many other javascript features.

For example, it is possible to write the following template:

{#generalCondition}
{#cond1 || cond2}
Paragraph 1
{/}
{#cond2 && cond3}
Paragraph 2
{/}
{#cond4 ? users : usersWithAdminRights}
Paragraph 3
{/}
There are {users.length} users.
{/generalCondition}

Filters

Filter - FilterBy

You can use this filter in order to extract filtered data for vulnerabilities using various conditions.

Currently the following conditions are supported:

• filterBy:'AffectedAssetReportGenTags'

• filterBy:'AffectedAssetReportGenTags-CountVulns'

filterBy:'AffectedAssetReportGenTags'

This filter can be used to retrieve a list of vulnerabilities which have affected assets that meet conditions in their ReportGen tags.

The following example will return a list of vulnerabilities which have affected assets that have at least one ReportGen tag that is set to Source = External. This is useful for reporting on External Vulnerabilities in your report.

{#vulnerabilities | filterBy:'AffectedAssetReportGenTags':['Source:External']}
{priority} - {title}
{#affected_assets}
{asset}
{/}{/}

• {#vulnerabilities | filterBy:'AffectedAssetReportGenTags':['Source:External']}

  • Loop through vulnerabilities.

  • Apply filterBy filter with following parameters:

    • AffectedAssetReportGenTags - this instructs the filter to use this condition

    • ['Source:External'] - this instructs the filter to only return vulnerabilities and their affected assets which specifically have a ReportGen tag which equals Source = External.

• {priority} - {title}

  • Print priority and title of vulnerability which meets the filter.

• {#affected_assets}

  • Loop through affected assets on the vulnerability.

• {asset}

  • Print name of the affected asset.

This filter supports an array of ReportGen tags when inputting conditions, as well as AND and OR operators.

For example, using an AND operator with multiple ReportGen tag conditions:

{#criticalVulnerabilities | filterBy:'AffectedAssetReportGenTags':['Source:External','OWASPTop10:True']:'AND'}
{priority} - {title}
{#affected_assets}
{asset}
{/}{/}

This will return a list of critical vulnerabilities which have affected assets that have both ReportGen tags Source = External and OWASPTop10 = True.

You can also omit the AND operator, as this filter uses AND condition by default.

For example, using an OR operator with multiple ReportGen tag conditions:

{#criticalVulnerabilities | filterBy:'AffectedAssetReportGenTags':['Source:External','OWASPTop10:True']:'OR'}
{priority} - {title}
{#affected_assets}
{asset}
{/}{/}

This will return a list of critical vulnerabilities which have affected assets that have either ReportGen tags Source = External or OWASPTop10 = True.

filterBy:'AffectedAssetReportGenTags'

This filter can be used to retrieve a count of vulnerabilities which have affected assets that meet conditions in their ReportGen tags.

The following example will return a count of vulnerabilities which have affected assets that have at least one ReportGen tag that is set to Source = External. This is useful for reporting on total number of External Vulnerabilities in your report.

{vulnerabilities | filterBy:'AffectedAssetReportGenTags-CountVulns':['Source:External']}

• {vulnerabilities | filterBy:'AffectedAssetReportGenTags-CountVulns':['Source:External']}

  • Apply filterBy filter with following parameters:

    • AffectedAssetReportGenTags-CountVulns - this instructs the filter to use this condition

    • ['Source:External'] - this instructs the filter to only count vulnerabilities where their affected assets specifically have a ReportGen tag which equals Source = External.

This filter supports an array of ReportGen tags when inputting conditions, as well as AND and OR operators.

For example, using an AND operator with multiple ReportGen tag conditions:

{criticalVulnerabilities | filterBy:'AffectedAssetReportGenTags':['Source:External','OWASPTop10:True']:'AND'}

This will return a count of critical vulnerabilities which have affected assets that have both ReportGen tags Source = External and OWASPTop10 = True.

You can also omit the AND operator, as this filter uses AND condition by default.

For example, using an OR operator with multiple ReportGen tag conditions:

{criticalVulnerabilities | filterBy:'AffectedAssetReportGenTags':['Source:External','OWASPTop10:True']:'OR'}

This will return a count of critical vulnerabilities which have affected assets that have either ReportGen tags Source = External or OWASPTop10 = True.

Filter - Includes

You can check to see if a tag contains a specified value, or array of values, and continue if true/exists.

{#vulnerabilities}
{#title | includes:['SQL Injection','Cross Site Scripting']}
{priority} - {title}
{/}{/}

• {#vulnerabilities}

  • Loop through vulnerabilities.

• {#title | includes:['SQL Injection','Cross Site Scripting']}

  • Check to see if the title of the vulnerability contains the values "SQL Injection" or "Cross Site Scripting", and if so proceed. Otherwise stop. This filter also includes partial matches e.g. "Blind SQL Injection" would also return true.

• {priority} - {title}

  • Print priority and title of vulnerability assuming that it includes or partially includes

    "SQL Injection" or "Cross Site Scripting" in the title.

Filter - Excludes

You can check to see if a tag does not contain a specified value, or array of values, and continue if true/doesn't exist.

{#vulnerabilities}
{#title | excludes:['SQL Injection','Cross Site Scripting']}
{priority} - {title}
{/}{/}

• {#vulnerabilities}

  • Loop through vulnerabilities.

• {#title | excludes:['SQL Injection','Cross Site Scripting']}

  • Check to see if the title of the vulnerability does not contain the values "SQL Injection" or "Cross Site Scripting", and if so proceed. Otherwise stop. This filter also includes partial matches e.g. "Blind SQL Injection" would also return true.

• {priority} - {title}

  • Print priority and title of vulnerability assuming that it does not include or partially include

    "SQL Injection" or "Cross Site Scripting" in the title.

Filter - Store

You can store custom data in arbitrarily defined tags using this filter.

For example we can create a new custom tag called 'AllVulns' and reference it, along with its data, later in the template as follows:

{#vulnerabilities}{#title | store:’AllVulns’:this}{/}{/}
{#$storedAllVulns}
{priority} {title}
{/}

• {#vulnerabilities}{#title | store:’AllVulns’:this}{/}{/}

  • Loop through vulnerabilities.

  • Define a new custom tag called 'AllVulns'

  • Store the value of this in the new custom tag. In the context of {#vulnerabilities} - this will be equal to the vulnerability

• {#$storedAllVulns}

  • Loop through the new custom tag we created above called AllVulns

  • You must include #$stored prefix in order to use this new custom tag

• {priority} {title}

  • Print priority & title of vulnerability.

A more complex example includes how to create a custom tag that will hold all of the Critical Web Application vulnerabilities found on the project. This includes using ReportGen custom tags for affected_assets:

{#vulnerabilities}
{#priority == “Critical”}
{#affected_assets}
{#assetCustomTags}
{#Source == “Web”}
{#title | store:’CriticalWebVulns’:this:’affected_assets’:’assetCustomTags’:[‘Source:Web’]}


{/}
{/}
{/}
{/}
{/}
{/}
{#$storedCriticalWebVulns}
{priority} {title}
{/}

• {#vulnerabilities}

  • Loop through vulnerabilities.

• {#priority == “Critical”}

  • Check if vulnerability priority is equal to Critical, then proceed

  • This check is used to ascertain the vulnerability is a Critical vulnerability

• {#affected_assets}

  • Loop through affected assets on the vulnerability

• {#assetCustomTags}

  • Loop through custom ReportGen tags on the affected asset

• {#Source == "Web"}

  • Check if custom ReportGen tag has key/name "Source" and a value "Web"

  • This check is used to ascertain the vulnerability is a Web Application vulnerability

• {#title | store:’CriticalWebVulns’:this:’affected_assets’:’assetCustomTags’:[‘Source:Web’]}

  • Define a new custom tag called 'CriticalWebVulns'

  • Store the value of this which in this case is the vulnerability itself

  • Check if any of the custom affected asset tags contain any of the key/value pairs supplied, in this case ‘Source:Web’ – note this is an array, you can add more values, it is an OR operator

• {/} {/} {/} {/} {/} {/}

  • Close all of the open loops (see above)

• {#$storedCriticalWebVulns}

  • Loop through the new custom tag we created above called CriticalWebVulns. This custom tag now contains Critical vulnerabilities which have affected assets which have custom tags indicating they are web application vulnerabilities

  • You must include #$stored prefix in order to use this new custom tag

• {priority} {title}

  • Print priority & title of vulnerability.

Filter - Find

You can search a tag which contains an array of objects to return an object which meets a specific condition

{#vulnerabilities | find:"title":"Missing X-XSS-Protection Header"}
{title}
{/}

• {#vulnerabilities | find:"title":"Missing X-XSS-Protection Header"}

  • Loop through vulnerabilities and search each one until it finds a vulnerability with a title equal to Missing X-XSS-Protection Header, then return the vulnerability.

• {title}

  • Print title of vulnerability, in this case it would be "Missing X-XSS-Protection Header" as that is the vulnerability which was returned from the list of vulnerabilities.

Filter - FindVulns

You can use this filter to find a vulnerability based on a Title & Priority.

For example, if you wanted to create a report which shows all Assets on the project, and their Vulnerabilities (Asset to Vulnerability table or mapping) - you can achieve that using this filter. Note this requires using the store filter in combination with findVulns filter as follows:

{#vulnerabilities}{#title | store:’allVulns’:this}{/}{/}
{#assetVulnerabilityMapping}
{asset}
{#vulnerabilities}
{priority} - {status} - {vulnerability}
{#vulnerabilities | findVuln:’allVulns’:this.vulnerability:this.priority}
{description}

{attack_scenario}
{remediation_recommendation}

{/}{/}{/}

• {#vulnerabilities}{#title | store:’allVulns’:this}{/}{/}

  • Loop through vulnerabilities.

  • Define a new custom tag called 'allVulns'

  • Store the value of this which in this case is the vulnerability itself

• {#assetVulnerabilityMapping}

  • Loop through Asset-to-Vulnerability mapping

• {asset}

  • Print the name of the asset

• {#vulnerabilities}

  • Loop through vulnerabilities linked to the Asset

  • NOTE: This is different to {#vulnerabilities} referenced at line 1 above.

• {priority} - {status} - {vulnerability}

  • Print the priority, remediation status & name of the vulnerability

• {#vulnerabilities | findVuln:’allVulns’:this.vulnerability:this.priority}

  • Find the vulnerability (from list of all project vulnerabilities) where it matches the name/title & priority of the current vulnerability linked to the asset

• {description}

  • Print the description of the vulnerability linked to the asset

• {attack_scenario}

  • Print the attack scenario of the vulnerability linked to the asset

• {remediation_recommendation}

  • Print the remediation recommendation of the vulnerability linked to the asset

Filter - Unique

You can use a 'unique' filter to check if a value has already been printed in the report, and if so, it will skip printing it again.

{#vulnerabilities}
{#priority == “Critical”}
{#affected_assets}
{#assetCustomTags}
{#Source == “Internal”}
{#title | unique:'InternalVulnsTable'}
{title}
{/}{/}{/}{/}{/}{/}

• {#vulnerabilities}

  • Loop through vulnerabilities.

• {#priority == “Critical”}

  • Select vulnerabilities which have a priority of ‘Critical’.

• {#affected_assets}

  • Loop through Affected Assets for each Critical vulnerability.

• {#assetCustomTags}

  • Loop through Custom Tags for each Affected Asset for each Critical vulnerability.

• {#Source == “Internal”}

  • Check to see whether a Custom Tag ‘Source’ exists, and if so check to see if it’s value is “Internal”.

• {#title | unique:'InternalVulnsTable'}

  • This is a condition against the ‘title’ field for a vulnerability

  • This condition will check to see whether the value is unique (i.e. it hasn’t already been used/printed). This is useful to prevent printing duplicate values when looping through affected assets, for example vulnerability title.

  • This function works by taking 2 arguments – Key & Value. In the example above, Key = {title} e.g. Blind SQL Injection; and Value = ‘InternalVulnsTable’

  • This function will check to see if the Key/Value pair has already been printed in the report, and if so, it will skip printing it again – for example to avoid duplicating printing of vulnerability title for each affected asset in a table containing list of Internal Vulnerabilities.

• {title}

  • Print title of vulnerability.

Filter - Count

You can use a 'count' filter to set an arbitrary counter for a condition, then reference that counter later on.

{#vulnerabilities}
{#priority == “Critical”}
{#affected_assets}
{#assetCustomTags}
{#Source == “Internal”}
{#title | unique:'InternalVulnsTable' | count:'InternalVulnsTableCritical'}
{title}
{/}{/}{/}{/}{/}{/}
{#$countInternalVulnsTableCritical}
{$countInternalVulnsTableCritical}
{/}

• {#vulnerabilities}

  • Loop through vulnerabilities.

• {#priority == “Critical”}

  • Select vulnerabilities which have a priority of ‘Critical’.

• {#affected_assets}

  • Loop through Affected Assets for each Critical vulnerability.

• {#assetCustomTags}

  • Loop through Custom Tags for each Affected Asset for each Critical vulnerability.

• {#Source == “Internal”}

  • Check to see whether a Custom Tag ‘Source’ exists, and if so check to see if it’s value is “Internal”.

• {#title | unique:'InternalVulnsTable' | count:'InternalVulnsTableCritical'}

  • We are chaining together the 'unique' filter with the 'count' filter against the ‘title’ field for a vulnerability

  • For details on how the 'unique' filter works - see above.

  • Count filter works by taking 2 arguments – Key & Value. In the example above, Key = {title} e.g. Blind SQL Injection; and Value = ‘InternalVulnsTableCritical’

  • This function will count the number of times it is executed and store the result in a tag called $countVALUE where VALUE = ‘InternalVulnsTableCritical’

  • Because we are chaining this filter with another filter - in this case the 'unique' filter - the unique filter condition must be met first before this function executes and counter is incremented.

  • For example, if the dataset had 3 unique Critical vulnerabilities - $countInternalVulnsTableCritical will be equal to 3.

• {title}

  • Print title of vulnerability.

• {#$countInternalVulnsTableCritical}

  • Access the new dynamic tag '$countInternalVulnsTableCritical' created when we ran count:'InternalVulnsTableCritical'

• {$countInternalVulnsTableCritical}

  • Print the value of the counter for 'InternalVulnsTableCritical'

Filter - Uppercase

You can convert a tag to uppercase using the following filter:

{#title | upper}

Filter - Lowercase

You can convert a tag to lowercase using the following filter:

{#title | lower}

Data Aggregation

If your data is the following:

{
    "items": [
        {
            "name": "Acme Computer",
            "price": 1000,
        },
        {
            "name": "Mouse & Keyboard",
            "price": 150,
        }
    ],
}

And you would like to show the total price, you can use:

{#items}
{name} for a price of {price} €
{/}
Total Price of your purchase : {items | sumby:'price'}€

Data Formatting

This example is to format numbers in the format: “150.00” (2 digits of precision):

{
    "items": [
        {
            "name": "Acme Computer",
            "price": 1000,
        },
        {
            "name": "Mouse & Keyboard",
            "price": 150,
        }
    ],
}

And you would like to show the price with two digits of precision, you can write in your template :

{#items}
{name} for a price of {price | toFixed:2} €
{/}

Assignments

It is possible to assign a value to a variable directly from your template. For example, in your template, write:

{full_name = first_name + last_name}

The problem with this expression is that it will return the value of full_name. There are two ways to fix this issue, either if you still would like to keep this as the default behaviour, add ; ‘’ after your expression, for example

{full_name = first_name + last_name; ''}

This will first execute the expression, and then execute the second statement which is an empty string, and return it.

An other approach is to automatically silence the return values of expression containing variable assignments.

Individual Reports

IMPORTANT: To render an Individual Report - you must have the following tags in your template, with all the template data between these tags:

{#individualReport} ... {/individualReport}

IMPORTANT: If you would like to use tags in the HEADER or FOOTER - you must include the tags above BEFORE and AFTER e.g. {#individualReport}{someTagInHeader}{/individualReport}

Combined Reports

IMPORTANT: To render a Combined Report - you must have the following tags in your template, with all the template data between these tags:

{#combinedReport} ... {/combinedReport}

IMPORTANT: If you would like to use tags in the HEADER or FOOTER - you must include the tags above BEFORE and AFTER e.g. {#combinedReport}{someTagInHeader}{/combinedReport}

Available Tags for Individual Reports

• {#projectCustomTags} - you can define & use custom tags/fields in ReportGen. For more details check out Creating Custom Fields within Individual Reports​

• {projectName} - name of the project

• {projectCode} - project code

• {projectGroups} - details for each linked Group

  • {name} - name of the group

• {timestamp} - timestamp for when JSON report was downloaded

• {#statusUpdates} - details for each project status update e.g. when project goes on-hold or off-hold

  • {status} - e.g. 'On-Hold' or 'Off-Hold'

  • {note} - reason why project was on-hold or off-hold

  • {created} - timestamp when project went on-hold or off-hold

• {totalUniqueVulnerabilities} - total unique vulnerabilities on the project

• {totalCriticalVulnerabilities} - total unique critical vulnerabilities on the project

• {totalHighVulnerabilities} - total unique high vulnerabilities on the project

• {totalMediumVulnerabilities} - total unique medium vulnerabilities on the project

• {totalLowVulnerabilities} - total unique low vulnerabilities on the project

• {totalInfoVulnerabilities} - total unique informational vulnerabilities on the project

• {totalZeroDayVulnerabilities} - total unique zero-day vulnerabilities on the project

• {totalEasilyExploitableVulnerabilities} - total unique easily exploitable vulnerabilities on the project

• {totalTestcases} - total test cases assigned to the project

• {totalCompleted} - total completed test cases on the project

• {totalInProgress} - total in-progress test cases on the project

• {totalNotTested} - total not-tested test cases on the project

• {totalNotApplicable} - total not applicable test cases on the project

• {#execSummaryNotesHeading} - set a custom heading for the exec summary, auto disable if no exec summary on project

• {#execSummaryNotes} - executive summary notes on the project

  • {execSummaryNotes} - exec summary notes

  • {%inlineScreenshot} - display exec summary screenshots

• {startDate} - test window start date for the project

• {progress} - percentage of test cases actioned on the project

• {endDate} - test window start date for the project

• {totalVulns} - total vulnerabilities across all assets on the project

• {totalCriticalVulnsAllAssets} - total critical vulnerabilities across all assets on the project

• {totalHighVulnsAllAssets} - total high vulnerabilities across all assets on the project

• {totalMediumVulnsAllAssets} - total medium vulnerabilities across all assets on the project

• {totalLowVulnsAllAssets} - total low vulnerabilities across all assets on the project

• {totalInfoVulnsAllAssets} - total informational vulnerabilities across all assets on the project

• {totalFixedVulns} - total fixed/closed vulnerabilities across all assets on the project

• {totalRetestingVulns} - total vulnerabilities flagged as retesting across all assets on the project

• {totalNotFixedVulns} - total not fixed/open vulnerabilities across all assets on the project

• {#assets} - list of all assets on the project

  • {.} - name of each asset

• {#projectTeam} - list of all project team members

  • {.} - name of each project team member

• {#retestingHistory} - list of all rounds of retesting requested & completed on the project

  • {retesting_round} - e.g. 1, 2, 3, etc.

  • {retesting_round_status} - whether the retest round was Requested or Completed

  • {retesting_custom_round_name} - custom round name (optional)

  • {retesting_custom_status_name} - custom status name (optional)

  • {retesting_round_actioned_by} - name of person who requested or completed the round of retesting

  • {created} - date when round of retest was requested or completed

  • {#vulnerabilities} - list of all vulnerabilities requested / completed on the round of retesting

    • {vulnerability} - name of the vulnerability

    • {vulnerability_alternate_id} - user-friendly id associated with the vulnerability, set via project settings

    • {#vulnerability_details}

      • {#vulnerabilityCustomTags} - you can define & use custom tags/fields in ReportGen. For more details check out Creating Custom Fields within ReportGen Reports​

      • {title} - title of the vulnerability

      • {priority} - priority of the vulnerability e.g. Critical, High, Medium, Low, Info

      • {remediation_status} - either Open or Closed. Only Closed if all affected assets are also Closed.

      • {description} - description of the vulnerability

      • {attack_scenario} - attack scenario for the vulnerability

      • {remediation_recommendation} - remediation recommendation for the vulnerability

      • {cvssv3_vector} - includes the CVSS v3.1 vector string e.g. /AV/...

      • {cvssv3_base_score} - includes the CVSS v3.1 base score e.g. 10.0

      • {cvssv3_temporal_score} - includes the CVSS v3.1 temporal score e.g. 10.0

      • {cvssv3_environmental_score} - includes the CVSS v3.1 environmental score e.g. 10.0

      • {testcases} - list of all the linked test cases to the vulnerability

      • {#tags} - list of all tags

        • {.} - tag

      • {#affected_asset} - details for the affected asset - see {#assetVulnerabilityMapping} - {asset}

        • {#assetCustomTags} - you can define & use custom tags/fields in ReportGen. For more details check out Creating Custom Fields within Individual Reports​

        • {alternate_id} - user-friendly id associated with the vulnerability, set via project settings

        • {asset} - asset name

        • {remediation_status} - includes the remediation status of the vulnerability for the affected asset e.g. Open / Ready for Retest on <DATE> / Closed on <DATE>

        • {#remediation_notes} - list of all remediation notes for this affected asset

          • {created} - date stamp when remediation note was created

          • {note} - remediation note details

        • {#notes} - list of all notes for this affected asset

          • {note} - note details

          • {%inlineScreenshot} - display inline images where they are included in the note

        • {#proof_of_concept} - details for proof of concept / steps to reproduce

          • {text} - proof of concept / steps to reproduce

          • {%inlineScreenshot} - display inline images where they are included in the note

        • {#proof_of_concept_raw} - details for proof of concept / steps to reproduce in RAW HTML format (verbatim).

        • {#assets_equally_affected_title} - in order to cut-down report size, de-duplication is performed for each asset where #notes and #proof_of_concept are the same. This tag is used to display the heading for this section e.g. LIST OF ASSETS EQUALLY AFFECTED

        • {#assets_equally_affected} - in order to cut-down report size, de-duplication is performed for each asset where #notes and #proof_of_concept are the same. This tag is used to display the names of all the assets which have the same POC & Notes as the vulnerability above.

          • {.} - asset name

      • {#affected_assets} - list of all affected assets for this vulnerability

        • {#assetCustomTags} - you can define & use custom tags/fields in ReportGen. For more details check out Creating Custom Fields within Individual Reports​

        • {asset} - asset name

        • {remediation_status} - includes the remediation status of the vulnerability for the affected asset e.g. Open / Ready for Retest on <DATE> / Closed on <DATE>

        • {#remediation_notes} - list of all remediation notes for this affected asset

          • {created} - date stamp when remediation note was created

          • {note} - remediation note details

        • {#notes} - list of all notes for this affected asset

          • {note} - note details

          • {%inlineScreenshot} - display inline images where they are included in the note

        • {#proof_of_concept} - details for proof of concept / steps to reproduce

          • {text} - proof of concept / steps to reproduce

          • {%inlineScreenshot} - display inline images where they are included in the note

        • {#proof_of_concept_raw} - details for proof of concept / steps to reproduce in RAW HTML format (verbatim).

        • {#assets_equally_affected_title} - in order to cut-down report size, de-duplication is performed for each asset where #notes and #proof_of_concept are the same. This tag is used to display the heading for this section e.g. LIST OF ASSETS EQUALLY AFFECTED

        • {#assets_equally_affected} - in order to cut-down report size, de-duplication is performed for each asset where #notes and #proof_of_concept are the same. This tag is used to display the names of all the assets which have the same POC & Notes as the vulnerability above.

          • {.} - asset name

      • {#evidence} - list of all evidence files uploaded to the vulnerabilities for each affected asset. De-duplication is performed to remove images which have already been displayed in the in-line screenshots

        • {%fileBase64} - display image (if evidence type is of image format)

        • {fileName} - name of the file uploaded

        • {caption} - caption for the file (optional)

  • {#vulnerabilitiesNotTested} - list of all vulnerabilities not retested on the round of retesting

    • {vulnerability} - name of the vulnerability

    • {vulnerability_alternate_id} - user-friendly id associated with the vulnerability, set via project settings

    • {#vulnerability_details}

      • {#vulnerabilityCustomTags} - you can define & use custom tags/fields in ReportGen. For more details check out Creating Custom Fields within ReportGen Reports​

      • {title} - title of the vulnerability

      • {priority} - priority of the vulnerability e.g. Critical, High, Medium, Low, Info

      • {remediation_status} - either Open or Closed. Only Closed if all affected assets are also Closed.

      • {description} - description of the vulnerability

      • {attack_scenario} - attack scenario for the vulnerability

      • {remediation_recommendation} - remediation recommendation for the vulnerability

      • {cvssv3_vector} - includes the CVSS v3.1 vector string e.g. /AV/...

      • {cvssv3_base_score} - includes the CVSS v3.1 base score e.g. 10.0

      • {cvssv3_temporal_score} - includes the CVSS v3.1 temporal score e.g. 10.0

      • {cvssv3_environmental_score} - includes the CVSS v3.1 environmental score e.g. 10.0

      • {testcases} - list of all the linked test cases to the vulnerability

      • {#tags} - list of all tags

        • {.} - tag

      • {#affected_asset} - details for the affected asset - see {#assetVulnerabilityMapping} - {asset}

        • {#assetCustomTags} - you can define & use custom tags/fields in ReportGen. For more details check out Creating Custom Fields within Individual Reports​

        • {alternate_id} - user-friendly id associated with the vulnerability, set via project settings

        • {asset} - asset name

        • {remediation_status} - includes the remediation status of the vulnerability for the affected asset e.g. Open / Ready for Retest on <DATE> / Closed on <DATE>

        • {#remediation_notes} - list of all remediation notes for this affected asset

          • {created} - date stamp when remediation note was created

          • {note} - remediation note details

        • {#notes} - list of all notes for this affected asset

          • {note} - note details

          • {%inlineScreenshot} - display inline images where they are included in the note

        • {#proof_of_concept} - details for proof of concept / steps to reproduce

          • {text} - proof of concept / steps to reproduce

          • {%inlineScreenshot} - display inline images where they are included in the note

        • {#proof_of_concept_raw} - details for proof of concept / steps to reproduce in RAW HTML format (verbatim).

        • {#assets_equally_affected_title} - in order to cut-down report size, de-duplication is performed for each asset where #notes and #proof_of_concept are the same. This tag is used to display the heading for this section e.g. LIST OF ASSETS EQUALLY AFFECTED

        • {#assets_equally_affected} - in order to cut-down report size, de-duplication is performed for each asset where #notes and #proof_of_concept are the same. This tag is used to display the names of all the assets which have the same POC & Notes as the vulnerability above.

          • {.} - asset name

      • {#affected_assets} - list of all affected assets for this vulnerability

        • {#assetCustomTags} - you can define & use custom tags/fields in ReportGen. For more details check out Creating Custom Fields within Individual Reports​

        • {asset} - asset name

        • {remediation_status} - includes the remediation status of the vulnerability for the affected asset e.g. Open / Ready for Retest on <DATE> / Closed on <DATE>

        • {#remediation_notes} - list of all remediation notes for this affected asset

          • {created} - date stamp when remediation note was created

          • {note} - remediation note details

        • {#notes} - list of all notes for this affected asset

          • {note} - note details

          • {%inlineScreenshot} - display inline images where they are included in the note

        • {#proof_of_concept} - details for proof of concept / steps to reproduce

          • {text} - proof of concept / steps to reproduce

          • {%inlineScreenshot} - display inline images where they are included in the note

        • {#proof_of_concept_raw} - details for proof of concept / steps to reproduce in RAW HTML format (verbatim).

        • {#assets_equally_affected_title} - in order to cut-down report size, de-duplication is performed for each asset where #notes and #proof_of_concept are the same. This tag is used to display the heading for this section e.g. LIST OF ASSETS EQUALLY AFFECTED

        • {#assets_equally_affected} - in order to cut-down report size, de-duplication is performed for each asset where #notes and #proof_of_concept are the same. This tag is used to display the names of all the assets which have the same POC & Notes as the vulnerability above.

          • {.} - asset name

      • {#evidence} - list of all evidence files uploaded to the vulnerabilities for each affected asset. De-duplication is performed to remove images which have already been displayed in the in-line screenshots

        • {%fileBase64} - display image (if evidence type is of image format)

        • {fileName} - name of the file uploaded

        • {caption} - caption for the file (optional)

• {#projectNotes} - list of all exportable project notes

  • {modified} - contains date when note was last created or last updated

  • {note} - contains note

• {#criticalVulns} - list of all critical vulnerabilities & statistics for affected assets. You can also use {#highVulns}; {#mediumVulns}; {#lowVulns}; and {#infoVulns} to access details for vulnerabilities in each of the priority categories.

  • {retest_status} - contains status whether vulnerability is Fixed or Not Fixed. A vulnerability is only considered Fixed if ALL affected assets are also fixed/closed.

  • {title} - title of the vulnerability

  • {total_affected_assets} - total number of affected assets

  • {total_affected_assets_fixed} - total number of affected assets which are fixed / closed

  • {total_affected_assets_retesting} - total number of affected assets which are flagged for retesting

  • {total_affected_assets_not_fixed} - total number of affected assets which not fixed / open

• {#attackchains} - list of all attack chains on the project

  • {title} - attack objective

  • {#links} - contains details for all links in the chain

    • {%icon} - icon displayed for the link in the chain

    • {type} - type of link e.g. Action, Vulnerability, Flag etc.

    • {description} - details for the link in the chain

    • {discovered} - details for when the vulnerability was discovered and by whom

• {#vulnerabilities} - list of all the vulnerabilities on the project. You can also use {#criticalVulnerabilities}; {#highVulnerabilities}; {#mediumVulnerabilities}; {#lowVulnerabilities}; and {#infoVulnerabilities} to access details for vulnerabilities in each of the priority categories.

  • {#vulnerabilityCustomTags} - you can define & use custom tags/fields in ReportGen. For more details check out Creating Custom Fields within Individual Reports​

  • {title} - title of the vulnerability

  • {priority} - priority of the vulnerability e.g. Critical, High, Medium, Low, Info

  • {remediation_status} - either Open or Closed. Only Closed if all affected assets are also Closed.

  • {description} - description of the vulnerability

  • {attack_scenario} - attack scenario for the vulnerability

  • {remediation_recommendation} - remediation recommendation for the vulnerability

  • {cvssv3_vector} - includes the CVSS v3.1 vector string e.g. /AV/...

  • {cvssv3_base_score} - includes the CVSS v3.1 base score e.g. 10.0

  • {cvssv3_temporal_score} - includes the CVSS v3.1 temporal score e.g. 10.0

  • {cvssv3_environmental_score} - includes the CVSS v3.1 environmental score e.g. 10.0

  • {testcases} - list of all the test cases linked to the vulnerability

  • {#tags} - list of all tags

    • {.} - tag

  • {#affected_assets} - list of all affected assets for this vulnerability

    • {#assetCustomTags} - you can define & use custom tags/fields in ReportGen. For more details check out Creating Custom Fields within Individual Reports​

    • {alternate_id} - user-friendly id associated with the vulnerability, set via project settings

    • {asset} - asset name

    • {asset_library_created} - timestamp when asset was added to Assets module library. NOTE: requires tenant configuration with Assets module enabled.

    • {asset_library_id} - Assets module library id. NOTE: requires tenant configuration with Assets module enabled.

    • {asset_external_id} - user-defined external id for the asset. NOTE: requires tenant configuration with Assets module enabled.

    • {asset_type} - asset type e.g. Web App, API, Network, etc. NOTE: requires tenant configuration with Assets module enabled.

    • {asset_details} - asset details. NOTE: requires tenant configuration with Assets module enabled.

    • {remediation_status} - includes the remediation status of the vulnerability for the affected asset e.g. Open / Ready for Retest on <DATE> / Closed on <DATE>

    • {#remediation_notes} - list of all remediation notes for this affected asset

      • {created} - date stamp when remediation note was created

      • {note} - remediation note details

    • {#notes} - list of all notes for this affected asset

      • {note} - note details

      • {%inlineScreenshot} - display inline images where they are included in the note

    • {#proof_of_concept} - details for proof of concept / steps to reproduce

      • {text} - proof of concept / steps to reproduce

      • {%inlineScreenshot} - display inline images where they are included in the note

    • {#proof_of_concept_raw} - details for proof of concept / steps to reproduce in RAW HTML format (verbatim).

    • {#assets_equally_affected_title} - in order to cut-down report size, de-duplication is performed for each asset where #notes and #proof_of_concept are the same. This tag is used to display the heading for this section e.g. LIST OF ASSETS EQUALLY AFFECTED

    • {#assets_equally_affected} - in order to cut-down report size, de-duplication is performed for each asset where #notes and #proof_of_concept are the same. This tag is used to display the names of all the assets which have the same POC & Notes as the vulnerability above.

      • {.} - asset name

  • {#evidence} - list of all evidence files uploaded to the vulnerabilities for each affected asset. De-duplication is performed to remove images which have already been displayed in the in-line screenshots

    • {%fileBase64} - display image (if evidence type is of image format)

    • {fileName} - name of the file uploaded

    • {caption} - caption for the file (optional)

• {#completedTestcases} - list of all completed test cases on the project. You can also access {#inProgressTestcases}; {#notTestedTestcases}; {#notApplicableTestcases}; {#passedTestcases}; {#failedTestcases}; {#remediatedTestcases} and {#abuseCases} to get details on test cases and their linked vulnerabilities.

  • {is_failed} - default is No. If at least one vulnerability is linked to the test case, value will be Yes.

  • {is_remediated} - default is Not Applicable. If at least one vulnerability is linked to the test case and is Open, value will be No. If all vulnerabilities linked to the test case are Closed, value will be Yes.

  • {remediation_status} - default is Passed. If at least one vulnerability is linked to the test case and is Open, value will be Failed. If all vulnerabilities linked to the test case are Closed, value will be Remediated.

  • {tags} - list of all tags presented as a string

  • {title} - test case details

  • {modified} - date stamp when test case was created or last modified

  • {modifiedBy} - user that created or last last modified the test case

  • {testcase_code} - code assigned to the test case.

  • {testsuite_name} - name of the associated test suite.

  • {testsuite_code} - code of the associated test suite.

  • {#notes} - list of all notes assigned to the test case

    • {modified} - date stamp when notes was created or last modified

    • {modifiedBy} - user that created or last modified the note

    • {note} - note details

  • {#evidence} - list of all evidence uploaded to the test case

    • {fileName} - name of the file for the evidence uploaded

    • {%fileBase64} - display image (if evidence type is of image format)

  • {#linked_vulnerabilities}

    • {#vulnerabilityCustomTags} - you can define & use custom tags/fields in ReportGen. For more details check out Creating Custom Fields within Individual Reports​

    • {title} - title of the vulnerability

    • {priority} - priority of the vulnerability e.g. Critical, High, Medium, Low, Info

    • {remediation_status} - either Open or Closed. Only Closed if all affected assets are also Closed.

    • {description} - description of the vulnerability

    • {attack_scenario} - attack scenario for the vulnerability

    • {remediation_recommendation} - remediation recommendation for the vulnerability

    • {cvssv3_vector} - includes the CVSS v3.1 vector string e.g. /AV/...

    • {cvssv3_base_score} - includes the CVSS v3.1 base score e.g. 10.0

    • {cvssv3_temporal_score} - includes the CVSS v3.1 temporal score e.g. 10.0

    • {cvssv3_environmental_score} - includes the CVSS v3.1 environmental score e.g. 10.0

    • {testcases} - list of all the linked test cases to the vulnerability

    • {#tags} - list of all tags

      • {.} - tag

    • {#affected_assets} - list of all affected assets for this vulnerability

      • {#assetCustomTags} - you can define & use custom tags/fields in ReportGen. For more details check out Creating Custom Fields within Individual Reports​

      • {alternate_id} - user-friendly id associated with the vulnerability, set via project settings

      • {asset} - asset name

      • {asset_library_created} - timestamp when asset was added to Assets module library. NOTE: requires tenant configuration with Assets module enabled.

      • {asset_library_id} - Assets module library id. NOTE: requires tenant configuration with Assets module enabled.

      • {asset_external_id} - user-defined external id for the asset. NOTE: requires tenant configuration with Assets module enabled.

      • {asset_type} - asset type e.g. Web App, API, Network, etc. NOTE: requires tenant configuration with Assets module enabled.

      • {asset_details} - asset details. NOTE: requires tenant configuration with Assets module enabled.

      • {remediation_status} - includes the remediation status of the vulnerability for the affected asset e.g. Open / Ready for Retest on <DATE> / Closed on <DATE>

      • {#remediation_notes} - list of all remediation notes for this affected asset

        • {created} - date stamp when remediation note was created

        • {note} - remediation note details

      • {#notes} - list of all notes for this affected asset

        • {note} - note details

        • {%inlineScreenshot} - display inline images where they are included in the note

      • {#proof_of_concept} - details for proof of concept / steps to reproduce

        • {text} - proof of concept / steps to reproduce

        • {%inlineScreenshot} - display inline images where they are included in the note

      • {#proof_of_concept_raw} - details for proof of concept / steps to reproduce in RAW HTML format (verbatim).

      • {#assets_equally_affected_title} - in order to cut-down report size, de-duplication is performed for each asset where #notes and #proof_of_concept are the same. This tag is used to display the heading for this section e.g. LIST OF ASSETS EQUALLY AFFECTED

      • {#assets_equally_affected} - in order to cut-down report size, de-duplication is performed for each asset where #notes and #proof_of_concept are the same. This tag is used to display the names of all the assets which have the same POC & Notes as the vulnerability above.

        • {.} - asset name

    • {#evidence} - list of all evidence files uploaded to the vulnerabilities for each affected asset. De-duplication is performed to remove images which have already been displayed in the in-line screenshots

      • {%fileBase64} - display image (if evidence type is of image format)

      • {fileName} - name of the file uploaded

      • {caption} - caption for the file (optional)

• {#vulnerabilityAssetMapping} - list of all vulnerabilities mapped to their affected assets

  • {priority} - priority of the vulnerability e.g. Critical, High, Medium, Low, Info

  • {vulnerability} - vulnerability title

  • {#assets} - list of all affected assets

    • {status} - remediation status e.g. Fixed / Not Fixed

    • {asset} - asset name

• {#assetVulnerabilityMapping} - list of all assets on the project mapped to their vulnerabilities

  • {asset} - asset name

  • {#vulnerabilities} - list of all vulnerabilities the asset is affected by

    • {vulnerability} - vulnerability title

    • {priority} - priority of the vulnerability e.g. Critical, High, Medium, Low, Info

    • {status} - remediation status e.g. Fixed / Not Fixed

    • {#vulnerabilityDetails}

      • {#vulnerabilityCustomTags} - you can define & use custom tags/fields in ReportGen. For more details check out Creating Custom Fields within ReportGen Reports​

      • {title} - title of the vulnerability

      • {priority} - priority of the vulnerability e.g. Critical, High, Medium, Low, Info

      • {remediation_status} - either Open or Closed. Only Closed if all affected assets are also Closed.

      • {description} - description of the vulnerability

      • {attack_scenario} - attack scenario for the vulnerability

      • {remediation_recommendation} - remediation recommendation for the vulnerability

      • {cvssv3_vector} - includes the CVSS v3.1 vector string e.g. /AV/...

      • {cvssv3_base_score} - includes the CVSS v3.1 base score e.g. 10.0

      • {cvssv3_temporal_score} - includes the CVSS v3.1 temporal score e.g. 10.0

      • {cvssv3_environmental_score} - includes the CVSS v3.1 environmental score e.g. 10.0

      • {testcases} - list of all the linked test cases to the vulnerability

      • {#tags} - list of all tags

        • {.} - tag

      • {#affected_asset} - details for the affected asset - see {#assetVulnerabilityMapping} - {asset}

        • {#assetCustomTags} - you can define & use custom tags/fields in ReportGen. For more details check out Creating Custom Fields within Individual Reports​

        • {alternate_id} - user-friendly id associated with the vulnerability, set via project settings

        • {asset} - asset name

        • {remediation_status} - includes the remediation status of the vulnerability for the affected asset e.g. Open / Ready for Retest on <DATE> / Closed on <DATE>

        • {#remediation_notes} - list of all remediation notes for this affected asset

          • {created} - date stamp when remediation note was created

          • {note} - remediation note details

        • {#notes} - list of all notes for this affected asset

          • {note} - note details

          • {%inlineScreenshot} - display inline images where they are included in the note

        • {#proof_of_concept} - details for proof of concept / steps to reproduce

          • {text} - proof of concept / steps to reproduce

          • {%inlineScreenshot} - display inline images where they are included in the note

        • {#proof_of_concept_raw} - details for proof of concept / steps to reproduce in RAW HTML format (verbatim).

        • {#assets_equally_affected_title} - in order to cut-down report size, de-duplication is performed for each asset where #notes and #proof_of_concept are the same. This tag is used to display the heading for this section e.g. LIST OF ASSETS EQUALLY AFFECTED

        • {#assets_equally_affected} - in order to cut-down report size, de-duplication is performed for each asset where #notes and #proof_of_concept are the same. This tag is used to display the names of all the assets which have the same POC & Notes as the vulnerability above.

          • {.} - asset name

      • {#affected_assets} - list of all affected assets for this vulnerability

        • {#assetCustomTags} - you can define & use custom tags/fields in ReportGen. For more details check out Creating Custom Fields within Individual Reports​

        • {asset} - asset name

        • {remediation_status} - includes the remediation status of the vulnerability for the affected asset e.g. Open / Ready for Retest on <DATE> / Closed on <DATE>

        • {#remediation_notes} - list of all remediation notes for this affected asset

          • {created} - date stamp when remediation note was created

          • {note} - remediation note details

        • {#notes} - list of all notes for this affected asset

          • {note} - note details

          • {%inlineScreenshot} - display inline images where they are included in the note

        • {#proof_of_concept} - details for proof of concept / steps to reproduce

          • {text} - proof of concept / steps to reproduce

          • {%inlineScreenshot} - display inline images where they are included in the note

        • {#proof_of_concept_raw} - details for proof of concept / steps to reproduce in RAW HTML format (verbatim).

        • {#assets_equally_affected_title} - in order to cut-down report size, de-duplication is performed for each asset where #notes and #proof_of_concept are the same. This tag is used to display the heading for this section e.g. LIST OF ASSETS EQUALLY AFFECTED

        • {#assets_equally_affected} - in order to cut-down report size, de-duplication is performed for each asset where #notes and #proof_of_concept are the same. This tag is used to display the names of all the assets which have the same POC & Notes as the vulnerability above.

          • {.} - asset name

      • {#evidence} - list of all evidence files uploaded to the vulnerabilities for each affected asset. De-duplication is performed to remove images which have already been displayed in the in-line screenshots

        • {%fileBase64} - display image (if evidence type is of image format)

        • {fileName} - name of the file uploaded

        • {caption} - caption for the file (optional)

Creating Custom Fields within Individual Reports

AttackForge ReportGen lets you define your own custom fields/tags which can be referenced anywhere within your report templates.

Custom fields can be used to capture additional information for projects, vulnerabilities and affected assets. This could include metadata, scoring, client information, or simply used for logically separating data within your reports - for example you can create a template to show just PCI-DSS vulnerabilities, or External vulnerabilities, etc.

Custom fields/tags can be set at three (3) different levels:

• Project-Level

• Vulnerability-Level (in library)

• Affected Asset-level (vulnerability on project)

Project-Level Custom Fields

1. From page menu, click on ReportGen Custom Tags. You must have Edit permissions to the project.

2. Create custom fields/tags. Do not put any spaces in the Name field.

3. Update your ReportGen DOCX template file to reference the custom tags. You can access the tags using following syntax from the root/project level in the report:

{#projectCustomTags} {#ClientName} {ClientName} {/} {/}

where {ClientName} represents the value of this field.

You can also use Conditions, Loops, Filters, Data Aggregation, Data Formatting, & Assignments. Click here for more details.

4. Generate report and observe the custom tags are now referenced in your template.

Vulnerability-Level (Library) Custom Fields

You can define & create custom vulnerability-level fields which can be referenced in your template within the following sections:

• {#vulnerabilities}

• {#criticalVulnerabilities}

• {#highVulnerabilities}

• {#mediumVulnerabilities}

• {#lowVulnerabilities}

• {#infoVulnerabilities}

• {#completedTestcases} --> {#linked_vulnerabilities}

• {#inProgressTestcases} --> {#linked_vulnerabilities}

• {#notTestedTestcases} --> {#linked_vulnerabilities}

• {#notApplicableTestcases} --> {#linked_vulnerabilities}

• {#passedTestcases} --> {#linked_vulnerabilities}

• {#failedTestcases} --> {#linked_vulnerabilities}

• {#remediatedTestcases} --> {#linked_vulnerabilities}

• {#abuseCases} --> {#linked_vulnerabilities}

1. Open your Vulnerability Library. Create a new entry, or Edit an existing entry.

2. Create custom fields/tags. Do not put any spaces in the Name field.

3. Update your ReportGen DOCX template file to reference the custom tags.

{#vulnerabilities} {#vulnerabilityCustomTags} {#TLS_weakness == "True" || PCI-related == "True"} {priority} - {title} {description} {/} {/} {/}

where {priority}{title}{description} represents the vulnerability details.

The above code works as follows:

• Loop through list of all vulnerabilities {#vulnerabilities}

• Loop through list of all custom fields/tags if present {#vulnerabilityCustomTags}

• Check to see if the tag 'TLS_weakness' exists and has a value of 'True'; or check to see if the tag 'PCI-related' exists and has a value of 'True'.

• If the above condition is met, print the {priority}{title}{description} for the current vulnerability.

You can also use Conditions, Loops, Filters, Data Aggregation, Data Formatting, & Assignments. Click here for more details.

4. Generate report and observe the custom tags are now referenced in your template.

Affected Asset-Level (Project) Custom Fields

You can define & create custom vulnerability-level fields which can be referenced in your template within the following sections:

• {#vulnerabilities} --> {#affected_assets}

• {#criticalVulnerabilities --> {#affected_assets}

• {#highVulnerabilities} --> {#affected_assets}

• {#mediumVulnerabilities} --> {#affected_assets}

• {#lowVulnerabilities} --> {#affected_assets}

• {#infoVulnerabilities} --> {#affected_assets}

• {#completedTestcases} --> {#linked_vulnerabilities} --> {#affected_assets}

• {#inProgressTestcases} --> {#linked_vulnerabilities} --> {#affected_assets}

• {#notTestedTestcases} --> {#linked_vulnerabilities} --> {#affected_assets}

• {#notApplicableTestcases} --> {#linked_vulnerabilities} --> {#affected_assets}

• {#passedTestcases} --> {#linked_vulnerabilities} --> {#affected_assets}

• {#failedTestcases} --> {#linked_vulnerabilities} --> {#affected_assets}

• {#remediatedTestcases} --> {#linked_vulnerabilities} --> {#affected_assets}

• {#abuseCases} --> {#linked_vulnerabilities} --> {#affected_assets}

1. Create a new vulnerability or Edit an existing vulnerability on your project.

2. Create custom fields/tags. Do not put any spaces in the Name field.

3. Update your ReportGen DOCX template file to reference the custom tags.

{#vulnerabilities} {#affected_assets} {#assetCustomTags} {#Discovered == "External Testing"} {#assetCustomTags} {#Application == "True"} {asset} - {title} {/} {/} {/} {/} {/} {/}

where {asset}{title} represents the affected asset name and title of the vulnerability.

The above code works as follows:

• Loop through list of all vulnerabilities {#vulnerabilities}

• Loop through list of affected assets for each vulnerability {#affected_assets}

• Loop through list of all custom fields/tags if present {#assetCustomTags}

• Check to see if the tag 'Discovered' exists and has a value of 'External Testing'

• If the above condition is true - loop through the list of all custom fields/tags and check to see if the tag 'Application' exists and has a value of 'True'. If both conditions are met print the asset name {asset} and vulnerability title {title}.

• If the above condition is false - stop & move onto the next asset

You can also use Conditions, Loops, Filters, Data Aggregation, Data Formatting, & Assignments. Click here for more details.

4. Generate report and observe the custom tags are now referenced in your template.

Available Tags for Combined Reports

• {#projectName} - list of all projects combined in the report

  • {.} - name of the project

• {#projectCode} - list of all project codes for all projects combined in the report

  • {.} - project code

• {timestamp} - timestamp for when this report was created

• {totalUniqueVulnerabilities} - total unique vulnerabilities across all projects

• {totalCriticalVulnerabilities} - total unique critical vulnerabilities across all projects

• {totalHighVulnerabilities} - total unique high vulnerabilities across all projects

• {totalMediumVulnerabilities} - total unique medium vulnerabilities across all projects

• {totalLowVulnerabilities} - total unique low vulnerabilities across all projects

• {totalInfoVulnerabilities} - total unique informational vulnerabilities across all projects

• {totalZeroDayVulnerabilities} - total unique zero-day vulnerabilities across all projects

• {totalEasilyExploitableVulnerabilities} - total unique easily exploitable vulnerabilities across all projects

• {#execSummaryNotes} - list of all executive summary's across all projects

  • {project} - name of the project

  • {notes} - executive summary notes on the project

• {#testWindow} - list of all test windows and progress across all projects

  • {project} - name of the project

  • {startDate} - test window start date for the project

  • {progress} - percentage of test cases actioned on the project

  • {endDate} - test window start date for the project

• {totalVulns} - total vulnerabilities across all assets across all projects

• {totalCriticalVulnsAllAssets} - total critical vulnerabilities across all assets across all projects

• {totalHighVulnsAllAssets} - total high vulnerabilities across all assets across all projects

• {totalMediumVulnsAllAssets} - total medium vulnerabilities across all assets across all projects

• {totalLowVulnsAllAssets} - total low vulnerabilities across all assets across all projects

• {totalInfoVulnsAllAssets} - total informational vulnerabilities across all assets across all projects

• {#assets} - list of all assets on the project

  • {name} - name of each asset

  • {project} - name of the project

• {#projectTeam} - list of all project team members

  • {name} - name of each project team member

  • {project} - name of the project

• {#retestingHistory} - list of all rounds of retesting requested & completed on the project

  • {retesting_round_status} - whether the retest round was Requested or Completed

  • {retesting_round_actioned_by} - name of person who requested or completed the round of retesting

  • {created} - date when round of retest was requested or completed

  • {project} - name of the project

  • {#vulnerabilities} - list of all vulnerabilities requested / completed on the round of retesting

    • {vulnerability} - contains name of the vulnerability

• {#projectNotes} - list of all exportable project notes

  • {project} - name of the project

  • {modified} - contains date when note was last created or last updated

  • {note} - contains note

• {#criticalVulns} - list of all critical vulnerabilities & statistics for affected assets across all projects

  • {retest_status} - contains status whether vulnerability is Fixed or Not Fixed. A vulnerability is only considered Fixed if ALL affected assets are also fixed/closed.

  • {title} - title of the vulnerability

  • {total_affected_assets} - total number of affected assets

• {#highVulns} - list of all high vulnerabilities & statistics for affected assets across all projects

  • {retest_status} - contains status whether vulnerability is Fixed or Not Fixed. A vulnerability is only considered Fixed if ALL affected assets are also fixed/closed.

  • {title} - title of the vulnerability

  • {total_affected_assets} - total number of affected assets

• {#mediumVulns} - list of all medium vulnerabilities & statistics for affected assets across all projects

  • {retest_status} - contains status whether vulnerability is Fixed or Not Fixed. A vulnerability is only considered Fixed if ALL affected assets are also fixed/closed.

  • {title} - title of the vulnerability

  • {total_affected_assets} - total number of affected assets

• {#lowVulns} - list of all low vulnerabilities & statistics for affected assets across all projects

  • {retest_status} - contains status whether vulnerability is Fixed or Not Fixed. A vulnerability is only considered Fixed if ALL affected assets are also fixed/closed.

  • {title} - title of the vulnerability

  • {total_affected_assets} - total number of affected assets

• {#infoVulns} - list of all critical vulnerabilities & statistics for affected assets across all projects

  • {retest_status} - contains status whether vulnerability is Fixed or Not Fixed. A vulnerability is only considered Fixed if ALL affected assets are also fixed/closed.

  • {title} - title of the vulnerability

  • {total_affected_assets} - total number of affected assets

• {#attackchains} - list of all attack chains across all projects

  • {title} - attack objective

  • {#links} - contains details for all links in the chain

    • {%icon} - icon displayed for the link in the chain

    • {type} - type of link e.g. Action, Vulnerability, Flag etc.

    • {description} - details for the link in the chain

    • {discovered} - details for when the vulnerability was discovered and by whom

• {#vulnerabilities} - list of all the vulnerabilities across all projects

  • {title} - title of the vulnerability

  • {priority} - priority of the vulnerability e.g. Critical, High, Medium, Low, Info

  • {remediation_status} - either Open or Closed. Only Closed if all affected assets are also Closed.

  • {description} - description of the vulnerability

  • {attack_scenario} - attack scenario for the vulnerability

  • {remediation_recommendation} - remediation recommendation for the vulnerability

  • {cvssv3_vector} - includes the CVSS v3.1 vector string e.g. /AV/...

  • {cvssv3_base_score} - includes the CVSS v3.1 base score e.g. 10.0 {cvssv3_temporal_score} - includes the CVSS v3.1 temporal score e.g. 10.0

  • {cvssv3_environmental_score} - includes the CVSS v3.1 environmental score e.g. 10.0

  • {#tags} - list of all tags

    • {.} - tag

  • {#affected_assets} - list of all affected assets for this vulnerability

    • {asset} - asset name

    • {remediation_status} - includes the remediation status of the vulnerability for the affected asset e.g. Open or Closed on <DATE>

    • {#remediation_notes} - list of all remediation notes for this affected asset

      • {created} - date stamp when remediation note was created

      • {note} - remediation note details

    • {#notes} - list of all notes for this affected asset

      • {note} - note details

      • {%inlineScreenshot} - display inline images where they are included in the note

    • {#proof_of_concept} - details for proof of concept / steps to reproduce

      • {text} - proof of concept / steps to reproduce

      • {%inlineScreenshot} - display inline images where they are included in the note

    • {#proof_of_concept_raw} - details for proof of concept / steps to reproduce in RAW HTML format (verbatim).

    • {#assets_equally_affected_title} - in order to cut-down report size, de-duplication is performed for each asset where #notes and #proof_of_concept are the same. This tag is used to display the heading for this section e.g. LIST OF ASSETS EQUALLY AFFECTED

    • {#assets_equally_affected} - in order to cut-down report size, de-duplication is performed for each asset where #notes and #proof_of_concept are the same. This tag is used to display the names of all the assets which have the same POC & Notes as the vulnerability above.

      • {.} - asset name

  • {#evidence} - list of all evidence files uploaded to the vulnerabilities for each affected asset. De-duplication is performed to remove images which have already been displayed in the in-line screenshots

    • {%fileBase64} - display image (if evidence type is of image format)

    • {fileName} - name of the file uploaded

• {#vulnerabilityAssetMapping} - list of all vulnerabilities mapped to their affected assets

  • {priority} - priority of the vulnerability e.g. Critical, High, Medium, Low, Info

  • {vulnerability} - vulnerability title

  • {#assets} - list of all affected assets

    • {status} - remediation status e.g. Fixed / Not Fixed

    • {asset} - asset name

• {#assetVulnerabilityMapping} - list of all assets across all projects mapped to their vulnerabilities

  • {asset} - asset name

  • {#vulnerabilities} - list of all vulnerabilities the asset is affected by

    • {vulnerability} - vulnerability title

    • {priority} - priority of the vulnerability e.g. Critical, High, Medium, Low, Info

    • {status} - remediation status e.g. Fixed / Not Fixed