How Druva built a scalable, culture-driven security program with creativity, engineering ownership, and a little Star Wars magic.
“Shift Left” Sounds Great, Until You Run Out of Headcount
Druva Engineering operates in a fast-paced, rapidly scaling environment. Teams are constantly launching new services and expanding data protection capabilities across cloud-native, data center, endpoint, and SaaS workloads.
At the same time, Druva’s cloud-native platform spans diverse tech stack and multi-cloud deployments — containerized microservices, serverless functions, APIs, and integrations across AWS, Azure, and third-party ecosystems. Add in the rise of AI-assisted development, and feature velocity soared.
While the “Shift Left” philosophy was well established, traditional security scaling methods couldn’t keep up. Like most organizations, Product Security teams were outnumbered, leading to delayed or post-implementation reviews. More “catching up” than shifting left.
The realization was clear:
It wasn’t a headcount problem, it was a leverage problem.
As Bruce Schneier famously said, “Security is not a product, but a process.”
That process needed broader participation and stronger ownership across engineering.
Security Champions: The Obvious Idea, Done Differently
Security Champions seemed like the natural solution — embed security-minded engineers within development teams to scale product security. But in practice, most programs fail due to vague roles, inconsistent engagement, lack of accountability, and little integration into real workflows.
Druva wanted to do better. To succeed, the program had to deliver measurable value — not just to security teams, but to every level of engineering.
- For Developers: Meaningful, career-enhancing work — not just “extra” work. Visibility, recognition, and credit during performance reviews.
- For Engineering Managers: A trusted partner within the team who can flag risks early and reduce last-minute surprises.
- For Leaders: Scalable risk reduction, faster compliance cycles, and improved incident response without adding headcount.
The result: a program that didn’t feel like a mandate but a strategic enabler.
Becoming a Security Jedi
To make the program memorable, Druva introduced a theme that fit naturally into its culture — the Security Jedi.
With Star Wars–inspired visuals, swag, and training decks, the identity immediately captured attention and made participation fun. But behind the creativity was structure and clarity.
Who are Security Jedi?
They’re engineers who play an active, defined role in the Secure SDLC and product security activities. Their responsibilities include:
- Performing Security Impact Assessments for new features and major changes
- Participating in architecture risk discussions
- Triaging vulnerabilities for their teams
- Contributing to security standards and guidelines
- Conducting code reviews using curated checklists
They’re not expected to memorize every OWASP Top 10 issue — only to recognize risks, think critically, and escalate when needed.
Clarity + Enablement = Confidence
Clarity defined direction. Enablement sustained momentum.
Security Jedi received themed, hands-on training covering topics from Security 101 to Druva’s internal security tools. Storytelling made concepts stick — for example, explaining Risk = Threat × Vulnerability through Luke Skywalker exploiting the Death Star’s exhaust port.
Beyond training, Druva provided tangible tools:
- Context-specific review checklists
- Security guidelines mapped to Druva’s tech stack
- Templates for impact assessments and vulnerability triage
These resources helped Jedi contribute effectively — with confidence, consistency, and connection.
Embedding Security into the SDLC
Even the best programs fail without integration into real workflows. Druva embedded the Security Jedi role directly into the SDLC process using Jira automation.
Every new feature epic automatically generates security tasks — assigned to both the Jedi and Product Security. The Jedi’s first step: a Security Impact Assessment to determine sensitivity, controls, and escalation paths.
Workflows for security design reviews, vulnerability management, and PSIRT events were updated to include Jedi checkpoints — making security a built-in step, not an afterthought.
Visibility, Feedback, and Recognition
Security thrives on visibility and accountability. Druva built lightweight, transparent systems to make Jedi contributions measurable and visible:
- Real-Time Dashboards: Track vulnerabilities, design reviews, and security assessments across teams.
- Regular Jedi Connects: Two-way discussions to share feedback and improvements.
- Quarterly Business Reviews: Presenting Jedi metrics and wins alongside core security KPIs.
- Recognition and Rewards: Shoutouts, swag, and performance review consideration for standout contributions.
This ensured that security ownership was visible, valued, and rewarded. Not just appreciated.
Lessons Learned
- One Size Doesn’t Fit All: Security varies across products, stacks, and workloads. Tailored checklists and contextual content made training relevant.
2. Awareness Beats Expertise: Jedi weren’t hired to be security experts, but to bring a security-aware mindset into every design and discussion.
3. Developers First, Jedi Second: Respecting deliverables and sprint commitments kept the program grounded and sustainable.
4. Engagement Needs Repetition: The Star Wars theme drew people in. Ongoing communication, feedback, and fresh content kept them engaged.
Closing Thoughts
The Security Jedi Program wasn’t just about scaling Product Security — it was about bridging security and engineering, compliance and culture.
What began with a spark of creative branding became a system sustained by role clarity, process integration, and shared accountability.
Is it perfect? No, and that’s okay. Security is a journey, not a destination.
At Druva, we don’t just shift security left, we bring it closer to the people who build, run, and own the product. One Jedi at a time.
Want more such insights? Head over to our tech blog section.