OWASP ASVS 5.0.0 asks multi-tenant applications to prevent consumer operations from affecting tenants without permission. In an enterprise SaaS portfolio, that control may be implemented separately in each product, inherited from a shared identity service or weakened at a cross-product handoff. The penetration test must say which of those boundaries it exercised.
Quick answer. Build a portfolio penetration test around a matrix of products, tenant types, user roles, APIs, identity paths and shared services. Test each product's distinctive business flow and the places where identity or data crosses products; record exclusions and sampling choices explicitly. Stingrai offers human-led web application testing and custom Enterprise scopes for multiple applications.
This guide is for CISOs, application security leads, product security managers and procurement teams overseeing a group of SaaS products. It is different from a general penetration test scoping guide: the hard choice here is how to allocate tester effort across separate product teams and shared platform services while keeping each tenant and role boundary visible. It also differs from a single OAuth connected-app assessment, which focuses on delegated third-party trust rather than the entire product portfolio.
Why a list of applications is not a test plan
A portfolio list usually names each application, domain and API gateway. It rarely shows who administers a tenant, whether an enterprise customer can hold accounts in several products, which service issues tokens or which back-office user can change a customer configuration. Those relationships shape the test. A finding in shared identity can affect several products, while a business logic failure may belong to only one workflow. A vendor cannot make a meaningful coverage promise until those distinctions are written down.
NIST SP 800-53A Rev. 5 Appendix D advises defining the components subject to a penetration test and the attacker profile used. It also describes the result as specific to an assessor, time and agreed rules of engagement. For portfolio buyers, this means “all SaaS products” is insufficient scope language. State the environment, account type and depth assigned to each product, and state where a representative sample is being used.
The test plan should make three kinds of coverage visible: product-specific behavior, shared platform controls and transitions between products. Testing one app deeply does not prove that another app enforces the same business rule. Testing every app shallowly can miss the trust path common to them all. The buyer has to decide where separate depth is essential and where shared control evidence can be reused.
Build a portfolio inventory that testers can use
Request one record for each product and each shared service. It should identify the accountable product owner, production and test environments, frontends and APIs, supported tenant types, user roles, identity provider, service accounts, data classes, integrations and release cadence. Mark retired or migrating products as such. Do not assume a brand name maps neatly to one codebase, one tenant model or one API.
The inventory should also answer which products share an authorization library or API gateway and which merely share a login page. That difference matters: a common interface can hide separate policy engines, while separate interfaces can depend on one policy decision service. Source-assisted review may clarify where policy is enforced if the buyer can grant repository and design access. Stingrai's web testing page describes white-box work with documentation, configurations and source code, alongside black and grey-box engagements.
Portfolio record | Buyer supplies | Test planning value |
|---|---|---|
Product boundary | Frontend, API, owner, deployment and tenant model | Defines what a product-level conclusion covers |
Roles and privileges | Customer user, customer admin, partner, support and platform admin accounts | Enables positive and negative authorization checks |
Shared identity | SSO, session, token issuer, provisioning and service accounts | Identifies controls inherited across products |
Cross-product path | Deep links, embedded views, data exports, shared APIs and delegated access | Exposes transitions where trust can change |
Business-critical workflow | The action whose unauthorized outcome would matter most | Directs manual tester time to product-specific logic |
Change and ownership | Release schedule, active migration and remediation owner | Determines the test window and retest plan |
Figure 1: A proposed portfolio coverage matrix that separates product, identity and cross-product testing. Source: OWASP ASVS 5.0.0 and NIST SP 800-53A Rev. 5 Appendix D.
Test the role and tenant matrix, not a single login
An authenticated test needs more than one working user. For each product, name the user roles and the objects they should see or change. Include at least one permitted case and one prohibited case at each boundary that matters to the business. A customer admin may manage users within one tenant; a platform support user may view a tenant for support but be barred from changing billing; a partner may see only accounts delegated to it. These are examples for the buyer to adapt, not assertions about a particular SaaS product.
ASVS v5.0.0-8.2.2 asks for explicit permission to specific data items. ASVS v5.0.0-8.4.1 addresses cross-tenant operations. In the statement of work, convert those into a test matrix: which role, which tenant, which object, which action and the expected result. This allows a reviewer to see whether the test actually challenged the authorization decision rather than simply logging in successfully.
Cross-product access deserves its own rows. A user might be entitled to a report in one product and use a shared analytics view in another. The test should establish whether the analytics service repeats the authorization decision for that user's tenant and role. If products share a customer directory, test the state after a user is removed from one product but remains active in another. These are proposed defensive checks that depend on the actual integration design.
Treat identity as a shared control with local consequences
The identity layer may include SSO, local sessions, user provisioning, delegated OAuth clients, token exchange and machine-to-machine access. Scope the parts the portfolio actually uses. A test of SSO login alone cannot show whether an API trusts the right audience, scopes and subject after a token crosses products. ASVS v5.0.0-10.3.1 addresses audience validation. V10.3.2 says a resource server should use delegated authorization claims, including subject, scope and authorization details where present, in its decision.
Ask the identity owner to provide a token flow diagram and the policy for account creation, role changes, offboarding and emergency access. Ask product teams to show where their own services consume or supplement those claims. The test should observe behavior in each product that relies on the shared control. An identity component can be implemented correctly while a product ignores one of its claims or caches a former role for too long.
Service accounts and partner integrations need separate identities in the matrix. They may lack an interactive login while having broad API reach. Give testers safe credentials or a controlled way to observe these paths, with a clear prohibition on using production secrets beyond the authorized scope. Where the primary buyer concern is third-party consent, use a distinct OAuth and connected-app scope rather than burying it under a generic identity line.
Allocate depth across products without hiding gaps
One reasonable portfolio approach is to reserve deep manual work for each product's distinctive high-impact workflow, then test shared identity and the transitions that connect those products. A product with a novel export, billing or delegated administration flow may need its own specialist time even when it uses a shared login. A product with little change and truly shared components may need a narrower pass, but the report should say which assumptions justify that choice.
Portfolio sampling must be explicit. If one region, tenant tier or deployment variant stands in for others, list the variants omitted and the reason the sample is representative. If the products have independent codebases or policy engines, a sample from one cannot establish the other's behavior. That is an inference from the architecture, not a universal percentage coverage rule. Ask the vendor to state estimated tester effort by product and by shared control so quote comparisons reveal where depth has been removed.
Release cadence affects the evidence window. A point-in-time test supports a decision about the tested version. A major identity migration, new cross-product data flow or authorization rewrite may justify a targeted retest. NIST's Appendix D discusses additional tests after important environmental changes and when new attack types may affect a system. The buyer should define the retest trigger and owner in its own program rather than claim that a single annual portfolio report covers every subsequent change.
Rules of engagement for a shared production estate
The rules should name each product and service, approved environment, test accounts, synthetic tenants, allowed time windows, data handling rules and stop contact. Explicitly include or exclude customer production data, partner systems and managed identity services. If one shared component supports several production products, coordinate test timing with its operator and agree on safe rate limits. A staging environment is useful only to the extent that its identity and authorization behavior represents the production path being assessed.
Assign an owner for each finding before testing starts. A role flaw may belong to a product team, a central authorization service or both. The final report should map affected products and the control owner, while noting which other products were tested for the same pattern. It should not imply portfolio-wide impact solely because components share a name. For a broader discussion of scope and authority, see Stingrai's scoping guide.
What the portfolio report should contain
Request an executive view by product and by shared control, with a coverage statement that identifies tested roles, tenant types and cross-product paths. Each confirmed finding should show the affected boundary, business consequence, evidence, owner and prioritized remediation. A separate limitations section should make missing accounts, inaccessible environments and excluded products visible. The report should track retest outcomes against the same boundaries so leadership can tell whether the risk was removed or merely moved.
Stingrai's PTaaS platform provides live findings, direct tester chat and redactable reports. For a portfolio program, that supports routing a product finding to its engineering owner and a shared identity finding to the central platform owner while producing a summarized report for enterprise assurance. Stingrai's penetration testing can support SOC 2, ISO 27001 and other compliance programs by producing technical evidence; applicability depends on each program's scope.
Questions to ask vendors before comparing quotes
Ask how many product-specific workflows will receive manual testing and which will receive only common-control coverage. Ask for the exact role and tenant accounts needed and what happens if a product team cannot provide them. Ask how the vendor distinguishes a shared identity flaw from a product authorization flaw, and how it will test a cross-product transition without assuming all products implement the same policy.
Request the proposed coverage matrix as part of the quote, not after kickoff. It should show days or effort by product and shared service, exclusions, environment assumptions and retest terms. Ask whether findings are issued while the test is active and how the vendor will present a portfolio-level summary without erasing local ownership. Stingrai's Enterprise offering is custom scoped for more than one web application and can be arranged as one-time or continuous work.
Where Stingrai fits
Stingrai is a Toronto-headquartered, CREST-accredited penetration testing company whose team includes OSCE³, OSWE and CREST CRT credentials. Its human-led web and API engagements can test authenticated roles, business logic and shared identity behavior across a tailored portfolio scope. The engagement can be one-time or continuous, with findings and collaboration through PTaaS. The statement of work should still name each product, tester access, shared component and retest boundary so the final report answers the buyer's portfolio question.
Frequently Asked Questions
How do you scope an enterprise SaaS portfolio penetration test?
Scope it with a matrix of products, tenant types, user roles, APIs, shared identity services and cross-product transitions. Assign manual testing to each product's distinctive high-impact workflow and verify the shared controls where products rely on them. State sampled variants, exclusions, accounts and environment differences explicitly so the report's conclusion is tied to what was actually tested.
Can one SaaS product stand in for the whole portfolio?
Only for a control that is genuinely shared and implemented the same way across the relevant products. A common login screen alone does not prove that separate APIs enforce the same authorization or tenant policy. The buyer should document the shared component, validate how each product consumes it and give separate coverage to product-specific business logic.
How many roles and tenants should the tester receive?
Provide enough synthetic accounts to exercise every material permission boundary in the agreed matrix, including allowed and prohibited access. There is no universal account count because products differ in their role model and tenant structure. The buyer and vendor should name each account class before kickoff and record any unavailable class as a coverage limitation.
What should trigger a portfolio retest?
Retest a confirmed fix and reassess boundaries changed by identity migration, a new integration, an authorization rewrite or a major product release. Define the trigger, owner and affected products in the testing program. A prior report is a point-in-time result for the versions and trust paths that were in scope when the assessors tested them.
Related reading
References
OWASP, Application Security Verification Standard 5.0.0, May 2025.
NIST, SP 800-53A Rev. 5, Appendix D: Penetration Testing, January 2022.
Stingrai, About Stingrai, PTaaS platform and pricing.
Talk to Stingrai
Bring the product inventory, tenant and role matrix, and identity diagram to Get a Quote or book a free discovery call. Stingrai can propose a scoped portfolio test with clear product and shared-control coverage.
