A new architecture or a major change
A first public API, a move to multi-tenancy or a new identity provider, while design decisions are still cheap to change.
Turn a security risk into a working control
Threat-model reviews, authorization design, CI controls and remediation for product teams. Bounded work with a named owner, written acceptance criteria and a handover your engineers can maintain.
When teams ask for this
A finding that keeps coming back
Each pentest finds another endpoint missing a tenant check. The fixes land; the authorization model underneath has not changed.
A reviewer asks how a control actually works
An enterprise customer or SOC 2 auditor wants evidence for access reviews, change management or logging the system only partly produces.
An integration gains more authority
An OAuth app, CI deploy identity or AI agent is about to read customer data or act. It needs a permission boundary before it ships.
What a finding looks like
A synthetic example in the format your report uses: evidence, impact, fix.
Export permission checked globally, not against the target workspace
- Asset
- api.example.com · POST /v2/exports
- Caller
- Analyst in workspace ws_102 (synthetic Tenant A)
- Standard
- CWE-863 · OWASP API Security Top 10 2023 API1 · ASVS 5.0 V8
Impact. A user with export permission in one workspace can export another tenant's customer data by changing one body field.
Fix. Evaluate permission against the target workspace through one policy function, deny by default and add role-by-tenant regression tests.
Evidence · request → response
POST /v2/exports HTTP/1.1 Host: api.example.com Authorization: Bearer <analyst token, workspace ws_102> Content-Type: application/json {"workspace_id":"ws_317","dataset":"customers","format":"csv"}
HTTP/1.1 202 Accepted Content-Type: application/json {"export_id":"exp_88f1","workspace_id":"ws_317","status":"queued", "download_url":"https://files.example.com/exp_88f1.csv"}
What we test
Named test areas and checks. The scope record in your proposal confirms which apply to your system.
Architecture and threat-model review4 checks
- Data-flow and trust-boundary map
- Identities: users, tenants, services, CI and support staff
- Threat scenarios tied to named components
- Prioritised design changes and a scoped test plan
Authorization design4 checks
- Role, permission and tenant matrix
- Enforcement points: gateway, handler, policy layer or query
- Tenant scoping in data access, not only route guards
- Impersonation, admin roles, sharing and delegation
Secure SDLC and CI controls4 checks
- Branch protection, required review and release approval
- Pipeline secrets and short-lived CI cloud credentials
- Dependency and static analysis tuned to the codebase
- Security regression tests on every merge
Remediation engineering4 checks
- Root-cause analysis of findings and related paths
- Fix design with acceptance criteria
- Reviewed pull requests, where commissioned
- Regression tests for original and nearby paths
SOC 2 technical control support3 checks
- Map listed technical controls to actual system behaviour
- Tighten access reviews, change management and logging
- Make the system produce evidence an auditor can inspect
What you receive
Items marked “terms to confirm” are set out in your proposal.
| Deliverable | Status |
|---|---|
| Threat model and design reviewData-flow map, threat scenarios, gaps and ranked design changes. | Included |
| Authorization modelRoles, actions and tenant scope, with each rule's enforcement point. | Included |
| Security regression testsTests that stop a later change silently removing agreed controls, where implementation is in scope. | Terms to confirm |
| Implementation pull requestsReviewed changes against acceptance criteria; stack support confirmed at scoping. | Terms to confirm |
| Control evidence notesHow each agreed control operates and where its evidence is recorded. | Included |
| Handover and remaining-risk registerWalkthrough, operating notes and outstanding work. | Included |
| Independent verification of fixesRetesting by a tester who did not write the changes. | Terms to confirm |
What we need, and what this is not
What we need from you
- A named engineering owner who can accept changes.
- Architecture documents or a walkthrough; for remediation, the findings and repositories.
- Written agreement on access and who approves each change.
- For SOC 2 work, your control list or auditor request list.
Not included
- SOC 2 attestation, ISO 27001 certification or any audit opinion.
- Policy writing and compliance programme management.
- Monitoring, managed detection and incident response.
- Penetration testing, which is scoped separately.
- Independent verification of changes ZenoPentest implemented, unless arranged separately with a tester who did not write them.
How we approach it
What security engineering covers here
Security engineering is the work between a design decision and a control that holds up under test. It answers questions a pentest report raises but cannot settle on its own: why did this class of bug happen, where should the check live, and how do we stop it returning?
Every engagement starts from a concrete problem: an architecture, a set of findings, a pipeline or a control list. It ends with artefacts that live with the system, such as design records, tests and reviewed changes, rather than a slide deck.
Starting points
An architecture under change
A threat-model review maps where data flows, which identities can act on it and which boundaries the design relies on. The output is a short list of design changes ranked by consequence, plus a test plan for the assumptions that need proof.
A backlog of findings
Remediation starts with root cause. Ten “missing tenant check” findings are usually one design gap: authorization decided per handler instead of in one place. Fixing the model removes the class; fixing ten endpoints leaves the eleventh.
A control someone needs to see working
Enterprise reviewers and auditors increasingly ask how a control operates, not whether a policy exists. The work is making the system behave as described and record that it did.
Why authorization design is its own workstream
Authorization failures are some of the most consequential findings in multi-tenant software and among the hardest to fix piecemeal. Design work here typically covers:
- A written matrix of roles, actions and tenant scope that engineers and reviewers can both read
- One enforcement point per resource type, with deny by default
- Tenant scoping applied in data access, so a forgotten route guard does not expose another customer
- Explicit rules for support impersonation, sharing and service accounts
- Regression tests that exercise each role against each tenant boundary
The synthetic finding on this page shows the pattern: a permission evaluated against the caller’s roles anywhere, rather than against the workspace being acted on.
Pipeline and SDLC controls
CI is a privileged system. Review covers who can merge and release, how secrets reach builds, whether deploy identities use short-lived credentials scoped to one environment, and whether security tests block a merge or only report. Tooling is chosen and tuned to the codebase, so engineers keep paying attention to its output.
SOC 2: supporting controls, not attestation
For teams preparing for a SOC 2 examination, ZenoPentest can help the technical controls on your list work as written. Examples include access reviews that come from real identity data, change management enforced by branch rules, and logging that records administrative actions. The CPA firm performs the examination and issues the report. Nothing here is an attestation or a promise of a clean opinion.
Review, implementation and verification stay separate
The proposal states which of the three roles ZenoPentest holds. If ZenoPentest implements a fix, that is disclosed, and independent verification goes to someone else where a reviewer requires it.
How an engagement runs
- Define the problem. Agree the system boundary, access, owner and acceptance criteria in writing.
- Review or build. Carry out the commissioned review or changes, keeping rationale and evidence beside the work.
- Validate. Check each agreed criterion and record what was and was not validated.
- Hand over. Walk the owning team through the work and the risks that remain.
What shapes the scope
Packages have published starting prices. These factors move a quote up or down.
See pricingSystem boundary
Services, tenants, identity providers and integrations in scope.
Review or implementation
Design review only, or code changes too, and in which stack.
Readiness
Documentation, environments and speed of access.
Findings and controls
How many, and how far they share a root cause.
Independence
Whether a reviewer needs verification by someone who did not implement.
Buying directly, or through an agency
Buying for your own product
Your engineering lead is the client. Where implementation is in scope, ZenoPentest works in your repositories and CI; the proposal names who approves, merges and accepts the handover.
Buying through an agency
The agency or its client commissions. Agree beforehand who owns the code, who merges changes, whether ZenoPentest speaks to the end client and whose name the review carries. Remediation can sit inside the agency's sprint.
Being confirmed
- Delivery model (in-house or partner-led) and named engineering lead.
- Stacks supported for implementation, and whether implementation is offered at launch.
- Independent verification arrangement for fixes ZenoPentest implements.
- Prices, timelines and handover terms.
How the engagement runs
How we work, step by step- 01Scoping callScope record
- 02Written scope and authorisationSigned authorisation
- 03Access and test accountsAccess checklist
- 04Testing windowCritical-issue escalation
- 05ReportReport and evidence
- 06ReadoutEngineer walkthrough
- 07RetestVerification ledger
Methodology behind this service
- Authentication and sessionsHow sign-in, recovery, multi-factor, federated login, sessions and tokens are tested across every entry point, including the mobile API and the legacy endpoint nobody remembers.
- Authorization and tenant isolationHow we test that every role can do only what it should, and that one customer organisation can never reach another's data, using a role matrix and at least two test tenants.
- Reporting and retestHow findings are evidenced, rated and written up, how the readout works, and how fixes are retested and recorded so a reviewer can see what changed.
Questions about security engineering
How is this different from a penetration test?
A pentest exercises defined attack paths and reports what it reached. Security engineering reviews or changes how controls are built. Each often feeds the other, but each has its own scope and deliverables.
Can you implement fixes rather than only recommend them?
Implementation can be commissioned as bounded work with agreed pull requests, tests and acceptance criteria. Supported stacks are confirmed at scoping and named in the proposal.
Can the same provider verify fixes it wrote?
ZenoPentest discloses any implementation role. Where a reviewer needs independent verification, a tester who did not write the change verifies it, or you use another provider.
Will this get us through SOC 2?
No engagement can promise that. An independent CPA firm examines and reports. This work helps technical controls operate as described and produce evidence the auditor may review.
Do you need production access?
Usually not. Most work happens in repositories, CI and non-production environments. Any access is least-privilege and approved in writing by the system owner.
What determines the cost and timeline?
The scoping factors above become a written proposal. No fixed turnaround is assumed.
Is this an ongoing vCISO or security retainer?
No. Each engagement has a defined boundary, owner and output. Any ongoing arrangement is a separate agreement.
Related services
- AI application securityA scoped review and test of AI features in your product: data access, retrieval boundaries, tool and agent permissions, prompt injection resilience and output handling, mapped to OWASP guidance for LLM and agentic applications.
- Integration security reviewsA scoped review and test of the integration surface software companies expose to enterprise customers: SSO (SAML and OIDC), SCIM provisioning, OAuth apps and scopes, webhooks, API keys, data sync and marketplace apps, for product teams and the agencies that build them.
- Penetration testingA scoped, manual assessment of a web application and its APIs: authentication, sessions, authorisation, tenant isolation, business logic, input handling and the API surface, reported with request-level evidence and specific fixes.
Scope your security engineering.
Tell us the system and the requirement behind it. You get scoping questions, then a fixed quote.