· Yair Knijn
The penetration test that only covered the flagship app, not the eight around it
The IT director books one pen test a year and scopes it to the flagship product. The reasoning is clean on a spreadsheet: that app holds the most users, earns the most revenue, and a per-application test costs real money. Nine apps at full scope is a number nobody approves. So the supporting estate, the billing tool, the support portal, the analytics add-on, the eight smaller things customers actually log into, get a line in the scope document that reads out of scope.
The wrong assumption is that the flagship is the perimeter. It is not. It is one host inside a perimeter that the other eight apps share. A clean report on the front door tells the customer's security team nothing about the side entrances, and they know it.
Why single-app scope leaves the estate's real attack surface untested
A pen test proves an exploit path exists. It cannot prove the absence of risk in systems it never touched, and a single-app scope draws the boundary too small to be useful as estate assurance. The flagship comes back with two mediums and a remediation plan. Meanwhile the support portal runs an older auth library, the analytics tool has an admin panel reachable without MFA, and the billing app trusts a session cookie minted by the flagship. None of that is in the report because none of it was in the scope.
FedRAMP made this explicit years ago: you cannot exclude an in-boundary system from testing without opening a gap in your Authorization to Operate. The same logic applies whether or not you carry that authorization. If a system shares the trust boundary, leaving it untested does not shrink the attack surface. It only shrinks what you looked at.
Shared identity and data: how one tool's flaw reaches the others
The integration that makes a suite feel like one product is exactly the thing that makes a single-app test misleading. One SSO issuer signs tokens for all nine apps. One session, accepted across the estate. Often one shared service account moving data between them. An attacker does not care which app you tested. They care which app is weakest, because from there the shared identity layer carries them sideways into the one you did test.
- A token forged or replayed against the weakest app is honored by the strongest, because they trust the same issuer.
- An over-permissioned service account in the analytics add-on reads tenant data the flagship was hardened to protect.
- A stale admin in the support portal is a stale admin everywhere the directory reaches.
Cross-platform privilege chains across identity, cloud, and SaaS tools are where real incidents live now. Testing one node of that chain and reporting it as the chain's health is the specific false assurance a regulated buyer has learned to distrust.
Scoping assurance to the estate without a nine-times budget
Estate-wide does not mean nine full external tests. It means scoping to the shared mechanics, then sampling the edges. Test the identity layer once, hard: token issuance, session handling, the trust relationships between apps. Test the data paths the service accounts travel. Then rotate which supporting app gets the deep per-app treatment each cycle, so over two or three years every tool has been under the lamp, not just the flagship every single year. That is a fraction of nine-times spend and it produces a defensible coverage map instead of one green checkmark and eight blanks.
What a regulated buyer means by estate-wide assurance
Auditors lean on pen testing as evidence under SOC 2 Common Criteria CC4.1, the requirement that controls are present and operating. A buyer's security team reads your report the same way. They are not impressed by a flagship with zero criticals. They ask which systems were in scope, which were excluded, and why an excluded system that shares your identity provider should be treated as assured. If the honest answer is "we only tested the one," you have not given them assurance. You have given them a question they now have to escalate.
This is the same record problem underneath every cross-product question: assurance is hard to scope when each app keeps its own identity, its own data, and its own boundary in isolation. Spot Suite hangs every product off one Customer Environment per customer, so identity, data access, and the audit trail share a boundary you can actually scope a test to and report on as a whole, not nine fragments stitched together the night before the review. See how that holds together on security.