Risk Grustlers EP 18 | Bridging the security-dev divide

In this Black Hat special episode of Risk Grustlers, Nick Muy, CISO at Scrut Automation, is joined by Siyavash M., CISO at ShyftLabs, for a conversation on how smaller engineering teams can strengthen application security.

From his early days as a software engineer to leading security at a fast-growing company, Siyavash shares lessons on training developers, fostering collaboration between engineering and security teams, and using visibility to drive accountability. The discussion also explores how GRC platforms can bring teams closer and why, amid all the AI hype, going back to the basics of cybersecurity still matters most.

Here are some key highlights from the episode:

Nicholas: You began your career in software development before moving into cybersecurity. What led to that shift?
Siyavash: It happened quite unexpectedly. I was a software developer in Singapore, studying for my master’s in software engineering, when KPMG’s cybersecurity division approached me about joining their team. At that point, I had no plans to work in security. They had a project that required someone who could review source code for vulnerabilities, and since I was comfortable reading and analyzing code, I decided to give it a try. Once I started, I found the work surprisingly fascinating. It was like solving puzzles, tracing issues back to their roots, and understanding how small decisions in code could create large risks. That curiosity pulled me in completely. I began learning penetration testing, vulnerability assessment, and network defense, and over time, cybersecurity became not just my job but my core interest.

Nicholas: Having come from a development background, how has that experience shaped how you view application security today?
Siyavash: It has made me appreciate how different the two worlds are. Developers are focused on building features, hitting sprint goals, and moving fast. Security engineers, on the other hand, are focused on stability and protection. Each side has good intentions, but they often speak different technical languages. Because I have worked in both roles, I understand the tension and can translate between them. For example, when a security engineer reports a vulnerability, I can explain it to developers in terms they relate to, such as performance, maintainability, or user trust, instead of abstract risk terms. That translation changes the dynamic completely. It stops being about blame and becomes about improving the product together.

Nicholas: You mentioned the knowledge gap between developers and security engineers. How do you bridge that gap in practice?
Siyavash: I always say that awareness is not enough; you need real training. Developers often know very little about security, and security engineers often know very little about development. When these two groups try to collaborate, misunderstandings are inevitable. The best solution is to train developers with hands-on examples. For instance, I like to show them how a simple input validation mistake can lead to SQL injection. Once they see how an attacker can exploit something they wrote, it clicks. They begin to think differently while coding. You do not need to hire more security engineers to make your company secure. You can make your existing teams stronger by helping them understand what secure code looks like and what can go wrong if they overlook it. Over time, this reduces vulnerabilities and builds confidence across the board.

Nicholas: What role do QA teams play in that approach, especially in smaller organizations?
Siyavash: QA teams can be a bridge between development and security. They already test software for functionality, making sure inputs and outputs behave as expected. If you extend their test cases slightly to include security checks, such as validating inputs or checking for injection points, you naturally integrate security into the software development lifecycle. This approach works especially well for smaller companies where everyone wears multiple hats. It removes friction because security findings come from the QA process instead of an external audit. Developers see it as part of normal quality assurance rather than criticism, and that helps security flow more smoothly through the pipeline.

Nicholas: Disagreements between developers and security engineers are common, especially around what counts as a vulnerability. How do you handle those?
Siyavash: The key is to make sure both sides understand the context. Developers often believe that if the code runs correctly, it cannot be a vulnerability. Security engineers sometimes expect everything to be fixed in the code, even when the issue lies elsewhere. I have seen both sides argue endlessly over the same issue, one insisting it is not a problem and the other insisting it is critical. The truth usually lies in the middle. Sometimes the solution is architectural, such as scanning uploaded files before they reach the system, instead of changing the code itself. When teams understand that not every issue belongs to one group, it breaks the cycle of blame and builds trust.

Nicholas: You have also talked about GRC tools helping beyond audits and certifications. How can they improve security across an organization?
Siyavash: Most people think of GRC tools as something you use during audits to collect evidence, manage controls, and simplify compliance. But a well-integrated GRC system can go far beyond that. Vulnerabilities appear at every level of an organization, in infrastructure, code, CI/CD pipelines, and even internal processes. By connecting these systems to your GRC platform, you get real-time visibility into where issues exist. Instead of isolated reports, everyone from project managers to engineers can see the same data. That visibility changes behavior. Teams begin to fix vulnerabilities earlier because they can see the impact directly. And when everyone can see what is at risk, accountability becomes shared.

Nicholas: After spending the week at Black Hat, what do you think is missing from today’s conversations about security?
Siyavash: Everyone is talking about AI, how it introduces new risks, how it can automate detection, and how it might solve everything. But we are ignoring the basics. Many teams still have untested infrastructure, outdated dependencies, and poor visibility. I have seen AI-based scanning tools that miss simple issues like SQL injection. So before adopting the newest technology, organizations need to get their fundamentals right. Secure your infrastructure, secure your code, train your people, and then use new tools to enhance what already works. Security should evolve with innovation, not get distracted by it.