Issue 932: Prevent Dependabot version updates from running on HHS:main

[jtwillis92]

Summary of Changes

Updates the Dependabot configuration to only check dependencies and issue fixes against the branch raft-tdp-main. As a result, since the HHS:main repo does not have this branch this will prevent Dependabot PRs from being opened upstream.

Additionally, the labels configuration was added to set the labels for PRs opened by Dependabot to dependencies, frontend or backend and raft review to match the labels used on other PRs.

Closes #932

How to Test

As with the previous Dependabot PR this change relates to built in functionality of GitHub so our only option to test before merge is to validate the config file by pasting it here

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:
  • Dependabot version update PRs do not get opened against HHS:main

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 no code changes

Deliverable 3: Properly Styled Code

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

Acceptable Quality Level: 0 linting errors and 0 warnings

N/A no code changes

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 no changes to deployed sites

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

N/A no code changes

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?

[jorgegonzalez]

LGTM

[ADPennington]

@jtwillis92 could you add an ADR to this PR? Template below, please feel free to edit, as needed.

---

16. Migrating to Github Native Dependabot for TDP Dependency Management

Date: 2021-05-14 (yyyy-mm-dd)

Status

Pending

Context

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.

Proposed Decision

Rather than setting up Snyk on a new organization and in order to get ahead on the impending Dependabot migration, We propose an update which provides the necessary YAML config to enable the new GitHub Native version of Dependabot.

Consequences

To maintain our gitflow:

• We need 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 security-related PRs to both repos. This can be disabled in the security analysis settings as shown below:
  
• We also need to specify a target_branch in the dependabot configuration file to prevent automated version-related PR updates from opening in the HHS repo.

Pros

• Mitigate the need to manage unnecessary file for dependency management
• Mitigate the need to manage multiple dependency management tools
• Dependency management no longer contingent upon project user accounts.

Cons

• None that we are aware of at this time.

Notes

Time estimate for development: n/a. #917 and #932 were created to support this migration and PR #944 complete this migration.

[jtwillis92]

@jtwillis92 could you add an ADR to this PR? Template below, please feel free to edit, as needed.

Completed! Thank you for providing the template 🙌

[ADPennington]

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:
  • Dependabot version update PRs do not get opened against HHS:main
    confirmed security-related PRs do not open in hhs repo. to validate version-related PRs don't open upon merge to hhs:main
    As Product Owner, @lfrohlich will decide if ACs are met.

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.

n/a

Deliverable 3: Properly Styled Code

n/a

Deliverable 4: Accessible

n/a

Deliverable 5: Deployed

n/a

• Was the code successfully deployed via automated CircleCI process to development on Cloud.gov?

Deliverable 6: Documented

no code changes but ADR 016 includes full documentation trail for this change.

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?
  none detected