Migrating from Veracode to middleBrick
What middleBrick covers
- Black-box API scanning with under one minute turnaround
- Read-only methods to ensure safe, non-intrusive testing
- 12 OWASP API Top 10 categories with prioritized findings
- OpenAPI 3.0/3.1 and Swagger 2.0 spec parsing
- Authenticated scanning with header allowlist controls
- Score trends, compliance mappings, and exportable reports
Planning the migration
Begin by inventorying the APIs currently analyzed in Veracode. Export scan records and policy configurations so you have a clear baseline of findings, risk grades, and tracked remediation work. Map Veracode policy rules to middleBrick categories, noting which checks align with authentication, authorization, input validation, and data exposure. Decide on a cutover window that minimizes disruption, and ensure domain ownership verification records (DNS TXT or HTTP well-known file) are in place before enabling authenticated scans.
Exporting data from Veracode
Veracode provides scan data through its UI and platform APIs. Export findings in a structured format such as XML or JSON, including finding IDs, severity, CWE references, and affected components. Retain historical reports to compare later results in middleBrick. Note that Veracode’s detailed remediation steps and legacy policy constructs may not have direct equivalents; plan to translate them into middleBrick’s prioritized findings and remediation guidance.
Rebuilding scan history
middleBrick does not ingest Veracode exports to recreate historical findings. Instead, use the exported data to manually recreate a comparable baseline, focusing on high-severity items and recurring problem areas. Track key metrics such as authentication bypass attempts, sensitive data exposure, and rate-limiting gaps. As you run initial scans in middleBrick, log the date and scan parameters so you can construct a timeline that approximates your Veracode history.
CI/CD continuity during cutover
Keep your Veracode pipeline stage active while introducing the middleBrick CLI or GitHub Action in parallel. Run middleBrick scans on the same set of APIs and compare scores and findings. Configure the middleBrick GitHub Action to fail the build only when new critical findings appear, avoiding false gates during the transition. Gradually shift enforcement to middleBrick once confidence in the parity of results is established, and then decommission the Veracode CI step.
What you’ll miss and what you’ll gain
You will lose Veracode’s deep binary analysis and its extensive language-specific rule set, as middleBrick is a black-box HTTP/API scanner without code instrumentation. You will also lose built-in remediation code suggestions that are tightly coupled to Veracode’s platform. In return, middleBrick provides faster scan turnaround, straightforward read-only testing that avoids intrusive payloads, and clear mapping to OWASP API Top 10, PCI-DSS 4.0, and SOC 2 Type II. The dashboard offers score trends, branded compliance PDFs, and flexible integrations with webhooks, Slack, Teams, and CI systems, while keeping scan data deletable on demand.
Final cutover checklist
Before switching fully, verify that domain ownership is validated for authenticated scans, confirm that allowed headers are limited to Authorization, X-API-Key, Cookie, and X-Custom-* headers, and ensure sensitive endpoints such as cloud metadata addresses are not inadvertently exposed. Run a parallel monitoring window where both tools operate, confirm that risk scores and finding categories align within acceptable variance, and update runbooks to reflect new workflows. Archive Veracode exports for audit reference, then redirect CI gates to use the middleBrick CLI or GitHub Action and enable continuous monitoring for ongoing posture tracking.