7 AppSec tips from Snowflake’s Director of Product Security

At this year’s AWS re:Invent, Mic McCully, Field CTO at Snyk, spoke with Jacob Salassi, Director of Product Security at Snowflake. They discussed what it looked like for Snowflake to overcome various security challenges with the right combination of processes, company culture shifts, and tool partners (including Snyk!). Read on to learn about the practices Jacob and his team established to create a successful application security program.

How Snowflake established AppSec best practices

As a regulated company working with sensitive data and high-profile customers — including government entities — the Snowflake team knew securing their applications was table stakes. But to get there, Jacob and his team needed to overcome several challenges, such as gaining developer buy-in and establishing process consistency. Throughout his conversation with Mic at AWS re:Invent, Jacob offered several tips for conquering these challenges based on his experiences with the Snowflake team. 

Start with empathy

First and foremost, an application security program requires developer investment. After all, the development teams know their apps better than anyone and can implement security best practices earlier in the development cycle.

To gain developer buy-in, the Snowflake team had to start with empathy — understanding what development looks like and the daily opportunities and challenges developers face. In Jacob’s words, “So I think the one thing that's always been important to me is to approach [AppSec] from the perspective of a developer.” 

Establish a feedback loop

To make this development-security relationship effective, Jacob’s team knew they needed to create an intentional space for conversation. They set up engagement activities such as weekly opportunities, surveys, 1:1 interactions, and community-building. Jacob described his team’s mindset about feedback, saying, “You always have the duty of demonstrating that you've listened.”

Focus on engineering excellence

Jacob’s team also decided to establish a security champion program. But first, they set clear parameters on what the developers could do and what they should handle instead. 

Jacob said, “Something that's very important about our approaches: we talk about engineering excellence, and we try to talk less about security. And when you cross the line from engineering excellence into security, that's when you should ask yourself, ‘Should I be asking a developer to do this? Or should I be bringing in a security engineer to do this?’ And I think something we really focus on is, ‘Just how far up to the line can we take a developer? And where does that line stop?’”

Drive accountability

Another tip from Jacob: empower people to remediate security issues in their own work beyond just securing their first- and third-party code. With this in mind, his team started pushing for an infrastructure-as-code (IaC) approach.

In his words, “I think everybody here understands that developers are accountable for the bugs in their repo. But how many people think developers are accountable for the bugs on the server? I do. And probably many of you are living a story where security operations or other security engineers go and touch production servers that they had nothing to do with manufacturing. You don't know what it is, you didn't build it, and now you're being forced to go and touch it in production and change packages…so a big focus for us is, how do you get all of this in code?”

Create focused training

Jacob also brought up the importance of rolling out periodic, team-specific training. He said, “You should have role-based training, and it should be contextualized. You should not think you're going to get a ton of value out of giving the same slides to every single team.”

Curate the entire security experience

Jacob’s team also focused on curating a seamless security experience for developers by giving them the path of least resistance for completing security activities. To do so, the team set up an agile vendor strategy, including Snyk’s automated PR fixes for first-party code and project management with JIRA. 

In Jacob’s words, “We spend a lot of time making sure that all the information they need is right in front of them and they don't have to leave wherever they were or whatever they're familiar with to resolve that particular issue.”

Document, document, document

As a final thought, Jacob mentioned the importance of documenting all application security activities to benefit future conversations and decisions later down the road. He said, “Something I felt very strongly that AppSec had failed at was retaining its own artifacts... this is valuable data you should structure and persist.”

How Snyk partners with Snowflake in reaching these goals

Reaching these goals was a tall order, so the Snowflake product security team brought Snyk into their application security initiatives. Snyk provided them with tools for success, including:

• Developer-first tooling, built with developers’ existing workflows in mind

• First- and third-party code remediation, right from their developers’ CLIs

• Seamless integration with other pieces of their toolkit, including JIRA

• Detection for vulnerabilities in base image dependencies & Dockerfile commands

To learn more about Snowflake’s partnership with Snyk, tune into Jacob and Mic’s entire conversation from AWS re:Invent 2023.