There is a version of DevSecOps that most South African organisations have already bought. It consists of a SAST tool, maybe a container scanning step in the pipeline, a vulnerability dashboard that someone looks at periodically, and a policy document that says security is everyone's responsibility.
This is not DevSecOps. It is DevOps with a compliance layer that creates the appearance of security integration without the substance of it. The distinction is visible in incident retrospectives: when a security issue makes it to production, the SAST scanner ran, but the finding was suppressed or deferred because it was blocking a release. The policy said security is everyone's responsibility, which in practice meant it was no one's.
What the culture change actually means
DevSecOps as a genuine practice is the outcome of changing three things that most tool-first approaches leave untouched: who has security context, when security decisions are made, and whose job it is to fix them.
Security context needs to be in the team that builds the thing. The traditional model — a separate security team that reviews outputs and flags issues — is structurally incompatible with the pace of modern software delivery. A development team shipping multiple times a week cannot route all security decisions through a central function and maintain velocity. The security expertise needs to move closer to the work: either embedded security engineers who work alongside development teams, developer security champions who own the function within the team, or developers who have been genuinely upskilled in the security properties of what they build.
This is not about removing security specialists. It is about changing where the first line of security decision-making sits. Central security functions become advisors, tooling owners, and escalation paths — not the primary reviewers of every change.
Security decisions need to happen at design time, not review time. Finding a SQL injection vulnerability in a code review is better than finding it in production. Finding it before the feature was scoped is better still, because at that point you can make the architectural choice that prevents the class of problem entirely.
Threat modelling — the practice of systematically asking "how could this go wrong?" before building starts — sounds like overhead. In organisations that do it consistently, it costs two to four hours per feature and saves multiples of that in rework, patching, and incident response. It also moves the security conversation to where it is most productive: before code exists, when decisions are cheap to reverse.
The feedback loop needs to be fast enough to change behaviour. If a developer introduces a vulnerability on Monday and learns about it three weeks later in a security review, the feedback is too far from the action to change how they work. If they introduce it on Monday and a pipeline check flags it before the pull request merges, the feedback is immediate, contextual, and connected to the specific decision they made. The second model changes developer behaviour over time. The first just generates findings that accumulate in a dashboard.
Where to start: the three interventions that matter most
Security tooling is not the starting point. These three interventions are.
Name a security champion in each development team. This person does not need to be a security expert. They need to be interested, empowered to raise security concerns, and given time to develop the competence. A security champion who attends team standups, participates in design conversations, and is the first point of contact for security questions changes the team's security posture more than most tools.
Add threat modelling to your definition of done for new features. Not a full security assessment — a structured thirty-minute conversation that asks: what data does this feature touch, who can access it, what does an attacker gain by breaking it, and what are the three most likely failure modes? Document the outputs. They become the basis for the controls you build.
Fix the suppression culture. Most organisations have security findings they have been deferring for months or years. Some deferrals are legitimate — the finding is low risk, the remediation cost is high, and the risk decision was made deliberately. Most deferrals are not deliberate: they happened because the finding blocked a release and someone clicked "suppress" to keep the pipeline moving. Auditing your current suppression list and making the risk decisions explicit — which items are genuinely deferred by design and which are deferred by inertia — is a valuable exercise that rarely takes more than a day.
The South African context
South African organisations face a specific pressure that makes security culture change harder than it should be: the skills shortage is severe, and security skills are scarcer than development skills. Many development teams do not have a security engineer they can embed or consult easily.
This makes the champion model more important, not less. Developing internal security capability — even at a basic level, even one person per team — is more sustainable than relying on external consultants for every review, and it compounds over time.
It also means that the tooling choices need to be evaluated for developer experience, not just capability. A SAST tool that generates hundreds of low-confidence findings that developers learn to ignore is worse than a simpler tool with high-signal findings that get fixed. The goal is behaviour change, not a full findings list.
What good looks like two years in
The organisations that have genuinely embedded security into their development culture share a few characteristics two years after starting.
Developers raise security questions in planning, not just in retrospectives. Threat modelling is a normal part of feature development, not an add-on for compliance purposes. The security findings backlog is managed and declining, not growing. Pipeline security checks are treated the same way test failures are: something to fix before merging, not a box to uncheck.
Getting there is not primarily a tool procurement exercise. It is a change management exercise that happens to require some tools to support it. Start with the culture.
CloudNala works with South African engineering organisations on DevSecOps maturity — from programme design to team enablement. Talk to us if you want a practical assessment of where your organisation is and what would move the needle.