Hash-pin action usages, minimize CI/CD permissions

[woodruffw]

Hello! This addresses some findings from zizmor 🙂

TL;DR is that I've hash-pinned all actions to make them more hermetic (making it harder for an attacker who compromises an action to push code directly to you via a mutable tag or branch). I've also added a Dependabot config that'll keep actions up-to-date, with a cooldown period that'll ensure that any action changes have at least a week to bake/receive security scrutiny before they're proposed for your inclusion. Separately, I've made the permissions on your CI/CD as minimal as possible and removed a very minor source of on-disk credential persistence via actions/checkout.

With these changes, the only remaining default zizmor finding is this:

warning[secrets-outside-env]: secrets referenced without a dedicated environment
--> ./.github/workflows/build.yml:82:20
|
18 | build:
| ----- this job
...
82 | token: ${{ secrets.CODECOV_ORG_TOKEN }}
| ^^^^^^^^^^^^^^^^^^^^^^^^^ secret is accessed outside of a dedicated environment
|
= note: audit confidence → High
3 findings (2 suppressed): 0 informational, 0 low, 1 medium, 0 high

...which is pretty minor, but could be resolved by a maintainer by moving that credential into a dedicated deployment environment.

Separately, I have not included a CI integration for zizmor in this PR. But if you're interested in one LMK and I'd be happy to do a follow up PR for it!

[zooba]

Thanks. We'll see how dependabot goes, I find it mostly annoying in every scenario and so it tends to manage about 5 notifications before I shut it down. Is there a way to make sure it's constrained to only complain about important stuff (such as pipelines) and not (e.g.) test data?

[woodruffw]

I find it mostly annoying in every scenario and so it tends to manage about 5 notifications before I shut it down

Same 😅 -- what I've done here is configure Dependabot to hopefully be a bit less noisy than the defaults: the current config will only run update checks once a week, and will batch all updates into a single PR. I've also only enabled the github-actions updater, so Dependabot shouldn't nag you with Python dep bumps or anything else.

(It's very easy to further ratchet that down as well, e.g. to only do updates every month or even every quarter. Whatever works for you, I'm happy to amend to!)

[zooba]

Batching all updates is finally here ❤️

Let's do it. I'm in the middle of pinning other build-time dependencies, but I wouldn't have got these, so the PR is well timed.

[woodruffw]

Hello! This addresses some findings from zizmor 🙂

TL;DR is that I've hash-pinned all actions to make them more hermetic (making it harder for an attacker who compromises an action to push code directly to you via a mutable tag or branch). I've also added a Dependabot config that'll keep actions up-to-date, with a cooldown period that'll ensure that any action changes have at least a week to bake/receive security scrutiny before they're proposed for your inclusion. Separately, I've made the permissions on your CI/CD as minimal as possible and removed a very minor source of on-disk credential persistence via actions/checkout.

With these changes, the only remaining default zizmor finding is this:

warning[secrets-outside-env]: secrets referenced without a dedicated environment
--> ./.github/workflows/build.yml:82:20
|
18 | build:
| ----- this job
...
82 | token: ${{ secrets.CODECOV_ORG_TOKEN }}
| ^^^^^^^^^^^^^^^^^^^^^^^^^ secret is accessed outside of a dedicated environment
|
= note: audit confidence → High
3 findings (2 suppressed): 0 informational, 0 low, 1 medium, 0 high

...which is pretty minor, but could be resolved by a maintainer by moving that credential into a dedicated deployment environment.

Separately, I have not included a CI integration for zizmor in this PR. But if you're interested in one LMK and I'd be happy to do a follow up PR for it!

[zooba]

Thanks. We'll see how dependabot goes, I find it mostly annoying in every scenario and so it tends to manage about 5 notifications before I shut it down. Is there a way to make sure it's constrained to only complain about important stuff (such as pipelines) and not (e.g.) test data?

[woodruffw]

I find it mostly annoying in every scenario and so it tends to manage about 5 notifications before I shut it down

Same 😅 -- what I've done here is configure Dependabot to hopefully be a bit less noisy than the defaults: the current config will only run update checks once a week, and will batch all updates into a single PR. I've also only enabled the github-actions updater, so Dependabot shouldn't nag you with Python dep bumps or anything else.

(It's very easy to further ratchet that down as well, e.g. to only do updates every month or even every quarter. Whatever works for you, I'm happy to amend to!)

[zooba]

Batching all updates is finally here ❤️

Let's do it. I'm in the middle of pinning other build-time dependencies, but I wouldn't have got these, so the PR is well timed.

