Type of Issue:
Issue Creator Checklist
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
Type of Issue:
Issue Creator Checklist
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: