Migrating from Snyk to middleBrick

Begin by inventorying the APIs you monitor in Snyk and the scan configurations you rely on. List each target URL, authentication method, and any custom rules or query patterns you have defined. Note which findings you treat as blocking and which are informational, so you can map them to equivalent middleBrick risk scores and detection coverage.

Use the Snyk API to pull vulnerability and test result data. A typical export includes endpoint, severity, title, CVE or OWASP reference, and timestamps. Example using curl and jq:

curl -s -H "Authorization: token ${SNYK_TOKEN}" \
  "https://api.snyk.io/org/${ORG_ID}/v1/issues?project=${PROJECT_ID}" | jq '.issues[] | {id, title, severity, primaryUrl, cve}'

Complement this with audit logs to capture user-driven scans and policy changes. Save these exports as JSON or CSV; they provide the raw evidence you will compare against middleBrick scans to validate coverage continuity.

With your inventory and exports, recreate a timeline of findings in middleBrick by running historical-style scans. For each target, execute a scan using the CLI or dashboard and store the JSON report. Use consistent naming (e.g., api-name-date) so you can diff reports across time.

During cutover, keep Snyk active for one full scan cycle while enabling middleBrick continuous monitoring at the same cadence (daily or weekly). Compare new middleBrick findings against your Snyk baseline to confirm that existing issues are still detected and that no meaningful regressions are introduced.

Wire the middleBrick CLI or GitHub Action into your pipelines as a parallel step before removing Snyk. Configure authentication using Bearer or API key tokens and restrict forwarded headers to the allowed set. Ensure the domain verification gate is completed for each environment so authenticated scans succeed without exposing credentials.

Set the GitHub Action gate to the same severity threshold that Snyk used for blocking builds. Run the action on a feature branch to confirm behavior, then promote to main. Keep Snyk gates active until the middleBrick gate produces identical pass/fail outcomes over several runs.

You will lose Snyk’s library vulnerability database and its framework-specific patch advice. middleBrick does not detect known package versions or supply-chain issues; it focuses on runtime API behavior aligned to OWASP API Top 10, PCI-DSS, SOC 2 Type II, and related audit evidence needs.

In return, you gain black-box scanning that requires no agents, works across any language, and completes in under a minute. Detection coverage includes authentication bypass, BOLA and BFLA, sensitive data exposure such as PII and API keys, SSRF probes, and LLM security testing across multiple tiers. Continuous monitoring and HMAC-SHA256 signed webhooks give you ongoing visibility without maintaining custom scripts.

Plan for data transition by exporting findings and scan metadata, then triggering deletion of stored data in Snyk according to their retention policy. For middleBrick, remember that you can request deletion of scan data on demand; it is purged within 30 days of cancellation and is never used for model training.

When handling compliance evidence, use middleBrick’s mapping to PCI-DSS 4.0, SOC 2 Type II, and OWASP API Top 10 (2023). For other frameworks, rely on alignment language to support audit evidence rather than claiming certification or guarantees. This keeps your documentation accurate and within policy bounds.