August 31, 20230 mins read
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
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?’”
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.