Migrate to GitHub Native Dependabot

[jtwillis92]

Summary of Changes

Currently our Snyk configuration is configured on the carltonsmith Snyk organization which will no longer work after @carltonsmith leaves the project. Additionally, these Snyk PRs require us to manage an unnecessary requirements.txt file in addition to our Pipfile and python dependency update PRs are not complete when they get opened since they don't update anything in our actual dependencies. Example Snyk Python Dependency PR

Additionally, we currently use the Dependabot Preview app which is being deprecated in favor of a GitHub Native Dependabot which has more features and is configured via a YAML file committed to the repo.

Rather than setting up Snyk on a new organization and in order to get ahead on the impending Dependabot migration this PR proposes an update which provides the necessary YAML config to enable the new GitHub Native version of Dependabot. The new version is capable of providing both dependency version upgrades as well as security upgrades in response to vulnerabilities, which covers the functionality provided by both Snyk and Dependabot Preview.

NOTE: We may want to explicitly disable automated PR updates on the HHS repo if it is not already, otherwise once this file gets merged in we will get Dependabot PRs to both repos, which would conflict with our git flow as they would be opened on divergent branches. This can be disabled in the security analysis settings as shown below:

How to Test

Unfortunately due to the way Dependabot works we can't fully test this until it gets merged. On merge to raft-tdp-main a scan should begin immediately and the status checks should update shortly thereafter in the Dependency Graph

We can however, run the proposed YAML file against the Dependabot provided validator here as shown below:

Deliverable 1: Accepted Features

Performance Standard(s): At the beginning of each sprint, the Product Owner and development team will collaborate to define a set of user stories to be completed during the sprint. Acceptance criteria for each story will also be defined. The development team will deliver code and functionality to satisfy these user stories.

Acceptable Quality Level: Delivered code meets the acceptance criteria for each user story. Incomplete stories will be assessed and considered for inclusion in the next sprint.

• Look up the acceptance criteria in the related issue; paste ACs below in checklist format.
• Check against the criteria:
  • Project dependencies can be automatically kept up to date.
  • Security vulnerabilities in project dependencies can be automatically resolved.
  • All relevant documentation is updated to reflect this change.

As facilitator/product manager, @kniz-raft will decide if ACs are met from Raft's perspective.

Deliverable 2: Tested Code

Performance Standard(s): Code delivered under the order must have substantial test code coverage. Version-controlled HHS GitHub repository of code that comprises products that will remain in the government domain.

Acceptable Quality Level: Minimum of 90% test coverage of all code. All areas of code are meaningfully tested.

N/A changes relate only to dependency and vulnerability management

Deliverable 3: Properly Styled Code

Performance Standard(s): GSA 18F Front- End Guide

Acceptable Quality Level: 0 linting errors and 0 warnings

N/A changes relate only to dependency and vulnerability management

Deliverable 4: Accessible

Performance Standard(s): Web Content Accessibility Guidelines 2.1 AA standards

Acceptable Quality Level: 0 errors reported using an automated scanner and 0 errors reported in manual testing

N/A no UX changes

Deliverable 5: Deployed

Performance Standard(s): Code must successfully build and deploy into the staging environment.

Acceptable Quality Level: Successful build with a single command

NOTE: until we have a proper staging environment this may not be satisfiable prior to merging

N/A changes relate only to dependency and vulnerability management

Deliverable 6: Documented

Performance Standard(s): Summary of user stories completed every two weeks. All dependencies are listed and the licenses are documented. Major functionality in the software/source code is documented, including system diagram. Individual methods are documented inline in a format that permits the use of tools such as JSDoc. All non-inherited 800-53 system security controls are documented in the Open Control or OSCAL format and HHS Section 508 Product Assessment Template (PAT) are updated as appropriate.

Acceptable Quality Level: Combination of manual review and automated testing, if available

• If this PR introduces backend code, is that code documented both inline and overall?
• If this PR introduces frontend code, is that code documented both inline and overall?
• If this PR introduces dependencies, are their licenses documented?

Deliverable 7: Secure

Performance Standard(s): Open Web Application Security Project (OWASP) Application Security Verification Standard 3.0

Acceptable Quality Level: Code submitted must be free of medium- and high-level static and dynamic security vulnerabilities

• Does the OWASP Scan pass on CircleCI?
• Do manual code review and manual testing detect any security issues?

[jtwillis92]

Snyk was installing a ton of packages we didn't actually need. Dependabot can now handle all of this within Github natively without needing to affect our dev dependencies - this may help speed up local builds as an added bonus.

[jtwillis92]

This was only used for running snyk checks locally if needed.

[jtwillis92]

These ignores are all expired even if we choose to continue using Snyk on a different organization instead of accepting this PR's changes.

[jtwillis92]

Dependabot can manage Python dependencies using the Pipfile so we no longer need to maintain this file. (It's out of date anyway - note this closed vulnerability, in our Pipfile.lock version 3.3.2 of cryptography is currently in use)

[jtwillis92]

Just want to point this out - the badges aren't currently working correctly for GitHub Native Dependabot so they were not used in this PR.

[jorgegonzalez]

LGTM, dropping Snyk was long overdue in my opinion.

[ADPennington]

👍🏾 👍🏾 confirming that dependabot alerts disabled in hhs repo. given that there is a snyk upgrade ready to merge (#886) , let's hold off on the merge to test if merging this one first will detect the need for dependency upgrade.

ACs:

• Project dependencies can be automatically kept up to date.
• Security vulnerabilities in project dependencies can be automatically resolved.
• All relevant documentation is updated to reflect this change.

Code changes:

• If this PR introduces backend code, is that code documented both inline and overall?
• If this PR introduces frontend code, is that code documented both inline and overall?

Security:

• Does the OWASP Scan pass on CircleCI?
• Do manual code review and manual testing detect any security issues?