What security engineers can learn from DevSecOps

The talk argues that DevSecOps should run in both directions: developers learn security, and security engineers should learn how software gets built and shipped. The speaker suggests starting with small, low-priority bugs from the vulnerability backlog. Doing that shows how much work a seemingly simple fix takes, including testing, code review and deployment, and it builds empathy with engineers and personal connections across teams.

The middle covers moving from bug fixes to customer-facing security features, using examples such as a password strength meter, multi-factor authentication and SCIM user provisioning. Security features can serve customers better and open revenue in business-to-business sales. The speaker recommends finding a team already working on something, agreeing on a shared goal and long-term ownership, and justifying funding with questionnaire data, customer contract values and product metrics. Design docs should follow the company template and include reviewers, referenced standards, a glossary, prioritised requirements, diagrams, risks and an early security review.

The closing advice covers pull requests kept short and explained for future readers, thorough tests and manual test notes, planned rollback steps, staggered feature-flag rollouts, and dashboards wired to alerts. Security staff should also share what they learned with the teams they worked with and credit collaborators. The main takeaway is that learning how a company writes and maintains software makes a security engineer better at the job, even without a long-term software career.