Application Security Assurance
You ship weekly and test annually. This binds real application testing to your release cadence instead of the calendar, so the features deployed between audits no longer go untested.
Speed creates the gap
An annual penetration test describes one deployed state. If you release weekly, roughly fifty subsequent states go untested, and the report is out of date well before the compliance cycle it feeds ends.
A scanner does not close that gap, because the findings that matter here are not pattern matches: authorization decisions that are individually correct and jointly wrong, workflow states reachable in an order nobody designed for, entitlement logic that can be argued with. An agent swarm will reach those states. Deciding whether reaching one was ever meant to be possible is a question about your product, and that is where a person is required.
Engagement types this combines
A solution is not a separate capability. It is the engagement types from Services sequenced against a specific situation: here, a release cadence that makes annual testing stale.
Penetration Testing
Agent-driven exploitation of applications and APIs each cycle: authentication, authorization, injection, and business logic. The engagement type doing the work.
View engagementSecurity Consulting
Application security program design, so recurring finding classes get addressed at the source.
View engagementWhat gets tested each cycle
Authentication and session
- SSO, OAuth, and SAML implementation flaws
- Session fixation, hijacking, and lifetime handling
- Password reset and account recovery flows
- Multi-factor enforcement and bypass
- JWT signature, algorithm, and claim validation
- Token issuance, refresh, and revocation
Authorization and access control
- Object-level authorization across every role pair
- Horizontal and vertical privilege escalation
- Multi-tenant isolation
- Role-based access control bypass
- Function-level authorization on API endpoints
- Resource-level permission inheritance
Business logic
- Payment and billing manipulation
- Workflow state tampering and step skipping
- Rate limit and quota abuse
- Race conditions and time-of-check to time-of-use
- Feature flag and entitlement bypass
- Integrity of derived and aggregated values
API surface
- REST, GraphQL, and WebSocket testing
- Mass assignment and excessive data exposure
- Injection across every accepted content type
- GraphQL introspection, batching, and depth abuse
- Undocumented and deprecated endpoints
- Versioning and backwards-compatibility exposure
Injection and data flow
- SQL, NoSQL, and ORM-layer injection
- Server-side request forgery
- Server-side template injection
- XML external entity processing
- Cross-site scripting, including DOM sinks
- Command execution and unsafe deserialization
Supporting configuration
- Cloud service misconfiguration reachable from the application
- Container and orchestration exposure
- Secrets in source, configuration, and build artefacts
- TLS configuration and certificate handling
- CORS policy and security headers
- Dependency exposure with reachability analysis
How the program runs
Steps 01 to 03 run once, at the start. Steps 04 to 06 repeat for as long as the program does.
01
Threat model and baseline scope
1-2 days
Architecture walkthrough, trust boundary mapping, and identification of the surfaces where a failure would actually matter. This is done once and revised as the system changes, not repeated every cycle.
Output: Application threat model, prioritised attack surface inventory, and the standing scope definition.
02
Baseline assessment
5-10 days
A full assessment of the current deployed state, establishing the starting position. The swarm works the surface and carries each candidate through to a working exploit. Anything it cannot exploit is discarded.
Output: Baseline findings with proof-of-concept and reproduction steps, in your issue tracker.
03
Secure code review of critical paths
3-5 days
Manual review of the code behind the surfaces that matter: authentication, authorization, payment handling, data access, and cryptographic use. Finds the flaws that are invisible from outside the running application.
Output: Code-level findings with the specific change to make, and the pattern to apply elsewhere.
04
Cycle testing
Per release cadence
Each cycle, scope is set by what changed: new endpoints, modified authorization logic, new integrations, and anything touching a previously vulnerable path. Agents work the diff in full and exploit what they reach; a human rules on the parts that require knowing what the feature is for. Regression testing runs against previously remediated findings.
Output: Per-cycle findings raised as tickets, with severity and reproduction, as they are confirmed.
05
Remediation retest
Within 30 days of fix
Critical and High findings are retested once the fix is deployed, including attempts to bypass the fix itself. Anything only partially resolved is recorded as partially resolved.
Output: Per-finding retest status and residual risk.
06
Periodic posture review
Quarterly
Stepping back from individual findings to the pattern behind them. Which classes keep recurring, which part of the development process produces them, and what change to the process would stop them.
Output: Posture review covering finding trends, recurring classes, and program recommendations.
What you receive
Continuous output into your workflow, plus periodic documents for the people who do not live in it.
Findings in your issue tracker
Every confirmed finding raised as a ticket in Jira, Linear, or GitHub Issues, with severity, reproduction steps, and the specific change to make. Filed as it is confirmed, not batched.
Per-cycle summary
What was in scope this cycle, what was found, what was retested, and what remains open. Short enough to read in the sprint review.
Quarterly posture review
Trend across cycles: which finding classes recur, which part of the process produces them, and the program change that would stop them recurring.
Compliance-ready engagement report
On request, a formal report covering the period, formatted for an auditor or an enterprise security review, mapped to SOC 2, ISO 27001, or PCI DSS.
Every finding was exploited first
Nothing reaches your backlog on the strength of a scanner or an agent. If it is in the tracker, a person reproduced it and it carries the exact request that reproduces it. Your engineers should never spend a sprint disproving a finding.
What we need to quote
Release cadence is the input that most determines the shape of the program. Everything else adjusts around it.
- →Applications and API surfaces in scope, with an OpenAPI or GraphQL schema if one exists.
- →Release cadence, and whether releases are scheduled or continuous.
- →Role and tenant model, and whether tenants share infrastructure.
- →Technology stack and hosting, including anything unusual in the auth layer.
- →Test environment availability, and whether its data is representative.
- →Credentials you can issue: two accounts per role, so horizontal access can be tested.
- →Issue tracker and where you want findings to land.
- →What is driving this: a customer requirement, an audit cycle, or a specific incident.
Common questions
How does testing bind to our sprints?+
Scope is agreed per cycle against what actually changed: new endpoints, modified authorization logic, new integrations. Findings go into your issue tracker as they are confirmed.
What does this find that our scanners do not?+
Anything requiring reasoning about intent. Authorization decisions that are correct in isolation and wrong in combination, workflow states reachable out of order, race conditions on balance and quota operations, and entitlement logic that can be manipulated. A scanner has no model of what your application is for.
Which API styles do you test?+
REST, GraphQL, and WebSocket. Testing covers authentication, object- and function-level authorization, injection, mass assignment, and rate limiting across each. gRPC is assessed case by case.
What happens when something critical is found mid-cycle?+
It is reported the day it is confirmed, through whichever channel you nominate. Nothing exploitable in production waits for a scheduled report.
Is remediation retest included?+
Yes. Critical and High findings are retested within 30 days of the fix being deployed, inside the engagement, including bypass attempts against the fix itself. Partial fixes are recorded as partial.
Can AI tooling not do this now?+
It does. Agent swarms run every cycle across whatever changed, exploiting what they reach: role and tenant pair permutation, injection sinks, dependency reachability, authorization across the diff. That is what makes per-cycle coverage affordable. What stays human is judgement: whether a reachable state is a defect or an intended behaviour, what it is worth against your business, and the severity argument. A human signs the cycle report.
How is this different from booking a penetration test each year?+
A penetration test is a point-in-time result against a deployed state. If you ship weekly, it is stale within a month and it never sees the twelve releases that follow it. This binds the same testing to the release cadence instead of the calendar.
How to start
Send the application, the release cadence, and what is driving this. If a single penetration test would serve you better right now, that is what the first call will conclude.
Direct: hello@principlebreach.com