Notifications

Overview

AttackForge includes email notifications to help keep everyone informed on testing progress, including retesting, as well as new vulnerabilities and changes on existing vulnerabilities.

Daily Started / Stopped Testing

For project team members with Edit access e.g. pentesters/consultants, they can inform the project team by email every day when they start or stop testing.

The emails can be personalised for each project, to provide a contextual update for teams.

To do this, from the project dashboard menu - select Daily Commencement Email to inform the project team you have started testing; and Daily Completion Email to inform the project team you have stopped testing.

To configure the emails - see this link

New Vulnerabilities

To make vulnerability information flow faster to help reduce time-to-remediate, email notifications can be enabled on different events, such as discovery of a new critical or high vulnerability.

These emails will only be sent when a vulnerability is set to be visible.

You can configure how much, or how little, vulnerability information you would like to share for each project.

You can opt into whichever email notifications are relevant for the project team or individual team members.

Notification Type For New Vulnerabilities

Emails for new vulnerabilities can be sent in two different ways:

• Send Individual Email For Each New Vulnerability - an email will be sent to each opt-in project team member (and additional recipients, if configured) for every new vulnerability discovered. That is, one email will be sent per new vulnerability.

• Send One Email with Details For All New Vulnerabilities - an email will be sent to each opt-in project team member (and additional recipients, if configured) which includes a summary for every new vulnerability discovered, in a single email. That is, one email will be sent with a summary for each new vulnerability.

To configure the emails - see this link

Custom One-Off Emails

You can send custom one-off emails to the project team, or individual team members. This is useful for one-off emails which need to be sent from AttackForge.

Custom one-off emails support Project Email Meta Tags.

To send a custom one-off email, click on Custom One-Off Email from the project menu.

Include an email subject and body. The body supports limited HTML and CSS.

Select the recipients, or enter any additional email addresses and click Send Email.

Custom Time-Based Emails

AttackForge has a powerful utility for generating custom emails on a schedule, leveraging our rules-based engine.

Custom emails extend the robust notifications that already come standard with AttackForge workflows. Custom emails allow you to create your own workflows for reminders, escalations, or reporting. These are just few examples of what custom emails can bring to your organisation.

Administrators can configure custom emails from the Administration -> Notifications -> Custom Emails section.

Custom time-based emails allow you to create, configure and send emails on a repeating frequency.

Every custom email can have it's own unique set of configuration options, including:

• Key - this is used to reference this custom email rule.

• Email Frequency - this is where you define the repeating frequency for this custom email.

• Email Time - this is where you define which hour of the day you would like this custom email to be sent.

• Type - this is where you can configure the type of email you would like to send, and the data you will have access to for each recipient.

• Filter - this is where you can filter the data from the Type based on your unique requirements for this custom email.

• Recipients - this is where you configure the audience for this custom email.

• Subject - this is the email subject for the custom email.

• Body - this is the email body for the custom email.

Email Frequencies

The following email frequencies are currently supported:

• Daily - emails will be sent each day during the selected hour

• Weekly - emails will be sent on the selected day, every week during the selected hour

Email Time

Custom time-based emails can be configured to be sent at any time during the day, during a selected hourly block.

For example, you can configure a custom email to be sent between 8AM and 9AM to ensure recipients have the information at the start of their day; or between 5PM and 6PM so that they have a summary from that day.

Type

Types will give you access to a particular set of data that can be used for the custom email.

The following types are currently supported:

• Vulnerabilities - this includes data relating to the vulnerabilities, their assets, projects, and users.

• Projects - this includes data relating to projects including statistics for vulnerabilities, assets and test cases

• Project Requests - this includes data relating to project requests.

• Users - this includes data relating to users.

• Writeups - this includes data relating to writeups.

The type will determine what data can be included in the Filter and also the Body.

Filter

Filter is used to select the exact dataset you would like to use for the custom email. The filter works similar to a database query, where you can specify fields & operators - these help to narrow down the results to the data you would need for the custom email.

!IMPORTANT: After data is filtered, and before it is sent to recipients - it is verified against the recipient to ensure that the recipient has privileges to access the data.

Filters support the following operators:

$and

Can be used to AND two or more conditions.

Example: Filter vulnerabilities which are Open and Critical

{    
    $and: [
        {
            status: { $eq: 'Open' }
        },
        {
            priority: { $eq: 'Critical' }
        }
    ]
}

$or

Can be used to OR two or more conditions.

Example: Filter vulnerabilities which are Critical or High

{
    $or: [
        {
            priority: { $eq: 'Critical' }
        },
        {
            priority: { $eq: 'High' }
        }
    ]
}

$eq

Used to check that a field is equal to a value. A value can be a string, boolean, number, null or a function.

Example: Filter vulnerabilities which are Critical

{
    priority: { $eq: 'Critical' }
}

$ne

Used to check that a field is not equal to a value. A value can be a string, boolean, number, null or a function.

Example: Filter vulnerabilities which are not Informational

{
    priority: { $ne: 'Info' }
}

$in

Used to check that a value exists in a list. Supports an array of values.

Example: Filter vulnerabilities which have a tag 'OWASP Top 10' (Top 10 Vulnerability)

{
    tags: { $in: ['OWASP Top 10'] }
}

$nin

Used to check that a value does not exist in a list. Supports an array of values.

Example: Filter vulnerabilities which do not have a tag 'OWASP Top 10' (Not a Top 10 Vulnerability)

{
    tags: { $nin: ['OWASP Top 10'] }
}

$gt

Used to check that a field is greater than a value. Supports strings, numbers and functions.

Example: Filter vulnerabilities which have a likelihood of exploitation greater than 7

{
    likelihood_of_exploitation: { $gt: 7 }
}

$gte

Used to check that a field is greater than or equal to a value. Supports strings, numbers and functions.

Example: Filter vulnerabilities which have a likelihood of exploitation greater than or equal to 7

{
    likelihood_of_exploitation: { $gte: 7 }
}

$lt

Used to check that a field is less than a value. Supports strings, numbers and functions.

Example: Filter vulnerabilities which have a likelihood of exploitation less than 7

{
    likelihood_of_exploitation: { $lt: 7 }
}

