Add 'npm audit signatures' to workflow.

[sanason]

This PR is related to the Trello card Implement subresource integrity for all analytics.usa.gov application components. npm audit signatures "verifies the registry signatures of downloaded packages" that "you download from the public npm registry, or any registry that supports signatures". It also verifies the "provenance attestations" of any packages that provide them.

[sanason]

If this seems reasonable, I will add it to our other npm-reliant analytics repositories.

[levinmr]

Yea, this seems fine. I'm wavering back and forth on whether deployment jobs should depend on this new job as well.

My developer side doesn't want to be in a place where we can't deploy to some environment when we need to, and the security side is telling me that we shouldn't be able to deploy if the signatures don't match.

Like currently running npm audit signatures fails for several packages

[levinmr]

@sfrederick-gsa-gov please weigh in

[levinmr]

Yea, this seems fine. I'm wavering back and forth on whether deployment jobs should depend on this new job as well.

My developer side doesn't want to be in a place where we can't deploy to some environment when we need to, and the security side is telling me that we shouldn't be able to deploy if the signatures don't match.

Like currently running npm audit signatures fails for several packages

Hmm actually running the npm audit signatures command only fails for me locally. It doesn't fail in CI. I re-ran the CI workflow for this PR and it was successful

[levinmr]

Ah I see, CI is using a more recent node version (22.10.0) than what we have configured in the repo (20.11.x). When I use the same version of node as CI, then the signatures check passes

[sanason]

Yea, this seems fine. I'm wavering back and forth on whether deployment jobs should depend on this new job as well.

My developer side doesn't want to be in a place where we can't deploy to some environment when we need to, and the security side is telling me that we shouldn't be able to deploy if the signatures don't match.

Like currently running npm audit signatures fails for several packages

Actually, it was my intention that failing audit_dependencies blocks deployment but I thought you got that for free since deploy depends on test and test depends on audit_dependencies. Is that not how GitHub workflows work?

[sanason]

Ah I see, CI is using a more recent node version (22.10.0) than what we have configured in the repo (20.11.x). When I use the same version of node as CI, then the signatures check passes

Yeah, the documentation for provenance attestations says:

Because provenance attestations are such a new feature, security features may be added to (or changed in) the attestation format over time. To ensure that you're always able to verify attestation signatures check that you're running the latest version of the npm CLI. Please note this often means updating npm beyond the version that ships with Node.js.

So, that could be an issue, though maybe more an issue with the npm version than with the node version. For example -

npm audit signatures fails with "node v20.11.1 (npm v10.2.4)" but it succeeds with "node v20.11.1 (npm v10.9.0)" which I got by running nvm use followed by nvm install-latest-npm.

[levinmr]

Ah I see, CI is using a more recent node version (22.10.0) than what we have configured in the repo (20.11.x). When I use the same version of node as CI, then the signatures check passes

Yeah, the documentation for provenance attestations says:

Because provenance attestations are such a new feature, security features may be added to (or changed in) the attestation format over time. To ensure that you're always able to verify attestation signatures check that you're running the latest version of the npm CLI. Please note this often means updating npm beyond the version that ships with Node.js.

So, that could be an issue, though maybe more an issue with the npm version than with the node version. For example -

npm audit signatures fails with "node v20.11.1 (npm v10.2.4)" but it succeeds with "node v20.11.1 (npm v10.9.0)" which I got by running nvm use followed by nvm install-latest-npm.

I updated the CI jobs for this repo to use the .nvmrc file for determining which version of node to install, and updated the node version to 22. That should eliminate the confusion between CI and local. If you could just update your new job to install node the same way, this should be good

[levinmr]

Yea, this seems fine. I'm wavering back and forth on whether deployment jobs should depend on this new job as well.
My developer side doesn't want to be in a place where we can't deploy to some environment when we need to, and the security side is telling me that we shouldn't be able to deploy if the signatures don't match.
Like currently running npm audit signatures fails for several packages

Actually, it was my intention that failing audit_dependencies blocks deployment but I thought you got that for free since deploy depends on test and test depends on audit_dependencies. Is that not how GitHub workflows work?

Yea you're right, this is just a preference thing where I like to explicitly say that all the jobs before must pass. It's not necessary to do that.

[sanason]

I updated the CI jobs for this repo to use the .nvmrc file for determining which version of node to install, and updated the node version to 22. That should eliminate the confusion between CI and local. If you could just update your new job to install node the same way, this should be good

Done.

[sanason]

Yea you're right, this is just a preference thing where I like to explicitly say that all the jobs before must pass. It's not necessary to do that.

No objections to that preference and I don't want to violate the repo's existing practices so I added dependencies to all the deploy jobs.