Migrating from Qualys to middleBrick

Map a phased migration to avoid downtime in your CI/CD pipeline. Start with a read-only comparison run: execute a Qualys scan and a middleBrick scan against the same API surface within a short window, then compare risk scores and finding counts. Use the middleBrick CLI to establish a baseline with middlebrick scan <url> --output json and store the JSON artifacts as the reference point. If you rely on Qualys authenticated scans, replicate the same authentication surface in middleBrick by supplying tokens or cookies only to the staging environment first. This approach limits risk while you validate coverage and workflow compatibility.

Qualys exports typically come as XML or CSV with findings, host mappings, and ticket states. Convert these exports into a structured list of targets and findings so you can cross-walk them to middleBrick results. Example Python normalization skeleton:

import csv, json
rows = []
with open('qualys_export.csv') as f:
    reader = csv.DictReader(f)
    for row in reader:
        rows.append({'host': row['host'], 'path': row['path'], 'qid': row['QID'], 'severity': row['severity']})
with open('normalized.json', 'w') as out:
    json.dump(rows, out)

Keep normalization simple and version-controlled so you can reliably map legacy findings to current API inventory during and after migration.

middleBrick does not ingest Qualys findings directly; you rebuild tracking by correlating targets and storing JSON scan artifacts. Store each scan output in a dedicated directory keyed by date and commit these artifacts to a versioned store (for example, an S3 bucket or a Git LFS repo). Use the diff capabilities in the Pro dashboard or write a lightweight script to compare new scans against prior runs to surface new findings or resolved items. This gives you a comparable trend line even though the underlying engine and data model differ from Qualys.

During the transition, run both Qualys and middleBrick in parallel on feature branches and merge to a canary environment before full promotion. Wire the middleBrick GitHub Action as a gate with a score threshold; set it to warn but not fail initially so teams can observe delta behavior. Use header allowlist rules to ensure only necessary authentication headers are forwarded when authenticated scans are enabled. If your pipeline must fail on new security issues, gradually tighten the threshold after validating that middleBrick’s severity mapping aligns with your risk appetite.

You will lose some Qualys-specific coverage around deep authenticated crawl workflows and certain legacy host-based heuristics. middleBrick focuses on API surface behavior rather than host posture, so findings tied to server configuration or network segmentation will not appear. You also forgo active exploit attempts such as SQL injection or command injection; these remain outside scope. In return, you gain rapid black-box scans under a minute, OWASP API Top 10 coverage aligned to PCI-DSS 4.0 and SOC 2 Type II, and developer-friendly integrations that do not require agents or SDK changes.

Configure data deletion and retention to match internal policy and audit needs. middleBrick allows on-demand deletion of scan data, with purges executed within 30 days of cancellation. For Pro tier, set up scheduled rescans and HMAC-SHA256 signed webhooks to feed findings into your existing ticketing or SIEM pipelines. Ensure only the domain owner can run authenticated scans by maintaining the domain verification gate; rotate credentials immediately if any are exposed. This operational hygiene reduces noise and keeps long-term comparisons clean and actionable.