Insights
Application security
OWASP-led assessment work from the practitioner side — what a structured review actually covers, where access-control bugs hide, and the difference between a scanner report and a finding somebody reproduced.
Where we stand
A scanner produces a list. An assessment produces findings somebody reproduced, with the reasoning for the severity shown, which is a different artefact with a different cost and a different value. We would rather hand over twelve demonstrated issues than three hundred lines of tool output that a developer has to triage before they can act.
The findings that matter are usually about authorisation rather than about injection. Products spanning several roles have far more role pairs than anyone wrote acceptance criteria for, and the damaging bug is one account reaching another account’s data through a path nobody enumerated. That work is manual, and it is where most of the value sits.
We are direct about what we are not. An OWASP-based assessment is not a certified penetration test by an accredited body, and we are not a notified body under any European regulation. Where procurement requires either, we say so early rather than at the report stage, because discovering it late is expensive for everyone.
Remediation sessions matter more than the report. Findings explained while the reproduction is still on screen get fixed correctly the first time; findings handed over cold produce a round of clarification and, often, a fix that addresses the symptom.
Articles on Application security
- OWASP assessment vs penetration test: which one your requirement namesSuppliers use the two terms interchangeably. Contracts, insurers and regulators do not. How to read the clause you have been given before you buy the wrong thing.
- Broken object level authorisation: the API risk no scanner will find for youThe top entry on the OWASP API Security Top 10 returns a perfectly normal 200 to the wrong person. Why tooling cannot see it, and how the testing actually runs.
- Triaging dependency vulnerabilities: what to do with 400 open alertsA scanner dashboard nobody opens is worse than no scanner. How to sort advisories by whether they can actually be triggered, and how to record the ones you defer.
- Your first enterprise security questionnaire: how to answer it honestlyTwo hundred questions arrive attached to the largest deal in your pipeline. What the buyer is really assessing, the only three answers worth giving, and where suppliers get caught.
- NIS2 when your customers are in scope and you are notThe directive binds essential and important entities. Its supply-chain article reaches everyone who sells to them, and it arrives as contract clauses rather than as law.
- DORA’s testing programme: what a financial entity has to prove, and how oftenDORA asks for a documented testing programme over the systems behind critical functions, and a much heavier threat-led test for entities singled out for it. The two are not the same product.
- The Cyber Resilience Act’s first deadline: what changes on 11 September 2026From 11 September 2026, manufacturers must report an actively exploited vulnerability within 24 hours. Who that binds, what the clock actually demands, and what to have in place before it starts.
- What an OWASP-based security assessment covers — and what it does notThe difference between a vulnerability assessment and a penetration test, what a report should contain, and why "we ran a scanner" is not an assessment.
Contact
Have a project in mind?
Tell us what you are building — or what keeps breaking. You will get a considered reply from an engineer, not an autoresponder.