-
Notifications
You must be signed in to change notification settings - Fork 87
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?
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).
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.
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. We have had trouble editing the .snyk file directly, so please use the snyk CLI if possible. An example would be snyk ignore --id='SNYK-JS-ANSIREGEX-1583908' --expiry='2023-06-30' --reason='ansi-regex input is from trusted sources so a ReDoS attack is not a concern. Not able to be upgraded at this time.', and full documentation can be seen here.
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.
For scans that find vulnerabilities in terraform code, you can snooze or ignore terraform issues through the snyk UI.
When triaging issues with data.gov, 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 data.gov. 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 in use on all repositories by default, see dashboard for what is being scanned and why. If docker files and/or terraform files are added to repositories, they may need to be added manually after they are deployed...
To note items that can be safely ignored (after researching the vulnerability), you should update the .snyk file at the root of the project. You can see documentation on using the Snyk CLI to manage these exceptions here. Make sure that the file is formatted correctly (see here for example of fixing the formatting).
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.