MurtaSec

Fictional worked example · SaaS & software

How we would assess
a SaaS platform release.

See how shared workspaces, file handling and integrations could become a focused assessment before a release. This scenario uses fictional data and does not describe completed client work.

The fictional brief

Start with the decision
the assessment must support.

A fictional software company is adding shared project workspaces, new permission levels and a partner API to its SaaS platform. It wants to understand the risks across the application before rolling the release out to existing and new organisations.

Decision to support
Identify weaknesses in the release, prioritise fixes and decide whether the new workflows are ready for a wider rollout.
System in scope
One staging version of the web application, its API and the company-controlled integration code, with agreed web server, CDN and cache settings.
Representative roles
Organisation owner, workspace administrator, member and guest accounts across two fictional organisations, plus an agreed platform-support role.
Information used
Synthetic project records, files and accounts. Partner connections use an authorised sandbox or simulator; real customer data and production systems are outside this proposed scope.
01 / Application

Shared workspaces

Follow project creation, invitations, file sharing and exports across the agreed roles and organisations.

02 / Connected services

API and partner integration

Assess the platform’s API and integration behaviour using test credentials and an approved partner test connection.

03 / Deployment

Configuration around the application

Include the relevant web server, CDN and cache settings agreed for this staging environment.

Planned coverage

Connect each question
to evidence and a boundary.

The OWASP Web Security Testing Guide is the web-testing baseline, informed by OWASP API security guidance. Specialists build on that baseline around the architecture, technology and business rules in the agreed scope. They validate findings and interpret their impact.

Proposed coverage only. No testing has been performed and no results are asserted.
Area Question for the assessment Context and boundaries
Accounts and organisation boundaries Do sign-in, sessions and permissions keep each organisation’s records and actions separate, including guest and support access? Use representative accounts in two fictional organisations. Include invitations, role changes and account recovery in the agreed workflows.
Input, files and application behaviour Does the application handle forms, imports, uploads and exports safely, including injection risks? Follow how input moves through the agreed application and API. Use synthetic files and records within the permitted operating constraints.
Business rules and important actions Do workspace changes, approvals and plan-specific features follow the intended rules? Agree the expected behaviour for membership, ownership transfers and feature access. Real payments and third-party billing systems are outside this example.
APIs and integrations Do API credentials, requests and integration responses preserve the intended access and business rules? Assess company-controlled endpoints and code against the authorised sandbox or simulator. This does not test a partner’s live infrastructure.
Information and deployment settings Could responses, errors, logs or caches expose information, and do the agreed web server, CDN and transport settings support the application’s security? Review the agreed components and available configuration. Differences between staging and production need to be understood before applying conclusions to a release.

Before testing

Make the boundaries
and preparation explicit.

Included scope has limits.

  • This scope covers the named release and workflows, not every product, organisation or infrastructure component.
  • Production, live customer records, real payments and third-party infrastructure are outside this proposed assessment.
  • Sandbox and simulator behaviour may differ from the live partner service. Any production verification needs its own agreed scope.
  • Availability-impacting work is excluded unless specifically agreed. Findings inform your release decision; the assessment does not certify the platform or guarantee it is free of vulnerabilities.

What to prepare.

  • A representative staging build, API documentation and a short map of the application and integrations.
  • Accounts in two fictional organisations, a role-and-permission matrix and examples of permitted sharing.
  • Synthetic files and records, expected workflow rules and authorised sandbox or simulator access.
  • A technical contact, written authorisation, permitted test windows and an agreed escalation route.

Your assessment report

Clear findings.
Practical next steps.

Your report helps you understand the findings and gives your technical team the detail needed to act on them.

What your MurtaSec assessment report includes.
Report section What it contains How it helps
Executive summary A clear overview of the assessment’s key findings and their implications. Give decision-makers a concise view of the risks that need attention.
Summary of findings An overview of the individual findings in one place. Review the issues together and plan the next steps with your team.
Finding details Each finding includes a description, reproduction steps, remediation steps and references. Help your technical team understand the issue, reproduce it and work through the recommended fix.

Let’s plan
your assessment.

Use this example as a starting point. Tell us how your workflow differs, what you need to learn and any requirements the assessment must address.

Talk through your assessment