How Datto made developer-first security a reality with Snyk

When David McCheyne, DevOps Engineer at Datto, outlined a plan to ease the company into developer-first security using Snyk, he thought it would take his teams a year to prove the concept. A seasoned DevOps pro, David understood very well the enormity of this change and was prepared to slowly introduce Datto security champions to the Snyk platform and not force the process.

It was a great plan that quickly changed. In a matter of months, all of Datto’s developer teams had embraced Snyk. “Within a couple of weeks of launch, developers were talking to each other about making stuff better, and they started coming to me to ask if their teams could try [Snyk] too,” he explains. “Before I knew it, almost by accident, every product team from Datto had a security champion who had implemented Snyk.”

At a time when developing safe software with speed has never been more critical, Datto’s nearly painless adoption of developer-first security offers a model nearly any company can follow. We asked David to share what teams should prioritize and what they should prepare for. Spoiler alert: fast adoption wasn’t David’s only surprise!

Start with buy in

Developer-first security requires buy-in, especially from developers. David says that’s the single hardest thing about the entire process. “Developers want to do the right thing but they have a lot of competing interests,” he says. “There are always new features, new technologies, operating system upgrades… always 12 different things competing for a developer’s attention. And security’s not sexy or exciting and it doesn’t pay big dividends unless it’s big news.”

The trick is to make it dead simple for developers. “Snyk lets developers engage in security while doing other tasks,” he says. Because Datto’s software engineering teams live and breathe CI pipelines, it was a low implementation effort to add Snyk into those existing processes where it didn’t get in the way of normal operations. With the added traffic signal, developers were able to know instantly which dependencies needed upgrades early enough in the process that they didn’t reach the red light. “This makes it so easy for our developers to do the right thing while not competing with the time spent developing products. Snyk did a great job addressing this issue for us.”

And there was an added bonus in the form of drastically reduced dependency management debt. Dependency resolution is no developer’s favorite thing to deal with, but automating the process has been a complete game changer at Datto, David says. Although most of Datto’s projects only have between three and five dependencies, some have upwards of 2500. That’s a lot to wade through if a developer isn’t using the right version and only discovers it at the end of the process. “In every single developer CI pipeline and every single commit there’s an extra little stoplight signal that everyone can see and be empowered to address that problem dependency early in the process,” David explains. With Snyk in place, Datto’s teams are “able to spend more human time on different and more valuable application-level security issues while worrying about dependencies a whole lot less.”

Take a broader look at security

David was understandably so focused on dependencies that he was pleasantly surprised to find Snyk could deal with another time-consuming process: open source license scanning. “In a lot of companies open source license scanning is a totally manual process involving legal and IT,” David says, and that was certainly true for Datto. But once Snyk was in the CI pipeline, David realized he could take already reviewed licenses and set those projects in Snyk. Legal and IT “aren’t in the same CI spaces because they’re entirely different teams, but saving time on license scanning using Snyk was a surprisingly invaluable bonus that worked out well for us.”

Embrace security champion diversity

If Datto’s development teams had a secret weapon in their shift to developer-first security it has to be security champions, David says. The internal buzz about Snyk had people from all parts of the company raising their hands to get involved with the security culture. But buzz or not, it’s important for companies to cast a really wide net while building a security champions program, he explains. “Don’t make it a secret Security club,” he says flatly. “The goal is for everyone to play a part in security and the more people involved and thinking about security the better.”

David saw people from “unusual corners” of Datto step forward around the security champion role, many who had no idea what specifically was involved in being a champion. Part of the reason is Datto’s culture, which likes the concept of “guilds” and is supportive of cross-functional teams. “We have a high level of ceremony around our security champions,” he says, but adds it’s important to fit a champions program into a company’s existing culture. “There’s no one size fits all,” he says. “You need to understand how to fit a security champions program into your own jigsaw puzzle.”

Build a strong DevOps culture

Developer overload is real and it’s something to consider when moving towards developer-first security, David says. But a strong DevOps culture should be an antidote to that. Listen to your DevOps teams and take their feedback to the people designing the products, he suggests. DevOps advocacy around developer tooling and workload is critical to organizational health and success and their concerns should be amplified. DevOps teams need to be prepared to take a stand on tech solutions, particularly those that might increase developer workloads. Every company wants to be more efficient, but if leadership doesn’t appreciate the importance of DevOps culture in delivering a strong developer experience, overload and burnout can occur. Teams want solutions that make it easy to do the right thing, David says, like Snyk.

Just do it!

David’s last piece of advice is quite straightforward: don’t be afraid to try. Concerns about buy-in, culture, cost, and support are all real, but need to be balanced with the importance of just getting started with security engagement. “It’s easy to be concerned about how difficult it might be to build a developer-first security practice and whether it would catch on or be popular,” David says. But if teams choose technology well and roll out wisely, the responses can only be positive. “One thing Snyk did a really good job with is creating a product that makes developers’ lives better in little but meaningful ways. Our dependency visibility is in such a healthier state today because of it.”