What a report from us looks like

Our report on Fernleaf Billing, a made-up online billing service. It has ten findings, each with why it matters and what fixed looks like.

Download the PDF Read four pages here

Fictional sample: an invented company, test systems and made-up data. No real client was assessed. PDF, 26 pages, 1.0 MB.

UM-SA-001 · Revision 4.0

One customer can read another customer’s invoices

In this fictional product, a signed-in customer could read another customer’s invoices by changing a number in an invoice link. The data export and the AI search had the same gap. Separately, code and permissions could reach production without the sign-off the team believed was in place.

10Findings

7High

3Medium

Issued before any fixes. One round of retesting is included.

Do first

Make every invoice, export and search request check which customer is asking. (ARC-01, APP-01, AI-01)
Let only the protected release workflow, its own roles and the images it built reach production. (CLD-01 to CLD-03)
Keep the assistant’s send action off until a person signs off each send. (AI-02)

For your engineers

Area	High	Medium	Main change
SaaS architecture	1	1	Tie each export job to the account that asked for it, and keep webhooks to public addresses.
Application and API	2	1	Check the account, the user’s role and current membership on every request.
Cloud and CI/CD	2	1	Limit production to the protected workflow, the runtime roles it needs and the images it built.
AI and agents	2	0	Filter search by account, and require a person’s sign-off before any external action.

What happens next

We make four fixes at a fixed price: identity, cloud monitoring, backups and edge.
Your developers make the code changes, from our pattern.
We retest every fix, ours and your developers’. One round is included.

Fictional sample. The company, systems and data are invented; no real client was assessed.

Fictional sample. The company, systems and data are invented; no real client was assessed.

Security assessment report

SaaS architecture, applications and APIs, cloud and CI/CD, and AI agents

Prepared for: Fernleaf Billing Ltd
Prepared by: Unmesha Technologies
Reference: UM-SA-001
Revision: 4.0
Distribution: Public sample

contact@unmesha.iowww.unmesha.io

The findings at a glance

7 high and 3 medium, found before any fixes.

7 high3 medium

Biggest risk: A signed-in customer could read another customer’s invoices by changing a number in the link. The data export and the AI search had the same gap.
Do first: Make every invoice, export and search request check which customer is asking.

Four pages from the report

Set out the way your report would be. The PDF has all 26, with the contents on page 2.

Page 3 of 26

Executive summary

What matters most and what to fix first, for the people who decide.

UM-SA-001 · Revision 4.0

One customer can read another customer’s invoices

10Findings

7High

3Medium

Issued before any fixes. One round of retesting is included.

Do first

Make every invoice, export and search request check which customer is asking. (ARC-01, APP-01, AI-01)
Let only the protected release workflow, its own roles and the images it built reach production. (CLD-01 to CLD-03)
Keep the assistant’s send action off until a person signs off each send. (AI-02)

For your engineers

Area	High	Medium	Main change
SaaS architecture	1	1	Tie each export job to the account that asked for it, and keep webhooks to public addresses.
Application and API	2	1	Check the account, the user’s role and current membership on every request.
Cloud and CI/CD	2	1	Limit production to the protected workflow, the runtime roles it needs and the images it built.
AI and agents	2	0	Filter search by account, and require a person’s sign-off before any external action.

What happens next

We make four fixes at a fixed price: identity, cloud monitoring, backups and edge.
Your developers make the code changes, from our pattern.
We retest every fix, ours and your developers’. One round is included.

Fictional sample. The company, systems and data are invented; no real client was assessed.

Page 11 of 26
A finding
What we found, why it matters, the evidence and what fixed looks like. This is APP-01, the biggest risk.
UM-SA-001 · Revision 4.0
APP-01Application and API
Invoice reads skip the account ownership check
Changing one number in an invoice link shows another customer’s invoice.
Severity
High
Risk
4 × 4 = 16
Status
Open
Proposed owner
Application engineering
Affected
Invoice page and GET /api/invoices/{id}
What we found
Signed in as a Member of Alder Studio, we opened Alder Studio’s invoice 104 and changed the number in the address to 208. The page showed invoice 208, which is billed to Birch Dental, with its amount and line items. The API behind the page returned the same invoice with status 200. The session was valid, but nothing checked that the invoice belongs to Alder Studio.
Why it matters
Any signed-in customer who changes the number in an invoice link can read another customer’s invoice, including the customer’s billing email and the amount owed.
Likelihood 4: an ordinary member changes one number in the link. Impact 4: another customer’s billing record comes back, and we treat invoices as confidential between customers.
Evidence
Figure 4. Invoice 208, billed to Birch Dental, open in Alder Studio’s account. The number in the address was changed from 104.
Reproduce and fix
Page 12 has the steps to reproduce it, the fix, what fixed looks like and the limit of the test.
Unmesha TechnologiesSecurity assessment reportFernleaf Billing Ltd11 / 26

Page 21 of 26

The plan

The fixes we make at a fixed price, and the code changes your developers make from our pattern.

UM-SA-001 · Revision 4.0

What we fix, and what your developers fix

Two kinds of work close the gaps. We make four fixes at fixed prices. Your developers make the code changes, working from our pattern.

