Three ways Snyk made software supply chains more secure in 2022

Snyk entered 2022 with a great foundation for securing your software supply chain, including the code that you write, the open source libraries and packages that your code leverages, the components in the build process, and the infrastructure as code (IaC) configurations for systems that your application runs on. Over the course of the past year, software supply chain security has gained visibility as threats like Log4Shell at the end of 2021 spurred the US government to issue Executive Orders requiring vendors to prove their software is built securely.

Software supply chain search trends. Source: Google Trends

If you’ve landed on this blog and have no idea what Snyk is or what we do, or how that applies to secure software supply chains, here’s a quick introduction. Snyk offers a developer-first security platform featuring tools for securing the entire SDLC. Our astatic application security testing (SAST) product — Snyk Code — provides developers actionable advice to mitigate risk, 10-50x times faster than traditional SAST solutions, enabling code checks right in the IDE, without impacting developers' productivity. Snyk Open Source helps identify, prioritize, and provide actionable remediation advice for vulnerabilities in open source software packages. Snyk Container helps developers select safe and up-to-date base images and pinpoints where they are adding vulnerabilities to their containers as they are built, going beyond the industry norm of spitting out a long laundry list of vulnerabilities. And, when you're finally ready to run your applications, Snyk Cloud takes a developer-first, application-centric approach to finding and fixing vulnerabilities in cloud infrastructure, from the time infrastructure is defined in code (IaC), through deployment when resources are running in the cloud  — and detects drift across your cloud infrastructure if the two diverge.

In 2022, Snyk continued to expand on our developer-centric approach to software security, by adding several key enhancements to the existing solutions — let's focus on three key capabilities introduced in the past year that can improve your supply chain security.

1. The code you write

Which comes first, the code that you write or the programming language/framework that you're going to use to build it? We've got you covered either way. Several new features have been added to Snyk Code: not only to facilitate better coding practices in the IDE, but to make it even easier to add functionality in the IDEs. You can read even more about the new language server and other enhancements to Snyk IDE support, enhancements to our SAST solution, and other ways we've bolstered Snyk's developer security platform in 2022.

2. The libraries you leverage and rely on

Depending on the organization and types of solutions being built, it's not uncommon for 70-90% of the code in an application to come from open source libraries and packages, as outlined in the 2022 State of Open Source Security report from Snyk and the Linux Foundation. That means that the majority of the code that developers are leveraging is outside of their control, which makes it even more important for organizations to be able to tell exactly what is included in their applications. Snyk Open Source already had the ability to identify vulnerable libraries and packages from the command line and CI/CD pipelines. In 2022, Snyk extended the IDE support to Visual Studio Code, adding the ability to visualize issues right in the IDE, providing developers easy to understand and in-context remediation advice.

The cost of finding and fixing security vulnerabilities at development time is considerably less time consuming (and less costly) than doing it once an application is in production. As members of the Open Source Security Foundation (OpenSSF), Snyk understands and embraces the fact that the implementation of security best practices needs to start with the developers: they're the ones deciding how to build their applications, and what libraries to use.

Detecting vulnerabilities in IDEs is one way to reduce that cost and friction, but there’s more to safety than just detecting known vulnerabilities. With all the open source packages in use, it’s also important for developers to keep in mind factors like maintenance frequency, size of maintainer community, and even popularity of a package they’re interested in using.

These all signal whether vulnerabilities will be fixed quickly if and when they're discovered. Snyk Advisor has been available on the Snyk website for a while, but we’ve also built Advisor into the IDE experience so developers get a sense of the safety of their packages, even if they currently have no vulnerabilities.

You do everything you can to keep vulnerabilities out of your software, however, things happen. New vulnerabilities routinely get discovered after libraries have been in the wild — potentially even years later. This makes it crucial for organizations to be able to quickly determine what each of their applications is made up of, and that's where a software bill of materials (SBOM) comes in.

An SBOM is a nested or hierarchical view of what makes up an application. Snyk Open Source was built from day one to help secure the software supply chain by enabling developers to pick secure open source packages from the start, test their code for vulnerable packages throughout the SDLC, and continuously monitor applications for new vulnerabilities. Snyk Open Source has expanded vulnerability and fix discovery by including support for exporting SBOMs via the CLI, using the new snyk sbom command, which now enables you to export your SBOM in the open standard CycloneDX format, providing a complete view of what your applications are made of: including transitive software dependencies. SBOM support isn't limited to basic export functionality: we've also added an SBOM checker which allows you to ensure SBOM security:

We also made our package-issues-API generally available, which enables customers to look-up vulnerabilities for a specific package by their package-url (purl), a leading package naming format for SBOMs. We've also contributed a Snyk provider for the Bomber open source project.

3. And the containers that you run

Similar to the way that modern applications rely heavily on open source libraries and packages, developers often rely on public base images as the foundation for the software containers that they build and deploy. Many of these come from Docker Hub as "Official Images" – popular container images, several of which are published and maintained by Docker. Starting from these base images, developers add their code or compiled applications, along with the packages that they depend on. In 2022, we added base image detection and upgrade recommendations for Red Hat’s Universal Base Image (UBI) versions 8 and 9.

Snyk Container already keeps track of popular Docker images and provides base image recommendations — as well as giving developers automated remediation capabilities via one-click pull request (PR) generation, providing teams the ability to quickly and easily move to more secure versions of the public images. In 2022, we added the ability to flag curated or "golden" images as "Custom Base Images", and insert those golden images into the recommendation logic (available as an open beta). This is a popular pattern in many companies, relieving developers of the need to worry about most of the container packages, and the new Snyk Container feature allows your devs to determine the best place to start while keeping within policy, using the same automatic remediation logic previously only offered with Docker Official Images. This allows organizations to define and curate their own base image options, providing even more control over the security of their software supply chain.

Developer-centric tools strive to meet the developers "where they work", and Snyk Container scans allow developers to leverage the tools they already use to build more secure containers. From an operational standpoint, the new-in-'22 integration between Snyk and Sysdig provides additional context from running workloads to help prioritize fixes, so you can further secure your software supply chain.

Bring on 2023!

While I mentioned way more than three things in this blog, here are the key takeaways from a supply chain perspective for Snyk in 2022:

• New language server support to streamline IDE plugins

• SBOM generation, tools, and support

• Custom/golden base image recommendations

• Runtime integrations

We hope that you also had a productive 2022, and we hope that 2023 is even better!