Sida Say, SSCP, CC, shares his experience of transforming his organization’s approach to security, starting with a simple code check and growing it into a company-wide culture change.
Disclaimer: The views and opinions expressed in this article belong solely to the author and do not necessarily reflect those of ISC2.
In fast-moving development environments, security often struggles to keep pace. Early in my career as a DevOps engineer, I believed the solution was simple: add more tools, automate more checks and security would fall into place. But I quickly learned otherwise. Tools matter, yes - but people, process and culture matter even more.
Start Security Early and Keep It Consistent
My journey began with good intentions and a simple idea: introduce security as early as possible in the development lifecycle. I started by adding Git hooks to enforce basic security and quality checks before developers committed their code.
Technically, the hooks worked. However, practically, they failed: some developers skipped them, others ignored them and a few disabled them entirely. Since the checks ran locally, there was no visibility or accountability. That was my first lesson: a security control without transparency or shared ownership rarely becomes a habit.
To fix this, I moved our Static Application Security Testing (SAST) into the CI pipeline. This time, every pull request was automatically scanned. If something failed – like security issues, code smell, or duplication – the merge was blocked and developers received detailed guidance on how to resolve the findings. Almost immediately, the tone shifted. Developers could now see why their code failed. They discovered legacy issues, fixed longstanding bugs and learned secure coding practices from the rule explanations.
Even with early success, gaps remained. A few teams still bypassed the checks and occasionally failing code slipped into release branches. It became clear: the obstacle wasn’t technical, it was cultural. To change culture, I needed support from above.
Support from Management Is Foundational
Leadership support is one of the most important success factors in any security program. Security teams must actively seek management’s involvement because leadership sets the tone. Their decisions and actions can make the difference between a policy that exists on paper and one that shapes daily behavior.
The turning point for me came when I met with leadership to show them the vulnerabilities SAST had caught early, along with what could have happened if they reached production. Seeing evidence, rather than hearing theory, changed the discussion. Leadership backed the initiative fully: they communicated expectations clearly, standardized the SAST workflow across teams and helped remove ambiguity around what was optional and what was required.
With their support, we implemented consistent guardrails:
- SAST became mandatory for every project
- Merge permissions were restricted to accountable reviewers
- Exceptions required review and documented justification
- False positives were managed through a clear escalation path
This top-down support transformed SAST from “a DevOps idea” into “the organizational standard.” It also reinforced something essential: security succeeds when leadership champions it, not just when engineers build it.
When executives support security initiatives, it sends a clear message. It makes it easier to secure resources, enforce standards and hold teams accountable. Without that backing, even the best tools or strategies can struggle to gain traction.
Security Culture Grows from People
Leadership may set direction, but people build the culture. Tools and policies provide structure, yet culture is defined by how individuals act every day. In my organization, I see proof of a strong security mindset when developers fix vulnerabilities proactively, staff report suspicious emails and everyone ask questions about best practices.
Even with leadership support, cultural change doesn’t happen through policy alone. It grows from everyday behavior especially from those closest to the code. As SAST matured, I began seeing developers fix issues proactively. IDE agents provided real-time feedback, so many issues never even reached the pipeline. Developers compared notes, shared examples and helped teammates interpret findings. A few became natural “security champions,” providing internal guidance and mentoring others.
This shift wasn’t forced. It grew because people saw tangible benefits: fewer production bugs, fewer emergency hotfixes, cleaner, more maintainable code, and more predictable releases. Security was no longer seen as extra work. It became part of what “good code” meant. And once individuals embraced it, the culture around them changed too. These small actions add up. They show that security is not just a task. It is a shared value.
Make Security Education Practical and Ongoing
Our early training efforts were too theoretical and engagement was low. So, we changed our approach, making security training personal, relevant and hands-on.
For developers, we used real findings from our pipeline: our code, our mistakes, our lessons. We walked through examples of insecure patterns, explored why they were risky and demonstrated how SAST rules helped identify and fix them. This turned training from passive learning into active understanding. For non-technical staff, we focused on practical topics like phishing, password safety and everyday data protection. We used real incidents rather than scare tactics to make risks meaningful.
Over time, security training stopped feeling like an annual compliance requirement. It became part of how we collaborated, discussed risks and improved our systems. Continuous education kept our culture strong and resilient as tools, threats and technologies evolved.
Know What You Have and Understand Your Risks
Once development processes matured, our next challenge was to understand our environment. We discovered fragmented documentation, missing system owners and inconsistent asset details. Security tools only helped if we knew what we were protecting. I duly instigated and led a collaborative effort across product, infrastructure and operations teams to build a unified, accurate inventory: applications, servers, environments, data flows and dependencies.
The resulting inventory enabled us to create a meaningful, simplified risk register that both technical and business teams could understand. Suddenly, risk wasn’t abstract but visible, structured and actionable. Decisions improved because everyone knew which issues mattered most.
Final Thoughts
Building a security culture is not a sprint. It is a habit formed through collaboration, transparency, and shared responsibility. My journey began with failed Git hooks and ended with a deep-rooted culture in which developers, managers and staff all contribute to secure practices. SAST was only the beginning; people were the real transformation. With clear leadership support, practical education and a structured understanding of risks, our teams became more confident, our pipelines became more resilient and our products became more secure.
Ultimately, I learned that real security isn’t built by tools, but by people who understand why it matters and take pride in doing it well.
Sida Say, SSCP, CC, has 10 years of experience in nonprofit, public sector and education technology environments. He has held technical and leadership roles, with responsibility for automating CI/CD pipelines, strengthening application security and improving cloud infrastructure reliability.