The fixes we make

Fix	What we set up	Calendar time
IdentityMFA covers only the people who deploy.	MFA enforced everywhere, with break-glass accounts. Single sign-on for your core apps. Conditional access rolled out report-only first, then enforced.	3 to 4 weeks
Cloud monitoringCloud logs are kept, but nobody is alerted.	CloudTrail, GuardDuty and Security Hub on AWS, Microsoft Defender on Azure, or Security Command Center on Google Cloud, with alerts routed to your team.	1 to 2 weeks
Backups and recoveryNightly backups have never been restored in a test.	Backups configured with retention, and made immutable where your platform allows it. One restore test, documented.	1 week
EdgeNothing filters traffic in front of the app.	A web application firewall in front of your app: count mode first, then tuning, then block.	2 to 3 weeks

The code changes your developers make

Grouped by the boundary each one repairs. Fernleaf’s developers estimate 4 to 6 weeks for all five.

Work package	Findings	What changes	How you know it worked
Customer data isolation	ARC-01APP-01AI-01	The account is taken from the signed-in session for every request, export job and search. No field the caller controls can widen what they see.	Own-account and cross-account cases run through the screens, the API, exports and search, cached results included.
Roles and membership	APP-02APP-03AI-02	Current role, current membership and a person’s verified sign-off are checked before any change or external action.	Refused cases leave nothing behind. Removals and expired sign-offs take effect on the next request.
Production identity	CLD-01CLD-02	Only the production workflow can assume the production role, and it can pass on only the runtime roles on its list.	A matrix of allowed and refused subjects and roles, checked with every policy layer in place.
Webhook destinations	ARC-02	An application rule for allowed destinations, backed by network egress controls.	Internal, redirected and re-resolved addresses fail from the real delivery network.
Release images	CLD-03	Sign-off and deployment both use the same verified image digest.	The deployed digest matches the one signed off, and any other image is refused.

Retest

We check each fix. One round of retesting is included.

Page 22 of 26

Closure checklist

What has to be true before a finding closes, and the retest that’s included.

UM-SA-001 · Revision 4.0

What we need to see before a finding closes

Stage	Record	Accepted when
Triage	Owner, affected release, agreed severity and scope.	The evidence supports the finding and its impact.
Fix	Change reference, the design or policy change, and every entry point it covers.	Each affected entry point has a named place where the check happens.
Verification	Refused and permitted cases run against the fixed build.	The refused action fails with no side effects, and normal use still works.
Retest	Request and result record, environment and build reference.	A reviewer can repeat the original case and see it refused.
Residual risk	Anything left untested, accepted limits and the decision record.	Nothing unresolved is reported as fixed.

Checks for every finding

Run the same account and role checks on direct API calls, background jobs, cached reads and assistant actions.
Change authority between a request and its execution, for example by removing a user, and confirm the change is honoured.
Confirm that refused requests leave no queued work, files, messages or data behind.
Where permissions are cached, repeat the checks on more than one server.

Retest

One round is included. Once your team has made the code changes, we retest them and check each of our fixes.

Handover

For each finding, supply the finding ID, the build or policy version, the results of the refused and permitted cases, log references and anything left untested. Keep credentials and confidential data out of tickets.

Download all 26 pages

The findings, part by part

Each finding sits in one part of the product, lit on the diagram. Open one to see why it matters and what fixed looks like.