[woodruffw]

Hello! This addresses some findings from zizmor 🙂

TL;DR is that I've hash-pinned all actions to make them more hermetic (making it harder for an attacker who compromises an action to push code directly to you via a mutable tag or branch). I've also added a Dependabot config that'll keep actions up-to-date, with a cooldown period that'll ensure that any action changes have at least a week to bake/receive security scrutiny before they're proposed for your inclusion. Separately, I've made the permissions on your CI/CD as minimal as possible and removed a very minor source of on-disk credential persistence via actions/checkout.

With these changes, the only remaining default zizmor finding is this:

warning[secrets-outside-env]: secrets referenced without a dedicated environment
--> ./.github/workflows/build.yml:82:20
|
18 | build:
| ----- this job
...
82 | token: ${{ secrets.CODECOV_ORG_TOKEN }}
| ^^^^^^^^^^^^^^^^^^^^^^^^^ secret is accessed outside of a dedicated environment
|
= note: audit confidence → High
3 findings (2 suppressed): 0 informational, 0 low, 1 medium, 0 high

...which is pretty minor, but could be resolved by a maintainer by moving that credential into a dedicated deployment environment.

Separately, I have not included a CI integration for zizmor in this PR. But if you're interested in one LMK and I'd be happy to do a follow up PR for it!

[zooba]

Thanks. We'll see how dependabot goes, I find it mostly annoying in every scenario and so it tends to manage about 5 notifications before I shut it down. Is there a way to make sure it's constrained to only complain about important stuff (such as pipelines) and not (e.g.) test data?

[woodruffw]

I find it mostly annoying in every scenario and so it tends to manage about 5 notifications before I shut it down

Same 😅 -- what I've done here is configure Dependabot to hopefully be a bit less noisy than the defaults: the current config will only run update checks once a week, and will batch all updates into a single PR. I've also only enabled the github-actions updater, so Dependabot shouldn't nag you with Python dep bumps or anything else.

(It's very easy to further ratchet that down as well, e.g. to only do updates every month or even every quarter. Whatever works for you, I'm happy to amend to!)

[zooba]

Batching all updates is finally here ❤️

Let's do it. I'm in the middle of pinning other build-time dependencies, but I wouldn't have got these, so the PR is well timed.

[woodruffw]

Hello! This addresses some findings from zizmor 🙂

TL;DR is that I've hash-pinned all actions to make them more hermetic (making it harder for an attacker who compromises an action to push code directly to you via a mutable tag or branch). I've also added a Dependabot config that'll keep actions up-to-date, with a cooldown period that'll ensure that any action changes have at least a week to bake/receive security scrutiny before they're proposed for your inclusion. Separately, I've made the permissions on your CI/CD as minimal as possible and removed a very minor source of on-disk credential persistence via actions/checkout.

With these changes, the only remaining default zizmor finding is this:

warning[secrets-outside-env]: secrets referenced without a dedicated environment
--> ./.github/workflows/build.yml:82:20
|
18 | build:
| ----- this job
...
82 | token: ${{ secrets.CODECOV_ORG_TOKEN }}
| ^^^^^^^^^^^^^^^^^^^^^^^^^ secret is accessed outside of a dedicated environment
|
= note: audit confidence → High
3 findings (2 suppressed): 0 informational, 0 low, 1 medium, 0 high

...which is pretty minor, but could be resolved by a maintainer by moving that credential into a dedicated deployment environment.

Separately, I have not included a CI integration for zizmor in this PR. But if you're interested in one LMK and I'd be happy to do a follow up PR for it!

[zooba]

Thanks. We'll see how dependabot goes, I find it mostly annoying in every scenario and so it tends to manage about 5 notifications before I shut it down. Is there a way to make sure it's constrained to only complain about important stuff (such as pipelines) and not (e.g.) test data?

[woodruffw]

I find it mostly annoying in every scenario and so it tends to manage about 5 notifications before I shut it down

Same 😅 -- what I've done here is configure Dependabot to hopefully be a bit less noisy than the defaults: the current config will only run update checks once a week, and will batch all updates into a single PR. I've also only enabled the github-actions updater, so Dependabot shouldn't nag you with Python dep bumps or anything else.

(It's very easy to further ratchet that down as well, e.g. to only do updates every month or even every quarter. Whatever works for you, I'm happy to amend to!)

[zooba]

Batching all updates is finally here ❤️

Let's do it. I'm in the middle of pinning other build-time dependencies, but I wouldn't have got these, so the PR is well timed.

