Product security is not about blocking developers with tools in the CI/CD pipeline. It starts with understanding organizational culture and building relationships across engineering, product management, and quality assurance. Trupti Shiralkar, Senior Engineering Manager for Product Security at Datadog, brings over 17 years of experience in security and privacy, including roles as Head of AppSec at Illumina and Product Security leader at Amazon. In this episode, she shares practical strategies for embedding security into engineering culture from day one.
You can read the complete transcript of the episode here >
How should new product security engineers approach security in the development process?
Trupti is emphatic: do not start by rolling security tools into the pipeline and blocking developers. Instead, spend the first three to four months understanding the organization:
- Study the engineering culture: Is it top-down, bottoms-up, or flat? This determines how you introduce change.
- Build an application inventory: Understand what applications exist and which ones to prioritize before applying security controls.
- Identify change catalysts: Find the people across product management, engineering, and TPM organizations who can champion security adoption.
- Create a strategic roadmap: Align security goals with the organization’s mission and vision to get executive buy-in.
For building awareness, Trupti recommends informal approaches like lunch-and-learns where you walk developers through real breaches or explain how specific vulnerabilities like SSRF or XSS work. Making security interesting and intriguing is what breaks knowledge silos and gets engineering teams to want security rather than resist it.
How should organizations quantify and prioritize security risks?
The traditional likelihood-versus-impact matrix from the NIST 800 framework series has been the standard for decades, but it falls short in modern cloud architectures with thousands of interdependent risks. Trupti recommends adding critical dimensions:
- Threat agents: Are you defending against a malicious insider or an external state actor with unlimited resources? The answer changes everything about prioritization.
- Cost of remediation: Is the fix a simple code change or does it require architectural redesign? A two-week fix and a three-month fix cannot share the same priority.
- Existing controls: What detective and preventive controls are already in place? A WAF rule might mitigate an XSS vulnerability while the engineering team works on a proper fix.
The key practice: get everyone in the room. Product managers, architects, developers, and QA engineers should collectively determine risk ratings. This shared ownership prevents security from becoming an isolated function that dictates priorities without context. This approach aligns with how mature teams handle enterprise risk management across complex organizations.
How should teams address security debt without separate processes?
Security debt has evolved alongside the industry. Fifteen to twenty years ago, compliance drove security and it was entirely the security team’s responsibility. With cloud adoption, it became a shared responsibility model. In today’s native cloud applications, the velocity of engineering makes separate security processes impractical.
Trupti’s solution is elegant: merge security into existing engineering processes.
- Join backlog grooming meetings: Instead of maintaining a separate security backlog, sit with engineering teams during their weekly bug grooming sessions. Security issues are software bugs and should be treated as such.
- Use your five minutes wisely: In those meetings, advocate for which security issues can be mitigated immediately and which need strategic planning.
- Build discipline into culture: When security is discussed alongside feature work and regular bugs, it stops being treated as a second-class concern.
This approach develops the discipline of treating security equally within engineering culture. Your voice is heard by all stakeholders in real-time, especially when issues have potential to create breaches. It mirrors the shift from friction to flow that modern security teams pursue.
How should organizations tackle supply chain security challenges?
With 80-90% of enterprise application components coming from open source libraries, supply chain security is a massive challenge. Trupti recommends a three-pronged approach:
- Standards and policy: Have an organizational open source security policy from day one. This becomes a forcing function that makes engineering think strategically about open source usage. Do not wait for your first security hire; this is the CTO’s responsibility.
- Tooling: Deploy software composition analysis tools that integrate well with CI/CD pipelines and engineering workflows. These create visibility into the open source landscape.
- Education and awareness: Build security championship programs to elevate developer security knowledge. Universities are not producing security-aware engineers, so companies must fill the gap.
For practical management, categorize open source components into two buckets:
- Low impact: Components that can be upgraded regularly without causing regression. Keep these current regardless of security issues.
- High impact: Components capable of causing regression. Update less frequently but with thorough testing.
The goal is staying on top of updates as a habit, not just reacting when vulnerabilities are disclosed. This connects to broader supply chain and SBOM management practices.
What methods build a security-centric culture across an organization?
Culture change requires more than annual training. Trupti outlines a multi-layered engagement model:
- Start at hiring: Check candidates’ security DNA during interviews. It is not about existing knowledge but whether they value security.
- Security champions program: Create team-building experiences that introduce engineering to the exciting side of security. Lock-picking villages, cryptography challenges, and privacy workshops make security approachable.
- Tiered engagement model:
- Top 5 critical applications: Embed dedicated security engineers with those teams
- Middle 80 medium/low-risk applications: Train security champions from curious developers
- Bottom 15-20%: Provide self-service security tools anyone can use
The fundamental mindset shift: security should be treated like UX research or performance engineering. Just as teams consult UX researchers for design decisions, they should consult security for architecture decisions. It is part of quality engineering, not a separate discipline imposed from outside.
When building cybersecurity teams, this tiered model ensures coverage scales with the organization without requiring a security engineer for every team.
