Integrate Snyk into your workflow
This example shows how Snyk can integrate into your GitHub-based workflow.

Step 1: Set up environment

  1. 1.
    Open up Snyk CLI, and run a git clone command on the goof repository.
    1
    git clone https://github.com/snyk/goof.git
    Copied!
  2. 2.
    Create a new branch, add vulnerabilities on this branch, then merge changes back to GitHub as a Pull Request:
    1
    git branch add_vulns
    2
    git checkout add_vulns
    Copied!

Step 2: Add an open source dependency

Review the package.json manifest file in your cloned goof application, to see multiple direct dependencies listed:
These direct dependencies can also have additional transitive dependencies; libraries that they depend on.
To add the dependency:
  • Add the tinymce 4.1.0 library at the bottom of the dependencies list:
1
{
2
"name": "goof",
3
...
4
}
5
"dependencies" {
6
...
7
"typeorm": "^0.2.24",
8
"tinymce": "4.1.0"
9
},
10
...
Copied!
Tip: remember to place a comma after the previous dependency.
  • Create a lock file for our Node application:
    1
    npm install --package-lock
    Copied!
Tip: if this file already exists, run rm package-lock.json to remove it**.**

Step 3: Commit and review changes

  • Commit your change locally, checking the status of the change in our local git repository, then adding the change to our local git, then committing it:
1
git status
2
git add package*
3
git commit -m "adding tinymce v4.1.0"
Copied!
  • Commit your local code change to GitHub, transferring the files and history to your upstream git repository on GitHub:
1
git push --set-upstream origin add_vulns
Copied!
1
GitHub has received your changes on your **add\_vulns** branch.
Copied!
  • In GitHub, click Compare & pull request to compare the add_vulns branch with the master branch and generate a pull request:

Step 4: Snyk tests pull request checks

Snyk automatically tests your pull request for vulnerability and license checks in the merge process:
As the PR workflow completed, Snyk validated the vulnerability and license policy set for the project. Based on the policy, the checks either passed or failed; this is shown in GitHub.
This allows you to establish a security gate and prevent pull requests from adding new vulnerabilities, or new open source libraries that do not meet your license policy, to the source code baseline.
For more details on PR checks see the article on our GitHub integration.