Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: Re-enable Dependabot security updates #1071

Closed
wants to merge 9 commits into from

Conversation

ChrisBAshton
Copy link
Contributor

@ChrisBAshton ChrisBAshton commented Aug 3, 2022

GitHub automatically opts all qualifying repos in for security
updates, but this gets overwritten by the presence of a
dependabot.yml file, which we have in most repos. We’ll
therefore need to edit the Dependabot config to fix security
related PRs not being raised.

It’s not immediately clear from the docs exactly what’s needed
to opt in, but we believe our use of an allow-list may be the
issue.

We get some value from configuring Dependabot to raise fewer PRs
(i.e. only update the dependencies we care about), but we need
security updates for all dependencies, so this PR is an
attempt to arrive at a configuration that allows security PRs but that
doesn't break our existing behaviour.

See https://docs.github.com/en/code-security/dependabot/dependabot-security-updates/configuring-dependabot-security-updates#overriding-the-default-behavior-with-a-configuration-file

Trello: https://trello.com/c/nqliwwxV/2952-investigate-how-to-fix-dependabot-not-raising-security-prs

⚠️ This repo is Continuously Deployed: make sure you follow the guidance ⚠️

GitHub automatically opts all qualifying repos in for security
updates, but this gets overwritten by the presence of a
`dependabot.yml` file, which we have in most repos. We’ll
therefore need to edit the Dependabot config to fix security
related PRs not being raised.

It’s not immediately clear from the docs exactly what’s needed
to opt in, but we believe our use of an allow-list may be the
issue.

We get some value from configuring Dependabot to raise fewer PRs
(i.e. only update the dependencies we care about), but we need
security updates for _all_ dependencies, so this commit is an
attempt to write a rule that allows security PRs but won’t affect
the rest of our config.

See https://docs.github.com/en/code-security/dependabot/dependabot-security-updates/configuring-dependabot-security-updates#overriding-the-default-behavior-with-a-configuration-file

Trello: https://trello.com/c/nqliwwxV/2952-investigate-how-to-fix-dependabot-not-raising-security-prs
@ChrisBAshton
Copy link
Contributor Author

ChrisBAshton commented Aug 3, 2022

Looks like there's no way to validate this config until it's on main 😢
dependabot/dependabot-core#4605

Unless I change the repo's default branch to reenable-security-updates? That way I can avoid tarnishing the commit history of main.

I'll do that now, and change it back after trying a Dependabot run.

@ChrisBAshton
Copy link
Contributor Author

Yeah, that's not allowed...

Screenshot 2022-08-03 at 16 52 32

Error message: The property '#/updates/1' is a duplicate. Update configs must have a unique combination of 'package-ecosystem', 'directory', and 'target-branch'

