Customer SOC 2 questionnaire prep
What middleBrick covers
- Black-box scanning of any API runtime without agents or SDKs
- Maps findings to SOC 2 control evidence and OWASP API Top 10
- OpenAPI 3.x and Swagger 2.0 parsing with recursive $ref resolution
- Authenticated scans with Bearer, API key, Basic auth, and cookies
- CI/CD integration via GitHub Action and CLI with JSON output
- Continuous monitoring with diff detection and scheduled rescans
What customer SOC 2 questionnaires require
SOC 2 Type II questionnaires evaluate the design and operating effectiveness of security controls. Reviewers look for evidence that access to customer data is governed by authentication, authorization, encryption, monitoring, and change management practices. They ask how access is provisioned, how permissions are reviewed, how secrets are stored, how logs are retained, and how incidents are detected and responded to. The control narrative must be backed by artifacts such as policy documents, configuration screenshots, audit logs, and test results. Responses that are vague, incomplete, or based on assumed rather than observed behavior increase audit risk and remediation effort.
Risks of skipping a structured evidence workflow
Without a repeatable workflow, teams rely on ad hoc screenshots and memory, which do not age well and are difficult to verify. Controls that appear correct in documentation may not match runtime behavior, leading to control failures during testing. Privilege creep, unused admin endpoints, and overexposed data fields are common when there is no continuous mapping between specification and deployment. Evidence gaps also complicate incident response, because the necessary context about who accessed what and when is incomplete or inconsistent.
A good evidence collection workflow
Start by inventorying all public and authenticated API endpoints that serve customer data. Capture the runtime behavior of each endpoint using read-only methods, then compare findings to the published specification such as OpenAPI definitions. Classify findings by control relevance, noting which requirements they support evidence for. Store artifacts centrally with versioned snapshots, and retest on a scheduled basis to detect new deviations. Prioritize findings that directly affect access control, data exposure, and auditability.
What middleBrick covers out of the box
middleBrick is a black-box API security scanner that submits read-only requests to your runtime services and maps findings to SOC 2 control evidence. It parses OpenAPI 3.0, 3.1, and Swagger 2.0 specifications with recursive $ref resolution and cross-references definitions against observed behavior. The scanner detects issues in authentication bypass, JWT misconfigurations, IDOR, privilege escalation, data exposure, encryption settings, and input validation. For authenticated scans, it supports Bearer tokens, API keys, Basic auth, and cookies, with domain verification to ensure only domain owners can submit credentials.
Mapped findings and reporting for audits
Findings are organized to help you map evidence to control objectives. Each result includes a risk score, a description, evidence such as HTTP responses and parameter values, and remediation guidance. You can generate branded compliance PDFs from the dashboard to attach to questionnaires. The CLI provides JSON and text output for automation, and the GitHub Action can gate CI/CD when scores drop below your defined threshold. Continuous monitoring keeps a diff of findings over time, highlighting new security drift and resolved items.
Limitations and complementary practices
middleBrick is a scanning tool and does not fix, patch, or block issues. It does not test business logic, perform intrusive payloads for SQL or command injection, or detect blind SSRF via out-of-band channels. It cannot replace a human pentester for high-stakes audits or provide compliance certification. Use it to surface findings relevant to control testing, then validate and remediate with your internal processes and specialist review where necessary.