®Offensive security / Software & SaaS pentesting
Fast releases need a security review that understands your application. OTOKO® analyzes SaaS products, APIs, applications operated on PaaS, and legacy software that has grown over time. The focus is on achievable impact: other tenants’ data, unauthorized actions, misused business logic and the boundaries between user roles. Reproducible findings give your development team a basis for remediation.
Services in detail
Analysis, integration and documented handover
Your brief for OTOKO®
The work packages are derived from your current situation. Your team knows the agreed scope, the required involvement and the results that should be available at handover.
Together, we define important business processes and test roles. We then examine whether a function can be used beyond its intended limits. Automated checks are supplemented by manual analysis of the application.
Assessed findings with business impact and verifiable evidence.
Tenant assignment, object access and privileged functions are tested within the approved scope. A dedicated test data set makes the impact assessable without having to use other customers’ data as evidence.
Documented review of the agreed role and tenant boundaries.
For PaaS applications, we look at the settings and interfaces you are responsible for. For legacy systems, known operating limits and dependencies are included in the test planning. Third-party platforms remain outside the scope wherever approval has not been granted.
Defined test scope with methods suited to the technical and operational context.
Findings are prioritized and discussed with your development team. The agreed retest checks whether the specific cause has been fixed in the new version. Results refer to the scope and point in time actually tested.
Technical report, management summary and documented retest results.
Planning & implementation
A SaaS product does not consist only of publicly reachable endpoints. Different roles, invitations, exports, background tasks and administration functions together make up the business logic. Before testing, we therefore clarify which processes need particular protection and which boundaries the application is meant to enforce. This view complements conventional technical checks. A function can respond in a formally correct way and still permit an action that is not intended for the logged-in person or their tenant.
This forms the basis for a coordinated test scope. Black-box, gray-box or white-box elements are chosen according to the goal and the available information. If source code or architecture documentation is provided, observations can be interpreted more precisely. The test focuses on the authorized application and uses the agreed accounts and data. A tool finding is not treated as a confirmed vulnerability without assessment; the impact and prerequisites must be clear to your team.
For SaaS and PaaS, the boundary of responsibility is decisive. Testing your application or configuration is not automatically permission to attack a platform operator’s infrastructure. Together, we record objectives, permitted methods and required approvals. APIs and integrations are tested against the intended scope of data and permissions. Particular attention is paid to whether different roles and tenants remain reliably separated in the actual application paths.
Legacy software often calls for a different approach. Documentation can be incomplete, test environments reflect the production system only partially and individual components can be sensitive to load. These conditions belong in the planning before the start. We agree on test windows, available points of contact and abort criteria. Where a check cannot be carried out responsibly, this limitation is made visible in the result. This makes clear what conclusions the test supports and where additional investigation would be required.
A report is meant to enable a decision and help developers with the fix. A confirmed finding therefore describes the affected version, the prerequisites, the agreed evidence and the possible impact. Management and technical teams need different levels of detail here. Prioritization takes the application context into account, instead of just producing a long list of equally weighted findings. Evidence is limited to what is necessary and shared through agreed channels with authorized points of contact.
The fix is discussed with your team; an agreed retest evaluates the specific change. A resolved finding, however, does not automatically mean that the entire application is free of vulnerabilities. New releases and configuration changes can alter the starting situation. On request, this can be developed into a regular review of important changes. For suitable, clearly defined targets, Result as a Service can also be agreed: payment then depends on a result that is defined in advance and proven.
Illustrative project scenario
Two separate test tenants represent regular users and administration. Before the release, the agreed business processes and permission boundaries are examined. The team receives prioritized evidence and checks the fixes in the retest, without needing other customers’ data for the demonstration.
Before you start
Yes. For legacy applications, we plan around their operating limits, available test environments and dependencies. Checks that cannot be carried out are noted as a limitation in the report.
Scanners support the work. Business logic, roles and the actual application context, however, require expert assessment and targeted manual testing.
For suitable projects, a proof of result defined in writing with a fixed amount can be agreed. Without this proof, the agreed success-based penetration testing fee is not charged. Details are on the Result as a Service page.
No. The conclusion relates to the agreed scope, the version tested and the time window. The absence of findings is not a general security guarantee.
Related services
Software & SaaS pentesting with OTOKO®
Name the affected systems and the goal of your request. In the first consultation, we jointly define scope, preconditions and the next steps.
Discuss Software & SaaS pentesting