ChrisBAshton and others added 5 commits August 3, 2022 16:55
We think Brakeman is only raising security PRs for direct
dependencies, so if a security vulnerability exists in a
subdependency, we're not getting PRs. This commit should fix that.
Bumps [brakeman](https://github.com/presidentbeef/brakeman) from 5.2.1 to 5.2.3.
- [Release notes](https://github.com/presidentbeef/brakeman/releases)
- [Changelog](https://github.com/presidentbeef/brakeman/blob/main/CHANGES.md)
- [Commits](presidentbeef/brakeman@v5.2.1...v5.2.3)

---
updated-dependencies:
- dependency-name: brakeman
  dependency-type: indirect
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
Bumps [gds-api-adapters](https://github.com/alphagov/gds-api-adapters) from 81.0.3 to 81.0.4.
- [Release notes](https://github.com/alphagov/gds-api-adapters/releases)
- [Changelog](https://github.com/alphagov/gds-api-adapters/blob/main/CHANGELOG.md)
- [Commits](alphagov/gds-api-adapters@v81.0.3...v81.0.4)

---
updated-dependencies:
- dependency-name: gds-api-adapters
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
This only defines whether we want to get PRs for subdependencies
of brakeman.
According to [the docs](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#target-branch),
Dependabot will ignore the configs in dependabot.yml for security
PRs, if a target-branch has been set to something other than the
default branch.

I'm hoping to accomplish two things with these changes:

1) Allow security PRs through again (even if they are for
   dependencies not on the `allow` list)
2) Have a way of distinguishing between security and non security
   related PRs (by the absence of the new `not-security` label).

Apart from the verbosity of the config, this does cause one new
issue: what to do with the `latest-dependencies` branch (we'll
definitely have to automate merging that to `main`, or at least
automate opening a PR to `main`). We'll also need to figure out
what happens if the `latest-dependencies` branch has not been
created yet.
@ChrisBAshton
Copy link
Contributor Author

Nice - so we do need to manually create the branch first.

Screenshot 2022-08-04 at 14 53 00

This was fixed in #1064.
An ActiveRecord vulnerability existed which was fixed by a patch
in Rails.

By removing it, I'm hoping Dependabot will raise a PR to patch
Rails again.
This time, however, I've also removed Rails (and related gems)
from the allow-list, which previously would have stopped the
security PR from being raised.

Now that we have the `target-branch` workaround, I'm hoping the
PR will be raised.
I will need to recreate the `latest-dependencies` branch from this
branch first, and then trigger a Dependabot scan.
@ChrisBAshton
Copy link
Contributor Author

Triggered a Dependabot scan: https://github.com/alphagov/content-data-admin/network/updates/433990960
Nothing interesting. But I guess that makes sense - we've only configured Dependabot to look at X dependencies, not including Rails anymore, so not surprised it didn't try to raise a Rails PR.

The Dependabot security PRs presumably are raised through some other process, e.g. a nightly scan. I can't see anything to trigger a security scan in https://github.com/alphagov/content-data-admin/security - maybe if we leave it overnight it will do that? Or maybe security PRs are only raised for recently declared vulnerabilities?

@ChrisBAshton
Copy link
Contributor Author

I'm afraid at this point I may have to call in our good ex colleague, @issyl0! 👋 Long time no speak! I believe you're on the Dependabot team these days...?

In RFC-126, we arrived at a Dependabot configuration that cut down the number of PRs raised, as hoped. An unexpected consequence of that is we've stopped receiving security updates for dependencies unless they're explicitly listed 😬

There was a recent CVE-2022-32224 in Active Record, which GitHub reviewed and categorised as High Severity, but Dependabot didn't open any PRs to bump it to the patched version. Running the Dependabot scanner on the email-alert-api repo, we can see:

updater | INFO <job_417588463> Starting update job for alphagov/email-alert-api
updater | INFO <job_417588463> Checking if activerecord 7.0.3 needs updating
  proxy | 2022/07/13 07:27:50 [016] GET https://rubygems.org:443/api/v1/versions/activerecord.json
  proxy | 2022/07/13 07:27:50 [016] 200 https://rubygems.org:443/api/v1/versions/activerecord.json
updater | INFO <job_417588463> Latest version is 7.0.3.1
updater | INFO <job_417588463> Dependabot cannot update to the required version as all versions were ignored for activerecord
updater | INFO <job_417588463> Finished job processing
updater | INFO Results:
updater | Dependabot encountered '1' error(s) during execution, please check the logs for more details.
updater | time="2022-07-13T07:27:50Z" level=info msg="task complete" container_id=job-417588463-updater exit_code=0 job_id=417588463 step=updater

Dependabot did eventually raise a PR bumping Rails, as that is allowed in the config. We ended up manually raising a number of PRs to bump ActiveRecord in all of our repositories.

Is there a way of enabling security-related updates for all dependencies & subdependencies, whilst still retaining the opinionated configs we have for general version updates? I was really hoping for a allow-all-security-updates: true option or something!

I've found https://docs.github.com/en/code-security/dependabot/dependabot-security-updates/configuring-dependabot-security-updates, but that's dedicated mostly to enabling security updates in the repo settings (which we've done). The open-pull-requests-limit 'hack' isn't suitable for us as it doesn't seem to allow any non-security related PRs. I did try (in this PR) seeing if I could mix and match multiple definitions for the same package manager, but that doesn't seem to be allowed.

Any suggestions would be gratefully received. 🙏 Thanks in advance!

@issyl0
Copy link
Contributor

issyl0 commented Aug 4, 2022

Hello!

I now work on the Code Scanning functionality, but luckily for you the wider Advanced Security group that I'm part of does include Dependabot and some very kind colleagues helped me out here. 🙇🏻

It would appear that your use of allow vs. ignore in dependabot.yml is causing you not to get security updates for dependencies outside of your allowlist. The docs on allow say that "allow" applies to both version and security updates, whereas the docs on ignore state that "ignore" only applies to version updates, as long as you don't additionally specify update-type for each ignored dependency because that will block security updates again. (The docs do read a bit confusingly, but I'm assured that is the behaviour and ignore does currently allow security updates through by default.)

TL;DR: You need to switch to using ignore lists of dependencies to ignore, because ignore only applies to version updates and should let all security updates through.

Thinking back to the size of the Gemfiles and the amount of lesser cared about gems and the maintenance of these lists across your repos vs. the smaller allowlist that you've got so far, I would probably suggest scripting the generation of the ignore lists, such that everything not in the list of n gems that you care about gets ignored. But you do you! ❤️

@ChrisBAshton
Copy link
Contributor Author

Thanks @issyl0! 🙌

@ChrisBAshton ChrisBAshton deleted the reenable-security-updates branch August 16, 2022 08:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants