I have been fortunate enough to lead both engineering teams and security teams. I have felt the pain on both sides. On the engineering side, I felt the pressure of delivering for my product leaders and client services teams. On the Security side, I pressed hard to achieve acceptable risk levels and to remove vulnerabilities for my own organizations and clients. Eliminating competing priorities between Engineering and Security is, in my opinion, one of the most challenging elements of a CISO’s role.
Engineers want to own their own destiny as they build great applications and products. AppSec needs to intercept the build/deploy pipeline to enforce scale, code coverage, adoption and visibility. Oftentimes, AppSec teams implement high-touch technology and processes where they own the deployment of security tools into engineering workflows and gate deployments with human reviews. This strategy may work occasionally but it mostly doesn’t scale. It checks a box but creates incredible friction in the product engineering lifecycle.
Combine these years-old challenges with the fact that we’re facing very tough economic headwinds in 2023 and perhaps into 2024. CISOs and CTOs may face more pressure to optimize, reduce cost and do more with less than ever before. We’re going to have to scale by changing the way we attack the AppSec challenge and forging strong platform partnerships to support our new process/skill orientation.
So how do you get started? Here’s some what I’m seeing from the best and most innovative Security teams:
Reframe the conversation
Engineering lives in the worlds of Epics, Features, Bugs, Code Quality. Security tends to have more traditional project planning and a completely different vocabulary. Start by closing this gap.
Consider the following tangible steps:
- Engage in the CTO’s normal operating processes where code quality is reviewed. If you’re not already at this table, seek the opportunity to “listen in” or observe how your organization’s Product Engineering teams function. Avoid interjecting as an observer, listen to learn. Take abundant notes on process, terminology, and key challenges. Bring this information back to the Security team.
- Spend time formatting AppSec data and metrics to use the same terminology that you heard as an observer. An easy example would be to consider referring to code vulnerabilities as Security Bugs.
- Take your vulnerability data out of siloed security systems and partner with engineering to incorporate the data into code quality reviews, bug/defect metrics.
At the end of the day, vulnerable code is not quality code. We tend to have separate conversations about code quality and security vulnerabilities. Integrate those two things.
This is post one in a series of articles by our CISO Chris Hatter discussing topics of relevance from his experience in the CISO chair. Please check back next week for the 2nd installment of this discussion.