Secure development and code review
Three complaints arrive together often enough to be treated as one problem: the code has defects nobody has looked for, the pipeline that ships it enforces nothing, and there is a queue of several thousand scanner findings that no one has owned since the tool was bought.
The short version: the code, the pipeline, and the queue nobody owns
Fixing one without the other two does not hold. A code review that finds thirty defects is worth a quarter of what it should be if the pipeline lets the thirty-first in next sprint. A pipeline full of gates is theatre if the findings it raises land in a queue with no owner and no deadline. And a vulnerability programme with no engineering capability behind it just produces a longer list.
This page covers all three. They are usually bought together and can be bought separately.
Secure code review: what does a finding look like?
Review is performed on source the client supplies, in a repository or an archive. That distinction is deliberate and it is not a formality: this is advice on how to protect data in code you own, not testing of a live estate. Nothing here is run against your production systems. Where you want a running system attacked, that is penetration testing, scoped and authorized separately.
Rarely the whole codebase. Review is aimed at the code that decides who may do what, the code that handles untrusted input, and the code that touches money, credentials or regulated data. A review that spreads itself evenly across a million lines finds less than one that spends its time on the authorization layer, the deserialization path and the payment handler.
Every finding carries the same five parts, because a finding missing any one of them cannot be acted on:
- Location — file and line, with the surrounding context quoted, not a module name.
- Class — what kind of defect it is, mapped to the OWASP Top 10:2025 category it belongs to, so a reader can group it with others.
- Exploitability rationale — why this is reachable, by whom, and under what preconditions. A defect on an unreachable path is written down as exactly that.
- Severity — argued from impact and reachability, not copied from a tool.
- Remediation — the change to make, in your language and your framework, including the case where the right fix is architectural and the tactical patch is a stopgap.
A follow-up re-read of the changed code is part of the engagement. Fixes that introduce a second defect are common enough that closing a finding without re-reading it is not closing it.
Which defects does the OWASP list actually name?
The OWASP Top 10:2025 is the classification used in reports, because it is the one your customers, your insurer and the assessors who examine you already recognize. Its categories are broken access control; security misconfiguration; software supply chain failures; cryptographic failures; injection; insecure design; authentication failures; software or data integrity failures; security logging and alerting failures; and mishandling of exceptional conditions.
Two of those are worth flagging for anyone who last read the list a few years ago: supply chain failures now sit near the top, and the handling of errors and exceptional conditions is named in its own right. What that means for a review is covered in what changed in the OWASP Top 10:2025.
Secure SDLC and DevSecOps design
The pipeline is where a class of defect stops being possible rather than being caught. The design work covers:
- Pipeline controls — which checks run, at which stage, which of them block a merge and which only report, and what the documented route around a blocking check is when a release genuinely cannot wait.
- Branch protection and review policy — who may approve what, how emergency changes are handled, and how the record of that is kept.
- Secrets handling — where credentials live, how they reach a running process, how they are rotated, and how a leaked one is detected before it is used rather than after.
- Dependency policy — what may be pulled in, from where, how new versions are adopted, and what happens when a dependency is abandoned upstream.
- Tool selection rationale — written down, so the next person knows why the stack looks like this and what it does not cover.
- Developer-facing standards — short, specific to your stack, and written to be read by someone in the middle of a task.
A control your engineers route around within a month is worse than no control, because it also produces a false record. Where a gate cannot realistically block, the design says so and makes it advisory on purpose.
Why does a scanner with thousands of findings not make you safer?
Because the tool solved the detection problem and left the two harder problems untouched: deciding which findings matter to this organization, and giving each of those to a person with a date. A backlog of four thousand unactioned findings is not a tooling failure. It is the absence of a programme, and buying a second tool makes it a backlog of nine thousand.
Programme design covers the asset inventory approach — you cannot prioritize findings on systems you have not enumerated; a severity-to-service-level model, so that a critical finding on an internet-facing system has a different clock from a medium one on an internal tool; an exception and risk-acceptance process with an expiry date and a named approver, because permanent exceptions are how a queue becomes noise; ownership, mapped to teams that exist; and reporting that shows trend and ageing rather than a raw count.
No. Running recurring scans against a client estate is an operation this practice does not offer: we design the programme, and your team or your managed provider operates it.
Where AI-assisted development changes the picture
Generated code arrives faster than it can be reviewed, carries the assumptions of its training data, and is frequently accepted by a developer who did not write it and cannot say why a particular branch is there. The secure development practices for that case are set out in NIST’s SP 800-218A, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models, a community profile that extends the Secure Software Development Framework rather than replacing it.
In practice the pipeline changes are small and the review emphasis changes a lot. The specific failure patterns, and what to check for, are in AI-generated code security.
What you receive
| Deliverable | What it is for |
|---|---|
| Findings register | Every defect with location, class, exploitability, severity and remediation |
| Pipeline control design | Which checks run where, what blocks, and the documented route around a block |
| Developer standards | Short, stack-specific, written to be read mid-task |
| Programme documentation | Severity targets, exception process, ownership map and reporting |
| Maturity re-measure | The same assessment repeated later, so the roadmap is answerable |
The shape of the written output is shown in the sample report. It is the same structure used across this practice, so a reader who has seen one has seen them all.
How the work is bounded
The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.
SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.
Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.
Questions we are asked
Do you review the whole codebase?
Scope is set from the architecture, which is why this work pairs naturally with security architecture and threat modelling: the threat model says which components are worth a reviewer’s time.
Which scanner should we buy?
The scanner matters less than the queue behind it, and the tool that fits your languages, your pipeline and the team who will own the findings is the one to buy — we take no commission on any of them. What we do give you is a written rationale for the tool class, so the decision survives the person who made it.
Will you run the scans for us?
The reason is not modesty about capability. An advisory practice that also operates a client’s controls ends up reviewing its own work, and the review is worth less for it.
How does this relate to a penetration test?
Code review reads the source you supply and finds classes of defect, including ones no test would ever reach; a penetration test attacks a running system and proves what is exploitable today. Most organizations need both, and the usual order is review first, because a test that rediscovers what a reviewer would have found in an afternoon is an expensive way to learn it.
Start with the code that would hurt most
Describe the stack, the repositories in scope and what the system holds. The reply says what a review would cover, what you would receive and what is out of scope — see also all security services.