Operating security ownership at scale: Twilio’s perspective

As organizations continue to adopt DevSecOps practices to deliver secure software, security ownership is an ever-critical consideration. Snyk recently held a roundtable with Twilio to discuss security ownership in 2021.

In this post, we’ll recap the discussion between Guy Podjarny, President & Co-Founder of Snyk, and Yashvier Kosaraju, Senior Manager of Product Security at Twilio. Twilio’s Product Security teams leverage Snyk Open Source to make sure code is secure at all stages of design and deployment.

How to decide who (Dev or Sec) owns what

When companies move to a DevSecOps approach, one core question they need to answer is: What should my developers and security teams own from a practices and processes point of view?

Security teams should own all the security functions, such as scans, threat models, penetration tests, as well as the processes around a secure software development lifecycle (SSDLC) and corporate security. On the other hand, development teams should own the risk and ensure vulnerabilities are closed in a timely manner.

That said, Kosaraju believes the security team should provide tooling in a usable way so it’s easier to generate results.

"When you hire developers, you look for things like: can they code, can they design, and do they know algorithms,” says Kosaraju. “It’s not a negative aspect, but security expertise is seldom given top priority during the hiring process, so having a core team that’s security focused and making those decisions for your company is critical.” 

Ultimately, executive teams need to make the final decision on who owns what. But it’s the security team’s responsibility to serve as a “center of excellence” for developers since practices and controls will need to be built directly into applications.

It’s also essential to assign specific processes to an organizational structure. Otherwise, companies will have a risk scorecard that reports tons of vulnerabilities with no business unit looped in to fix them. Clearly defined security ownership from the start yields concrete action.

Breaking the “we’re developers, not security people” mindset

Driving developer adoption of security can be difficult for organizations. Oftentimes, there are two major roadblocks for getting started: visibility and ease.

For starters, security doesn’t have a natural feedback loop. This means vulnerabilities often accrue without being resolved until there are so many the business begins to be impacted. Companies need to be very explicit and make security requirements visible to all developers.

The reality is security is just too complicated. And for developer adoption, security should be simplified. One common mistake companies make is taking on too much, too soon. When first getting started, look for an early win, such as implementing open source security and Software Composition Analysis (SCA).

“I think it’s important to show what you have today and where you need to go as a continuous improvement path, so having visibility matters,” says Kosaraju. “I also think it’s important to set boundaries, for example, when you say the security team will secure the company, does it mean they’ll find security issues to fix, or they’ll go fix those issues? Establishing a clear divide of responsibilities around who does what is critical.”

At the code level, Twilio created an ownership model by asking all developers to add a YAML file to each code repository. Each file contains the information necessary to identify the owners within those repositories. The security team can then file tickets in the right queue and contact the owner whenever there is an incident/vulnerability. This helped the company move from manually hunting down owners to being able to instantly locate the correct team and automate vulnerability management.

Measuring security one developer at a time

Starting with a bug bounty program is a great way to understand the ROI of security tools. Once this program is in place, it’s possible to start attaching tools to various parts of the SDLC and drive down the number of bug bounty submissions. A decrease in submissions allows teams to begin focusing on shift left security practices.

“It’s important to keep in mind that when a new tool is introduced, the number of bugs will always spike up,” says Kosaraju. “A key distinction to make is calling out deficiencies in security tooling and capabilities. Security teams aren’t perfect, but acknowledging this reality sends a message that everyone’s working together to make the company more secure while adopting a security mindset.”

The best way for developers to contextualize vulnerabilities compared to overall visibility is to look at how long critical vulnerabilities remain open in a queue. This is an ideal metric to view how responsive teams are in fixing vulnerabilities. For example, if the security team deploys Tool X that flags 30 vulnerabilities as critical, and an Engineering team fixes 29 of those in two weeks, that’s an excellent metric to track over time.

Since security ownership continues to evolve every year, Snyk regularly hosts webinars to gain different perspectives from security professionals within the industry. These roundtables are an opportunity for Snyk to understand the needs of application security teams and developers so companies can continue to align their products to the security needs of organizations like Twilio.