As the CISO at a tech company, my responsibilities include empowering our software engineering teams to maintain a strong security posture of our products. While everyone agrees that security is important, the different incentives of security and engineering teams can make it harder to collaborate. Here's some advice on weaving security into the software development cycle based on my experience as a security leader (now, at Axonius) and a product manager (prior to my current role).
Understand the Teams' Motivations
To collaborate with software teams, first understand their worldview. What motivates them? What incentives has the company defined for their work this quarter, this year, and for the longer term? What factors do they believe contribute to their professional success? Security teams need to frame our efforts in a way that works with these goals.
Product teams are primarily driven by business objectives such as shipping requested features, acquiring customers, and hitting revenue for the business. With these motivators, security can get deprioritized, especially when release deadlines loom. Contrast this mindset with that of security teams, which focus on reducing risk, ensuring compliance, responding to incidents, and earning customer trust.
Understanding the motivations of the engineering team will help security professionals maintain levelheadedness, for example, when they don't understand why their security concerns are not immediately addressed. And it'll make it easier to offer security guidance in the right way and at the right time.
Balance Each Other's Responsibilities
Because of the different roles and objectives, engineering and security teams often see the same goal from very different perspectives. That's good because this allows each team to balance each other.
For example, when supporting the expansion of the company's user base, engineering and product management teams might ask, "What new features should we develop to attract more users?" The security teams will wonder, "How will the new features expand our attack surface?"
Even though all teams' work ultimately supports the company's business objectives or mission, we play different roles. We should balance each other's efforts so that there is not too much security (which can slow down the business) and not too much careless engineering (which can expose the company to unacceptable levels of risk).
Apply Pressure While Being Supportive
So, the security team's focus on secure coding principles and risk mitigation should balance product and engineering teams' software and revenue goals. The security team can help the company balance these objectives by applying pressure on other teams. This involves highlighting practices that exceed risk tolerance thresholds, offering guidance, and holding the teams accountable for their security responsibilities.
To apply pressure in a constructive way, security professionals need to understand the world of product managers and software engineers. This means knowing their terminology but also reviewing the relevant roadmap plans and sprint details. This also involves being invited to and attending discussions where prioritization and architecture decisions are made.
Security teams are often in the position to identify or report vulnerabilities in homegrown code or third-party dependencies. Being supportive in this aspect of our practice involves spotting such issues as early in the development process as possible--the earlier we bring up the issue such as during code commit and build, the less costly or disruptive it is for the engineers to address it.
Applying security pressure often means prioritizing the vulnerabilities and influencing the engineering teams to address them in a timely way. This means being careful about not overwhelming developers with immaterial or inaccurate findings and ranking. When prioritizing such issues, we should take into account not only the vulnerability's severity--say based on the results of an automated scan--but also factors such as exploitability and business criticality. We should include in the analysis context and conduct a more nuanced risk analysis to know which security flaws should be prioritized for remediation over others.
We should recognize that the product's code base will always have some vulnerabilities and carry some level of risk. Be pragmatic in deciding what residual risk levels are acceptable. Work with devs to establish SLAs that allow them to ship on time while also fixing the highest-risk issues within a reasonable timeframe after release. Making incremental security gains over multiple release cycles is often more sustainable than aiming for perfection in every release.
Keep Learning About Securing Software Products
To hear more of my thoughts on securing products, watch the Seeding AppSec podcast episode that I recorded with Nir Valtman and Simon A. Wenet. The content of this post draws on our discussion: