Integrate Renovate into the SSF as part of the pre-build step

[GuyBarGil]

Current Behavior

Currently there is no automated dependency update mechanism in the SSF. Without automated dependency updates the pipeline and the application use unmanaged, outdated dependencies which exposes it to ever-increasing technical debt and risk over time. In addition, this results in missing out on new features and bug fixes, lower agility for handling unexpected issues (including zero-day vulnerabilities), and an increased risk of being exposed to publicly known vulnerabilities.

Expected Behavior

We want to implement an automatic dependency update mechanism into the SSF to ensure that pipelines and applications are effortlessly kept up-to-date with the latest functionality and minimal exposure to vulnerabilities

Possible Solution or Alternative

We want to integrate Renovate as a step in one of our example pipelines to automatically include secure steps in the build.

Context

Renovate is part of the OpenSSF. It works out of the box and leverages a mix of crowdsourced data and your test suite to smartly detect when a dependency (or group of) can be updated without human intervention, and when a quick review is recommended to ensure the update is smooth. Also, Renovate can be easily and seamlessly into any workflow with its CLI tool which has an extremely high level of configurability.

Here is an example of a dependency update PR that Renovate automatically opens:

[mlieberman85]

This looks really good. I think there are a few questions to answer here in the short and long term.

• Can folks use Renovate to also verify that a particular new release was signed by trusted keys and/or has valid attestations? It's ok if the answer is "no" today but would be useful in the future. For example integrate with sigstore.
• What access should Renovate have in the pipeline? I've used renovate before to create PRs, but how should Renovate's credentials or secrets be secured?
• Does it make sense to have Renovate as part of the pipeline itself or as part of a separate step?

I haven't used Renovate a ton, but I think there are a few separate options we have in including it as either a step in SSF or as a component in SSF

[lmilbaum]

I am still new to this project and to Renovate. Please take this into consideration when reading my following feedback.

Establishing an automated dependencies update is a good idea when the project has a solid CI which can validate that the update is not breaking anything.

[GuyBarGil]

Thanks, my answers to your questions below:

• Can folks use Renovate to also verify that a particular new release was signed by trusted keys and/or has valid attestations? It's ok if the answer is "no" today but would be useful in the future. For example integrate with sigstore.

At the moment Renovate doesn't look into this.

• What access should Renovate have in the pipeline? I've used renovate before to create PRs, but how should Renovate's credentials or secrets be secured?

Renovate typically runs in a one-to-many fashion (i.e. it's not common to set it up once in every repo's pipeline, but rather once centrally for an org / group of orgs). Renovate only needs permissions to create branches and PRs. The credentials or secrets can be configured in the pipeline using environment variables.

• Does it make sense to have Renovate as part of the pipeline itself or as part of a separate step?

Renovate is easier to set up and maintain in one central location rather than per repo, and it runs independently of whether a commit was made. With that in mind I think it makes more sense to run Renovate as a separate step rather than as part of the pipeline itself, although it can also potentially be run within the pipeline itself.

Importantly, Renovate's execution should not be linked to commits in a repository alone. Even if a repo has no commits for a month, Renovate should still be executing regularly to notify when newer versions of dependencies are available.

[GuyBarGil]

Establishing an automated dependencies update is a good idea when the project has a solid CI which can validate that the update is not breaking anything.

I agree with your statement, and each project needs to evaluate their risk independently. Inadequate tests is one form of risk (including for security) because it doesn't allow projects to fix problems nimbly. On the other hand, having outdated dependencies is an additional risk because they tend to have more vulnerabilities and reduce your agility for fixing urgent problems.

[mlieberman85]

I think it would be valuable to have Renovate through SSF generate attestations that a project's dependencies have gone through appropriate updates.