Evolving the Snyk CLI through an extensible approach

Every day, thousands of developers use the Snyk CLI as part of their development workflow, to identify and resolve security issues in their code as early as possible. What if these developers and other security professionals could harness the power of this dev-first approach and also utilize entirely new security analyses, filters, and workflows via an extensible approach? Imagine being able to programmatically filter, ignore, and escalate results according to custom business logic, or introducing custom security analysis into an extensible snyk test command and having the results of that analysis surface throughout the software development lifecycle.

This is where we’re going with the Snyk CLI, and today we’re announcing the first step towards this vision with some important changes.

Providing a great CLI experience with a distributed model

Since its very first open source commit, back in 2015, the Snyk CLI has seen incredible growth and adoption. An increasing number of developers rely on it to secure their applications. As a growing set of features that supports many developer-first security workflows, it touches all aspects of a modern day application, from code to cloud.

To realize our extensible vision, and continue to scale and grow the Snyk CLI to deliver value to our users while still providing a clean and consistent command-line experience, we’re moving away from a centralized “monolithic” CLI application to a distributed model. This new model embraces an extensible-by-default approach, governed through stable interfaces.

We are shifting how we architect, build, and release the Snyk CLI, so that the top-level snyk commands act as the common entry point to multiple extensions, with one such extension being the legacy CLI itself.

That’s a lot to picture! Here’s a helpful diagram to illustrate the approach:

This approach has a number of benefits: we maintain backwards compatibility, while at the same time having the means to innovate and introduce new features, in dedicated namespaces. At the same time, we can safely and gradually break apart and decompose the legacy monolithic CLI application into its constituent (and extensible) pieces. 

Those who have been following recent CLI developments closely may have noticed that we’re already practicing this model through the introduction of the snyk sbom command, currently in beta, and written using our extensibility framework.

Stay tuned for future updates

Over time, we’ll see more of these “first-class extensions” being introduced and bundled together as a cohesive whole under the top-level snyk CLI namespace. Our goal is to enable an open ecosystem of useful extensions that provide customization and innovation around the Snyk CLI. For example: a third party security tool that can increase the analyses performed by snyk test to bring additional security awareness into the tools and workflows that developers use and trust every day.

Right now, however, while under the hood things are a little different — with the entry point and extensions delivered as standalone binary executables — from an external perspective, there is no change in how the CLI is used. We’ll continue to provide releases via GitHub and npm, and host each release on our CDN, static.snyk.io. In the future, if we make breaking changes to the Snyk CLI, we’ll announce and declare them explicitly (for example, following semantic versioning).

Meanwhile, we hope you continue to enjoy using the Snyk CLI to secure your development workflows. Read more about the Snyk CLI in our docs. For any questions or assistance, please get in touch.