Developer empowerment for software security with Snyk IDE plugins

This post was written by Snyk Ambassador, Soumen Mukherjee. Snyk Ambassadors are passionate about sharing their security expertise. Become one today by signing up!

For application security, the shift left strategy is something that every enterprise is embracing today, which essentially means putting the security controls in earlier stages of development.

This is more like a “nipping the problem in the bud” strategy where the security controls in their respective domains highlight the potential security weaknesses related to vulnerabilities in code, vulnerabilities in third-party packages and code quality issues. Today, there are a plethora of tools which enforce these controls, using their respective algorithms and engines, and put together a nice dashboard of sorts to provide transparency and visibility for the technical team members, as well as managers to take further decisions on corrective actions. But most tools can only solve some of the problems, not all. However what stands out today in the industry is Snyk. Snyk is definitely my preferred tool for shifting left, as it does it all in a nice, elegant, and seamless manner.

It is generally also a well-known fact that, economically, it is much cheaper to address issues in the early stages. The sooner the problem is fixed, the cheaper the cost. Well that being said, the industry is still struggling to follow this motto practically. Even today, with the variety of tools that are used and are integrated with the various build pipelines, we are still not far enough left to lower the cost of fix. Additionally,  we are mostly reactive, and not nearly proactive enough. Indeed, what these tools lack today is the ability to empower the developers to take proactive rather than reactive steps. For example, integrating with the build pipelines is somewhat of a shift left approach, but there are better ways to really be integrated in development workflows (rather than ops workflows) and much earlier.

DevSecOps vs. SecDevOps: Which shifts further?

As of today, while the world is moving towards DevSecOps, there is also a growing urge to transition towards SecDevOps.

In my opinion, when we are talking about a security-first mindset, the developers form an integral part of the chain, and for things to shift truly left, the dev teams need to have access to all the pieces of security controls that, as of today, are being built into the pipeline. However, in practical situations, the security controls (SAST, SCA, code quality) are reactive, in the sense that by the time the developers knows what is wrong, they have already done the following.

• Implemented a significant portion of the code / stubs by making use of the third-party packages.

• Committed code to a feature branch with significant effort spent already on writing unit test and functional test.

• In some less mature scenarios/setups, already merged the code into the integration branch.

So, any red flag around vulnerability, or code quality, or code level vulnerability at this stage triggers a reactive response and by far becomes an expensive operation.

Now what is the way out? As I said earlier, nipping the problem in the bud.

Shift into the IDE!

That is where the Snyk IDE plugins come to the rescue. Snyk provides a whole bunch of IDE plugins / extensions for open source and for SAST which in the regular course of work notifies the developer about all the possible red flags around third-party vulnerabilities, code quality issues and vulnerabilities in the code that is being written.

This really shifts the entire mindset from being run in a CI and on weekends and being reactive, to giving you alerts and advice on insecure code that you write, while you write it, in the IDE, in a proactive way. I think that is a master class example of what “shift left" is really about.

Snyk IDE plugins truly empower developers to visualize the three outlined areas while they  work and empowers them to be proactive rather than reactive.

The benefits of Snyk IDE plugins

First, they provide a nicely curated list of open source security issues, each ordered respectively by their severity. Clicking on any of them also opens up the full set of details from the vulnerability database:

Coming next to code security, this flags the potential vulnerabilities that exist in the written code:

For those who are still in love with code quality, the third part of the IDE plugin outputs the code quality issues in the project:

Empower your team with Snyk

So, my recommendation is to shift extreme left and empower the developers with all that they need to help them identify, remediate, and validate the vulnerability fixes in the code before they commit anything to any branch. The Snyk IDE plugins do exactly all of this, and when you combine this with the true potential of Snyk as a platform you are looking at a master stroke strategy towards application security.

More info about the supported IDEs from Snyk can be found on Snyk’s plugin page, and you can use them right from your free Snyk account.