Every part
How the product is designed, from one end to the other.
2 findings, filed under SaaS architecture
ARC-01High
A customer can download another customer’s invoices through the export feature.
Why it matters
One request can hand a customer another customer’s billing records. An export holds many invoices at once, so this route leaks more than a single page view, even though the normal screens filter correctly.
What fixed looks like
- A customer’s export contains only that customer’s records.
- A request for another customer’s export is refused before any job is created.
- Someone removed from an account can no longer download exports they started earlier.
Owner: Platform engineering
In a client report this part also gives your engineers the steps to reproduce it, the evidence and the fix.
ARC-02Medium
A customer can set a webhook that calls services inside Fernleaf’s own network.
Why it matters
If the server that sends webhooks can reach internal services, a customer could make it send requests to systems they cannot reach themselves. How serious that is depends on which internal services answer.
What fixed looks like
- Webhooks to customers’ own public addresses keep working.
- Internal, loopback and link-local addresses are refused before any connection is made.
- A redirect or a DNS change cannot move an approved webhook onto an internal address.
- The network blocks those addresses even if the application check is skipped.
Owner: Platform and network engineering
In a client report this part also gives your engineers the steps to reproduce it, the evidence and the fix.
Web app and API
What a signed-in customer can see and do.
3 findings, filed under Application & API
APP-01High
Changing one number in an invoice link shows another customer’s invoice.
Why it matters
Any signed-in customer who changes the number in an invoice link can read another customer’s invoice, including the customer’s billing email and the amount owed.
What fixed looks like
- A member can open their own account’s invoices and no one else’s.
- A request for another customer’s invoice returns no invoice data, from the API or from a cache.
- Unknown and foreign invoice numbers get the same response.
Owner: Application engineering
In a client report this part also gives your engineers the steps to reproduce it, the evidence and the fix.
APP-02High
A user with read-only access can give someone full control of the customer account.
Why it matters
Anyone with read-only access can give full control of the account to a second address of their own or to someone outside the business. A Billing admin can change payment details and download every invoice.
What fixed looks like
- Only Billing admins can invite users, through the screens and through the API.
- A refused invitation creates no user and sends no email.
- Every invitation records who sent it and the role it grants.
Owner: Application and identity engineering
In a client report this part also gives your engineers the steps to reproduce it, the evidence and the fix.
APP-03Medium
A person removed from a customer account can still see its data while they stay signed in.
Why it matters
When a customer removes someone, for example a person who has left the business, that person can keep reading the account’s billing information until their session ends.
What fixed looks like
- The first request after someone is removed is refused.
- Removal takes effect on every server and every cache.
- People who were not removed keep their access.
Owner: Identity and application engineering
In a client report this part also gives your engineers the steps to reproduce it, the evidence and the fix.
Pipeline and cloud account
Which code reaches production, and which cloud roles it can use.
3 findings, filed under Cloud & CI/CD
CLD-01High
A test branch can get the same production access as an approved release.
Why it matters
Code from a branch that has not been through release approval could obtain production deployment permissions, unless another cloud control blocks it.
What fixed looks like
- Only the protected production environment can assume the production role.
- Feature branches, pull requests and other environments are refused.
- Each production deployment records which workflow ran it.
Owner: Cloud platform and release engineering
In a client report this part also gives your engineers the steps to reproduce it, the evidence and the fix.
CLD-02High
The release pipeline can run code under an admin role it was never meant to use.
Why it matters
Anyone who controls the release pipeline could run code with permissions well beyond deployment, including access to data exports.
What fixed looks like
- The deployment can pass only the approved runtime roles, and only to the service it deploys to.
- An attempt to pass ops-export-admin is refused.
Owner: Cloud security and platform engineering
In a client report this part also gives your engineers the steps to reproduce it, the evidence and the fix.
CLD-03Medium
The release you approve isn’t guaranteed to be the one that goes live.
Why it matters
The software running in production can differ from what was reviewed. An accidental retag or a compromised publishing account could get past the approval step.
What fixed looks like
- Production runs the exact image that was approved.
- Moving a tag after approval does not change what is deployed.
- An image from an untrusted build is refused at release.
- Rollback goes to an earlier approved image.
Owner: Release engineering
In a client report this part also gives your engineers the steps to reproduce it, the evidence and the fix.
AI features
What the AI features can read and do.
2 findings, filed under AI & agent security
AI-01High
The AI search can show one customer’s documents to another customer.
Why it matters
Another customer’s content can reach the assistant’s answer, its citations or any tool it calls.
What fixed looks like
- Two customers asking the same question each see only their own documents.
- Citations, caches and batch jobs follow the same rule.
- Documents a user loses access to stop appearing in their results.
Owner: AI platform and application engineering
In a client report this part also gives your engineers the steps to reproduce it, the evidence and the fix.
AI-02High
The AI assistant can email a report outside the company without anyone approving it.
Why it matters
A document from outside the business, or a mistaken instruction, can make the assistant send account data to an outside address with no person involved.
What fixed looks like
- No report is queued or sent without a person’s approval for that recipient and that report.
- Changing the recipient or the report cancels the approval.
- An approval cannot be used twice.
Owner: Agent platform and product engineering
In a client report this part also gives your engineers the steps to reproduce it, the evidence and the fix.

Want a report like this on your platform?

Tell us about your platform on a free 30-minute call. Leave passwords and customer data out of your first message.

Request a free call

We reply within one working day. We set up the call, and you meet the people who’d do the work.
We send a proposal with the scope, the timing and a fixed fee.
Work starts when you say go.

Or see what a mini assessment report looks like

The findings at a glance

Four pages from the report

Executive summary

One customer can read another customer’s invoices

Do first

For your engineers

What happens next

A finding

Invoice reads skip the account ownership check

What we found

Why it matters

Evidence

Reproduce and fix

The plan

What we fix, and what your developers fix

The fixes we make

The code changes your developers make

Retest

Closure checklist

What we need to see before a finding closes

Checks for every finding

Retest

Handover

The findings, part by part

Every part

Export workers trust the account named in the request

Why it matters

What fixed looks like

Webhook destinations can reach the internal network

Why it matters

What fixed looks like

Web app and API

Invoice reads skip the account ownership check

Why it matters

What fixed looks like

Members can send invitations that grant Billing admin

Why it matters

What fixed looks like

Removed users keep access until their session expires

Why it matters

What fixed looks like

Pipeline and cloud account

Production role trusts every branch in the repository

Why it matters

What fixed looks like

Deployment permissions can pass an unintended admin role

Why it matters

What fixed looks like

Release approval is not bound to the deployed image

Why it matters

What fixed looks like

AI features

Assistant search returns other customers’ documents

Why it matters

What fixed looks like

The assistant can send email without the required approval

Why it matters

What fixed looks like

Want a report like this on your platform?