Incorporating Snyk into Continuous Integration with Azure Yaml Pipelines

Automate all the things! The same goes for security checks in our application. Continuous Security is the automation of these checks as part of the continuous delivery pipeline. The type of check determines where the check can, or should, go. Static testing (SaST), for example, should happen outside of, but be triggered by, CI. Dynamic Testing (DaST) happens outside of, but triggered by, deployment.
Another scan we can, and should, perform is a security analysis of packages we’re pulling into our applications. This can happen during CI, and the build or pull request can be rejected if packages with known vulnerabilities are used.
There are several tools emerging in this space, one of which is Snyk.io. These tools compare your imported packages and versions to those listed in various CVE databases to determine if a package has a known vulnerability, and, if applicable, report the version you should upgrade to in order to patch the vulnerability.
Some tools, like Snyk or even Github themselves, will continuously monitor your repository, so if a CVE is later issued for a package you are using, you can be alerted.
Snyk also has a CLI tool that allows you to perform a scan immediately against your project. The scan is fast, since it is simply searching the databases for packages listed in your dependencies, so build time is a good place for it. This can prevent a vulnerability from getting deployed to any environments.
Let’s look at how.

Creating a CLI Token for Snyk

The first thing you need is an API token for your Snyk account. To do this, log in to your Snyk account, and go to Account Settings.

Setting up the Pipeline

I'm using Azure Pipelines here, but the same can be accomplished with any CI tool such as Travis, Jenkins, or Circle CI.
The first step is to install the Snyk CLI onto the build agent. The CLI is a NodeJS module, so we can simply use the NPM task to install it.
Then, we can use a script task to authenticate to Snyk, run the test, and setup the project to be continuously monitored. The CLI will return a non-success error code if any packages have known vulnerabilities.
name: $(Date:yyyy.MM.dd).$(Rev:r)
variables:
  SNYK_TOKEN: 
jobs:
- job:
  steps:
  - task: Npm@1
    displayName: 'Install Snyk.io'
    inputs:
      command: custom
      verbose: false
      customCommand: 'install -g snyk'

  - script: |
      snyk auth $(SNYK_TOKEN)
      snyk test
    displayName: 'Scan dependencies for vulnerabilities with Snyk'

  - script: |
      snyk monitor
    displayName: 'Setup dependency vulnerability monitoring with Snyk'


  - task: DotNetCoreCLI@2
    inputs:
      command: build
      arguments: -p:Version=$(Build.BuildNumber)
Conclusion
Security vulnerabilities in our application’s dependencies are a real threat. Snyk’s co-founder Guy Podjarny has a great presentation he did at QCon where he uses a known vulnerabiliy in a popular NodeJS module to obtain a remote SSH session into an AWS Lambda and take control of the underlying container. Scanning for these vulnerabilities is fast, easy, and cheap. There is no excuse to not be scanning for them.
This is only one piece if the puzzle but a great compliment to your static and dynamic code scans.

Comments

Post a Comment

Popular posts from this blog

Adding New Microsoft Extensions to Legacy WCF and ASMX Web Services

I was asked by several people recently: Can I use dependency injection with my legacy WCF and ASMX web services? Microsoft has some new stuff they released with core–specifically, a new configuration system, caching, and logging providers. Can I use them in my legacy WCF and ASMX web services? The answer to both is yes you can! In fact, I recommend it! To illustrate this, we’ll take a look at taking a sample application that has a WCF service and a ASMX service and we’ll: Add dependency injection using Ninject. Add the new Configuration provider from the new  Microsoft.Extensions.Configuration  packages. Add caching functionality using Microsoft’s new  Microsoft.Extensions.Caching  packages. Use the new logging providers from  Microsoft.Extensions.Logging  packages. Dependency Injection We use Ninject, but you can just as easily use AutoFac or SimpleInjector as they also have packaged integrations for WCF. You can use other containers, but may need to hand-roll your
Read more

Using NHibernate in Asp.Net Core

Starting with version 5.1, NHibernate now supports .Net Core and .Netstandard as well as the full framework. Let’s take a quick look at how to set it up in an ASP.Net Core 2.x/3.x application. Configuration As of this writing, NHibernate doesn’t support the configuration system within Asp.Net Core based on Microsoft.Extensions.Configuration. The good news is, you don’t have to use a  hibernate.cfg.xml  file or the   section in app.config. You can add the properies manually, and pull the values from Asp.Net Core’s configuration, taking advantage of all the goodies that come with it. This opens up a world of configuration deployment possibilities. var config = new Configuration (); IDictionary < string , string > properties = new Dictionary < string , string > { { "connection.connection_string" , Configuration . GetConnectionString ( "Default" ) }, { "dialect" , "NHibernate.Dialect.SQLiteDialect" },
Read more

Code Coverage for Multiple Projects in a Single Build using Dotnet Test and Coverlet

Most of the time, your solution will have more than one project and a test unit project for each of those. Azure DevOps only, as of this writing, only allows you to update a single code coverage summary. If you upload more than one, each overwrites the next and only the last one remains. To accomplish this, we can use the merge functionality in Coverlet . I use the MSBuild extension, because it is better suited for CI pipelines. In your test project XML, add the package... <PackageReference Include="coverlet.msbuild" Version="2.7.0">     <PrivateAssets>all</PrivateAssets>     <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets> </PackageReference> Then, in your dotnet test command or msbuild command, tell it to use Coverlet and to merge results. If you're using Azure DevOps, your test task looks this... (line wrapped for read ability in the article) - task: DotNetCoreCLI@2 displayName: Test i
Read more