Migrating from 42Crunch to middleBrick for CI/CD security gate

What middleBrick covers

Black-box API scanning with no agents or SDKs
Risk scoring A–F with prioritized findings
OWASP API Top 10 aligned detection
CI/CD gate via CLI exit codes
Authenticated scanning with header allowlist
Post-scan monitoring and webhook integration

Why migrate CI/CD security gates from 42Crunch to middleBrick

The primary motivation for migration is removing the intrusive, build-blocking steps common with agent-based scanners while retaining gate integrity. 42Crunch requires instrumentation, agents, or network proxies that add complexity and change application behavior. middleBrick operates as a black-box scanner that submits only read-only methods to a public URL, producing a risk score and prioritized findings in under a minute. This supports a CI/CD security gate that fails builds based on score thresholds without requiring code changes or secrets in the runtime environment.

Scan workflow and gate configuration changes

In 42Crunch, scans often depend on runtime agents, injected sidecars, or network-level interception that must be present for tests to execute. With middleBrick, the workflow shifts to a simple URL submission model. Your pipeline calls the CLI or API with the target endpoint, receives a structured result, and applies policy gates. Example using the CLI:

middlebrick scan https://api.example.com --threshold C --output json

The command returns a non-zero exit code when the score is at or below the threshold, allowing native CI/CD conditions to block promotion. No build-side proxies, service accounts, or injected traffic are required.

Mapping findings to compliance frameworks in CI/CD evidence

middleBrick maps findings directly to OWASP API Top 10 (2023), PCI-DSS 4.0, and SOC 2 Type II controls, which is useful for audit evidence within your pipeline. You can embed compliance checks as gates that enforce specific control coverage. For example, you can configure the gate to fail when findings mapped to authentication or data exposure categories exceed a defined count. Unlike claims of certification, this approach treats the scanner as an evidence source that supports audit activities rather than guaranteeing compliance.

Authenticated scanning and credential handling

If your API requires authentication, middleBrick supports Bearer tokens, API keys, Basic auth, and cookies at the Starter tier and above. Domain verification via DNS TXT record or HTTP well-known file ensures only the domain owner can submit credentials for scanning. The scanner forwards a strict allowlist of headers, including Authorization and X-API-Key, and does not attempt to remediate or modify requests. This keeps the gate read-only and avoids side effects in production-like environments used for testing.

Post-scan integration and monitoring considerations

After the gate passes, you can integrate continuous monitoring using the Pro tier to schedule rescans and track score trends over time. The system can emit diffs between scans, highlighting new findings or resolved items, and send alerts via email or HMAC-SHA256 signed webhooks. Note that the scanner does not fix or patch findings; it reports prioritized remediation guidance. You remain responsible for interpreting results in the context of your API design and business logic.

Frequently Asked Questions

Will this migration require changes to how tests are triggered in our pipeline?

Yes. You replace agent or proxy-based test steps with a URL submission and threshold check using the CLI or API. No test logic changes are needed downstream.

Can authenticated scans run against staging environments only?

Yes. Provide credentials only for staging-like environments and use domain verification to ensure scans are authorized. The scanner does not store or reuse credentials beyond the scan session.

Does the scanner validate controls required by SOC 2 or PCI-DSS?

It maps findings to SOC 2 Type II and PCI-DSS 4.0 controls, providing evidence that supports audit activities. It does not certify compliance.

What happens to scan data after account cancellation?

Customer scan data is deletable on demand and purged within 30 days of cancellation. Data is not sold and is not used for model training.

Can the gate fail the build based on new critical findings only?

Yes. Configure the threshold to fail on specific risk scores or findings so that only new critical issues block promotion while lower-sever items are tracked separately.