$lte

Used to check that a field is less than or equal to a value. Supports strings, numbers and functions.

Example: Filter vulnerabilities which have a likelihood of exploitation less than or equal to 7

{
    likelihood_of_exploitation: { $lte: 7 }
}

$regex

Used to perform a regular expression for a field. Support Javascript regular expressions.

Example: Filter vulnerabilities which have SQL in the title, using a case insensitive search.

{
    title: { $regex: /SQL/i }
}

$elemMatch

This operator matches documents that contain an array field with at least one element that matches all the specified query criteria.

Example: Filter vulnerabilities by a specific custom field name and value.

{
    custom_fields: { 
        $elemMatch: { 
            name: { $eq: "is_pci" }, 
            value: { $eq: "Yes } 
        } 
    }
}

$all

Used to perform a regular expression for a field. Support Javascript regular expressions.

Example: Filter vulnerabilities which both CWE-520 and Web App in the tags.

{
    tags: { $all: ["CWE-520", "Web App"] }
}

Functions

The following functions are currently supported:

• datetime()

datetime(timeValue, modifiers)

datetime can be used to construct a date & time and then modify it (if needed).

• timeValue - must be either:

  • now

  • YYYY-MM-DD

  • YYYY-MM-DD HH:MM

• modifiers - must be either:

  • +999 years

  • -999 years

  • +999 months

  • -999 months

  • +999 days

  • -999 days

  • +999 hours

  • -999 hours

  • +999 minutes

  • -999 minutes

  • start of year

  • start of month

  • start of day

Example 1: Filter vulnerabilities created greater than June 1st, 2022.

{
    created: { $gt: datetime('2022-06-01') }
}

Example 2: Filter vulnerabilities created greater than UTC 12:00 on June 1st, 2022.

{
    created: { $gt: datetime('2022-06-01 12:00') }
}

Example 3: Filter vulnerabilities created in last 7 days.

{
    created: { $gt: datetime('now', '-7 days') }
}

Example 4: Filter vulnerabilities with SLA greater than 7 days from now.

{
    sla: { $gt: datetime('now', '+7 days') }
}

Example 5: Filter vulnerabilities with SLA greater than 7 days + 1 year from now. Multiple modifiers will execute in order i.e. add 7 days, then add 1 year.

{
    sla: { $gt: datetime('now', '+7 days', '+1 year') }
}

Vulnerability Fields

The following fields are supported in filters for the 'Vulnerability' type:

id

The id for the vulnerability.

Example: get vulnerability with id 62a190f7793b8ccd085e0d9d

{
    id: { $eq: ObjectId("62a190f7793b8ccd085e0d9d") }
}

alternate_id

The alternate id for the vulnerability (set by the vulnerability code on the project).

Example: get vulnerability with alternate id GLOBEX-1

{
    alternate_id: { $eq: 'GLOBEX-1' }
}

created

The created date for the vulnerability.

Example: get vulnerabilities which have been created in the last 7 days.

{
    created: { $gte: datetime('now', '-7 days') }
}

modified

The modified date for the vulnerability.

Example: get vulnerabilities which have been modified in the last 7 days.

{
    modified: { $gte: datetime('now', '-7 days') }
}

priority

The priority for the vulnerability. Supports Critical, High, Medium, Low & Info.

Example: get vulnerabilities which are Critical.

{
    priority: { $eq: 'Critical' }
}

title

The title for the vulnerability.

Example: get vulnerabilities which have SQL in the title.

{
    title: { $regex: /SQL/i }
}

zero_day

Whether the vulnerability is a zero day or not. Supports Yes or No.

Example: get vulnerabilities which are a zero day.

{
    zero_day: { $eq: 'Yes' }
}

likelihood_of_exploitation

The likelihood of exploitation for a vulnerability. Supports 1, 2, 3, 4, 5, 6, 7, 8, 9, 10.

Example: get vulnerabilities which have a likelihood of exploitation greater than or equal to 7.

{
    likelihood_of_exploitation: { $gte: 7 }
}

status

The status for the vulnerability. Supports Open or Closed.

Example: get all open vulnerabilities.

{
    status: { $eq: 'Open' }
}

status_updated

The date when the status was last updated for the vulnerability.

Example: get vulnerabilities which have had their status change in the past 7 days.

{
    status_updated: { $gte: datetime('now', '-7 days') }
}

is_retest

Whether the vulnerability is flagged for retesting or not. Supports Yes or No.

Example: get vulnerabilities which are currently flagged for retesting.

{
    is_retest: { $eq: 'Yes' }
}

sla

The SLA date for the vulnerability.

Example: get open vulnerabilities which have exceeded/breached their assigned SLA by at least 7 days.

{
    $and: [
        {
            status: { $eq: 'Open' }
        },    
        {
            sla: { $lte: datetime('now', '-7 days') }
        }
    ]
}

target_remediation_date

The target remediation date for the vulnerability.

Example: get open vulnerabilities which have target remediation date exactly 7 days from now.

{    
    $and: [
        {
            status: { $eq: 'Open' }
        },    
        {
            target_remediation_date: { $lte: datetime('now', '+7 days') }
        },
        {
            target_remediation_date: { $gte: datetime('now', '+6 days') }
        }
    ]
}

release_date

The release date for the vulnerability.

Example: get vulnerabilities which have been released in the past 7 days.

{
    release_date: { $gte: datetime('now', '-7 days') }
}

custom_tags

The custom tags for the vulnerabilities.

Example: get vulnerabilities which have a custom tag "is_pci" and value "Yes".

{
    custom_tags: { 
        $elemMatch: { 
            name: { $eq: "is_pci" },
            value: { $eq: "Yes" }
        }
    }
}

custom_fields

The custom fields for the vulnerabilities.

Example: get vulnerabilities which have a custom field "qa_passed" and value "Yes".

{
    custom_fields: { 
        $elemMatch: { 
            name: { $eq: "qa_passed" },
            value: { $eq: "Yes" }
        }
    }
}

Project Fields

The following fields are supported in filters for the 'Project' type:

id

The id for the project.

Example: get project with id 62a190f7793b8ccd085e0d9d

{
    id: { $eq: ObjectId("62a190f7793b8ccd085e0d9d") }
}

created

The created date for the project.

Example: get projects which have been created in the past 7 days.

{
    created: { $gte: datetime('now', '-7 days') }
}

modified

The modified date for the project.

Example: get projects which have been modified in the past 7 days.

{
    modified: { $gte: datetime('now', '-7 days') }
}

name

The name of the project.

Example: get projects which have Web in the name.

{
    name: { $regex: /Web/i }
}

code

The code for the project.

Example: get projects which have ACME in the code.

{
    code: { $regex: /ACME/i }
}

status

The status for the project. Must be one of the following: Overrun, Waiting to Start, Testing, Completed, Retest, On Hold

Example: get projects which are Overrun.

{
    status: { $eq: 'Overrun' }
}

start_date

The start date for the project.

Example: get projects which have a start date in the next 7-days.

{
    $and: [
        {
            start_date: { $lte: datetime('now', '+7 days') }
        },
        {
            start_date: { $gte: datetime('now') }
        }
    ]
}

end_date

The end date for the project.

Example: get projects which ended in the past 7-days.

{
    $and: [
        {
            end_date: { $gte: datetime('now', '-7 days') }
        },
        {
            end_date: { $lte: datetime('now') }
        }
    ]
}

on_hold

Whether the project is on-hold. Supports Yes or No.

Example: get projects which are on-hold.

{
    on-hold: { $eq: "Yes" }
}

organization_code

The project organization code.

Example: get projects with the organization code 'ORG123'.

{
    organization_code: { $eq: 'ORG123' }
}

vulnerability_code

The vulnerability code assigned to the project.

Example: get projects which have 'PROJ' in the vulnerability code.

{
    vulnerability_code: { $regex: /PROJ/i }
}

custom_fields

The custom fields for the project.

Example: get projects which have a custom field "report_released" and value "Yes".

{
    custom_fields: { 
        $elemMatch: { 
            name: { $eq: "report_released" },
            value: { $eq: "Yes" }
        }
    }
}

Project Request Fields

The following fields are supported in filters for the 'Project Request' type:

id

The id for the project request.

Example: get project request with id 62a190f7793b8ccd085e0d9d

{
    id: { $eq: ObjectId("62a190f7793b8ccd085e0d9d") }
}

created

The created date for the project request.

Example: get project requests which have been created in the past 7 days.

{
    created: { $gte: datetime('now', '-7 days') }
}

modified

The modified date for the project request.

Example: get project requests which have been modified in the past 7 days.

{
    modified: { $gte: datetime('now', '-7 days') }
}

name

The name of the project request.

Example: get project requests which have Web in the name.

{
    name: { $regex: /Web/i }
}

code

The code for the project request.

Example: get project requests which have ACME in the code.

{
    code: { $regex: /ACME/i }
}

status

The status of the project request. Supports Pending Approval, Requested Information, Approved, and Rejected

Example: get project requests which are Pending Approval.

{
    status: { $eq: 'Pending Approval' }
}

start_date

The requested start date for the project request.

Example: get project requests which have a requested start date in the next 7-days.

{
    $and: [
        {
            start_date: { $lte: datetime('now', '+7 days') }
        },
        {
            start_date: { $gte: datetime('now') }
        }
    ]
}

end_date

The requested end date for the project request.

Example: get projects requests which have a requested end date in the next 30 days.

{
    $and: [
        {
            end_date: { $lte: datetime('now', '+30 days') }
        },
        {
            end_date: { $gte: datetime('now') }
        }
    ]
}

organization_code

The project request organization code.

Example: get project requests with the organization code 'ORG123'.

{
    organization_code: { $eq: 'ORG123' }
}

custom_fields

The custom fields for the project request.

Example: get project requests which have a custom field "is_urgent" and value "Yes".

{
    custom_fields: { 
        $elemMatch: { 
            name: { $eq: "is_urgent" },
            value: { $eq: "Yes" }
        }
    }
}

User Fields

The following fields are supported in filters for the 'User' type:

id

The id for the user.

Example: get user with id 62a190f7793b8ccd085e0d9d

{
    id: { $eq: ObjectId("62a190f7793b8ccd085e0d9d") }
}

created

The created date for the user.

Example: get users which have been created in the past 7 days.

{
    created: { $gte: datetime('now', '-7 days') }
}

modified

The modified date for the user.

Example: get users which have been modified in the past 7 days.

{
    modified: { $gte: datetime('now', '-7 days') }
}

first_name

The first name of the user.

Example: get users which have John in their first name.

{
    first_name: { $regex: /John/i }
}

last_name

The last name of the user.

Example: get users which have McDonald in their last name.

{
    last_name: { $regex: /McDonald/i }
}

username

The username of the user.

Example: get users which have attackforge in their username.

{
    username: { $regex: /attackforge/i }
}

email

The email address of the user.

Example: get users which have attackforge.com in their email address.

{
    email: { $regex: /attackforge.com/i }
}

last_logged_in

The timestamp when the user last logged in.

Example: get users which logged in in the past 7 days.

{
    last_logged_in: { $gte: datetime('now', '-7 days') }
}

status

The status of the user. Supports Active and Blocked.

Example: get users which have been manually blocked.

{
    status: { $eq: "Blocked" }
}

role

The role of the user. Supports client, consultant, librarymod, projectoperator and admin.

Example: get users who are administrators.

{
    role: { $eq: "admin" }
}

failed_logins

The number of failed logins for a user.

Example: get users with at least 1 failed login.

{
    failed_logins: { $gte: 1 }
}

mfa_enabled

Whether MFA is enabled for a user. Supports Yes or No.

Example: get users with MFA disabled.

{
    mfa_enabled: { $eq: "No" }
}

last_active_on_app

The timestamp when the user was last active on the app.

Example: get users which were active on the app in the past 7 days.

{
    last_active_on_app: { $gte: datetime('now', '-7 days') }
}

last_active_on_ssapi

The timestamp when the user was last active on the self-service API.

Example: get users which were active on the self-service API in the past 7 days.

{
    last_active_on_ssapi: { $gte: datetime('now', '-7 days') }
}

account_expiry

The timestamp when the users account is set to expire.

Example: get users which are expiring in next 7 days.

{
    account_expiry: { $gte: datetime('now', '+7 days') }
}

Writeup Fields

The following fields are supported in filters for the 'Writeup' type:

id

The id for the writeup.

Example: get writeup with id 62a190f7793b8ccd085e0d9d

{
    id: { $eq: ObjectId("62a190f7793b8ccd085e0d9d") }
}

created

The created date for the writeup.

Example: get writeups which have been created in the past 7 days.

{
    created: { $gte: datetime('now', '-7 days') }
}

modified

The modified date for the writeup.

Example: get writeups which have been modified in the past 7 days.

{
    modified: { $gte: datetime('now', '-7 days') }
}

reference_id

The 15-digit reference Id for the writeup.

Example: get writeup with id 499319508518208

{
    reference_id: { $eq: "499319508518208" }
}

title

The title for the writeup.

Example: get writeups which have SQL in the title.

{
    title: { $regex: /SQL/i }
}

description

The description for the writeup.

Example: get writeups which have SQL in the description.

{
    description: { $regex: /SQL/i }
}

attack_scenario

The attack scenario for the writeup.

Example: get writeups which have SQL in the attack scenario.

{
    attack_scenario: { $regex: /SQL/i }
}

remediation_recommendation

The remediation recommendation for the writeup.

Example: get writeups which have SQL in the remediation recommendation.

{
    remediation_recommendation: { $regex: /SQL/i }
}

likelihood_of_exploitation

The likelihood of exploitation for a writeup. Supports 1, 2, 3, 4, 5, 6, 7, 8, 9, 10.

Example: get writeups which have a likelihood of exploitation greater than or equal to 7.

{
    likelihood_of_exploitation: { $gte: 7 }
}

severity

The severity for a writeup. Supports 1, 2, 3, 4, 5, 6, 7, 8, 9, 10.

Example: get writeups which have a severity greater than or equal to 7.

{
    severity: { $gte: 7 }
}

custom_library_key

The custom library key for the writeup.

Example: get writeups in the library 'external_team'

{
    custom_library_key: { $eq: "external_team" }
}

imported_library

Whether or not the writeup is in the imported library.

Example: get writeups in the imported library.

{
    imported_library: { $eq: "Yes" }
}

project_library

Whether or not the writeup is in the project library.

Example: get writeups in the project library.

{
    project_library: { $eq: "Yes" }
}

tags

The tags for the writeup.

Example: get writeups which have both CWE-520 and Web App in the tags.

{
    tags: { $all: ["CWE-520", "Web App"] }
}

custom_tags

The custom tags for the writeups.

Example: get writeups which have a custom tag "is_pci" and value "Yes".

{
    custom_tags: { 
        $elemMatch: { 
            name: { $eq: "is_pci" },
            value: { $eq: "Yes" }
        }
    }
}

custom_fields

The custom fields for the writeups.

Example: get writeups which have a custom field "qa_passed" and value "Yes".

{
    custom_fields: { 
        $elemMatch: { 
            name: { $eq: "qa_passed" },
            value: { $eq: "Yes" }
        }
    }
}

Recipients

The recipients are the list of users who will be sent the custom email.

Vulnerability Recipients

The following vulnerability recipients are currently supported:

• Vulnerability Creator

• Project Team - Clients

• Project Team - Consultants

• Project Team - Library Moderators

• Project Team - Project Coordinators

• Project Team - Administrators

• Project Team - Everyone

• Project Group Members - Clients

• Project Group Members - Consultants

• Project Group Members - Library Moderators

• Project Group Members - Project Coordinators

• Project Group Members - Administrators

• Project Group Members - Everyone

• Clients

• Consultants

• Library Moderators

• Project Coordinators

• Administrators

• Individual Groups (select groups by name)

• Individual Users (select users by name/email)

Every vulnerability recipient will receive a personalised vulnerability list based on vulnerabilities & projects for which they have access to.

Project Recipients

The following project recipients are currently supported:

• Project Creator

• Project Team - Clients

• Project Team - Consultants

• Project Team - Library Moderators

• Project Team - Project Coordinators

• Project Team - Administrators

• Project Team - Everyone

• Project Group Members - Clients

• Project Group Members - Consultants

• Project Group Members - Library Moderators

• Project Group Members - Project Coordinators

• Project Group Members - Administrators

• Project Group Members - Everyone

• Clients

• Consultants

• Library Moderators

• Project Coordinators

• Administrators

• Individual Groups (select groups by name)

• Individual Users (select users by name/email)

Every project recipient will receive a personalised project list based on projects for which they have access to.

Project Request Recipients

The following project request recipients are currently supported:

• Project Requestor Creator

• Clients

• Consultants

• Library Moderators

• Project Coordinators

• Administrators

• Individual Groups (select groups by name)

• Individual Users (select users by name/email)

Every project request recipient will receive a personalised project request list based on project requests for which they have access to.

User Recipients

The following user recipients are currently supported:

• Clients

• Consultants

• Library Moderators

• Project Coordinators

• Administrators

• Individual Groups (select groups by name)

• Individual Users (select users by name/email)

Writeup Recipients

The following writeup recipients are currently supported:

• Clients

• Consultants

• Library Moderators

• Project Coordinators

• Administrators

• Individual Groups (select groups by name)

• Individual Users (select users by name/email)

Every user recipient will receive a personalised writeup list based on writeups for which they have access to. Admins will see all writeups. Non-admins will only see writeups based on the libraries which they have access to.

Subject

This is the subject name/title for custom email that will be delivered to recipients.

Body

This is the body/contents of the email that will be delivered to recipients. Emails are HTML enabled meaning you can include things like headings, lists, tables and images.

Every body will have different meta-tags which are supported based on the custom email type. For a full list of supported tags, please check below:

Vulnerability Metatags

• {user.firstName} - recipient first name

• {user.lastName} - recipient last name

• {vulnerabilities}...{/vulnerabilities} - execute a loop for every vulnerability. Place tags below in-between these tags.

  • {vuln.id} - vulnerability id

  • {vuln.created} - vulnerability created date in DAY MONTH DATE YEAR format e.g. Sat July 02 2022

  • {vuln.modified} - vulnerability modified date in DAY MONTH DATE YEAR format e.g. Sat July 02 2022

  • {vuln.priority} - vulnerability priority. Either Critical/High/Medium/Low/Info

  • {vuln.title} - vulnerability title

  • {vuln.description} - vulnerability description

  • {vuln.attack_scenario} - vulnerability attack scenario

  • {vuln.remediation_recommendation} - vulnerability remediation recommendation

  • {vuln.proof_of_concept} - vulnerability proof of concept / steps to reproduce

  • {vuln.status} - vulnerability status. Either Open/Retest/Closed

  • {vuln.status_updated} - vulnerability status last updated date in DAY MONTH DATE YEAR format e.g. Sat July 02 2022

  • {vuln.tags} - list of vulnerability tags. Displayed in unordered list format <ul><li>[tag]</li></ul>

  • {vuln.zero_day} - vulnerability zero day status. Either Yes or No

  • {vuln.likelihood_of_exploitation} - vulnerability likelihood of exploitation. Displayed in format 1/10...10/10.

  • {vuln.notes} - notes associated with the vulnerability. Each note is displayed in a new paragraph e.g. <p>[note]</p>

  • {vuln.test_cases} - list of vulnerability test cases. Displayed in unordered list format <ul><li>[test_case]</li></ul>

  • {vuln.alternate_id} - vulnerability alternative id (from project vulnerability code)

  • {vuln.sla} - vulnerability sla date in DAY MONTH DATE YEAR format e.g. Sat July 02 2022

  • {vuln.target_remediation_date} - vulnerability target remediation date in DAY MONTH DATE YEAR format e.g. Sat July 02 2022

  • {vuln.release_date} - vulnerability release date in DAY MONTH DATE YEAR format e.g. Sat July 02 2022

  • {vuln.cvssv3} - vulnerability CVSSv3 score e.g. 7.6

  • {vuln.cvssv3_vector} - vulnerability CVSSv3 vector e.g. CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:H/A:H

  • {vuln.cvssv3_base_score} - vulnerability CVSSv3 base score e.g. 7.1

  • {vuln.cvssv3_temporal_score} - vulnerability CVSSv3 temporal score e.g. 7.6

  • {vuln.cvssv3_environmental_score} - vulnerability CVSSv3 environmental score e.g. 6.9

  • {vuln.custom_tag_[name]} - vulnerability custom tag. Replace [name] with the name for your custom tag.

  • {vuln.custom_field_[key]} - vulnerability custom field. Replace [key] with the key for your custom field.

  • {vuln.library_id} - linked vulnerability library write-up id

  • {vuln.library_created} - linked vulnerability library write-up created date in DAY MONTH DATE YEAR format e.g. Sat July 02 2022

  • {vuln.library_modified} - linked vulnerability library write-up modified date in DAY MONTH DATE YEAR format e.g. Sat July 02 2022

  • {vuln.library_code} - linked vulnerability library write-up code

  • {vuln.library_tags} - linked vulnerability library write-up tags. Displayed in unordered list format <ul><li>[tag]</li></ul>

  • {vuln.library_import_source} - linked vulnerability library write-up import source

  • {vuln.library_import_source_id} - linked vulnerability library write-up import source id

  • {vuln.library_custom_tag_[name]} - linked vulnerability library write-up custom tag. Replace [name] with the name for your custom tag.

  • {vuln.library_custom_field_[key]} - linked vulnerability library write-up custom field. Replace [key] with the key for your custom field.

  • {vuln.asset} - vulnerability asset name

  • {vuln.asset_id} - vulnerability asset library id

  • {vuln.asset_created} - vulnerability asset library created date in DAY MONTH DATE YEAR format e.g. Sat July 02 2022

  • {vuln.asset_modified} - vulnerability asset library modified date in DAY MONTH DATE YEAR format e.g. Sat July 02 2022

  • {vuln.asset_external_id} - vulnerability asset library external id

  • {vuln.asset_type} - vulnerability asset library type

  • {vuln.asset_details} - vulnerability asset library details

  • {vuln.asset_custom_field_[key]} - vulnerability asset library custom field. Replace [key] with the key for your custom field.

  • {vuln.assets}...{/vuln.assets} - execute a loop for every asset on the vulnerability. Place tags below in-between these tags.

    • {vuln.asset.name} - vulnerability asset name

    • {vuln.asset.id} - vulnerability asset library id

    • {vuln.asset.created} - vulnerability asset library created date in DAY MONTH DATE YEAR format e.g. Sat July 02 2022

    • {vuln.asset.modified} - vulnerability asset library modified date in DAY MONTH DATE YEAR format e.g. Sat July 02 2022

    • {vuln.asset.asset_external_id} - vulnerability asset library external id

    • {vuln.asset.asset_type} - vulnerability asset library type

    • {vuln.asset.asset_details} - vulnerability asset library details

    • {vuln.asset.asset_custom_field_[key]} - vulnerability asset library custom field. Replace [key] with the key for your custom field.

  • {vuln.user_id} - vulnerability creator user id

  • {vuln.user_first_name} - vulnerability creator user first name

  • {vuln.user_last_name} - vulnerability creator user last name

  • {projects}...{/projects} - execute a loop for every linked project for this vulnerability. Place tags below in-between these tags.

    • {vuln.project_id} - vulnerability linked project id

    • {vuln.project_created} - vulnerability linked project created date in DAY MONTH DATE YEAR format e.g. Sat July 02 2022

    • {vuln.project_modified} - vulnerability linked project modified date in DAY MONTH DATE YEAR format e.g. Sat July 02 2022

    • {vuln.project_name} - vulnerability linked project name

    • {vuln.project_code} - vulnerability linked project code

    • {vuln.project_start_date} - vulnerability linked project start date

    • {vuln.project_end_date} - vulnerability linked project end date

    • {vuln.project_vuln_link} - link to the vulnerability page on the project in AttackForge. Displayed as a hyperlink with text View

    • {vuln.project_link} - link to the project dashboard for the vulnerability on the project in AttackForge. Displayed as a hyperlink with text View

    • {vuln.project_custom_tag_[name]} - vulnerability linked project custom tag. Replace [name] with the name for your custom tag.

    • {vuln.project_custom_field_[key]} - vulnerability linked project custom field. Replace [key] with the key for your custom field.

Project Metatags

• {user.firstName} - recipient first name

• {user.lastName} - recipient last name

• {projects}...{/projects} - execute a loop for every project. Place tags below in-between these tags.

  • {project.id} - project id

  • {project.created} - created time for the project

  • {project.modified} - last modified time for the project

  • {project.name} - project name

  • {project.code} - project code

  • {project.start_date} - project start date

  • {project.end_date} - project end date

  • {project.organization_code} - project organization code

  • {project.on_hold} - whether project is on-hold or off-hold. Returns Yes or No

  • {project.vulnerability_code} - project vulnerability code

  • {project.custom_tag_[name]} - project custom tag. Replace [name] with the name for your custom tag.

  • {project.custom_field_[key]} - project custom field. Replace [key] with the key for your custom field.

  • {project.user.id} - the user id for the user who created the project

  • {project.user.first_name} - the first name for the user who created the project

  • {project.user.last_name} - the last name for the user who created the project

  • {project.link} - a hyperlink to the project

  • {project.total_vulnerabilities} - the total number of vulnerabilities on the project

  • {project.total_zero_day_vulnerabilities} - the total number of vulnerabilities on the project

  • {project.total_easily_exploitable_vulnerabilities} - the total number of easily exploitable vulnerabilities on the project

  • {project.total_owasp_top_10_vulnerabilities} - the total number of OWASP Top 10 vulnerabilities on the project

  • {project.total_cwe_top_25_vulnerabilities} - the total number of CWE Top 25 vulnerabilities on the project

  • {project.total_critical_vulnerabilities} - the total number of critical vulnerabilities on the project

  • {project.total_high_vulnerabilities} - the total number of high vulnerabilities on the project

  • {project.total_medium_vulnerabilities} - the total number of medium vulnerabilities on the project

  • {project.total_low_vulnerabilities} - the total number of low vulnerabilities on the project

  • {project.total_info_vulnerabilities} - the total number of info vulnerabilities on the project

  • {project.total_pending_vulnerabilities} - the total number of pending vulnerabilities on the project

  • {project.total_testcases} - the total number of test cases assigned to the project

  • {project.total_not_tested_testcases} - the total number of not tested test cases on the project

  • {project.total_tested_testcases} - the total number of tested test cases on the project

  • {project.total_in_progress_testcases} - the total number of in progress test cases on the project

  • {project.total_not_applicable_testcases} - the total number of not applicable test cases on the project

  • {project.total_open_vulnerabilities} - the total number of open vulnerabilities on the project

  • {project.total_closed_vulnerabilities} - the total number of closed vulnerabilities on the project

  • {project.total_retest_vulnerabilities} - the total number of ready for retest vulnerabilities on the project

  • {project.total_retests_requested} - the total number of requested retests on the project

  • {project.total_retests_completed} - the total number of completed retests on the project

  • {project.total_assets} - the total number of assets on the project

  • {project.total_critical_open_vulnerabilities} - the total number of critical open vulnerabilities on the project

  • {project.total_critical_retest_vulnerabilities} - the total number of critical ready for retest vulnerabilities on the project

  • {project.total_critical_closed_vulnerabilities} - the total number of critical closed vulnerabilities on the project

  • {project.total_high_open_vulnerabilities} - the total number of high open vulnerabilities on the project

  • {project.total_high_retest_vulnerabilities} - the total number of high ready for retest vulnerabilities on the project

  • {project.total_high_closed_vulnerabilities} - the total number of high closed vulnerabilities on the project

  • {project.total_medium_open_vulnerabilities} - the total number of medium open vulnerabilities on the project

  • {project.total_medium_retest_vulnerabilities} - the total number of medium ready for retest vulnerabilities on the project

  • {project.total_medium_closed_vulnerabilities} - the total number of medium closed vulnerabilities on the project

  • {project.total_low_open_vulnerabilities} - the total number of low open vulnerabilities on the project

  • {project.total_low_retest_vulnerabilities} - the total number of low ready for retest vulnerabilities on the project

  • {project.total_low_closed_vulnerabilities} - the total number of low closed vulnerabilities on the project

  • {project.total_info_open_vulnerabilities} - the total number of info open vulnerabilities on the project

  • {project.total_info_retest_vulnerabilities} - the total number of info ready for retest vulnerabilities on the project

  • {project.total_info_closed_vulnerabilities} - the total number of info closed vulnerabilities on the project

Project Request Metatags

• {user.firstName} - recipient first name

• {user.lastName} - recipient last name

• {project_requests}...{/project_requests} - execute a loop for every project request. Place tags below in-between these tags.

  • {project_request.id} - project request id

  • {project_request.created} - project request created timestamp

  • {project_request.modified} - project request last modified timestamp

  • {project_request.name} - project request name

  • {project_request.code} - project request code

  • {project_request.start_date} - project request anticipated start date

  • {project_request.end_date} - project request anticipated end date

  • {project_request.status} - project request status

  • {project_request.organization_code} - project request organization code

  • {project_request.custom_field_[key]} - project request custom field. Replace [key] with the key for your custom field.

  • {project_request.user.id} - the user id for the user who created the project request

  • {project_request.user.first_name} - the first name for the user who created the project request

  • {project_request.user.last_name} - the last name for the user who created the project request

  • {project_request.link} - a hyperlink to view the project request

User Metatags

• {user.firstName} - recipient first name

• {user.lastName} - recipient last name

• {users}...{/users} - execute a loop for every user. Place tags below in-between these tags.

  • {user.id} - user id

  • {user.created} - user created timestamp

  • {user.modified} - user last updated timestamp

  • {user.first_name} - user first name

  • {user.last_name} - user last name

  • {user.last_logged_in} - user last logged in timestamp

  • {user.username} - user username

  • {user.email} - user email address

  • {user.status} - user status. Returns Active or Blocked

  • {user.role} - user role. Returns client, consultant, librarymod, projectoperator, admin

  • {user.failed_logins} - user failed logins. Returns a number

  • {user.mfa_enabled} - whether MFA is enabled for the user. Returns Yes or No

  • {user.last_active_on_app} - user last active on the app timestamp

  • {user.last_active_on_ssapi} - user last active on the Self-Service APIs timestamp

  • {user.account_expiry} - user expiry timestamp

Writeup Metatags

• {user.firstName} - recipient first name

• {user.lastName} - recipient last name

• {writeups}...{/writeups} - execute a loop for every writeup. Place tags below in-between these tags.

  • {writeup.id} - writeup id

  • {writeup.created} - writeup created timestamp

  • {writeup.modified} - writeup last updated timestamp

  • {writeup.title} - writeup title

  • {writeup.reference_id} - writeup reference id. Returns 15-digit number.

  • {writeup.description} - writeup description

  • {writeup.attack_scenario} - writeup attack scenario

  • {writeup.remediation_recommendation} - writeup remediation recommendation

  • {writeup.likelihood_of_exploitation} - writeup likelihood of exploitation. Returns number between 1 to 10.

  • {writeup.severity} - writeup severity. Returns number between 1 to 10.

  • {writeup.custom_library_key} - writeup custom library key.

  • {writeup.imported_library} - whether writeup is in Imported library. Returns Yes or No.

  • {writeup.project_library} - whether writeup is in Project library. Returns Yes or No.

  • {writeup.tags} - writeup tags. Returns an unordered list.

  • {writeup.custom_tag_[name]} - writeup custom tag. Replace [name] with the name for your custom tag.

  • {writeup.custom_field_[key]} - writeup custom field. Replace [key] with the key for your custom field.

Examples

Example 1

The following example is used to notify customers/engineers, security team administrators & compliance team about vulnerabilities they have access to for which the SLA will be exceeded/breached in exactly 7-days from now.

Type

Vulnerabilities

Filter

{
    $and: [
         {
                status: { $eq: 'Open' }
         },
         {
                sla : { $lte: datetime('now', '+7 days') }
         },
         {
                sla: { $gte: datetime('now', '+6 days') }
         }
     ]
}

Recipients

• Project Team - Clients

• Project Group Members - Clients

• Administrators

• Compliance Team (Group)

Subject

Vulnerability SLA Breaches In 7-days

Body

<p style="text-align: center; font-size: 20px;"><b>Vulnerability SLA Breaches In 7-days</b></p>
<p>Hi {user.firstName},</p>
<p>The following vulnerabilities will breach their SLAs in 7-days.<p>
<p>Please ensure you have reached out to the security team to schedule a retest, or discuss remediation plan.</p>
<p>
<table style="border: 1px solid;">
<tr>
<th style="width: 35%; text-align: center; border: 1px solid; background-color: #0a1f33; color: white;">Vulnerability</th>
<th style="width: 10%; text-align: center; border: 1px solid; background-color: #0a1f33; color: white;">Priority</th>
<th style="width: 15%; text-align: center; border: 1px solid; background-color: #0a1f33; color: white;">SLA</th>
<th style="width: 40%; text-align: center; border: 1px solid; background-color: #0a1f33; color: white;">Projects</th>
</tr>
{vulnerabilities}
<tr style="vertical-align: text-top;">
<td style="border: 1px solid;">{vuln.title}</td>
<td style="border: 1px solid; text-align: center;">{vuln.priority}</td>
<td style="border: 1px solid;">{vuln.sla}</td>
<td style="border: 1px solid;">{projects}{vuln.project_name} - {vuln.project_vuln_link}<br/>{/projects}</td>
</tr>
{/vulnerabilities}
</table>
</p>

Output

The following email will be sent to customers/engineers, security team administrators & compliance team with personalised vulnerability list based on vulnerabilities & projects for which they have access to.

Filter Examples

Filter for Open Critical or Open High vulnerabilities that have exceeded their SLA by 3 days

{
       $and: [
              {
                     status: { $eq: 'Open' }
              },
              {
                     $or: [
                            {
                                   priority: { $eq: 'Critical' }
                            },
                            {
                                   priority: { $eq: 'High' }
                            }
                     ]
              },
              {
                     sla : { $lte: datetime('now', '-2 days') }
              },
              {
                     sla: { $gte: datetime('now', '-3 days') }
              }
       ]
}

Filter for Open Critical or Open High vulnerabilities that have a target remediation date in 7-days time

{
       $and: [
              {
                     status: { $eq: 'Open' }
              },
              {
                     $or: [
                            {
                                   priority: { $eq: 'Critical' }
                            },
                            {
                                   priority: { $eq: 'High' }
                            }
                     ]
              },
              {
                     target_remediation_date : { $lte: datetime('now', '+7 days') }
              },
              {
                     target_remediation_date: { $gte: datetime('now', '+6 days') }
              }
       ]
}

Custom Date/Time Formats

Email meta tags support the dateFormat filter which can be applied to format the timestamp to a desired date and/or time.

Custom Email Meta Tags

The following meta tags can be used for the following emails in either the subject or the body of the email:

1. Project Requests

   1. Email Project Request Owner when request is created

   2. Email Project Request Owner when request is approved

   3. Email Project Request Owner when request is rejected

   4. Email Project Request Owner when information is requested

   5. Email Admins when new Project Request is created

   6. Email Admins when Project Request is updated

2. Groups

   1. Email User when invited to Group

   2. Email Group Member when project is added

3. Users

   1. Email User when Password Reset is requested

   2. Email User on change of IP address from last login

   3. Email User on New Registration

   4. Email New User with Welcome Message

   5. Email Admins when New User is created

   6. Email User on Invitation

4. Projects

   1. Email User when invited to new project

   2. Email Project Coordinator when new Project is created

   3. Email Project Team when Project is placed On Hold

   4. Email Project Team when Project is placed Off Hold

   5. Email Vulnerability Owner when Review Note is posted

   6. Email User when someone replies to their Vulnerability Review Note

   7. Email Additional Team Members when Vulnerability Review Note is posted

   8. Email Additional Team Members when someone replies to a Vulnerability Review Note

   9. Email Review Note Owner when someone replies to an Executive Summary Review Note

   10. Email Additional Team Members when an Executive Summary Review Note is posted

   11. Email Additional Team Members when someone replies to a Executive Summary Review Note

   12. Email Project Team when Vulnerability Status is updated

   13. Email Team Member when Project Role is updated

   14. Email Project Team when a Retest is completed

   15. Email Admins when a new Retest is requested

   16. Email Admins when a Retest is cancelled

   17. Email Project Team with one-time Custom Email

Tag	Applies to
{tenant_url}	All emails
{link}	1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 2.2, 3.1, 3.3, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12, 4.13, 4.14, 4.15, 4.16, 4.17
{link.url}	1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 2.2, 3.1, 3.3, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12, 4.13, 4.14, 4.15, 4.16, 4.17
{invite_link}	3.6
{invite_link.url}	3.6
{recipient.first_name}	All emails
{recipient.project_role}	4.1, 4.13
{recipient.password_reset_link}	3.1
{recipient.password_reset_link.url}	3.1
{recipient.account_activation_link}	3.3
{recipient.account_activation_link.url}	3.3
{retest_round.date}	4.14, 4.15, 4.16
{retest_round.requestor.first_name}	4.15
{retest_round.requestor.last_name}	4.15
{retest_round.actioned_by.first_name}	4.14, 4.16
{retest_round.actioned_by.last_name}	4.14, 4.16
{retest_round.vulnerabilities.total}	4.14, 4.15, 4.16
{review_note.creator.first_name}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11
{review_note.creator.last_name}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11
{review_note.note}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11
{review_note.topic}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11
{review_note.original_note}	4.6, 4.8, 4.9, 4.11
{review_note.reply_note}	4.6, 4.8, 4.9, 4.11
{group.name}	2.1
{user.first_name}	3.5, 3.6
{user.last_name}	3.5, 3.6
{user.username}	3.5
{user.email_address}	3.5
{user.role}	3.5
{user.ip_address}	3.2
{user.created_by.first_name}	3.5
{user.created_by.last_name}	3.5
{project_request.requestor.first_name}	1.5, 1.6
{project_request.requestor.last_name}	1.5, 1.6
{project_request.requested_information.details}	1.4
{project_request.rejected.reason}	1.3
{project_request.name}	1.1, 1.2, 1.3, 1.4, 1.5, 1.6
{project_request.id}	1.1, 1.2, 1.3, 1.4, 1.5, 1.6
{project_request.created_datetime}	1.1, 1.2, 1.3, 1.4, 1.5, 1.6
{project_request.last_updated_datetime}	1.1, 1.2, 1.3, 1.4, 1.5, 1.6
{project_request.status}	1.1, 1.2, 1.3, 1.4, 1.5, 1.6
{project_request.start_date}	1.1, 1.2, 1.3, 1.4, 1.5, 1.6
{project_request.end_date}	1.1, 1.2, 1.3, 1.4, 1.5, 1.6
{project_request.scope}	1.1, 1.2, 1.3, 1.4, 1.5, 1.6
{project_request.groups}	1.1, 1.2, 1.3, 1.4, 1.5, 1.6
{project_request.test_suites}	1.1, 1.2, 1.3, 1.4, 1.5, 1.6
{project_request.testing_hours}	1.1, 1.2, 1.3, 1.4, 1.5, 1.6
{project_request.onsite_testing}	1.1, 1.2, 1.3, 1.4, 1.5, 1.6
{project_request.justification}	1.1, 1.2, 1.3, 1.4, 1.5, 1.6
{project_request.organization_code}	1.1, 1.2, 1.3, 1.4, 1.5, 1.6
{project_request.link}	1.1, 1.2, 1.3, 1.4, 1.5, 1.6
{project_request.custom_field.<KEY>}	1.1, 1.2, 1.3, 1.4, 1.5, 1.6
{project.name}	2.2, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12, 4.13, 4.14, 4.15, 4.16, 4.17
{project.code}	2.2, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12, 4.13, 4.14, 4.15, 4.16, 4.17
{project.id}	2.2, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12, 4.13, 4.14, 4.15, 4.16, 4.17
{project.created_datetime}	2.2, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12, 4.13, 4.14, 4.15, 4.16, 4.17
{project.last_updated_datetime}	2.2, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12, 4.13, 4.14, 4.15, 4.16, 4.17
{project.start_date}	2.2, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12, 4.13, 4.14, 4.15, 4.16, 4.17
{project.end_date}	2.2, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12, 4.13, 4.14, 4.15, 4.16, 4.17
{project.organization_code}	2.2, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12, 4.13, 4.14, 4.15, 4.16, 4.17
{project.link}	2.2, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12, 4.13, 4.14, 4.15, 4.16, 4.17
{project.custom_field.<KEY>}	2.2, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12, 4.13, 4.14, 4.15, 4.16, 4.17
{project.on_hold.status}	4.3
{project.on_hold.details}	4.3
{project.off_hold.status}	4.4
{project.off_hold.details}	4.4
{vulnerability.id}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12
{vulnerability.created_datetime}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12
{vulnerability.last_updated_datetime}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12
{vulnerability.discovered_by.first_name}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12
{vulnerability.discovered_by.last_name}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12
{vulnerability.actioned_by.first_name}	4.12
{vulnerability.actioned_by.last_name}	4.12
{vulnerability.title}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12
{vulnerability.priority}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12
{vulnerability.affected_assets}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12
{vulnerability.likelihood_of_exploitation}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12
{vulnerability.zero_day}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12
{vulnerability.description}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12
{vulnerability.attack_scenario}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12
{vulnerability.remediation_recommendation}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12
{vulnerability.proof_of_concept}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12
{vulnerability.status}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12
{vulnerability.code}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12
{vulnerability.sla_date}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12
{vulnerability.target_remediation_date}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12
{vulnerability.tags}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12
{vulnerability.cvssv3.base_score}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12
{vulnerability.cvssv3.temporal_score}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12
{vulnerability.cvssv3.environmental_score}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12
{vulnerability.cvssv3.vector}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12
{vulnerability.notes}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12
{vulnerability.custom_tag.<KEY>}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12
{vulnerability.custom_field.<KEY>}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12
{vulnerability.link}	4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12