SurveyMonkey talks with Snyk about developer security during hypergrowth

Many companies look to CISOs or compliance teams to manage security throughout software development. But this practice usually keeps security considerations separate from developers. CISOs can assign security tasks to developers, but if developers aren’t thinking about security regularly, those tasks may be overlooked. One way to bridge this gap is to bring in a security engineering lead (similar to a security champion) — someone who advocates for security as part of the overall engineering process.

During a recent roundtable discussion, Simon Maple, Field CTO at Snyk, spoke with Craik Pyke, Senior Director of Security, Cloud, and DataStores Engineering at SurveyMonkey (now part of Momentive). They discussed using tools that provide visibility — and creating a paved road approach to encourage developers to focus on security — at hypergrowth organizations. SurveyMonkey uses Snyk Open Source, Snyk Container, and Snyk Code to integrate security throughout their development process. Here’s a recap of the conversation.

Create consistency and visibility

When Craik joined SurveyMonkey, they were using a microservices architecture. Each team was responsible for their own services, from design, to build, to deployment and support. This led to teams doing what they wanted — everyone adding plugins to their own pipelines and using their preferred tools. This created a traceability challenge. There was no clear tracking of where developers were getting containers, or how many dependencies they had. In this environment, Craik’s biggest concern was open source management. He asked if there was a way to track license usage, or to produce a reliable attribution statement. But with everything hand-managed, the answer was usually no.

[Developers would say], "I have 80,000 dependencies in my projects. How do I know what I’m pulling in? And do I have to go look up all these licenses?” That was where we started: we needed to help developers answer the questions — not force them into things because it was security.

With Craik’s experience, he knew this was the first challenge to address: establishing visibility and adding governance. He previously worked at a company that shipped products quickly, but the notion of being able to understand the package versions and open source risks involved wasn’t addressed until a customer asked for it. So at SurveyMonkey, before thinking about visibility, he considered consistency. He needed to establish a DevOps culture, where developers could give the work of building a pipeline to a designated group that would manage it. Once he got people hooked on that idea, it was easy to create a single pipeline for building. Getting to that build artifact was the first step. He quickly moved on to looking at tooling for visibility beyond the pipeline, into what developers were doing on their machines.

Provide better tools and data

Developers like to figure things out — they’ll pull in whatever they need to solve a problem on their own machine or in their IDE. Craik wanted to articulate and define what developers were pulling in during the prototyping phase. He wanted them to have tools that would mirror what happened in the build pipeline and within their IDE or command line.

How do we get [developers] good tooling that’s the same on their machine as it is in the build pipeline? Identifying that, and getting that deployed… was actually an easy uptake for developers once they knew that it mirrored the pipeline. Consistency is key.

He also wanted to give developers good data. For example, making it easy for developers to determine whether a package is viable for a project or whether they should find another one. The best way to do that is with data. When developers know something like Snyk Advisor is available, and they can quickly find metrics — how popular a package is, or what its most recent issue was — they understand the complexity. Craik says this was one of the deciding factors in his current role: to get reliable data into the hands of developers, then trust them to make the right choices.

Build a paved road

Next, Craik started working on a common build infrastructure. He used a common artifacts repository (in his case it was Artifactory, but there are many varieties that work). The main goal was to have developers always pull artifacts down from the registry. This is a vital step at a hypergrowth organization, where a growing team of developers could potentially mean a growing (and unregulated) infrastructure. But Craik didn’t want the security team to act as a blocker. They’d say to developers, “point your favorite configuration file at this artifact system, and if what you want isn’t there, the system will pull it down for you. It’ll help you.” They had to do some evangelizing at first to get developers to make the change. But once everyone was pulling their artifacts through that single artifact cluster, it gave them the visibility to know what’s going where and when — what versions are in play.

Craik’s team did allow developers to work outside of their pipeline — but as soon as they’d try to submit a PR, it would fail. The build pipeline that does their tests from GitHub wasn’t allowed to directly pull from the internet; it only pulls from their artifact repository. So if developers have adopted the expected behavior upfront and are using the artifact store, there’s no issue.

How did the developers not see security as a blocker? We did this with a friendly approach. We used carrots the entire way. We said, "when you go to the single artifact repository, you don’t have to worry about malicious packages or bad licenses, because we can scan things as they come in. We can ensure that you’re not doing the wrong thing." So developers shifted their view of security from being adversarial to being just the question and answer people. We’re there to help, not to hinder.

Security champions: a grassroots thing

While Craik’s team maintained the paved road, some of SurveyMonkey’s developers gradually became security champions. More experienced developers taught newer team members about the artifact repository, how to find signals in PRs, and where to go with questions. Craik calls this “a loose notion of shoving first level support into developer teams.” He didn’t formalize a security champions program, because as people joined the team, focusing on security simply became a learned behavior.

When developers are security auditors for their own code, the security team can be enablers: people who support developers when they need help. Craik points out that with a good paved road and toolset — including Snyk tools that make vulnerabilities easy to detect and fix — the security team can trigger rebuilds of the artifacts if necessary without having to bother developers.

The data we get from our tooling and our pipeline really does let the developer make an intelligent choice.

Share responsibilities and goals

In a successful shift left culture, developers want to handle security requirements upfront. Validation lets them move more quickly to complete revenue-driven work. The security team doesn’t go to developers to say “you have to take these steps because of security.” Rather, the developers come to the security team and say “I see an issue in this package. Is it ok for me to proceed?” The team also strives to share accountability: instead of placing blame for a vulnerability that might have gotten through, they remediate the issue as quickly as possible and then discuss what they learned from it.

Supporting developers also means letting developers support each other. When Craik’s team rolled out Snyk to check for vulnerabilities, they didn't make it a blocker in GitHub. Instead, they allowed more senior developers to coach junior developers during code and PR reviews. A senior developer might say: “This red X means you have an issue. Yes, technically you can still merge the code, but this is what’s going on right now.” There was no hard enforcement on day one; instead, they built a collaborative culture. Ramping up Snyk tools at the right level for SurveyMonkey’s teams was the best approach.

Watch the full talk for more great developer security insights.