Migrating from Apigee to middleBrick

Begin by inventorying the APIs you protect in Apigee and the security signals you already collect. Export API definitions and test results so they can be mapped to middleBrick inputs.

• Use the Apigee Management API to list all API products, environments, and deployed revisions.
• Export security policy configurations and any custom JavaScript or Python policies that implement authentication or validation logic.
• Extract access logs for a representative window to understand traffic patterns and existing error rates.

Keep these exports in a secure, versioned location so they can be referenced during validation and to support audit evidence for prior configurations.

middleBrick does not ingest prior scan data, so you will re-create the coverage using exported endpoints and documentation. This preserves the intent of historical reviews while using the new toolchain.

• Compile a canonical list of production endpoints from your Apigee inventory, including paths, methods, and authentication mechanisms.
• For each endpoint, record the expected request/response schema and any sensitive data flows (tokens, PII, payment fields).
• Run middleBrick scans on this inventory; store results in the dashboard and export reports to compare findings with your previous posture.

You will not reproduce identical historical scan artifacts, but you will achieve equivalent coverage through deliberate endpoint registration and ongoing monitoring.

Maintain security gating in your pipelines while transitioning from Apigee-native checks to middleBrick. The CLI supports JSON output for automation and can fail builds on poor scores.

middlebrick scan https://api.example.com/openapi.json --output json > mb-results.json
if jq -e '.score < 3' mb-results.json; then exit 1; fi

During the cutover, run the CLI in parallel with existing checks. Use the GitHub Action to enforce thresholds and surface results in pull requests. Limit header forwarding to Authorization, X-API-Key, Cookie, and X-Custom-* to avoid leaking sensitive values.

Note that business logic risks and blind SSRF are outside the scanner scope; retain manual code review and threat modeling for those areas.

middleBrick is a read-only black-box scanner and does not replace every component of a mature Apigee security program. You will lose some capabilities and must plan alternatives.

• Detailed API proxy debugging and policy-level trace logs are not available; rely on platform-native monitoring for latency and error analysis.
• Custom security policies and JavaScript plugins that enforce bespoke rules must be translated into testable API contracts or validated through manual review.
• Blind SSRF and out-of-band data exfiltration paths are not probed; include these in manual penetration tests and architecture reviews.

Compensate with explicit endpoint definitions, strong authentication configurations, and scheduled manual assessments for high-risk surfaces.

After migration, use middleBrick to maintain continuous visibility and align reporting with recognized frameworks. The scanner maps findings to OWASP API Top 10 (2023), supports audit evidence for SOC 2 Type II, and aligns with PCI-DSS 4.0 control objectives.

• Enable Pro-tier continuous monitoring for scheduled rescans and diff detection across scans.
• Configure email alerts and HMAC-SHA256 signed webhooks to integrate findings into incident response playbooks.
• Generate branded compliance PDFs for documentation and stakeholder reporting.

Remember that the tool detects and reports; it does not fix, patch, or certify compliance. Use its output to guide remediation decisions and to support audits rather than to prove compliance directly.