[ENT + CORE] Introducing Delegations

This release introduces an exciting new feature – delegations.
Delegations provide delegates with the ability to perform specific workflows and functions, which are usually considered privileged tasks in AttackForge.
Admins can grant delegations to individual users, or globally against user roles.
Delegations can help to:
  • Reduce the burden placed on admins and privileged users.
  • Empower trusted individuals with autonomy to perform more tasks in AttackForge.
In this release, we have included the following delegations:
  • Create Projects: User(s) can create new projects; edit their projects; and manage access to their projects.
  • Action Pending Project Requests: User(s) can view, edit, approve, reject, and request information for all pending project requests.
Individual user delegations can be granted and managed via the Users module.
In addition, global delegations can be applied via the Administration module.

[ENT + CORE] Smart Vulnerability Imports

Importing vulnerabilities can be a pain… especially when you need to adjust them before they can go to customers.
We have just released a new smart mapping feature – providing greater control when importing your vulnerabilities.
You can now consolidate vulnerabilities into single write-ups!
This powerful utility helps you to:
  • Combine vulnerabilities into a single unique writeup
  • Ensure your imported vulnerabilities are matched against known good and customer-ready write-ups
  • Speed up your quality assurance and review process
  • Reduce the amount of duplicate and similar entries in your vulnerability libraries
For example, say you have three (3) vulnerabilities your wish to import from Nessus:
  • SSL Version 2 and 3 Protocol Detection
  • TLS Version 1.0 Protocol Detection
  • TLS Version 1.1 Protocol Detection
However, you want to map these against one (1) single known-good writeup in your library - which covers all various TLS related configuration issues:
  • Weak TLS Implementation
You can now do this easily with a single custom mapping expression!
An example of a smart mapping expression (rule):
vuln.tags.pluginID $in writeup.tags.pluginID
This expression works as follows:
  • For every imported vulnerability (vuln), do the following
    • For every writeup in the library (writeup), do the following
      • Does the vulnerability have a tag 'pluginID' (vuln.tags.pluginId)?
      • Does the writeup have a tag 'pluginID' (writeup.tags.pluginID)?
      • Is one in the other? (vuln.tags.pluginID $in writeup.tags.pluginID)
      • If yes, map this imported vulnerability to the writeup in the library
      • Otherwise, proceed to import vulnerability as per normal
Smart mapping can take advantage of:
  • up to twelve (12) datapoints on the vulnerability; and
  • up to ten (10) datapoints on the vulnerability library writeup
Every expression utilizes operators, which can be combined to build more powerful expressions!
  • NOT or ! - used to negate an expression.
  • AND or && - used to and multiple expressions.
  • OR or || - used to or multiple expressions.
  • == - used to check for equivalency.
  • === - used to check for equality.
  • != or !== - used to check for not equivalency.
  • > - used to check for greater-than comparison.
  • < - used to check for less-than comparison.
  • >= - used to check for greater-than-or-equals comparison.
  • <= - used to check for less-than-or-equals comparison.
  • ( ) or !() - used to group statements together.
  • $in - used to check if a value is in a list of values.
  • $nin - used to check if a value is not in a list of values.
  • =~ /RegEx/i - used to check for a regular expression.
For more details on how smart mapping works, please check the following link on our Support centre:

[ALL] ReportGen v2.4 Released

We have just released version 2.4 for AttackForge ReportGen!

Updates to Filters

This release introduces an update to filterBy to include:
  • filterBy:'AffectedAssetProperties'
  • filterBy:'AffectedAssetCustomFields', and
  • filterBy:'AffectedAssetCustomFields-CountVulns'
