The ABCs of DevSecOps

Application security is often neglected while development teams prioritize shipping new features, and fixes tend to arrive only after a breach or an audit finding. The session treats this as a problem to solve across the whole application lifecycle rather than at the end. It starts with a plain explanation of DevOps as an iterative, merged cycle of planning, coding, building, testing, releasing, operating and monitoring, and argues that collaboration and automation make that cycle work.

The middle of the talk maps security controls onto each stage. Threat modeling during planning, using frameworks such as STRIDE and MITRE ATT&CK, comes first. Then come IDE plugins and pre-commit hooks, static analysis during the build, and software composition analysis to catch known flaws in third-party libraries. Once software is deployed, dynamic testing, container and infrastructure scanning, runtime monitoring, feature flags and rollback come into play. The speaker stresses that a defect found during requirements costs far less to fix than one found in production, and uses that point to make the business case.

The closing section covers governance. The CISO should define the implementation model and target maturity, while the business decides how much to spend on tooling. OWASP's DevSecOps verification standard and maturity model, DoD guidance and NIST's software supply chain work are offered as references. The main takeaway is to start small, for example by running a free static analysis scanner, and to secure executive backing and developer buy-in alongside the tools.