Is there anything in this that prevents anyone who wishes to deliberately plant malware in a repository from adding a --provenance flag? Granted it would be very naughty but anyone deliberately sneaking in malware is already being very naughty so a bit of extra naughtiness isn't going to worry them.
GitHub debuts pedigree check for npm packages via Actions
Developers who use GitHub Actions to build software packages for the npm registry can now add a command flag that will publish details about the code's origin. This feature is intended to further enhance the security of the open source software supply chain, which has become a common target for cyberattacks. GitHub Actions is …
COMMENTS
-
-
Thursday 20th April 2023 17:22 GMT bdehamer
It really depends on the attack vector. If our naughty actor is exploiting some leaked/compromised npm credentials (by far the most common way these attacks occur) to publish a malware-laden update, they absolutely can include the --provenance flag . . . however, the generated provenance is going to clearly show that this package was NOT generated from the original source repository. This isn't yet available in the current beta, but the registry will ultimately reject publish requests for packages if it sees that previous versions included a provenance statement but the new version either doesn't have provenance or has a provenance where the source repository is suddenly different.
An attack on the source repository itself is a whole other class of supply-chain attack that requires different defensive measures (branch protections, 2FA, etc) -- a provenance statement isn't going to do much for you here except maybe lead you back to the commit where the compromised code was initially introduced.