Skip to main content

Intruder Data Source

The Intruder connector enables you to ingest vulnerability scan results, issue records, target inventory, and scan history from your Intruder account into Nexla for downstream analysis, reporting, and integration with other security or business intelligence tools. Follow the instructions below to create a new data flow that ingests data from an Intruder source in Nexla.
intruder_api.png

Intruder

Create a New Data Flow

  1. To create a new data flow, navigate to the Integrate section, and click the New Data Flow button. Then, select the desired flow type from the list, and click the Create button.

  2. Select the Intruder connector tile from the list of available connectors. Then, select the credential that will be used to connect to the Intruder instance, and click Next; or, create a new Intruder credential for use in this flow.

  3. In Nexla, Intruder data sources can be created using pre-built endpoint templates, which expedite source setup for common Intruder endpoints. Each template is designed specifically for the corresponding Intruder API endpoint, making source configuration easy and efficient.
    • To configure this source using a template, follow the instructions in Configure Using a Template.

    Intruder sources can also be configured manually, allowing you to ingest data from Intruder endpoints not included in the pre-built templates or apply further customizations to exactly suit your needs.
    • To configure this source manually, follow the instructions in Configure Manually.

Configure Using a Template

Nexla provides pre-built templates that can be used to rapidly configure data sources to ingest data from common Intruder endpoints. Each template is designed specifically for the corresponding Intruder API endpoint, making data source setup easy and efficient.

Endpoint Settings

  • Select the endpoint from which this source will fetch data from the Endpoint pulldown menu. Available endpoint templates are listed in the expandable boxes below. Click on an endpoint to see more information about it and how to configure your data source for this endpoint.

    List Targets

    Retrieves a complete list of all targets (assets) registered in your Intruder account. Use this endpoint to maintain an up-to-date inventory of your monitored attack surface, including domain names, IP addresses, and cloud assets.

    • This endpoint automatically retrieves all targets accessible to your Intruder account. No additional configuration is required beyond selecting this endpoint template.
    • Each target record includes the target address, tags assigned to it, and metadata such as creation date and last scan time. Tags are useful for grouping targets by environment (e.g., production, staging) or team ownership.
    • The endpoint uses pagination to handle large target inventories efficiently, automatically fetching additional pages as needed.

    The Intruder API rate limits requests on a per-access-token basis. If you have a very large number of targets, Nexla will automatically handle pagination and retry logic to ensure all records are retrieved. For additional details on Intruder's data model, see the Intruder Developer Hub Overview.

    List Issues

    Retrieves all vulnerability issues identified across your monitored targets. Use this endpoint to pull a comprehensive list of security findings into Nexla for risk analysis, reporting, or integration with ticketing systems such as Jira.

    • This endpoint automatically retrieves all issues associated with your Intruder account. No additional configuration parameters are required beyond selecting this template.
    • Each issue record in the Intruder API includes key fields such as:

      • Severity: The risk level of the issue (e.g., critical, high, medium, low)
      • Title: A human-readable description of the vulnerability type
      • Affected targets: The target(s) on which the issue was detected
      • Status: Whether the issue is open, resolved, or accepted risk
      • First seen / Last seen: Timestamps indicating when the issue was first detected and when it was most recently observed
    • Intruder ranks issues by actual exploitability and contextual risk, so severity values reflect real-world impact rather than theoretical CVSS scores alone.

    To view detailed scanner output for a specific issue occurrence, use the List Occurrences endpoint. For complete details on the Issues data model, see the Intruder Developer Hub.

    List Scans

    Retrieves historical scan records from your Intruder account. Use this endpoint to audit scan frequency, review scan coverage over time, or build dashboards tracking your organization's security program activity.

    • This endpoint retrieves all scan records available for your Intruder account. No additional configuration parameters are required beyond selecting this template.
    • Each scan record includes key details such as:

      • Scan ID: A unique identifier for the scan run
      • Status: The current state of the scan (e.g., completed, in progress, queued)
      • Scan type: Whether the scan was a full scan, scheduled scan, or targeted scan
      • Targets scanned: The specific targets or tag groups included in the scan
      • Start and end times: Timestamps for when the scan began and completed
    • Scans can be triggered manually through the Intruder application or automatically via scheduled scanning. This endpoint captures both types.

    Intruder also supports initiating new scans via its API. If you need to trigger scans programmatically as part of a CI/CD pipeline, refer to the Starts a Scan reference in the Intruder Developer Hub.

    List Occurrences

    Retrieves detailed scanner output for individual issue occurrences across your targets. Use this endpoint when you need granular, per-target evidence for a specific vulnerability type — for example, to populate a SIEM, generate compliance reports, or feed detailed findings into a remediation workflow.

    • Each occurrence record represents a specific instance of a vulnerability on a specific target. An issue can have multiple occurrences if the same vulnerability type affects more than one target.
    • Occurrence records provide richer technical detail than issue-level records, including:

      • Scanner output: Raw or structured output from the vulnerability scanner for this specific finding
      • Target address: The specific host, IP, or URL where the vulnerability was detected
      • Port and protocol: Network-level details about where the vulnerability was found
      • Evidence: Supporting data such as HTTP response snippets, certificate details, or version information
    • This endpoint is particularly useful for organizations that need to provide auditors or compliance teams with detailed evidence of vulnerability findings and their current remediation status.

    Occurrence data can be voluminous if your account has a large number of findings. Nexla handles pagination automatically to ensure complete data retrieval. For a description of the Occurrences data model, see the Intruder Developer Hub Overview.

