Introduction to Git repositories
You can use Snyk functions to secure your application code, using Snyk Code for your own code, and Snyk Open Source for the open-source libraries you use:
Snyk functions to secure application code
These functions are available at the following points in the development process:
Developers can use Snyk to check for issues while writing code locally (on their machines), before any code changes are pushed to the central Git repository.
Developers can use:
- ​Snyk CLI for local checks on the developer’s machine. Training: see Introduction to the Snyk CLI​.
- ​Snyk for IDEs plugins for checks embedded in the developer IDEs. Training: see Introduction to using Snyk in an IDE.
When developers merge their code changes into their Git repository, Snyk can:
- Run PR Checks: scan for issues when a pull request (PR) is merged. By default, PR Checks acts to ensure that the attack surface of the application never increases, only failing when a PR adds a dependency with issues.
- Run daily scans: have Snyk by default run daily scans, if you imported Snyk Projects from your repo, to find any new problems in your current libraries, for example to find critical zero-day vulnerabilities quickly. This scanning occurs for all imported Projects, whether or not your teams are currently working on them. See Walkthrough: code repository projects.
- Create Jira tickets: manage work on new issues discovered, to assign this work to developers in your team and to track progress on these issues. See the Jira integration documentation.
Snyk can also suggest fixes by creating a PR for a number of reasons: to address a vulnerability, to address older dependencies, and to help address backlogged vulnerabilities over time. See Fix your first vulnerability.
Snyk can again act as a “gate†when you are building the application, checking that the code is secure at this stage to:
- Check for issues automatically as part of the build process
- Prevent a build from being completed based on policies
You can choose to either report on issues (allowing the build to happen) or to stop the build if issues are encountered. You can also easily add criteria to this process (including exploitability, CVSS score, whether a fix exists), to focus on fixing the issues that matter to you.