-
Notifications
You must be signed in to change notification settings - Fork 109
Dependency scanning
Snyk and Dependabot scan and review public repositories for free. Since data.gov makes all repositories public by default, this is a useful tool for us to make sure the dependencies we use have no security vulnerabilities.
When a report comes through of a security risk on a dependency, the following approach should be used to resolve the issue. As with all triage, use the white-noise rule. If the resolution would take more than 2 hours, create an issue to capture the work and keep any sensitive details in Google Drive.
- Is an update available?
- Document an alternative resolution:
- Are we affected by the vulnerability?
- Is there a patch to our code to resolve the vulnerability?
- Is there a patch to the dependency available?
- Is there some other mitigation in code or otherwise to reduce risk?
Updating the dependency is usually the simplest solution and is preferred. Any other resolution requires us to document how we're resolving the issue for compliance. Documenting the exception also hints to Snyk and Dependabot the issue is resolved.
Resolution follows our usual Service Level Agreement (SLA) of 10 days for critical issues, 30 days for high severity issues, and 90 days for moderate and lower.
Review the remediation provided by Snyk/Dependabot PR, see if easily implementable. In most cases, if automated checks are passing, then the PR can be merged.
In some cases, code changes are necessary to work with the updated dependency (like for major version bumps).
Alternative resolutions should be documented in the .snyk file. Once the triage is done, create ticket(s) if appropriate and/or update the .snyk file for the relevant repository with the updated issue and ignore notes. We should always set a short expiration as exceptions should be reviewed regularly. The expiration date should follow our SLA guidelines.
Are we affected by the vulnerability? Check the CVE or description of the vulnerability to understand the underlying issue. Is our code using the dependency in a way that we would be vulnerable? If not, we can safely ignore the vulnerability and document the exception.
Is there a code patch to resolve the vulnerability? Sometimes changing configuration or adding input validation can mitigate the vulnerability. Check the CVE for details.
Is there a patch available for the dependency? If a patch is available, we can fork the dependency so that our code is secure. Forking is not ideal and we must also include a plan to get back onto upstream. See Managing Forks for more info.
Is there some other mitigation to reduce the risk? Sometimes there are other ways to reduce or mitigate the risk without addressing the vulnerability. This could be like disabling a feature temporarily or changing a related application/system.
If there are remediation steps but the upgrade is not tenable, please note along with the answers to the questions above
When triaging issues with datagov-deploy, the default branch is not the master/production version (as in most other repositories). In order to get Snyk to recognize on the dashboard that a security issue is ignored/mitigated, the changes need to be pushed as a hotfix into master.
We review the Snyk Project Dashboard weekly to make sure no issues have been missed. Any errors should be triaged and mitigations documented/tickets created as necessary.
Note: The emails do not take .snyk files into consideration, so they might claim more un-triaged vulnerabilities than actually exist. The snyk dashboard is the correct source for vulnerabilities that need to be addressed.
The Snyk site has a number of useful configurations. We have setup both periodic scans and PR scans for various repositories. We don't scan our CKAN extensions, as the requirements/libraries utilized in those repositories are not shipped to staging or production: only the requirements in catalog-app (to be catalog.data.gov) and inventory-app.
All repositories should have the GitHub Integration as seen on the Projects page, except for datagov-deploy. This repository we were able to mark as open source via the configuration settings, and should not count against private tests.
The Infrastructure as Code scanning is still in beta and did not work to setup for datagov-infrastructure-live. Could be useful to setup in the future.
To integrate a new repository, simply login to Snyk.io and go to the Projects page. Click the Add Project button, and select GitHub. Search for the correct repository, and then create a new project. Nothing needs to be done on the GitHub side, everything is handled by Snyk.
There are some global settings in Snyk that may require overriding for specific repositories. All PR's are scanned, but only new issues specific to that PR are raised. This may not be the best for the added repository, so be sure to check inherited settings before finalizing setup.