Endpoint Testing

Once the selected endpoint template has been configured, Nexla can retrieve a sample of the data that will be fetched according to the current settings. This allows users to verify that the source is configured correctly before saving.

  • To test the current endpoint configuration, click the Test button to the right of the endpoint selection menu. Sample data will be fetched & displayed in the Endpoint Test Result panel on the right.

  • If the sample data is not as expected, review the selected endpoint and associated settings, and make any necessary adjustments. Then, click the Test button again, and check the sample data to ensure that the correct information is displayed.

Configure Manually

Intruder data sources can be manually configured to ingest data from any valid Intruder API endpoint. Manual configuration provides maximum flexibility for accessing endpoints not covered by pre-built templates or when you need custom API configurations.

With manual configuration, you can also create more complex Intruder sources, such as sources that use chained API calls to fetch data from multiple endpoints or sources that require custom request parameters.

API Method

  1. To manually configure this source, select the Advanced tab at the top of the configuration screen.

  2. Select the API method that will be used for calls to the Intruder API from the Method pulldown menu. The Intruder REST API primarily uses:

    • GET: For retrieving data such as targets, issues, scans, and occurrences
    • POST: For creating resources or triggering actions such as starting a new scan

API Endpoint URL

  1. Enter the URL of the Intruder API endpoint from which this source will fetch data in the Set API URL field. All Intruder API endpoints use the base URL https://api.intruder.io/v1/ followed by the resource path. For example:
    • https://api.intruder.io/v1/targets — retrieves all targets
    • https://api.intruder.io/v1/issues — retrieves all issues
    • https://api.intruder.io/v1/scans — retrieves all scan records
    • https://api.intruder.io/v1/occurrences — retrieves all occurrence records

Ensure the API endpoint URL is correct and accessible with your current credentials. You can test the endpoint using the Test button after configuring the URL. For a complete list of available Intruder API endpoints, see the Intruder API Reference.

Date/Time Macros (API URL)

Optional

Optionally, the API URL can be customized using macros—all macros added to the API URL will be converted into values when Nexla executes the API call. Macros are dynamic placeholders that allow you to create flexible API endpoints that can adapt to different time periods or data requirements.