[woodruffw]

Hello! This addresses some findings from zizmor 🙂

TL;DR is that I've hash-pinned all actions to make them more hermetic (making it harder for an attacker who compromises an action to push code directly to you via a mutable tag or branch). I've also added a Dependabot config that'll keep actions up-to-date, with a cooldown period that'll ensure that any action changes have at least a week to bake/receive security scrutiny before they're proposed for your inclusion. Separately, I've made the permissions on your CI/CD as minimal as possible and removed a very minor source of on-disk credential persistence via actions/checkout.

With these changes, the only remaining default zizmor finding is this:

warning[secrets-outside-env]: secrets referenced without a dedicated environment
--> ./.github/workflows/build.yml:82:20
|
18 | build:
| ----- this job
...
82 | token: ${{ secrets.CODECOV_ORG_TOKEN }}
| ^^^^^^^^^^^^^^^^^^^^^^^^^ secret is accessed outside of a dedicated environment
|
= note: audit confidence → High
3 findings (2 suppressed): 0 informational, 0 low, 1 medium, 0 high

...which is pretty minor, but could be resolved by a maintainer by moving that credential into a dedicated deployment environment.

Separately, I have not included a CI integration for zizmor in this PR. But if you're interested in one LMK and I'd be happy to do a follow up PR for it!

[zooba]

Thanks. We'll see how dependabot goes, I find it mostly annoying in every scenario and so it tends to manage about 5 notifications before I shut it down. Is there a way to make sure it's constrained to only complain about important stuff (such as pipelines) and not (e.g.) test data?

[woodruffw]

I find it mostly annoying in every scenario and so it tends to manage about 5 notifications before I shut it down

Same 😅 -- what I've done here is configure Dependabot to hopefully be a bit less noisy than the defaults: the current config will only run update checks once a week, and will batch all updates into a single PR. I've also only enabled the github-actions updater, so Dependabot shouldn't nag you with Python dep bumps or anything else.

(It's very easy to further ratchet that down as well, e.g. to only do updates every month or even every quarter. Whatever works for you, I'm happy to amend to!)

[zooba]

Batching all updates is finally here ❤️

Let's do it. I'm in the middle of pinning other build-time dependencies, but I wouldn't have got these, so the PR is well timed.

[woodruffw]

Hello! This addresses some findings from zizmor 🙂

TL;DR is that I've hash-pinned all actions to make them more hermetic (making it harder for an attacker who compromises an action to push code directly to you via a mutable tag or branch). I've also added a Dependabot config that'll keep actions up-to-date, with a cooldown period that'll ensure that any action changes have at least a week to bake/receive security scrutiny before they're proposed for your inclusion. Separately, I've made the permissions on your CI/CD as minimal as possible and removed a very minor source of on-disk credential persistence via actions/checkout.

With these changes, the only remaining default zizmor finding is this:

warning[secrets-outside-env]: secrets referenced without a dedicated environment
--> ./.github/workflows/build.yml:82:20
|
18 | build:
| ----- this job
...
82 | token: ${{ secrets.CODECOV_ORG_TOKEN }}
| ^^^^^^^^^^^^^^^^^^^^^^^^^ secret is accessed outside of a dedicated environment
|
= note: audit confidence → High
3 findings (2 suppressed): 0 informational, 0 low, 1 medium, 0 high

...which is pretty minor, but could be resolved by a maintainer by moving that credential into a dedicated deployment environment.

Separately, I have not included a CI integration for zizmor in this PR. But if you're interested in one LMK and I'd be happy to do a follow up PR for it!

[zooba]

Thanks. We'll see how dependabot goes, I find it mostly annoying in every scenario and so it tends to manage about 5 notifications before I shut it down. Is there a way to make sure it's constrained to only complain about important stuff (such as pipelines) and not (e.g.) test data?

[woodruffw]

I find it mostly annoying in every scenario and so it tends to manage about 5 notifications before I shut it down

Same 😅 -- what I've done here is configure Dependabot to hopefully be a bit less noisy than the defaults: the current config will only run update checks once a week, and will batch all updates into a single PR. I've also only enabled the github-actions updater, so Dependabot shouldn't nag you with Python dep bumps or anything else.

(It's very easy to further ratchet that down as well, e.g. to only do updates every month or even every quarter. Whatever works for you, I'm happy to amend to!)

[zooba]

Batching all updates is finally here ❤️

Let's do it. I'm in the middle of pinning other build-time dependencies, but I wouldn't have got these, so the PR is well timed.

