Add trussworks/lambda-dependabot appliance

[mdial89f]

Type of Issue:

• Enhancement: New feature or request

Issue Creator Checklist

• This issue has been thoroughly documented below; a developer should be able to understand the issue by reading it.

Background

By design, Dependabot triggered workflows do not have access to GitHub Secrets. See dependabot/dependabot-core#3253 as a solid entrypoint to read.

This has been an annoyance for some time... when Dependabot creates an automatic Security fix for a dependency, Dependabot pushes code to a branch and creates a PR. Both of these events trigger various GitHub Actions workflows that support our development process. This is great, but any workflows that require github secrets, including Deploy, fail since no secrets are provided.

Trussworks has built a solution to this problem in the form of a lambda that retries failed Dependabot jobs with a more priveleged (more than Dependabot) github access token. The source code is at https://github.com/trussworks/lambda-dependabot . This Issue is to add this lambda to the quickstart and its deployment model.

Proposed Approach

The truss lambda should plug right into the quickstart. To fit with our deployment model, it should probably be put into a serverless service. In keeping with the infrastructure related '.sechub' service, it should probably be in a 'dot' service folder. This helps identify it as a non-promotable service... it's not our product, it's support. To that end, this lambda should only be deployed once (for one stage) per product repository. This is even more restricted than the .sechub service, which deploys once (for one stage) per AWS account, of which there's usually three. The proposed pattern is not unprecedented and should be fine. However, this is the second support-type service we're putting in the application repository, and the idea of having a -support repository is looking more attractive.

Value

Deploying this re-run solution should alleviate project admins from re-running Dependabot builds. This will lead to reduced burden on devs, reduced frustration, and a product that gets security fixes a little bit faster.

AC:

• Dependabot triggered workflows that fail due to inaccessible secrets are re-run by this appliance

[mdial89f]

I dug fairly deep on this and can report back... in short, I recommend we put this on pause for a few months.

Before I got going on implementing the Truss solution, I re-read through the github issue where a lot of people in the community discuss this dependabot secrets issue. It let me to developments that have happened since this issue was created. See: https://github.blog/changelog/2021-10-06-github-actions-workflows-triggered-by-dependabot-prs-will-respect-permissions-key-in-workflows/

From the changelog at that link:

In addition to the permissions change we are working to enable workflows triggered by Dependabot to use Dependabot secrets. This change will enable you to use those secrets to pull dependencies from private repositories.

The above was also mentioned on the running github issue. So, I believe GitHub is making changes to allow Dependabot access to secrets, which should make this issue OBE.
Since this isn't it very high demand at the moment, and since we have reason to believe GitHub may make this OBE in the near future, I recommend we stop work on this and wait a bit.