Vulnerability checks that actually catch things.

01

What scanners are genuinely good at.

Automated tooling has become very good at the class of problem that can be recognised from a pattern, and you should absolutely run it. It is fast, cheap, tireless and not embarrassed to flag the obvious.

• Known vulnerable dependencies and out-of-date runtimes
• Secrets committed to the repository
• Missing security headers and weak transport configuration
• Recognisable injection and cross-site scripting shapes
• Permissive defaults in cloud and framework configuration

02

What they miss.

Everything that requires knowing what your application is for. A scanner sees code and traffic; it does not know that only a practice administrator should be able to reassign an appointment, or that a refund should never exceed the original payment.

• Business logic flaws — sequences that are individually valid and collectively wrong
• Broken object-level authorisation, where changing an identifier returns someone else's record
• Privilege escalation through a legitimate feature used out of order
• Data exposure that is technically authorised but commercially unacceptable
• Anything requiring two accounts and a specific order of operations to reproduce

03

The pre-release pass.

Before a release goes live, an engineer works through a fixed list. Fixed matters: it means the checks that catch things do not depend on who was on shift or how tired they were.

• Dependencies reviewed, not just scanned — including what any new package was added to do
• Authentication paths: registration, reset, session expiry, logout on every device
• Authorisation tested with two real accounts, deliberately trying to reach each other's data
• Input handling at the boundaries, including file uploads and anything rendered back to a page
• Transport and headers verified against the live host, not the developer machine
• Logs checked for tokens, personal data and full request bodies
• Rate limiting on anything that sends mail, costs money or reveals whether an account exists

04

What blocks a release.

Severity has to mean something or the list becomes theatre. Anything that exposes data belonging to one customer to another, allows privilege escalation, or puts credentials at risk stops the release. No negotiation, no shipping it behind a flag.

Everything else is triaged with a date attached. A medium finding with an owner and a deadline is fine. A medium finding recorded in a document nobody opens again is just a written record of a decision to accept risk quietly.

05

After go-live.

Security is a schedule, not a launch task. Dependency alerts need somewhere to arrive and someone to act on them. Certificates need expiry monitoring that pages a team. Access needs reviewing when people leave, which is exactly when everyone is busiest.

On our care and partner retainers this runs continuously rather than as an annual event, because the alternative is finding out from a customer.