[woodruffw]

Hello! This addresses some findings from zizmor 🙂

TL;DR is that I've hash-pinned all actions to make them more hermetic (making it harder for an attacker who compromises an action to push code directly to you via a mutable tag or branch). I've also added a Dependabot config that'll keep actions up-to-date, with a cooldown period that'll ensure that any action changes have at least a week to bake/receive security scrutiny before they're proposed for your inclusion. Separately, I've made the permissions on your CI/CD as minimal as possible and removed a very minor source of on-disk credential persistence via actions/checkout.

With these changes, the only remaining default zizmor finding is this:

warning[secrets-outside-env]: secrets referenced without a dedicated environment
--> ./.github/workflows/build.yml:82:20
|
18 | build:
| ----- this job
...
82 | token: ${{ secrets.CODECOV_ORG_TOKEN }}
| ^^^^^^^^^^^^^^^^^^^^^^^^^ secret is accessed outside of a dedicated environment
|
= note: audit confidence → High
3 findings (2 suppressed): 0 informational, 0 low, 1 medium, 0 high

...which is pretty minor, but could be resolved by a maintainer by moving that credential into a dedicated deployment environment.

Separately, I have not included a CI integration for zizmor in this PR. But if you're interested in one LMK and I'd be happy to do a follow up PR for it!

[zooba]

Thanks. We'll see how dependabot goes, I find it mostly annoying in every scenario and so it tends to manage about 5 notifications before I shut it down. Is there a way to make sure it's constrained to only complain about important stuff (such as pipelines) and not (e.g.) test data?

[woodruffw]

I find it mostly annoying in every scenario and so it tends to manage about 5 notifications before I shut it down

Same 😅 -- what I've done here is configure Dependabot to hopefully be a bit less noisy than the defaults: the current config will only run update checks once a week, and will batch all updates into a single PR. I've also only enabled the github-actions updater, so Dependabot shouldn't nag you with Python dep bumps or anything else.

(It's very easy to further ratchet that down as well, e.g. to only do updates every month or even every quarter. Whatever works for you, I'm happy to amend to!)

[zooba]

Batching all updates is finally here ❤️

Let's do it. I'm in the middle of pinning other build-time dependencies, but I wouldn't have got these, so the PR is well timed.

[woodruffw]

Hello! This addresses some findings from zizmor 🙂

TL;DR is that I've hash-pinned all actions to make them more hermetic (making it harder for an attacker who compromises an action to push code directly to you via a mutable tag or branch). I've also added a Dependabot config that'll keep actions up-to-date, with a cooldown period that'll ensure that any action changes have at least a week to bake/receive security scrutiny before they're proposed for your inclusion. Separately, I've made the permissions on your CI/CD as minimal as possible and removed a very minor source of on-disk credential persistence via actions/checkout.

With these changes, the only remaining default zizmor finding is this:

warning[secrets-outside-env]: secrets referenced without a dedicated environment
--> ./.github/workflows/build.yml:82:20
|
18 | build:
| ----- this job
...
82 | token: ${{ secrets.CODECOV_ORG_TOKEN }}
| ^^^^^^^^^^^^^^^^^^^^^^^^^ secret is accessed outside of a dedicated environment
|
= note: audit confidence → High
3 findings (2 suppressed): 0 informational, 0 low, 1 medium, 0 high

...which is pretty minor, but could be resolved by a maintainer by moving that credential into a dedicated deployment environment.

Separately, I have not included a CI integration for zizmor in this PR. But if you're interested in one LMK and I'd be happy to do a follow up PR for it!

[zooba]

Thanks. We'll see how dependabot goes, I find it mostly annoying in every scenario and so it tends to manage about 5 notifications before I shut it down. Is there a way to make sure it's constrained to only complain about important stuff (such as pipelines) and not (e.g.) test data?

[woodruffw]

I find it mostly annoying in every scenario and so it tends to manage about 5 notifications before I shut it down

Same 😅 -- what I've done here is configure Dependabot to hopefully be a bit less noisy than the defaults: the current config will only run update checks once a week, and will batch all updates into a single PR. I've also only enabled the github-actions updater, so Dependabot shouldn't nag you with Python dep bumps or anything else.

(It's very easy to further ratchet that down as well, e.g. to only do updates every month or even every quarter. Whatever works for you, I'm happy to amend to!)

[zooba]

Batching all updates is finally here ❤️

Let's do it. I'm in the middle of pinning other build-time dependencies, but I wouldn't have got these, so the PR is well timed.