01 / Risk
Identify what is at stake
Connecting data flows, actors and business rules explains why an area matters.
Software and secure development
From risk to a verified fix
A finding delivers value when it leads to an application fix.
02 / Finding
Describe conditions and evidence
Findings identify affected areas, prerequisites and minimal reproduction without overstating impact.
03 / Impact
Turn technical detail into decisions
Data, availability and permission impact informs priorities and accountable owners.
04 / Remediation
Recommend and verify remediation
Fixes address root causes. Where included in the proposal, retesting verifies the original scenario and potential regressions.
Access to other customers' orders through the API
- Affected asset
- Orders API, endpoint /api/orders/{id}
- Impact
- An authenticated user changes an order number to read other customers' data.
- Evidence
- Reproduction steps and shortened request and response without sensitive data.
- Recommendation
- Verify record ownership on the server for every request.
- Verification
- Retest fixes within the proposal's agreed scope.
# logged in as account A
GET /api/orders/1044 HTTP/1.1
Authorization: Bearer ••••••••
HTTP/1.1 200 OK
{ "order": 1044, "owner": "account B" }Different methods reveal different problems
Software security analysis is not a single automated scan. Depending on the objective and available information, we combine reviews of design, source code, dependencies and application behaviour. We agree the methods and depth in the brief.
Architecture and threats
Data flows, trust boundaries, identities, permissions, integrations and tenant isolation. This reveals risks that code scanning cannot see.
Manual code review
Critical implementation and business logic sections, referenced to a specific revision and code location.
SAST and SCA
Static code analysis and dependency checks support manual review. We deduplicate and assess the results in context.
DAST and application testing
Verifying the behaviour of the running application and APIs, including authentication, permissions and business scenarios.
SaaS and enterprise deliveries raise specific questions
OWASP ASVS can provide a control framework, while WSTG and OWASP API Security provide testing guidance. We always describe the specific coverage in the brief so the analysis boundaries are clear.
- Does the server enforce tenant isolation for every relevant operation?
- Do roles and permissions reflect the actual business process?
- How does the application handle integrations, webhooks, tokens and secrets?
- Are security decisions consistent across the UI, APIs and background processing?
- What risks arise from dependencies, configuration and the deployment pipeline?
Deliverables the development team can use
- A summary of risks, impact and priorities for management.
- Technical scenario descriptions, evidence and reproduction steps.
- Affected components, versions and references to code or configuration.
- Recommended fixes and discussion of complex or disputed findings.
- Optional retesting of original findings against an agreed version.
What information to prepare
For the first conversation, a short description of the application, technologies, reason for the analysis and required timing is enough. The engagement itself may require architecture, a specific code revision, build instructions, a test environment, user roles and API documentation.
Not every analysis needs all these inputs. However, missing information is always reflected in the stated limitations of the result.