Date/Time macros are particularly useful when querying Intruder endpoints that support date-range filtering, such as filtering issues or scans by their creation or modification date.

  1. To add a macro, type { at the appropriate position in the API URL (within the Set API URL field), and select the desired macro from the dropdown list.

    • {now} – The current datetime
    • {now-1} – The datetime one time unit before the current datetime
    • {now+1} – The datetime one time unit after the current datetime
    • custom – Datetime macros can reference any number of time units before or after the current datetime—for example, enter (now-4) to indicate the datetime four time units before the current datetime
  2. Select the format that will be applied to datetime macros from the Date Format for Date/Time Macro pulldown menu. This format will be applied to the base datetime value of the macro—i.e., the value of {now} in {now-1}.

  3. Select the datetime unit that will be used to perform mathematical operations in the included macro(s) from the Time Unit for Operations pulldown menu—for example, for the macro {now-1}, when Day is selected, {now-1} will be converted to the datetime one day before the current datetime.

Lookup-Based Macros (API URL)

Optional

Column values from existing lookups can also be included as macros in the API URL. Lookup-based macros allow you to reference data from previously configured data sources or lookups, enabling dynamic API endpoints that can adapt based on existing data.

Lookup-based macros are useful when building Intruder sources that need to reference specific target IDs, issue IDs, or other identifiers retrieved from a prior step in your Nexla data flow.

  1. To include a lookup column value macro, select the relevant lookup from the Add Lookups to Supported Macros pulldown menu.

  2. Type { at the appropriate position in the API URL, and select the lookup column-based macro from the dropdown list. Lookup-based macros are automatically populated into the macro list when a lookup is selected in the Add Lookups to Supported Macros pulldown menu.

Path to Data

Optional

If only a subset of the data returned by an API endpoint is needed, you can designate the part(s) of the response that should be included in the Nexset(s) produced from this source by specifying the path to the relevant data within the response. This is particularly useful when API responses contain metadata, pagination information, or other data that you don't need for your analysis.

For example, when a request call is used to fetch a list of Intruder issues, the API typically returns an array of issue records along with pagination metadata. By entering the path to the relevant data, you can configure Nexla to treat each element of the returned array as a record.

Path to Data is essential when API responses have nested structures. Without specifying the correct path, Nexla might not be able to properly parse and organize your data into usable records.

  • To specify which data should be treated as relevant in responses from this source, enter the path to the relevant data in the Set Path to Data in Response field.

    • For responses in JSON format enter the JSON path that points to the object or array that should be treated as relevant data. JSON paths use dot notation (e.g., $.data.items[*] to access an array of items within a data object).

    • For responses in XML format, enter the XPath that points to the object/array containing relevant data. XPath uses slash notation (e.g., /response/data/item to access item elements within a data element).

    Path to Data Example:

    If the Intruder API response is in JSON format and includes a top-level array named data that contains the relevant records, the path to the response would be entered as $.data[*].

Autogenerate Path Suggestions

Nexla can also autogenerate data path suggestions based on the response from the API endpoint. These suggested paths can be used as-is or modified to exactly suit your needs.

  • To use this feature, click the Test button next to the Set API URL field to fetch a sample response from the API endpoint. Suggested data paths generated based on the content & format of the response will be displayed in the Suggestions box below the Set Path to Data in Response field.

  • Click on a suggestion to automatically populate the Set Path to Data in Response field with the corresponding path. The populated path can be modified directly within the field if further customization is needed.

    PathSuggestions.png

Metadata

If metadata is included in the response but is located outside of the defined path to relevant data, you can configure Nexla to include this data as common metadata in each record. This is useful when you want to preserve important contextual information that applies to all records but isn't part of the main data array.

For example, when retrieving Intruder issues, the API response may include pagination metadata (such as total issue count or the current page number) alongside the array of issue records. If you have specified the path to the issue records but want to preserve pagination context, you can specify a path to this metadata to include it with each record.

Metadata paths are particularly useful for preserving API response context like request IDs, timestamps, or pagination statistics that apply to all records in the response.

  • To specify the location of metadata that should be included with each record, enter the path to the relevant metadata in the Path to Metadata in Response field.

    • For responses in JSON format, enter the JSON path to the object or array that contains the metadata, and for responses in XML format, enter the XPath.

Request Headers

Optional
  • If Nexla should include any additional request headers in API calls to this source, enter the headers & corresponding values as comma-separated pairs in the Request Headers field (e.g., header1:value1,header2:value2). Additional headers may be required for API versioning or content type specifications.

    You do not need to include the Authorization header here — it is automatically added from your Intruder credential. Common headers like Authorization, Content-Type, and Accept are handled automatically by Nexla based on your credential configuration.

Endpoint Testing

After configuring all settings for the selected endpoint, Nexla can retrieve a sample of the data that will be fetched according to the current configuration. This allows users to verify that the source is configured correctly before saving.

  • To test the current endpoint configuration, click the Test button to the right of the endpoint selection menu. Sample data will be fetched & displayed in the Endpoint Test Result panel on the right.

  • If the sample data is not as expected, review the selected endpoint and associated settings, and make any necessary adjustments. Then, click the Test button again, and check the sample data to ensure that the correct information is displayed.

Save & Activate the Source

  1. Once all of the relevant steps in the above sections have been completed, click the Create button in the upper right corner of the screen to save and create the new Intruder data source. Nexla will now begin ingesting data from the configured endpoint and will organize any data that it finds into one or more Nexsets.