The most expensive security findings are the architectural ones, and they are always found last. A test scheduled a fortnight before go-live can only surface what is already built. If the answer is that the authorisation model is wrong, you are choosing between a delayed launch and a documented risk you have decided to accept.
Security work belongs in the same place as every other quality practice: continuously, in the delivery pipeline, owned by the team building the thing.
Threat model on a whiteboard, early
Before implementation we spend a session on a simple question: who would want to abuse this, and what would they try? Not a formal methodology with a template, just an hour with the people who understand the domain, listing the assets, the actors, and the trust boundaries. It routinely changes the design, and it costs a morning.
What we automate into the pipeline
- Dependency scanning on every pull request, with a policy on what fails the build rather than what generates a report nobody reads.
- Secret detection before commit, because a rotated credential is cheap and a leaked one is not.
- Infrastructure policy checks (public buckets, permissive security groups, unencrypted volumes) as code review, not audit findings.
- Automated tests for the authorisation rules themselves, treating access control as behaviour that can regress.
This tooling is unremarkable and widely available. The differentiator is not the tools, it is that failures block the merge instead of accumulating in a dashboard.
If a security control depends on somebody remembering, it is not a control. It is a hope.
Least privilege, including ours
We work under scoped, time-bound access on client systems, and we ask to have it revoked at handover. It is a small thing that says something about how an engagement is run: the credentials belong to the client, live in their vault, and are auditable per environment.
Compliance is a byproduct, not a project
Teams that build this way find POPIA, GDPR, and customer security questionnaires far less painful, because the evidence already exists. Data flows are documented because they were designed. Access is logged because logging went in with the feature. Recovery objectives are known because somebody drilled them.
The alternative, assembling that evidence retroactively for an audit, consumes weeks of senior engineering time and produces a document rather than a safer system. It is the most avoidable cost in enterprise software, and it comes directly out of the delivery budget.
Do the boring things continuously and the annual test becomes what it should be: confirmation, with a few interesting findings, rather than a crisis with a launch date attached.
About the author
Bonolo Mathabela
Bonolo co-founded Bonang Technologies to prove a specific point: that a small, senior team with clear standards ships better software than a large one with none. As COO they own how the studio runs: how work is estimated, how it is staffed and reviewed, and what is allowed to reach production.
