Continuous testing
Continuous penetration testing, round by round.
A full test every quarter, with checks between rounds on request as you ship. Each round brings its own report and executive briefing.
What a tester checks in each round.
The whole agreed scope each quarter, new work first: the features, roles, endpoints, hosts and settings that changed since the last round.
New features since last round
The screens and jobs you shipped since the last round, tested first.
For example, feature: bulk-exportChanges to roles and access
New roles and sharing rules, tried with a separate test account for each.
For example, role: billing-adminNew endpoints and integrations
New routes and partner sign-ins, including the ones no screen calls yet.
For example, oauth: partner-ssoNew hosts and exposed services
Subdomains and admin panels that went live since the last round.
For example, beta.acme-corp.comSettings a deploy can change
Debug switches and verbose error pages that a release turns back on.
For example, debug: trueFixed issues that return
Earlier findings tried again in each full round, or sooner on request.
For example, POST /v2/webhooksSee the sample finding
What we need from you
- The systems in scope
- Release notes or a changelog
- A test account for each role
On live systems
Live systems by default, inside agreed windows, with a named contact and no destructive actions.
How we test it, step by step.
We read your release notes and map the surface again at the start of each round. The tester then works what is new and what came back.
A tester leads every step. AI speeds up recon, triage and reporting, and a person reviews every finding before it reaches you.
Map what changed
What the tester does
We set the fresh map beside the last round's and mark what changed.
What you learn
Which routes, roles and hosts appeared since the last report.
Test the new surface first
What the tester does
A tester works the changes first, then the rest of the agreed scope.
What you learn
Whether this quarter's releases opened a way in, with proof for each finding.
Try old findings again
What the tester does
We rerun the proof for earlier findings against the current build.
What you learn
Which fixes held, and which a later release undid.
Report and brief the round
What the tester does
We write up the round and brief your leadership on what moved since last quarter.
What you learn
How your exposure shifted from one quarter to the next, in plain business terms.
Three attack paths from an ordinary release.
Each sample starts with an ordinary release. A quarterly round meets that change within the quarter; a yearly test can meet it months later.
- Sample
A new export skips the tenant check
A sprint ships a bulk export without the tenant check. One customer's login downloads another's records.
- Sample
A copied role keeps admin rights
A billing role is copied from the admin role to save time. Its users are one request from admin.
- Sample
A partner sign-in trusts any address
The new partner sign-in accepts any return address. A crafted link hands a staff session to the attacker.
One sample finding, in full.
Between rounds, checks run when you ask for them. In this sample, a check after a release found that a webhook flaw fixed in round one had returned.
Acme Corp is a fictional client. Every sample on this page is illustrative, never client data.
A webhook flaw fixed in round one came back after a release
Whereapi.acme-corp.com/v2/webhooks
Round one, after the fix
POST /v2/webhooks{"url":"http://10.0.0.5/"}400 Bad Request: fix holds
Check on request, after a release
POST /v2/webhooks{"url":"http://10.0.0.5/"}201 Created: flaw is back
- Business risk
- Any customer account could again make your servers call internal systems that are never meant to face the internet.
- Fix
- Resolve each webhook address and refuse private ranges, checking again after every redirect.
Removed: fetch(hook.url)
Added: fetch(publicOnly(hook.url))
Checked by a tester before it reached the report.
What lands on your desk.
Every round is a full test, written up with proof of exploit, the business risk and a fix for each finding, then briefed to your leadership.
Full test
The whole agreed scope
Report and briefing
Findings, proof and fixes
Fix guidance
A fix for every finding
The next round
Starts from what changed
Who it suits, and when to book it.
Teams that release often, where last year's report no longer describes the product customers use.
Teams shipping every sprint
Products that change faster than a yearly test can follow.
Teams under regular review
Customers and auditors ask what was tested this quarter.
Products adding integrations
Every new webhook or partner sign-in widens what an attacker can reach.
When to book it
- Your release pace picks upWeekly releases outpace a report written once a year.
- Ahead of a product launchRun the first round before launch, then keep the rhythm after it.
- For customer security reviewsAnswer a buyer's security questionnaire with this quarter's report.
- When fixes keep coming backEach round tries earlier findings again against the current build.
- After a one-off testCarry its scope and findings into the first quarterly round.
Aligned with the same standards every round.
Every round is aligned with the same three standards, so one quarter's report reads against the last.
OWASP Top 10
Open Worldwide Application Security Project (OWASP) Top 10
The most critical risks to web applications, ranked.
OWASP ASVS
OWASP Application Security Verification Standard (ASVS)
Security requirements an application is verified against, in three levels.
NIST SP 800-115
National Institute of Standards and Technology (NIST) Special Publication 800-115
The technical guide to information security testing and assessment.
Aligned with, never certified by. Names belong to their owners; no endorsement implied.
Questions before scoping.
We reply to every quote request within one business day, from info@greysurface.com.
How is this different from a yearly test?
Each round is the same full test, four times a year instead of once. Between rounds you can ask us to check a change as it ships.
Is each round a full test?
Yes. Each quarterly round is a full test of the agreed scope, with proof of exploit, the business risk and a fix for every finding, plus an executive briefing.
How do checks between rounds work?
Tell us what shipped and where it runs, and a tester checks that change. The next quarterly round still tests the whole agreed scope.
Will quarterly testing disrupt our live systems?
Each round runs on live systems by default, inside agreed windows, with a named contact and no destructive actions.
What do you need from us each quarter?
The agreed scope, a test account for each role, and your release notes or changelog since the last round. We agree the list in the scoping conversation.