How Spotify uses Snyk to secure the SDLC

Spotify’s engineering team recently published a blog discussing their use of Snyk to maintain security testing in the SDLC. The following is a recap of that blog written by Engineering Manager, Edina Muminovic.

Spotify, a company known for employing thousands of world-class developers, needed to redraw its software development lifecycle, or SDLC. An ever-increasing surface area of attack meant that security couldn’t be an afterthought or even a final, important step — it had to be threaded through the entire development process. That’s why Spotify added Snyk, which has enabled their development team to create a new SDLC that better accounts for and prevents the possibility of a cyberattack.

With Snyk, Spotify can perform security assessment scans to find and identify vulnerabilities before they’re released and before attackers can use them. Further, Spotify can use Snyk throughout all stages of the SDLC, including design, development, deployment, maintenance, and product delivery.

Snyk helps support Spotify’s secure supply chain initiative

Nowadays, much of the software that companies and developers build isn’t exclusively the result of original coding, but is instead the result of components gathered and assembled together. These components can be large or small, private or open source, simple or complex. 

This multi-step process forms a software supply chain, a system that is inherently likely to include vulnerabilities. As Spotify redraws its SDLC to emphasize security, it also needs to account for the nature of the software supply chain and ensure that it never delivers malicious or vulnerable software to its customers.

Snyk is part of a category of tools that Spotify refers to as “reactive controls.” The primary goal of using reactive controls — as well as the main goal of Spotify’s secure supply chain initiative — is to ensure that the software Spotify uses doesn’t open it, or any of its customers, partners, or users, to any vulnerabilities that attackers can exploit.

Spotify uses Snyk’s vulnerability management platform — part of its general application security program — to track the lifecycle of relevant vulnerabilities. This tracking enables asset owners and operations teams to identify, address, and remediate vulnerabilities.

Remediation, due to the volume of vulnerabilities in and outside of a given codebase, is a game of risk management. Spotify arms its asset owners and operations teams with internal vulnerability policies, ensuring that they can track vulnerabilities and prioritize the most severe risks.

Even strict prioritization, however, would leave Spotify developers with a heavy remediation workload. But with Snyk’s automation, Spotify can keep its software, assets, and components up-to-date, providing a base layer of protection that safeguards it from some of the most common, albeit most severe, vulnerabilities.

Spotify prioritizes comprehensiveness and flexibility

Spotify is focused on two factors as it integrates security testing into its SDLC — comprehensiveness and flexibility.

Comprehensiveness is important because Spotify uses a wide variety of languages and package managers. An application security scanner that scans only a portion of those languages and package managers would hardly be useful.

Flexibility is essential because Spotify needs tools that can integrate into its existing CI/CD. Without the right integration, security would not feel like the essential part of the SDLC Spotify wants it to be.

Spotify chose Snyk, in part, because it fulfilled and captured these two factors. Snyk supports almost every language and package manager that Spotify needs, plus many more. Spotify was also able to integrate Snyk into its build pipeline, which enabled them to scan for vulnerabilities in review builds.

Security as enhancement, not burden

Developers are often wary of new security tools and programs because security sometimes has the reputation of slowing down the development process. Mindful of this possibility, Spotify had two complementary goals — build a stronger security program, and enable developers to focus on their own priorities even as they put security into practice. Snyk has helped Spotify to do both.

With Snyk, Spotify has been able to make the adoption of security scanning as simple and seamless as possible. For some languages and frameworks, the embedding of vulnerability scanning into CI/CD pipelines has been automatic. For other languages and frameworks, sheer automation isn’t possible, so Spotify has provided simple guides to help its developers add Snyk scans to the lists of build steps for their applications.

These complementary goals have already been achieved and are already working in tandem, as the number of scanned projects at Spotify is continuously increasing.

Keep risking responsibility

“Keep risking responsibly” is the mantra within the security team at Spotify. Risk, after all, is possible to reduce, but impossible to eliminate. By recognizing this, security teams can build the kinds of security and risk management programs necessary to address the complex security concerns brought on by ever-evolving software supply chains.

With the adoption and integration of Snyk, Spotify has built a much more holistic security program that emphasizes security throughout the SDLC.

Attackers, and the kinds of attacks they use, are advancing rapidly and companies need strong security programs to keep up. With Snyk, Spotify can automatically generate and merge vulnerability fixes without the intervention of engineering or security teams. Snyk also provides APIs Spotify can use to track the lifecycle of vulnerabilities, enabling Spotify to integrate vulnerability data directly into its vulnerability management platform.

Spotify takes risks, but with Snyk, it can do so responsibly and securely.