With his deep expertise in endpoint security and cybersecurity strategy, Rupert Marais has a front-row seat to the evolving battleground of application security. He has spent his career navigating the complex intersection of network management and software development, giving him a unique perspective on the immense pressure teams face to innovate rapidly without sacrificing security. He understands that in today’s digital ecosystem, the code that powers a business is also its most vulnerable asset.
In our conversation, we explore the critical skills gap that continues to challenge the industry and what effective, hands-on training truly entails. Rupert breaks down how organizations can strategically combine tools like Software Bills of Materials (SBOMs) and centralized repositories to move from merely identifying vulnerabilities to intelligently prioritizing them. We also delve into the cultural and technical hurdles of embedding security into automated pipelines and discuss how CISOs can prove the value of DevSecOps to the board. Finally, we look to the future, examining how emerging practices like “vibe coding” and AI-assisted development are reshaping the threat landscape and what the next five years hold for the delicate balance between agility and security.
Last year’s report found that 44% of organizations see the skills gap as their biggest AppSec obstacle. Beyond basic training, what specific, advanced skills are most in-demand, and what does a truly effective, hands-on secure coding program look like step-by-step?
That 44% figure doesn’t surprise me at all; in fact, I feel it in conversations every week. The real skills gap isn’t just about knowing the OWASP Top 10. The advanced skills in demand today are about proactive, architectural thinking. We need developers who can conduct threat modeling for complex microservices architectures, not just monolithic apps. We need engineers who understand the nuances of API security beyond simple authentication—things like rate limiting, input validation, and preventing business logic abuse. A truly effective program moves past slideshows. It starts with a baseline of secure coding principles, then immediately throws developers into hands-on, simulated environments where they have to exploit and then patch real-world vulnerabilities. From there, you cultivate a “security champions” program, embedding skilled advocates within each development team. This creates a culture where security is a shared responsibility, not a bottleneck.
With nearly half of organizations using a centralized repository for dependencies and 39% using SBOMs, how can teams effectively combine these tools? Please describe a practical workflow for using both to not only identify but also prioritize the most critical vulnerabilities for remediation.
It’s fantastic to see adoption rates of 49% for centralized repositories and 39% for SBOMs, but using them in isolation is a missed opportunity. The magic happens when they work together in a cohesive workflow. Think of your centralized repository as the gatekeeper—it’s the single source of truth for approved, vetted, and licensed components. When a developer starts a build in the CI/CD pipeline, the first check is against this repository. Then, once the application is built, an SBOM is automatically generated. This isn’t just a list; it’s a detailed receipt of every single component in that specific build. That SBOM is then fed into a scanning tool, which cross-references it with vulnerability databases. The final, critical step is prioritization. Instead of just getting a list of 500 CVEs, you correlate the findings with your own code analysis to answer the key question: “Is this vulnerable function actually reachable in my application?” This combination turns a firehose of alerts into a focused, actionable list of the five or ten things that truly pose a risk to your business.
The article highlights integrating security into CI/CD pipelines. From your experience, what are the primary cultural and technical roadblocks to achieving this DevSecOps automation, and what key metrics can a CISO present to the board to demonstrate a tangible return on that investment?
The biggest roadblocks are almost always human first and technical second. Culturally, there’s a deep-seated fear on both sides. Developers feel that security is a “Department of No” that will slow them down, while security teams are terrified of losing control by automating their checks. Overcoming this requires building trust and shared ownership. On the technical side, the main hurdle is “tool sprawl” and the resulting alert fatigue. Organizations buy a dozen different scanners that don’t talk to each other, overwhelming developers with conflicting and often false-positive results. To show ROI to the board, you have to speak their language. Forget talking about CVEs. Instead, present metrics like a 50% reduction in Mean Time to Remediate (MTTR) for critical vulnerabilities. Show them the decrease in security-related production incidents, which directly translates to brand reputation and uptime. You can even quantify the number of developer hours saved by catching flaws early, preventing costly rework later. That’s how you prove DevSecOps isn’t a cost center; it’s a competitive advantage.
The content mentions new challenges like “vibe coding” and AI agents expanding the attack surface. How do these modern practices change traditional vulnerability patterns, and what initial security controls should developers implement immediately to mitigate the unique risks they introduce?
These new practices are fascinating because they shift vulnerability patterns from obvious coding errors to more subtle, architectural flaws. “Vibe coding,” or developing based on intuition and rapid iteration, often leads to developers bypassing established security protocols, resulting in complex logic flaws that a simple scanner might miss. AI agents, while powerful, can be a Trojan horse; they might suggest a convenient but insecure code snippet or pull in a dependency with a hidden vulnerability. The attack surface expands from the code you write to the code you trust. The first line of defense is non-negotiable guardrails. For “vibe coding,” you must implement automated security gates within the CI/CD pipeline that cannot be bypassed. For AI agents, the immediate control is twofold: first, all AI-generated code must be subjected to the same rigorous static and dynamic analysis as human-written code before it gets committed. Second, you need stringent dependency analysis to ensure the AI isn’t introducing a poisoned library. It’s about enabling innovation while maintaining vigilance.
What is your forecast for the state of application security over the next five years, especially concerning the tension between developer agility and the increasing sophistication of threats?
That tension between speed and safety won’t go away; it will become the primary engine of innovation in AppSec. I forecast a major shift towards what I call “ambient security”—tools and processes that are so seamlessly embedded into the developer’s native workflow that they become almost invisible. Think of security feedback appearing directly in the IDE like a spellchecker, not as a blocking gate hours later. AI will become a profound double-edged sword. Threat actors will use it to discover zero-days and craft sophisticated attacks at an unprecedented scale. In response, defenders will leverage AI not just for detection but for automated remediation, suggesting secure code replacements in real-time. The ultimate goal will move beyond just finding vulnerabilities; it will be about building inherently resilient systems that can anticipate and withstand attacks, ensuring that even when a flaw is present, the business impact is minimized.
