When you request pen test evidence from a vendor, you'll typically receive one of two things: a full technical report with more detail than you need, or a vague one-pager that confirms testing happened without telling you anything useful. Neither helps you make a decision.
What you want is a scoped summary that confirms what was tested, what was found, and whether the vendor's team fixed it — in a format you can evaluate quickly and forward up the approval chain with confidence.
This reference shows what credible pen test deliverables look like, using a mostly fictional SaaS engagement to protect the guilty. The guidance annotations explain what each section tells you as a buyer and what to watch for.
How to Use This Reference
Part 1: Attestation Letter — The concise document you'll find on a vendor's trust center or attached to a vendor assessment response. For many deals, this is the only pen test evidence you'll see. It should tell you what was tested, how, and whether findings were fixed — in under two pages.
Part 2: Assessment Summary Report — The fuller document you request when the attestation letter passes initial review and your security team wants more depth before sign-off. This is what gets forwarded to the CISO or VP of Security for final approval.
Guidance annotations (in blockquotes) explain what each section tells you what a buyer's security team is looking for, what credible content looks like, and what will raise questions.
Part 1: Attestation Letter
Recipient & Purpose
Adversis was engaged by ACME Corp to perform a security assessment of the SpendLens platform. This letter attests to the scope, methodology, and results of that assessment.
What to look for: A clear statement of who performed the testing and what product was tested. This should be factual and specific over no marketing language. If the opening is vague about what was assessed or who assessed it, the rest of the letter usually follows suit.
Scope of Assessment
Adversis conducted a security assessment of ACME Corp's SpendLens platform, covering the following components:
- Web Application: SpendLens production application
- API: SpendLens REST API and AI service endpoints
- Authentication & Authorization: Login flows via Supabase Auth, session management, role-based access controls (Owner, Admin, Approver, Submitter, Viewer), multi-tenant boundaries, OAuth integrations
- Cloud Infrastructure: AWS environment configuration and access controls (us-east-1), including ECS task roles, S3 bucket policies, RDS access controls, and Lambda function permissions
- AI/ML Features: SpendLens AI receipt processing pipeline, natural language query interface, and document intelligence features — including prompt injection, data leakage, and tenant isolation within AI workflows
- Third-Party Integrations: Security boundaries and data flow between SpendLens and integrated services (Supabase, Vercel, Trigger.dev)
Assessment Period: June 16, 2026 through June 27, 2026 (10 business days)
Team Size: 2 security researchers
What to look for: Scope is where you decide whether the vendor tested the right things. For a SaaS product, you want to see the application itself, the API, authentication and authorization logic, multi-tenant boundaries, and cloud infrastructure.
If the scope says "external network scan" or "web application scan" with no mention of authorization or tenant isolation, the assessment likely missed what matters most.
Specific URLs and environments confirm the tester assessed the production product, not a forgotten staging instance. Note the team size and duration — a two-person, ten-day assessment obviously covers significantly more ground than a one-person, three-day engagement.
Summary of Methodology
The assessment followed a manual security testing methodology aligned with the OWASP Application Security Verification Standard (ASVS) Level 2 requirements and the OWASP Testing Guide, supplemented by targeted tooling.
Testing focused on the areas most relevant to SpendLens's SaaS architecture: tenant isolation, authorization model enforcement across all five user roles, business logic in approval workflows, API security across both the core REST API and AI service endpoints, and the security of AI/ML features including prompt injection resistance and cross-tenant data isolation within AI contexts. Where applicable, testing addressed controls relevant to ACME Corp's compliance context, including SOC 2 Type II.
Adversis's methodology is grounded in offensive security experience — our team tests what real attackers target, prioritized by what would cause genuine business harm. This approach reflects pattern recognition built from hundreds of engagements inside enterprise SaaS environments. See appendix for a further details.
What to look for: "We followed OWASP" is table stakes - everyone says it. What separates a credible methodology statement is specificity about what was actually tested.
You want to see the testing areas named: tenant isolation, authorization model, business logic. If the methodology section is generic enough to appear in any vendor's attestation letter, it probably describes a generic engagement. OWASP's Application Security Verification Standards are an excellent framework.
A methodology grounded in offensive security experience, testing what attackers actually target, produces different results than one following a compliance checklist.
Risk Summary
Adversis assessed SpendLens's overall security posture as satisfactory, with several areas requiring remediation and specific strengths in infrastructure configuration and authentication implementation.
The assessment identified 14 findings across the following severity tiers:
The most significant findings related to authorization enforcement gaps on internal API routes, a prompt injection vector in the AI document intelligence feature that allowed cross-tenant metadata retrieval, and client-side input handling in the custom receipt presentation layer.
No findings involved direct database-level exposure of customer financial data across tenant boundaries, and core authentication flows via Supabase Auth were well-implemented.
What to look for: The risk summary should give you the shape of the findings — severity distribution and general category — without being a vulnerability disclosure.
"The assessment identified 14 findings, including 1 critical issue related to cross-tenant data isolation in AI features" tells you something.
"Several vulnerabilities were discovered" tells you nothing.
Watch for whether the vendor characterizes what was not found as well — "no findings involved direct database-level exposure of customer data across tenant boundaries" is the kind of specific reassurance that matters when you're evaluating a multi-tenant SaaS product. A risk summary that's only positive or only vague should raise questions.
Remediation Status
All findings identified during the assessment were communicated to ACME Corp's development team on June 30, 2026. ACME Corp's team completed remediation of all identified findings by July 11, 2026.
Adversis performed a full retest of all previously identified findings on July 14–15, 2026. All findings were verified as resolved. No previously identified vulnerabilities remain outstanding.
The remediation timeline — 11 days from findings delivery to verified resolution — demonstrates that ACME Corp's development team treats security findings as priority work.
What to look for: This section shapes how the buyer perceives your engineering team. Treat remediation as priority work and not something that sits in a backlog so that the assessor can reflect that urgency here.
Specific dates and a tight timeline ("11 days from findings delivery to verified resolution") tell the buyer your team takes security seriously. Vague language like "findings were promptly addressed" invites skepticism.
Make sure your pen test firm includes retesting as part of the engagement — not as an upsell.
"Verified through full retesting" is what the buyer wants to see. Without it, the findings look like they were marked closed in a ticket system without anyone confirming the fixes work.
The remediation timeline is a strong trust signal. Earn it by fixing fast and asking your assessor to retest everything.
Closing Statement
Based on the assessment results and the remediation actions taken by ACME Corp, Adversis considers SpendLens's security posture to be consistent with industry expectations for a SaaS platform handling enterprise financial data.
Adversis is available to discuss the scope, methodology, and results of this assessment with authorized parties upon request from ACME Corp.
What to look for: A named individual with a title, not just a firm name. If you have follow-up questions, you want to know who actually did the testing.
The offer to discuss results with authorized parties is a good sign — it means the testing firm is willing to stand behind their work on a call.
If the attestation letter is unsigned or attributed only to the firm, ask the vendor who performed the assessment and whether that person is available for questions.
Part 2: Assessment Summary Report
1. Executive Summary
Adversis was engaged by ACME Corp to perform a security assessment of the SpendLens platform, including its web application, REST API, AI/ML features, cloud infrastructure, and third-party integration boundaries. The assessment was conducted from June 16 through June 27, 2026 by a team of 2 security researchers.
The assessment identified 14 total findings: 1 critical, 2 high, 4 medium, 4 low, and 3 informational. The application demonstrated solid foundational security practices: authentication via Supabase Auth is well-implemented, AWS infrastructure is configured with appropriate network segmentation and least-privilege IAM roles, and the core data model enforces tenant isolation at the database layer.
The findings identified were concentrated in three areas: authorization enforcement gaps on specific API routes, input handling in the AI document processing and receipt rendering features, and credential management for third-party integrations.
The most noteworthy finding involved a prompt injection vector in SpendLens's AI document intelligence feature. A crafted receipt document could manipulate the AI processing pipeline into returning metadata — file names, upload timestamps, and categorization tags — belonging to another tenant's documents. While the attack did not expose financial data or document contents, it represented a cross-tenant information disclosure path.
All findings were remediated by ACME Corp's development team within 11 days and verified through a full retest by Adversis. No outstanding vulnerabilities from this engagement exist.
What to look for: The executive summary should answer your core question without making you read the rest of the document: "Is this vendor's security posture acceptable?" Look for a severity breakdown, a characterization of what was found (not just how many), and confirmation that findings were fixed and verified.
Notice whether the summary mentions specific architectural strengths alongside the findings — a vendor whose assessment says "tenant isolation at the database layer held" has been tested more deeply than one whose summary only lists finding counts.
If the executive summary is vague enough to apply to any vendor, the assessment probably was too.
2. Scope
Assets Tested
Access Provided
- 5 user accounts across 5 roles: Owner, Admin, Approver, Submitter, Viewer
- 2 separate tenant environments for cross-tenant isolation testing
- REST API documentation and authentication credentials
- AI feature documentation including model integration architecture
- AWS console read-only access for infrastructure review
- Architecture documentation covering Supabase, Vercel, and Trigger.dev integration patterns
Environment Details
- Application version: SpendLens v3.14
- Infrastructure: AWS us-east-1 (ECS Fargate, RDS PostgreSQL via Supabase, S3, Lambda, CloudFront), Vercel (frontend + edge functions), Supabase (auth + database + storage), Trigger.dev (background jobs)
- Testing environment: Production with safeguards — dedicated test tenants, financial data seeded with synthetic records, AI features tested against controlled document sets
Exclusions
- Plaid financial account linking integration (third-party hosted, API-level boundary testing only — Plaid's internal infrastructure is outside ACME Corp's control)
- Mobile application (currently in beta; scheduled for separate assessment in Q4 2026)
- Stripe billing integration (Stripe-hosted checkout and billing portal; API key handling and webhook verification were in scope)
ACME Corp's team provided timely access and resolved environmental issues during the engagement without impacting the assessment timeline.
What to look for: The scope table tells you exactly what was and wasn't tested. Check that it covers the components that matter for the product you're evaluating — not just a network perimeter or marketing site.
For a SaaS product, you want to see the application, API, authorization model, cloud infrastructure, and any AI/ML features listed with specific identifiers.
Pay attention to exclusions: documented exclusions with reasoning ("third-party hosted, outside vendor's control") are a sign of thoughtful scoping. Undocumented gaps — where you expected something to be tested and it's simply not mentioned — are worth asking about.
Also note whether the vendor provided multiple user roles and separate tenant environments for testing. Single-role, single-tenant testing can't verify the authorization and isolation boundaries you care about.
3. Findings Summary
How We Present Risk
Each finding includes an industry-standard severity rating alongside our assessment of how likely the issue is to be exploited in a real-world scenario within the next 12 months. We use three exploitation likelihood tiers:
- Likely — An attacker with standard tools operating against this application would be expected to find and exploit this.
- Plausible — Exploitation is realistic but depends on specific conditions or knowledge that isn't immediately obvious.
- Theoretical — The vulnerability exists, but exploiting it requires unusual circumstances or chained preconditions that make near-term exploitation unlikely.
These assessments reflect Adversis's professional judgment based on the engagement context and our experience across similar environments. They are not guarantees or predictions — threat landscapes evolve, attacker capabilities shift, and these ratings are intended to support informed prioritization at a point in time.
Findings Summary
Findings by Priority
Finding 1: Cross-Tenant Metadata Disclosure via AI Document Intelligence
Severity: Critical | Likelihood: Plausible
An authenticated Submitter uploads a crafted receipt containing embedded prompt injection instructions. The AI pipeline processes the document and returns metadata — file names, upload timestamps, categorization tags — from another tenant's document store. Document contents and financial data were not accessible through this path, but any cross-tenant boundary violation is a material concern for enterprise buyers evaluating data isolation.
Finding 2: Missing Authorization on Internal Administrative API Routes
Severity: High | Likelihood: Likely
Seven API routes under /v2/internal/ intended for Admin and Owner roles did not enforce authorization checks. Any authenticated user — including Submitters and Viewers — could call these endpoints directly to access organization-level configuration, including team management, approval workflows, and integration settings. Endpoint naming followed a predictable convention that made discovery straightforward.
Finding 3: Shared Integration API Keys Across Tenants
Severity: High | Likelihood: Theoretical
API keys for the Trigger.dev background job integration were shared across all tenant environments rather than scoped per-tenant. Exploitation would require first compromising the job execution layer and then understanding cross-tenant queue structure — an unlikely chain in the near term. The finding is rated high because the shared credential pattern widens the blast radius of any future vulnerability in the job processing layer.
Finding 4: Stored Cross-Site Scripting in Custom Receipt Presentation
Severity: Medium | Likelihood: Plausible
The receipt notes and merchant name fields accepted input that was stored and rendered without adequate sanitization when an Approver reviewed the expense. The attack follows the application's normal workflow — Submitters create expenses, Approvers review them — requiring no unusual access or behavior beyond submitting a malicious entry.
Finding 5: Open Redirect via OAuth Callback Parameter
Severity: Medium | Likelihood: Plausible
The OAuth callback flow accepted an unsanitized redirect URI parameter, allowing an attacker to craft a link that begins with a legitimate SpendLens login and redirects to an attacker-controlled domain upon success. The seamless transition from real authentication to phishing page makes this significantly more convincing than a standalone fake login.
Finding 6: Excessive Data Exposure in Approval Workflow API Responses
Severity: Medium | Likelihood: Likely
Approval endpoint API responses returned full user profile objects — email addresses, internal IDs, role assignments, last-login timestamps — for all participants in the approval chain. The UI displayed only names and status. The unnecessary fields provide user enumeration data and activity patterns useful for planning further attacks.
Finding 7: AI Natural Language Query — System Metadata Disclosure
Severity: Medium | Likelihood: Plausible
The "Ask SpendLens" feature could be prompted to disclose internal database table names, column structures, and system prompt fragments through carefully constructed queries. Tenant data isolation held at the database query layer regardless of model behavior, but the disclosed information would help an attacker build more targeted attacks against other parts of the application.
Finding 8: Permissive CORS Configuration on AI Service Endpoints
Severity: Low | Likelihood: Theoretical
AI endpoints returned CORS headers permitting requests from any origin. Authentication was still required, but the permissive policy would allow a stolen session token to be used from any domain — widening the exploitation window in a scenario where an attacker has already obtained a valid token through a separate vector.
Finding 9: Session Tokens Not Invalidated on Role Change
Severity: Low | Likelihood: Theoretical
When a user's role was downgraded by an Admin, existing session tokens continued to carry the previous role's permissions until the next token refresh. The window is bounded by Supabase Auth's refresh interval, but during that period a demoted user retains elevated access.
Finding 10: Missing Rate Limiting on AI Query Endpoints
Severity: Low | Likelihood: Likely
The natural language query endpoint did not enforce per-user rate limiting. An authenticated user could submit a high volume of queries, incurring uncontrolled model inference costs and degrading service for other users in the same tenant.
Finding 11: Trigger.dev Webhook Missing Signature Verification
Severity: Low | Likelihood: Theoretical
The webhook endpoint receiving Trigger.dev job completion callbacks did not verify request signatures, allowing forged events if the endpoint URL was discovered. Practical impact was limited by the application's validation of job results against expected state before acting on them.
Deprioritized Findings
The following were assessed as low real-world risk given SpendLens's architecture. Documented for completeness; recommended for future hardening.
- Server Version Disclosure in API Response Headers (Informational) — Framework version identifiers in ECS task responses. Versions current and patched.
- Verbose Error Messages on Deprecated API Routes (Informational) — Stack traces on unused, deprecated routes scheduled for removal. No sensitive data exposed.
- Supabase Storage Bucket Listing for Authenticated Users (Informational) — Authenticated users could enumerate file names within their own tenant's bucket beyond what the UI exposed. Cross-tenant listing was not possible.
What to look for: This section tells you what the tester found, at the category level. You don't need reproduction steps here — you need to understand the shape of the findings.
Are they ordered by real-world impact, or just sorted by severity score? Findings prioritized by exploitability and business consequence suggest the tester exercised judgment.
A list sorted by CVSS score suggests a scanner did the thinking. Look for a deprioritization section — findings the tester flagged but assessed as low real-world risk, with reasoning.
This is a strong signal of testing quality: it means the tester understood the difference between a theoretical finding and a practical one, rather than presenting every result at equal weight.
If every finding is rated High or Critical with no deprioritization, ask whether the tester modeled your actual threat landscape or just ran a tool.
4. Remediation & Retesting
Timeline
1. Findings delivered to ACME Corp
2. Remediation completed by ACME Corp
3. Full retest performed by Adversis
4. Updated report and attestation delivered
All findings identified during the assessment were remediated by ACME Corp's development team. Key remediation actions included:
- AI document processing pipeline redesigned to enforce strict tenant-scoped context windows, with output filtering added to prevent metadata leakage across tenant boundaries
- Authorization middleware applied uniformly to all
/v2/internal/routes, with role enforcement validated against a centralized RBAC policy - Trigger.dev integration re-architected to use per-tenant API keys with scoped permissions
- Receipt rendering pipeline updated with DOMPurify sanitization and Content Security Policy headers on rendered receipt views
- OAuth callback redirect validation restricted to an allowlist of registered domains
- AI query output filtering hardened to suppress schema metadata and system prompt fragments
Adversis performed a full retest of every previously identified finding. All issues were verified as resolved, including regression testing of related functionality to confirm fixes did not introduce new issues.
All issues were fixed in a timely manner by ACME Corp. No outstanding security vulnerabilities discovered during this engagement exist.
What to look for: This is the expanded version of Part 1's remediation section, and it's where your engineering team's response tells its own story. When the buyer reads "authorization middleware applied uniformly to all internal routes" or "AI pipeline redesigned to enforce tenant-scoped context windows," they see an engineering team that understood the root cause and fixed the pattern, not just the instance.
Prioritize remediation speed. The timeline table is one of the first things a buyer's analyst scans. Eleven days from delivery to verified resolution reads very differently than sixty.
Ensure your pen test includes a full retest (not a spot-check) as standard, and ask them to note regression testing. "Full retest of every finding, including regression testing" gives the buyer confidence that fixes didn't break something else.
The closing statement ("no outstanding vulnerabilities exist") is the sentence the buyer wants to check the box.
5. Methodology
Approach
Manual security assessment of the web application, API, and cloud infrastructure. Testing prioritized manual analysis of authorization logic, business logic flows, and tenant isolation — the areas where automated tools produce the least reliable results and where SaaS products carry the most risk.
Adversis's assessment methodology is informed by offensive security experience across dozens of SaaS engagements. Our testers map realistic attack paths, chaining findings into the sequences real adversaries use, rather than simply cataloguing isolated vulnerabilities. Findings are prioritized by what would cause genuine impact, not by CVSS score alone.
Standards
Testing aligned with the OWASP Application Security Verification Standard (ASVS) Level 2 requirements and the OWASP Testing Guide. AI/ML feature testing incorporated OWASP Top 10 for LLM Applications. Where applicable, testing addressed controls relevant to ACME Corp's compliance context: SOC 2 Type II.
SaaS-Specific Testing
- Tenant isolation: Cross-tenant data access attempts across API endpoints, database queries (via Supabase RLS policies), S3 storage buckets, AI processing pipeline context windows, and Trigger.dev job queues. Testing verified that data belonging to one tenant could not be accessed, modified, or inferred through another tenant's session — with dedicated focus on whether AI features maintained tenant boundaries under adversarial input.
- Authorization model mapping: Systematic testing of role boundaries across all five SpendLens roles (Owner, Admin, Approver, Submitter, Viewer), privilege escalation paths (horizontal and vertical), BOLA/IDOR across all identified user roles and permission levels, with specific attention to approval workflow business logic — testing whether Submitters could approve their own expenses, whether Viewers could modify records through direct API calls, and whether role transitions maintained consistency.
- API security: Input validation, rate limiting, authentication enforcement across all endpoints (core REST API and AI service endpoints), and review of data exposure in API responses.
- AI/ML security: Prompt injection testing across all three AI features (document intelligence, natural language query, receipt processing), including attempts to manipulate model behavior through crafted documents and queries, cross-tenant data extraction through model outputs, system prompt extraction, and output manipulation to produce misleading financial summaries.
- Third-party integration boundaries: Review of data flows, credential scoping, and trust boundaries between SpendLens and Supabase, Vercel, and Trigger.dev — including webhook verification, API key isolation, and the security implications of the split-architecture deployment model.
Tooling
Burp Suite Professional, Semgrep, Project Discovery tools, cloud enumeration tools, custom scripts developed for tenant isolation and authorization testing specific to SpendLens's architecture, and purpose-built prompt injection payloads for the AI feature assessment.
Testing Priorities
Testing informed by attacker methodology. Scope prioritized by what would cause genuine business harm to ACME Corp and its customers — with particular attention to scenarios where a compromised or malicious user account in one tenant could access another tenant's financial data, and where AI features could be manipulated to violate data isolation guarantees that enterprise buyers evaluate. Recommendations address architectural patterns, not just individual instances — so the development team fixes the root cause rather than playing whack-a-mole across the codebase.
What to look for: The methodology section tells you whether the assessment was a generic checklist engagement or one designed for this vendor's architecture.
Look for SaaS-specific testing areas called out explicitly: tenant isolation, authorization model mapping, business logic, API security. If the vendor has AI features, those should be tested too — prompt injection, data leakage, tenant isolation within AI workflows.
Check whether the approach is described as manual testing supplemented by tooling, or automated scanning with manual review. The former finds authorization bypasses and business logic flaws. The latter mostly finds missing headers and outdated dependencies.
A "testing priorities" section that references attacker methodology and business harm rather than compliance requirements, suggests the tester prioritized by what would likely get exploited.
6. About Adversis
Adversis is a cybersecurity consulting partner for SaaS companies, founded by practitioners with offensive security backgrounds at organizations including Capital One, Okta, Bishop Fox, and Rivian. Our team holds advanced certifications including OSCP, OSCE, and GXPN, and created the Red Team Maturity Model used by Fortune 200 companies.
We specialize in working with SaaS companies selling into enterprises — the pen tests, the security review calls, the vendor assessments that determine whether a deal moves forward.
Our perspective is informed by experience on both sides of the evaluation: conducting security assessments for complex SaaS companies and running vendor security evaluations as enterprise buyers — including negotiating over $50M in enterprise contracts from the vendor side. That dual perspective shapes how we scope engagements, what we prioritize in testing, and how we structure deliverables. We test what the buyer's security team will ask about — because we've been the team asking and understand how attackers work.
What to look for: You're evaluating whether the firm that tested this vendor is credible.
Look for specifics about the team's background and whether they have relevant experience for the product type. A firm with offensive security experience and SaaS-specific expertise will produce different results than a generalist consultancy.
Experience on the buyer's side of vendor evaluations is a strong signal — it means the firm understands what you're looking for, not just how to run tools.
Certifications alone don't tell you much. What matters is whether the firm's background suggests they can find the things automated tools miss: authorization logic flaws, business logic abuse, tenant isolation failures.
Evaluating a vendor's pen test evidence? Check out the Pen Test Report Credibility Checklist and Talk to us — we've been on the buyer's side of these evaluations and can tell you what the report is actually saying.