This filter is used to retrieve a set of vulnerabilities where the affected assets meet certain conditions.
For filterBy:'AffectedAssetCustomFields' and filterBy:'AffectedAssetCustomFields-CountVulns' - these filters are used in the exact same way as filterBy:'AffectedAssetCustomTags', however will filter vulnerabilities by their custom fields instead of by their custom tags.
For filterBy:'AffectedAssetProperties' - this filter works on other properties associated with the affected assets, such as CVSS scores, priorities, status, and resolution reason. For example, you can return a list of vulnerabilities and their affected assets which are closed, as follows:
Or you can extend the filter to match multiple AND or OR conditions. For example, you can return a list of vulnerabilities and their affected assets which are either open or ready for retest.
This filter works with any key:value pair on affected_assets. If you are unsure which properties you can use this filter on, try using the Helper function to see which fields are available to you.

Performance boost!

We have introduced a new compression engine for AttackForge Core and Enterprise users which improves report generation by up to 70%! This is particularly noticeable on large reports with lots of images.

UX improvements

You now no longer need to include {#individualReport} tag in your AttackForge Core and Enterprise templates.

Bug fixes

We have fixed few different bugs which relate to rendering of lists and line breaks in the reports.

[ENT + CORE] New Functionality

We have added new functionality to make AttackForge even better for you and your teams and customers!

Approve project request with project clone

You can now approve a project request with a clone.
When selecting Approve Request & Clone Project, you can set up the new project based on parameters and vulnerabilities from a previous project.
This is ideal if the request is for a new round of testing for a previously tested application, system or set of assets.

Project cloning options

When cloning a project, you can now select from different cloning options available such as:
  • Clone Executive Summary? Yes/No
  • Clone Project Notes? Yes/No
  • Clone Project Workspace? Yes/No

Template Proof of Concept / Steps to Reproduce

You can now configure a template steps to reproduce / proof of concept that will be automatically copied to the POC field when creating a new vulnerability.

Bulk-add remediation notes

You can now bulk apply remediation notes to selected vulnerabilities.

Custom JIRA export issue mapping

You can now set additional JIRA export options for mapping vulnerabilities to JIRA tickets:
  • Custom Issue Type - you can export your vulnerabilities to your JIRA project using a custom issue type (i.e. not Bug, Story or Task).
  • Custom Priority (Critical / High / Medium / Low / Info) - you can export your vulnerabilities to your JIRA project using a custom mapping for issue rating. For example, default mapping in JIRA for Critical is Highest. However, your project may be configured to use another value which is not Highest. Here you can enter that value to map the vulnerabilities accordingly.

Custom sign-in page text

You can now set a custom sign-in page message. This could be used for welcome messages or disclaimers.
You can set your custom sign-in message from Administration --> Configuration --> Users tab.

Disable Attack Scenario field

You can now disable the Attack Scenario field, so that it is no longer require when creating or editing a write-up in the library.
We have also made this field optional if you choose to keep to enabled.

Exclude groups filter in analytics

You can now exclude groups from your analytics.
This is useful if you want to perform analysis such as ‘show me analytics for all projects and vulnerabilities which aren’t related to this group (or groups)’

Configure default role for new registrations

You can now configure the default role which is assigned to newly registered users, or users automatically created via Single-Sign-On Just-In-Time user provisioning.
You can set your default role from Administration --> Configuration --> Users tab.

[ENT + CORE] UX Improvements

Custom projects table in Portfolios

We have now added the ability to modify your table settings (such as columns, visibility, pagination, order, etc.) for projects when viewing Portfolios and Streams.

User schedule improvements

We have added more data for users when viewing the schedule and related projects.
All projects are now color-coded, you can easily track the status of each project assigned to the user.
We have also included more information for each project, including Role which helps you to better understand and filter the users’ role on each project.

Global pending vulnerabilities

The global dashboard now includes Pending vulnerabilities, making it easy to track vulnerabilities which require attention or quality review.
All ‘Select’ type custom fields now support search, making it easy to select an entry from a large list.

[ENT + CORE] Updates to Self-Service API

In this release, we have improved our Self-Service REST APIs to provide more flexibility and options when interacting with AttackForge.
We have created the following new APIs:
We have also made the following updates to existing APIs:
  • All vulnerability related endpoints – we now include altCustomFields as an alternative format for returned custom tags and custom fields
  • All project related endpoints – we have added project_extended_status and project_testing_progress fields to returned project data
  • CreateTestsuite, AddTestcaseToTestsuite, UpdateTestsuite, UpdateTestcaseOnTestsuite – we have added code & sort_order fields
  • CreateGroup, UpdateGroup – we have added linked_groups_view, linked_groups_upload and linked_groups_edit fields
  • CreateProject, UpdateProject – we have added portfolio_streams field


[ENT + CORE] Time-based Custom Email Notifications

This release introduces an exciting new feature – time-based custom email notifications.
AttackForge now has a powerful utility for generating custom-emails based on our new rules-based engine.
This utility allows you to craft & send custom emails on a daily or weekly recurring cycle.
Custom emails allow you to create your own workflows for reminders, escalations, or reporting.
Examples of when you might use this feature include:
  • Setting automated reminders for vulnerabilities which are nearing or overdue on their SLAs or Remediation Plans
  • Setting automated summary emails of vulnerabilities over defined periods, for example Critical Vulnerabilities in Past 72 Hours
  • Setting automated notifications for vulnerabilities based on their custom tags or custom fields, for example Vulnerabilities Ready for QA in Past 24 Hours
These are just few examples of what custom emails can bring to your organisation.
Custom emails extend the robust notifications that already come standard with AttackForge workflows.
Administrators can configure custom emails from the Administration --> Configuration --> Custom Emails tab.
Every custom email can have its 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 in your email 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.
Custom time-based emails can be configured to be sent on a daily or weekly basis, and at any time during the day.
For example, you can configure a custom email to be sent between 8AM and 9AM each day 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.
AttackForge supports twelve (12) filters & functions you can use to filter the data set that is relevant to your custom email.
AttackForge also supports sixteen (16) fields for vulnerabilities – helping you filter to the right data set that is relevant to your custom email.
The recipients of your custom emails can include twenty (20) different audiences – helping to ensure the right people are informed, every time.
Every recipient will receive a personalized vulnerability list based on vulnerabilities & projects for which they have access to.
The data which can be inserted into your custom emails is extensive, with over sixty (60) metatags currently supported.
Below is an example of a custom email that shows each recipient a personalized list of vulnerabilities which are 7-days from reaching their SLA:

[ENT + CORE] Test Case Workspaces & Execution Flows

Test cases now have their own page, complete with:
  • dedicated workspace to capture evidence & notes for each test case; and
  • execution flows and steps which help to guide a tester through the process of how to perform the test case.

Dedicated Workspaces

Every test case has its own dedicated workspace, where testers can document information and upload supporting files relating to the testing process.
Workspace notes are a great way to:
  • store evidence for how the test case was performed;
  • capture notes and observations during testing;
  • record information relating to particular tested assets; and
  • document conversations and events relevant to the test case.
Every workspace note has ability to upload supporting files.
Workspace notes are only visible to the testers on the project, where as the pre-existing Notes & Evidence features can still be used for customer & report facing notes and evidence.

Execution Flows

Execution flows can be assigned to each test case, and can have many uses such as:
  • Document steps and procedures guiding a person in how to perform the test case;
  • Document which tools should be used to perform the test case;
  • Document internal processes and procedures required by the test case; and
  • Provide links to external resources.
Execution flows are made up of ‘steps’ which can be defined for each test case within the Test Suite Builder module:

[ALL] ReportGen v2.3 Released

We have just released version 2.3 for AttackForge ReportGen!

Pentest Report Template v2

In this major update, we have introduced Pentest Report Template v2.
This new template demonstrates the sophistication and power we have been building into ReportGen over the past 18 months, showcasing the possibilities available in ReportGen v2+.
This template contains the following enhancements:
  • Redesigned Executive Summary - new dual-column layout + extra tags + styled executive summary notes
  • Redesigned Testing Summary - new layout + extra tags for overview of testing progress
  • New Section 'Summary Findings' - color-coded tables with overview of all vulnerabilities
  • Custom AttackChain Images - use your own images in your attack chains. New placeholders are included
  • Redesigned Vulnerability Details - new dual-column layout + color-coded vulnerability headings + styled POCs with center-aligned images and italicized captions
  • Whitespace Reductions - reduced whitespace to make reports more practical and concise
  • Redesigned Test Cases - new dual-column layout + color-coded section headings
  • New Section 'OWASP Top 10 Mapping' - demonstrates power of Functions to create custom dynamic sections within your reports
  • Updated Vulnerability-to-Asset & Asset-to-Vulnerability Mappings - color-coded for easy consumption of data
  • Updated Table of Contents
  • {#projectCustomTags} & {#assetCustomTags} - utilizes custom tagging to display new data in the report
  • New fonts & headings
  • DateFormat() filter - filter has been applied to dates & times
You can download this new template from Templates section inside ReportGen.
We have also released an updated example JSON test data which can be used for creating templates.

Custom JSON Data Now Supported

You can now use ReportGen with custom JSON data and files!
ReportGen now supports the {data} tag which provides access to the top-level array or object in your JSON file.
This tag provides direct access to the entire JSON file - providing support for custom data which is not included in a standard AF JSON project export file.
For example, if you had the following JSON file:
You can print this data in your custom report as follows:
You can access many of the pre-built Functions and Filters to add powerful logic and formatting to your custom data.

New Style: AF Images

We have added support for a new style AF Images which can be used to create a custom style for images and their captions inserted via the {..._styled} tags.
This new style provides ability to have custom formatting for how your images and captions are displayed in your reports, for example in your executive summary or steps to reproduce / proof of concepts.
To get started, create a new style inside Word with the name 'AF Images'. Then apply a format to this style.
When ReportGen builds your report, it will automatically map to this style for you.
You can now include links to your project and individual vulnerabilities in your reports.
This is useful to give the recipients of your report a link they can click in the report to then be directed to the project or a certain vulnerability.

[ENT + CORE] New Functionality

Portfolio custom fields

We have now added the ability to define custom fields for your portfolios; as well as ability to enable/disable the standard portfolio fields.
Administrators can modify the portfolio field settings from Administration --> Configuration --> Custom Fields – Portfolios.

Active Directory integration – options for Upload & Edit groups

Allow groups to receive project notifications

When linking Active Directory groups to AttackForge groups, you can now specify which level of privileges will be assigned to the group member.
This is useful if you have Active Directory groups for engineering or security teams and would like to automatically assign Upload and Edit permissions for the user to the related AttackForge group’s projects.
Groups can also now receive project email communications. This can be enabled when creating or editing the group settings.

Manually re-apply and delete vulnerability SLAs

Vulnerability SLAs can now be automatically or manually enabled per project.
Usually, SLAs will be automatically applied to any new vulnerabilities created or imported on your projects.
However, you can opt-out of applying SLAs automatically, and instead apply them manually on selected vulnerabilities.
This is useful if you want SLAs to applied only under certain conditions, for example:
  • Apply SLAs only at the end of the project;
  • Apply SLAs only when the application team acknowledges the findings;
  • Apply SLAs only on certain projects, for example compliance/regulatory projects;
  • Apply SLAs only on certain vulnerabilities that require an SLA.
To apply SLAs manually on your project, select Manual option:
You can bulk re-apply SLAs on vulnerabilities. This will remove the existing SLA on the vulnerability and replace it with a new SLA from the SLA ruleset.
If no SLA exists on the vulnerability, a new SLA will be applied.
This can also be performed on an individual vulnerability:
You can remove SLAs for vulnerabilities.
This can also be performed on an individual vulnerability:

View asset vulnerabilities in Assets module

Every user can now view vulnerabilities for assets (which they have access to) via the Assets module.
The vulnerabilities can be viewed by clicking on the name of the asset within the Assets module.

Resend welcome invitation email

If a user does not receive the initial welcome invitation email when they are invited to join your AttackForge tenant, you can now resend the welcome email from the Users module using the Actions menu.

[ENT + CORE] UX Improvements

More data columns in tables

Customize tables – projects, assets, vulnerabilities & library

We have enhanced the number of columns which are now available in many of the data tables, particularly relating to vulnerabilities.
This provides access to more data which can be used for filtering vulnerabilities, or as part of the CSV table export.
We have also combined this with new options to configure your tables to set your preferences relating to:
  • Default page size
  • Default column to sort on
  • Default column sort order
  • Toggle columns which are displayed
  • Toggle column position/order in which they are displayed

Project custom fields show in Tracking page

When viewing the project tracking & information page, we are now displaying project custom fields.
This can be useful to share more information with your project team about the given project.

Remove disabled buttons – reports, exports, collaboration

We have removed options and buttons from view when they are not explicitly enabled within configuration.
This helps to focus attention of users to configured options only.

[ENT + CORE] Updates to Self-Service API

In this release, we have improved our Self-Service REST APIs to provide more flexibility and options when interacting with AttackForge.
We have created the following new APIs:
  • New REST method: GetPortfolio
This method can be used to retrieve information for a specific portfolio.
  • New REST method: GetPortfolios
This method can be used to retrieve information for all portfolios.
  • New REST method: GetPortfolioStream
This method can be used to retrieve information for a specific stream on a portfolio.
  • New REST method: GetVulnerabilityRevisionHistory
This method can be used to retrieve revision history for a specific vulnerability.


[ENT + CORE] Project Clone

This release introduces a powerful new workflow – Project Clone.
Project Clone can help you to:
  • Reduce the amount of manual effort when preparing for a new round of testing
  • Track unique vulnerabilities more easily across projects
  • Focus retests on specific vulnerabilities, as new projects
When cloning a project, the new project will get access to:
  • Project settings, which can be adjusted for the new project - this includes name, codes, test suites, scope, email templates, portfolios, custom fields & project team
  • Project workspace, including all notes & files previously uploaded / created
  • Project notes previously created (excluding private notes)
  • Executive summary, including uploaded files
  • Vulnerabilities (if any) you would like to carry forward into the new project
When carrying vulnerabilities forward into the new cloned project, the new project will have access to exactly the same vulnerabilities – that means vulnerability status, remediation notes, revision history, any changes to the vulnerability will remain intact.
  • Vulnerabilities are not transferred. Vulnerabilities will become available in the new project and will also remain available in the source project.
  • Vulnerabilities are not copied. This means there will be no duplication of vulnerabilities.
  • Vulnerabilities are universal. Any changes to these vulnerabilities in source project, will also apply to the new project, and vice-versa.
This important design element ensures that your vulnerability dashboards, analytics and vulnerability management activities remains true, no matter how many cloned projects.
To start, you can select Clone Existing Project from project module menu; or select Clone Project from projects action menu.
Next, select the project from list which you would like to clone.
Review & adjust settings for new project.
Select any vulnerabilities from previous project you would like to bring into this new project.
Once you are done, simply click Create Project and your new cloned project will be ready.

[ALL] ReportGen v2.2 Released

We have just released version 2.2 for AttackForge ReportGen!
In this major update, we have introduced Parent objects.
ReportGen now automatically includes the parents for each object in your JSON project/reporting file.
This means you can traverse up or down anywhere in the report, to access the right data you need.
For example, say you were looping through each vulnerability and you wanted to print the project name as well as the vulnerability title - you could do the following:
{#vulnerabilities} {parent.projectName} – {title} {/}
Now instead if you are looping through affected assets and you want to print the project name + vulnerability title + affected asset name - you could do the following:
{#vulnerabilities} {#affected_assets} {parent.parent.projectName} – {parent.title} – {asset} {/}{/}
If you are unsure of what data or parents are available to you at anywhere in your report, you can use help function:
{#vulnerabilities} {#affected_assets} {$help["%()"]} {/}{/}
This will print a help section in your browser console when you try to run the report, which will detail all data you can access, including any parents, at that time and section within your template.
This release also introduces a new filter called 'filter'.
You can use this filter to select objects within a list that match a particular condition.
For example, if you wanted to filter your vulnerabilities by critical AND easily exploitable you could use the following:
{#vulnerabilities | filter:’easily_exploitable === true AND priority === “Critical”’} {title} {/}
Another example is filtering affected assets based on remediation status AND priority. Note this example applies the filter to the {#affected_assets} and utilises "parent" to access the priority from the vulnerability.
{#vulnerabilities} {#affected_assets | filter:’remediation_status === "Open" AND parent.priority === “Critical”’} {title} {/}{/}
The following operators are supported when using this filter:
  • NOT or ! - used to negate an expression. For example !(priority == "Critical")
  • AND or && - used to and multiple expressions. For example priority == "Critical" AND zero_day == true
  • OR or || - used to or multiple expressions. For example priority == "Critical" OR priority == "High"
  • == - used to check for equivalency. For example priority == "Critical"
  • === - used to check for equality. For example priority === "Critical"
  • !== - used to check for not equivalency. For example priority !== "Critical
  • > - used to check for greater-than comparison. For example likelihood_of_exploitation > 5
  • < - used to check for less-than comparison. For example likelihood_of_exploitation < 5
  • >= - used to check for greater-than-or-equals comparison. For example likelihood_of_exploitation >= 5
  • <= - used to check for less-than-or-equals comparison. For example likelihood_of_exploitation <= 5
  • ( ) - used to group statements together. For example (priority == "Critical") AND (zero_day == true) OR ((priority == "Critical") AND (likelihood_of_exploitation >= 8))
This release also introduces support for a new tag {@execSummaryNotesStyled} which can be used to display styled executive summary with images.

[VARIES] New Functionality

  • View executive summary in-application
  • Review notes now available in executive summary
  • Executive summary gets rich-text support
Project team members can now view the executive summary within the UI, without having to download the reports.
Review notes have also been added to the executive summary, making QA faster and easier!
Executive summary now includes support for rich-text which means you can style your executive summary and render it styled in your custom reports.
  • Inactivity account lockout policy
Admins can now configure a global inactivity account lockout policy for non-admin accounts.
This policy can be used to prevent users from signing in if they have exceeded the policy, for example have not logged into the application for at least 6 months.
When a user is blocked due to inactivity, the Users module will indicate this within the Status column.
Admins can re-activate login for the affected user by selecting Allow sign-in from the user actions menu.
After the user signs in, they will automatically fall under the inactivity policy going forward.
To configure the global inactivity account lockout policy, go to Administration --> Configuration --> Security and set Disable Inactive Non-Admin Users? To YES.
Select the number of days the policy should apply (1-365 days). Save your configuration.
  • User account expiration
Admins can now expire users. Once a user is expired, they will no longer be able to log into the application or use the Self-Service API.
This feature is great for contractors, external partners or temporary service accounts used for integrations.
When a user is expired, the Users module will indicate this within the Status column.
Admins can re-enable a user by adjusting their expiration date.
To configure user account expiration, go to Users module and using the actions menu, select Set Expiry Date for the user.
  • Project team notifications now includes vulnerability ready for retest, re-opened & closed events
When setting up a new project, or editing an existing project, you can now select the following options under Email Project Team on Following Events:
  • Vulnerability Ready for Retesting
    • Will send an email to notify that the vulnerability has been marked as ready for retesting
  • Vulnerability Re-opened
    • Will send an email to notify that the vulnerability has been re-opened
  • Vulnerability Closed
    • Will send an email to notify that the vulnerability has been closed
These notifications can be configured for individual project team members, when setting or updating their project team access records.
Users can also set their preferences for these notifications via Notifications module.
These notifications can also be forced via project settings.
  • Import vulnerabilities as pending or visible
  • Add custom tags prior to importing vulnerabilities
When importing vulnerabilities on your project, you can now set them as visible (everyone on project team can see them) or pending (only edit team members aka pentesters can see them).
You can also set custom tags prior to importing the vulnerabilities. This can help to save time by tagging the vulnerabilities immediately, so they are ready for custom reports.
  • Asset fields now available in daily start/stop testing emails
We have added ability to reference asset details when sending daily start/stop testing emails.
  • Project CSV export has more vulnerability & asset fields
We have updated the CSV export for projects to now include the following fields:
  • Vulnerability ID
  • Vulnerability Alternate ID
  • Vulnerability Title
  • Vulnerability Status
  • Vulnerability Status Updated
  • Affected Asset Name
  • Affected Asset ID
  • Affected Asset Library ID
  • Affected Asset Library External ID
  • Likelihood of Exploitation
  • Zero-day
  • Retest
  • Description
  • Attack Scenario
  • Recommendation
  • Notes
  • Steps to Reproduce
  • Tags
  • Custom Tags
  • Custom Fields
  • CVSSv3 Vector
  • CVSSv3 Base Score
  • CVSSv3 Temporal Score
  • CVSSv3 Environmental Score
  • Remediation Notes
  • SLA
  • Release Date
  • Target Remediation Date
  • Created
  • Created By
  • Modified

[VARIES] UX Improvements

  • Redesigned vulnerability page, including rendering images
We have redesigned the vulnerability page to provide easier access to critical information, as well display images within steps to reproduce and notes.
  • New vulnerability table columns – tags & custom tags
We have now added tags and custom tags columns when viewing vulnerabilities on a project.
This makes it easier to track and filter vulnerabilities, particularly for reporting or integration purposes.
Also as a reminder, you can update your project vulnerabilities table settings by clicking on the blue cog.
Here you can configure which table columns are shown and in which order, as well as default pagination, sort column, sort order, and others.
  • Approved project request automatically assigns files to new project workspace
Now when you approve a project request, any uploaded files as part of that request will automatically be uploaded to the projects’ workspace.
This reduces manual effort of transferring files, and ensures all information uploaded by the customer is available on the project and for the pentesters.
  • Project Edit users can now see all team members on project team + group access to project
Project team members with edit access to the project can now view entire project team, including users with inherited access via groups.
This makes it easier for pentesters to know exactly which persons have access to the project, if they need to collaborate with them.
  • Users module now shows last active via app and last active via Self-Service API for all users
When viewing users in the Users module, it now shows when they were last active via the application and also the Self-Service API.
This helps to monitor user session durations, and activities against the Self-Service API.
This can also be used for troubleshooting purposes.

[ENT + CORE] New Configuration Options

  • Pick new UI theme colors
  • Upload new logos for UI and reports
Admins can now configure new UI theme colors for the default standard theme for all users, as well as adjust the logos used for login page, in-app and on reports.
This provides greater flexibility and freedom to personalize your AttackForge interface.
These settings can be configured from Administration --> Configuration --> Miscellaneous
  • New project custom field type: table
Admins can now configure a new type of custom field for projects – Table.
This field type can be used to capture complex data, such as multiple records of data with different types of fields per record.
The table field displays ability to define columns, where the user can then create rows of data against these columns.
When creating a table field, the following options are available:
  • Key - This the name of the field (e.g. database field name). This is the reference you will use when referring to this field in the JSON export, ReportGen or via the Self-Service API. The key must be unique, and is limited to alpha-numeric and underscores only.
  • Label - This is the label that will be displayed in the form for this table.
  • Required - This is used to determine whether the table is mandatory or optional in the forms.
  • Hide Condition - This is used to create a condition to hide the field, until such condition is met. See Hide Conditions for more details.
You can then add columns by clicking Add Column Field . Each column has the following options:
  • Type - Input field, Text Area, Select, Multi-Select or Datepicker
  • Key - This the name of the field (e.g. database field name). This is the reference you will use when referring to this field in the JSON export, ReportGen or via the Self-Service API. The key must be unique, and is limited to alpha-numeric and underscores only.
  • Default Value / Selected Options - depending on the Type, this will allow you to specify default selected options/value for this field.
  • Label - This is the label that will be displayed in the form for this table.
  • Required - This is used to determine whether the table is mandatory or optional in the forms.
The form will present all of the columns (fields) for the user to enter, and ability to add rows.
  • Set max date option for SLAs
In the last release we introduced vulnerability SLAs to help improve vulnerability management and reduce risks.
In this release we have added ability to set a max date option for each SLA.
For example, you may have an SLA rule for Critical Vulnerability in Cardholder Data Environment.
You may also have an internal company policy that all critical vulnerabilities in CDE must be fixed within 10 days or no later than Q1 of the year.
Now you can define that policy when setting or modifying your SLAs:
  • Disable new user admin emails + welcome email
Admins can now disable the email which is sent to admins when a new user is registered, invited or created.
This option can be toggled from Administration --> Configuration --> Emails
  • Disable CSV / JSON / ReportGen custom reports
Admins can now disable ability to download CSV, JSON or ReportGen custom reports for either client users or all users.
This can be used to control which types of reports or exports your users are allowed to access, and is an extension of previous ability to disable PDF, DOCX and HTML reports.
This option can be toggled from Administration --> Configuration --> Reporting

[ENT + CORE] Updates to Self-Service API

In this release, we have improved our Self-Service REST APIs to provide more flexibility and options when interacting with AttackForge.
We have created the following new APIs:
  • New REST method: CreateUsers
This can be used to create bulk users. It is useful when pre-registering users in AttackForge.
  • New REST method: UploadWorkspaceFile
This can be used to upload files to a projects’ workspace. It is useful when setting up a new project or pentest as part of integrations with tools such as ServiceNow or JIRA.
  • New REST method: InviteUsersToProjectTeam
This can be used to bulk invite users to a project. It is useful when setting up integrations with tools such as ServiceNow or JIRA.
  • New REST method: RemoveProjectTeamMembers
This can be used to bulk remove members from a project team. It is useful when removing access to projects programmatically.


[ENT + CORE] Custom Vulnerability SLAs and Remediation Plans

Vulnerability SLAs are a powerful way to triage vulnerabilities to make vulnerability management more effective and efficient.
AttackForge helps to keep on top of vulnerabilities as they get closer to their SLA, by making it easy to filter, identify, action and export.
Every vulnerability can be automatically assigned with a custom SLA.
AttackForge provides a rules-based engine to configure custom vulnerability SLAs. This powerful utility allows you to create SLAs which meet specific conditions based on vulnerability, asset and project datapoints.
Every SLA is color-coded and includes a countdown tracker for easy filtering and sorting.
Vulnerability SLAs can be enabled by Administrators via Administration module.
AttackForge SLA rules-engine is a powerful utility to configure SLAs going beyond typical “Critical/High” ratings.
For example, you can create rules for vulnerabilities on “Internet-facing” assets, or vulnerabilities within scope of compliance such as PCI-DSS.
AttackForge SLA rules-engine supports over fifty (50) datapoints across vulnerabilities, assets & projects – greatly improving vulnerability compliance tracking and triaging to reduce risk.
AttackForge SLA rules-engine also supports over ten (10) different operators, allowing you to link together various datapoints in logical ways to create custom rules.
We have also introduced a new workflow to capture target remediation dates for vulnerabilities – Remediation Plans.
Remediation plans can be submitted by your customers, developers, engineers, and teams.
Remediation plans help to track when vulnerabilities are planned to be fixed, to help security team keep on top of open vulnerabilities.
Every remediation plan includes a countdown tracker to make it easy to identify and action vulnerabilities which are getting close to, or have already exceeded, their remediation plan dates.
Administrators can enable this functionality via Administration module.