Migrating from Intruder to middleBrick

Intruder stores scan data server-side and exposes it through its web UI and API. Use the Intruder API to export findings, evidence, and request parameters for each target. Authenticate with your API key, list scans, and retrieve per-scan JSON that includes host, request, response, and issue metadata.

Example export using curl and jq:

curl -s -H "Authorization: Bearer <INT_RUDDER_KEY>" \
  "https://app.intruder.io/api/v1/scans" | jq '.[] | {id, name, target}'
curl -s -H "Authorization: Bearer <INT_RUDDER_KEY>" \
  "https://app.intruder.io/api/v1/scans/<SCAN_ID>/issues" | jq . > intruder-issues.json

Include this export in your migration checklist so you can cross-reference historical findings with middleBrick results during validation.

middleBrick does not ingest Intruder exports directly. Reconstruct history by re-scanning the same targets with the same parameters that were used in Intruder. Use the CLI to run scans programmatically and store the JSON output in a version-controlled directory tied to the date and target.

Example script skeleton to preserve temporal scan records:

#!/usr/bin/env bash
while read domain; do
  middlebrick scan "$domain" --json > "scans/$(date +%Y%m%d)-$(echo $domain | tr . _).json"
done < domains.txt

Retain the exported Intruder data alongside middleBrick outputs so you can manually map findings and track remediation progress across migrations.

During the transition, maintain both tools in your pipeline to avoid gaps. Configure your CI to run Intruder scans for the current environment and middleBrick scans for the new target set. Use the GitHub Action for middleBrick to gate merges based on score thresholds once you are confident in its coverage.

Example step in a GitHub workflow (middleBrick):

- name: middleBrick scan
  uses: middlebrick/action@v1
  with:
    url: ${{ secrets.TARGET_URL }}
    threshold: C
    fail-on-threshold: true

Route alerts to separate channels during the overlap period so teams are not overwhelmed by duplicate notifications. Once the false-positive rate and coverage are verified, disable the Intruder CI step.

Intruder checks some areas that middleBrick does not actively test. Intruder performs active SQL injection and command injection with intrusive payloads; these are out of scope for middleBrick because they require destructive payloads. If coverage of injection classes is critical, retain a separate scanner or manual test plan for those vectors.

Intruder also includes authentication brute-force and session validation logic that middleBrick does not replicate. Compensate by adding authenticated scans in middleBrick with valid credentials and by validating session management manually. Business logic flaws are not detected by either tool; document domain-specific workflows and run manual reviews for those cases.

middleBrick provides continuous monitoring, scheduled rescans, and diff detection so you see new findings and regressions over time. It maps findings to PCI-DSS 4.0, SOC 2 Type II, and OWASP API Top 10 (2023), and it surfaces findings relevant to audit evidence without claiming certification or compliance guarantees.

As a next step, inventory your API endpoints, import domain lists into middleBrick, run an initial scan to establish baseline scores, and then enable Pro features for scheduled monitoring and GitHub Action integration. Use the CLI for ad hoc checks and the dashboard for report generation and stakeholder sharing.