# Tanzu Bump Robot

## Summary

Tanzu Bump Robot aims to automate the menial task of project dependency bumps through detection of new dependency versions and upgrading them with automated PR creation.

Check out the [demos](#MVP-Demo-asciinema) to see it working!

## Motivation

As all maintainers know, one of the frequent tasks for open source projects, is to bump their project dependencies.
The work is almost identical across different repositories, and lends itself well to automation.

### Goals

MVP will be focussed on Go dependency bumps, with following configuration options supported:

- Only patch bump go modules of your choice for security fixes
- Only patch bump all go modules for security fixes
- Patch bump go modules of your choice
- Patch bump all go modules

### Future Work

Some of the other dependency bumps that can be supported post MVP:

* Container base image dependency bumps (e.g. debian:buster --> debian:bullseye)
* Refactor of renamed Github Repos (See [example](https://github.com/google/gnostic/issues/262#issuecomment-940138015))
* Minor version upgrades for go modules
* Adding Github Action to make these bumps at regular cadence or on demand

This is not a replacement of dependabot. But it is complementary to it because:
* You get to pick what which dependencies you want to bump
* Tanzu Bump Robot can also bump ~~any dependencies regardless of whether they are security fixes or not~~ untagged (e.g. v0.0.0-20220101-h4kzc89) dependencies
* Tanzu Bump Robot creates PRs for bumps where Dependabot PR creation fails
* Tanzu Bump Robot detects additional security fixes not detected by dependabot

## Proposal

MVP proposes a workflow automation with following steps:

1. Detect all `go.mod` files in selected repo
1. Detect and upgrade all chosen go modules
1. Commit the relevant changes
1. If only security patches are selected,
* Detect if the available patches fix any CVEs
* Fetch CVE IDs fixed
* Add CVE IDs, upgrade path and link to changes since last update to commit message
1. Add Co-author name of a human to ensure accountability for robot actions
1. Create a Pull Request to the selected repo

### MVP Demo (asciinema)

Covers all four scenarios in goals:

* [Only patch bump go modules of your choice for security fixes](https://asciinema.org/a/479765)
* [Only patch bump all go modules for security fixes](https://asciinema.org/a/479777)
* [Patch bump go modules of your choice](https://asciinema.org/a/479773)
* [Patch bump all go modules](https://asciinema.org/a/479762)

### User Stories

This is useful for maintainers, security teams to keep up to date with patches while having control on when those patches are applied

#### Story 1

As a maintainer, I want to make sure I am always running on latest patches of my dependencies, so that I get timely bug fixes as well as security fixes while allowing me to review the changes before merging through a PR approval process

#### Story 2

As a maintainer, I want to reduce my burden by automating menial tasks like keeping up to date with dependencies so that I can focus on creating business value by adding new features

#### Story 3

As a security engineer, I want to have an ability to help maintainers keep up to date with security patches so that we reduce the risk of running code with unpatched vulnerabilities

#### Story 4

As a security engineer, I want to reduce the effort needed to upgrade dependencies so that the cost of assessing impact of a vulnerability is lower than upgrading it

#### Story 5

As a security engineer, in case of a critical severity vulnerability, I need a standardized way to detect and ugprade usage of the affected dependency so that I can upgrade it if needed or be able to confidently say that we do not use it.

#### Story 6

As a customer, I want all the products I buy to be shipped with latest available patches so that I have more trust in running business critical workloads on these products

#### Story 7

As a regulator / auditor, I want to see a standardized process to bump dependencies of open source projects used in the shippable releases of a product, so that I can be assured of the steps taken to secure the software supply chain.

### Requirements<todo></todo>

Some authors may wish to use requirements in addition to user stories.
Technical requirements should derived from user stories, and provide a trace from
use case to design, implementation and test case. Requirements can be prioritised
using the MoSCoW (MUST, SHOULD, COULD, WON'T) criteria.

The FR and NFR notation is intended to be used as cross-references across a CAEP.

The difference between goals and requirements is that between an executive summary
and the body of a document. Each requirement should be in support of a goal,
but narrowly scoped in a way that is verifiable or ideally - testable.

#### Functional Requirements

Functional requirements are the properties that this design should include.

##### FR1

##### FR2

#### Non-Functional Requirements

Non-functional requirements are user expectations of the solution. Include
considerations for performance, reliability and security.

##### NFR1

##### NFR2

### Implementation Details/Notes/Constraints

* What are some important details that didn't come across above.
* What are the caveats to the implementation?
* Go in to as much detail as necessary here.
* Talk about core concepts and how they relate.

### Security Model<todo></todo>

Document the intended security model for the proposal, including implications
on the Kubernetes RBAC model. Questions you may want to answer include:

* Does this proposal implement security controls or require the need to do so?
* If so, consider describing the different roles and permissions with tables.
* Are their adequate security warnings where appropriate.
* Are regex expressions going to be used, and are their appropriate defenses
against DOS.
* Is any sensitive data being stored in a secret, and only exists for as long as necessary?

### Risks and Mitigations<todo></todo>

* What are the risks of this proposal and how do we mitigate? Think broadly.
* How will UX be reviewed and by whom?
* How will security be reviewed and by whom?
* Consider including folks that also work outside the SIG or subproject.