Five questions an audit answers
- Is it exposed? The common vulnerability classes, checked specifically
- Is it supported? PHP version, framework version, dependency currency
- Is it tested? Not coverage percentage, but whether the important parts are covered
- Is it maintainable? Could another developer work on it
- What would a typical change cost? The most practical measure of all
The last question is the one that matters commercially. A codebase where a simple change takes three days is expensive regardless of how it scores on any metric.
Security, specifically
- Database access — parameterised, or string concatenation?
- Output escaping — consistent, or ad hoc?
- File uploads — where do they land?
- Authorisation — enforced server-side on every action?
- Dependencies — any with known vulnerabilities?
Practical maintainability signals
| Signal | Indicates |
|---|---|
| Can it run locally in a day? | Setup is documented |
| Are deployments repeatable? | Process exists |
| Is there version control history? | Changes are traceable |
| Do the tests pass? | They are maintained |
| Is configuration in the environment? | Environments are separable |
What an audit should produce
A prioritised list: what is urgent, what is important, what is cosmetic, with an effort estimate against each. Not a list of every style deviation.
The output should let a non-technical owner decide what to fund, which means it has to be written for them rather than for a developer.
When to commission one
- Before acquiring a business that depends on the software
- When taking over from another supplier
- When changes are taking longer than they used to
- Before deciding between fixing and rebuilding
- After a security incident, obviously