Managing sites and scan data
You can adjust various settings to control how Burp Suite Enterprise Edition handles sites and the data generated by their scans. To access these options, click the settings icon and select "Sites and scan data".
Automatically create sites for API-generated scans
When a scan is triggered via the REST API, for example, by a CI/CD pipeline, integrated using the legacy "Burp scan" integration option, Burp Suite Enterprise Edition attempts to attach the scan data to existing sites in the system. If no matching site is found, a new site is automatically created instead.
By default, sites generated in this way are not displayed in your site tree. However, if you enable this option, the site tree will display them alongside the sites that you create manually using the web UI.
This setting is irrelevant for CI/CD integrations that use the "Burp site-driven scan" option. Site-driven scans are manually linked to a specific site by the user and are integrated via the GraphQL API rather than the REST API.
How does Burp Suite Enterprise Edition decide which sites to match?
When a scan is triggered via the REST API using the legacy "Burp scan" integration option, Burp Suite Enterprise Edition uses its built-in site-matching rules to decide whether the scan and its data should be matched with an existing site. These site-matching rules are based on both the name of the site and the list of included and excluded URLs.
If a name was provided for the site when the scan was created:
- The system checks all folders to see if a site with this name already exists. If not, a new site is created.
- If a site with this name already exists and it contains exactly the same set of included and excluded URLs, the new scan is attached to this site. If more than one site with this name exists, the system uses the first instance it finds, starting from the top of the site tree.
- If a site with this name already exists, but the included and excluded URLs do not match, this results in an error and the scan does not run.
If no name was provided for the site when the scan was created:
- If an existing site contains exactly the same set of included and excluded URLs, the new scan is attached to this site. If more than one site with these included and excluded URLs exists, the system uses the first instance it finds, starting from the top of the site tree.
- If no existing sites are found that contain the same included and excluded URLs, a new site is created with an auto-generated name. The new site name is generated using the hostname found in the URL followed by a sequential number if necessary.
Automatically delete old scans
If you enable this setting, you can define a threshold for how long old scans will be kept in the system. By default, this is set to delete all scans that are more than one year old, but you can change this to anything from one day up to five years. Note that the most recent scan for each site is always kept, even if it is older than the defined threshold.
When a scan finds an issue, Burp Suite Enterprise Edition determines whether it is a new issue for the site or an issue that was already discovered by previous scans. This information is used to produce the trend information about new, resolved, and regressed issues that you see in the dashboards. It is also used to identify issues that have previously been flagged as false positives.
In the scan delta settings, you can adjust how Burp Suite Enterprise Edition decides which issues are "new". You have the following options:
Identify a new issue on a site as an issue type not seen before
This means that if an issue has already been reported anywhere on this site, the system will not treat any subsequent issues of the same type as "new" for this site. This is the default setting.
Identify a new issues on a site as an issue type and URL not seen before
This means that the URL where this issue was found is also taken into account. For example, if an SQL-injection issue has already been found for the site, but at a different URL, the system will treat the SQL-injection issues at each URL as separate and mark them each as "new" when they are discovered
Configuring false positive settings
You can configure how Burp Suite Enterprise Edition handles issues that are flagged as false positives. To access these options, click the settings icon and select "False positives".
By default, if you flag an issue as being a false positive, this will be remembered in future scans of the same site. If the same issue is reported again, it will automatically be flagged as a false positive. You can change this behavior using the "Remember false positives for future scans" option.
You can also configure how Burp Suite Enterprise Edition matches newly reported issues with past issues that were flagged as false positives. By default, these are matched based on the issue type and URL. However, you can change this so that issues are matched based solely on the issue type. You should use this option with caution. For example, if you enable it, and you flag a SQL injection issue as being a false positive, then all future SQL injection issues reported for the site will automatically be flagged as false positives, even if they arise at different URLs.
Backing up your data
If you are using the bundled database, you can control your database backup settings from within Burp Suite Enterprise Edition. Click the settings icon and select "Database backup".
You can control the following settings:
- The file location to which database backups will be saved.
- The schedule on which database backups will be performed. You can configure backups to run every 1-4 weeks at your chosen time of day.
- The number of backup files to retain. The default setting is to retain 3 backups.
You can also back up your database manually at any time using the "Back up now" button.
Note that if you use an external database, your database administrator manages your backup settings outside of Burp Suite Enterprise Edition.