What does a secure code review check?
A secure code review reads the source for the security flaws in the code itself: how users are authenticated and authorised, how input is validated and sanitised, where credentials and keys live, which dependencies are imported and pinned, what is logged, and whether the threat model matches the code.
In detail
ASD's Information security manual recommends code review as one part of software security testing, beside peer reviews, unit and integration testing, SAST, DAST and SCA, and allows independent testing to remove the bias of a team testing its own software. Under ISM-2060, code reviews confirm that software components meet Secure by Design principles and secure programming practices.
ISM-2061 expects peer reviews of all critical and security-related software components, and ISM-0402 expects software to be tested for vulnerabilities before its initial release, before any later release and periodically.
The reviewer starts from the threat model, which the manual expects to support the development life cycle (ISM-1238) and to be reviewed so it reflects the as-built software and changes in the threat environment (ISM-2039). Each trust boundary becomes a question for the code: what checks the identity, what validates the data, and what happens when the check fails.
| Area | What the reviewer looks for |
|---|---|
| Authentication and authorisation | That clients are authenticated and authorised when they call internet-accessible network APIs that modify data (ISM-1818) or give access to data not authorised for public release (ISM-1817), and the same for both kinds of API when they are not exposed to the internet (ISM-2013, ISM-2014) |
| Input handling | Validation and sanitisation of all input received over the internet (ISM-1240) and the local network (ISM-2016), with the rules documented, implemented in code and tested (ISM-2057) |
| Secrets | Credentials, keys and secrets kept out of the source, with commit scanning that finds plain text or encoded credentials, keys and secrets and blocks them from the authoritative source (ISM-2030) |
| Dependencies | Third-party libraries imported only from trustworthy sources (ISM-2029) and pinned to approved versions in the source (ISM-2154) |
| Output and sessions | Output encoding on everything a web application produces (ISM-1241), and session cookies that, if supported, set the HttpOnly, Secure and SameSite flags by default (ISM-2063) |
| Logging | Security-relevant usage, error messages and crashes centrally logged (ISM-1911), and all queries to databases, with any resulting crash or error messages, centrally logged (ISM-1536) |
| Database and uploads | Parameterised queries or stored procedures instead of dynamically generated queries (ISM-1276), serialised data validated before it is deserialised (ISM-2058), and file uploads restricted to specific file types and scanned before access (ISM-2059) |
The ISM expects vulnerabilities found in software to be resolved in a timely manner (ISM-1754), with root cause analysis so that, to the greatest extent possible, the whole vulnerability class is remediated (ISM-1909).
For an Australian organisation
ASD's Information security manual sets out these controls; no Australian law in the sources requires a private firm to run a code review.
If the firm is an APP entity, which includes private sector and not-for-profit organisations with annual turnover of more than $3 million and some businesses of any size such as private sector health service providers, APP 11 of the Privacy Act requires it to protect the personal information it holds.
Where there are reasonable grounds to suspect that a flaw has allowed unauthorised access to that information, the firm must take all reasonable steps to assess within 30 calendar days whether it is an eligible data breach (s 26WH(2)).
