Building Open Source Security Into The TeamCity Workflow With Snyk
This guest blog post is brought to you by Snyk.
As part of the effort to “shift-left”, the DevOps movement has mainly focused on controls or gating mechanisms within the pipeline. Normally defined by platform/architecture leadership but used by developers, these gates can make sure that whatever doesn’t measure up to policy doesn’t get shipped. Security is not an exception to that, as security teams attempt to ensure that critical vulnerabilities don’t get through to the infrastructure.
This focus on gates in the DevOps pipeline is efficient in a narrow sense for operators, but not so much in the bigger context of software development and delivery. Its binary nature doesn’t lend itself to insights about what was wrong, how to fix it, how to automate that fix, or how to prioritize between tasks.
In contrast, Snyk’s approach is to catch vulnerabilities in open source dependencies even earlier: at the IDE stage (as we’ve shown recently with our IntelliJ IDEA integration) and, even more powerfully, by using tight integration with Git (where users can fix vulnerabilities with a simple pull request, and monitor for any new commit).
Using a tool like Snyk allows a development team to make the most of the capability at the development stage—in this case, the capability is to find and fix vulnerabilities with detailed and actionable insights (or choose to ignore vulnerabilities of a certain level; users appreciate the choice). Once that happens, it is absolutely fine for the DevOps gates further down the pipe to be binary, as they are in this case a secondary control mechanism; they come into play after developers have already gained visibility into the issues and already fixed those that they deemed most critical.
Integrating With TeamCity
At Snyk, we have been embedding open source vulnerability scanning inside many third-party products and applications through available APIs. As we grow our language support and our user base, integrating with tools like TeamCity becomes an important enabler.
Here’s how it works: after putting my Snyk token into TeamCity, my build makes sure that it is in line with my Snyk org’s rules. In the example below, I have failed the build due to an app that is vulnerable beyond what my policy allows.
At this stage, I can know more before I go back into Snyk and start fixing vulnerabilities, as shown in the metadata below, which is embedded into the TeamCity UI.
With simple integration into Snyk, I have not only gated the build to keep safe from vulnerabilities, but I have also opened a door for myself to go back and use these insights for catching and fixing issues much earlier.
In our next post, we will go through the process of building this TeamCity plugin and share what we’ve learned along the way.
Read the next post: Building the Snyk Plugin for TeamCity.