AI
The Triangle of Tension
Security teams say developers ignore security issues. Developers say security slows them down. Leadership asks why breaches still happen despite buying all the tools. This three-way disconnect is the root problem. Security wants safety, developers want speed, and the business wants innovation without incidents. Nobody speaks the same language. That misalignment means even well-designed tools fail. The underlying issue is not tooling; it is a collaboration gap between teams with conflicting definitions of success.
Gatekeeping vs. Enabling: A Mindset Shift
The traditional model treats security as a checkpoint: review at the end, communicate decisions as “no” without alternatives, replace collaboration with compliance checklists. The enabling model flips this. Instead of forcing secure behavior, it asks how to make secure behavior the easiest path to follow. Developers stop being the audience for security and become co-owners of it. Success shifts from zero vulnerabilities to faster fixes and stronger collaboration between teams.
Four Pillars: Alignment and Automation
Two of the four cultural pillars address the structural side. Alignment means translating risk into business impact: instead of reporting 500 vulnerabilities, say that 12 specific fixes could delay the Q4 release by 3 weeks. Share OKRs between security and engineering teams. Measure mean time to remediate and release velocity. Automation goes beyond scanning to fixing: pre-commit hooks, automated PRs for vulnerable dependencies, AI patch suggestions, and escalation only for critical reachable production risks.
Education and Empathy: Designing Security for Developers
Developers don’t hate learning. They hate learning that feels irrelevant. Effective security education ties vulnerabilities to the actual code a developer writes today and uses security champions for peer learning. Blameless postmortems focus on insight, not blame. Empathy means shadowing a developer for a day to map their tool-switching overhead and design security around their workflows. At Autodesk, a network of 250 to 270 developers acts as a bridge between the AppSec team and engineering, each assigned to a specific product.
Translating Security Metrics Into Business Outcomes
Security culture is a business multiplier. Faster releases and fewer last-minute escalations follow from it, and so does stronger developer retention. Culture change takes 6 to 12 months of consistent reinforcement from leadership. Replace raw vulnerability counts with outcome metrics: mean time to remediate directly ties to release velocity, and repeat vulnerability ratio directly ties to incident cost. If mean time to remediate drops, delivery speed rises. If repeat vulnerabilities decrease, developer time shifts to new features.
Q&A
How do you measure culture? Shaik measures through defender days and developer training on security tooling, aiming to eliminate the perception of security as a gate blocker from the beginning of the SDLC. ▶ 20:35
What did applying the four pillars look like at Autodesk? One team was shipping multiple releases because customer fixes kept surfacing from outdated dependencies; after integrating security champions and tooling at each SDLC phase (automated PR fixes, secret scanning), release cycles shortened and shipped artifacts were free of known vulnerabilities. ▶ 22:56
When early and late-stage tool findings diverge, how do you manage the gap? Resolving issues at PR-merge time removes the majority before they reach later stages; it does not cover 100%, but most findings are handled early. ▶ 25:44
What does the security champion network look like in practice? Autodesk has 250 to 270 developer-champions, each assigned to a specific product org; they are developers with security knowledge, not AppSec staff, and act as a bridge between the AppSec team and engineering. ▶ 28:50
Notable Quotes
very few automate fixing Khaja Moinuddin Shaik · ▶ 7:14
So empathy is not about being soft. It’s Khaja Moinuddin Shaik · ▶ 9:56
dashboard can show issues. Only culture Khaja Moinuddin Shaik · ▶ 16:00
Security maturity isn’t a big bang Khaja Moinuddin Shaik · ▶ 19:19
Key Takeaways
- Guard rails embedded in developer workflows scale better than approval gates that review at the end.
- Measure mean time to remediate and repeat vulnerability ratio, not the number of vulnerabilities found.
- One security champion with developer credibility influences a team more than policy documents from the security org.
About the Speaker(s)
Khaja Moinuddin Shaik is Principal DevSecOps Engineer at Autodesk. He focuses on integrating security into CI/CD pipelines, automating AppSec tooling, and building developer-friendly security culture. His work centers on scalable solutions that close the gap between engineering and security teams.