Your source can stay untouched and the code you ship still turns malicious.
The Hacker News reports that attackers used the Ethersphere project's own release automation to publish malicious versions of two of its tools for the Swarm decentralized storage network: bee-js 13.3.0 and Swarm Desktop 0.56.2. BigGo Finance reports that Japan's Ryohin Keikaku dropped its plan to reopen the MUJI online store after a credential-stuffing attack left traces of unauthorized logins on 270,000 accounts. The Hacker News also reports that some WordPress sites can still be attacked while they install the fix for a flaw already under active exploitation, according to Picus Security researcher Umut Bayram.
What I'd take from the three together: treat the path that builds and publishes your software as production. Who can trigger a release, what the pipeline is allowed to sign with, whether your dependencies are pinned to exact versions. Those are access-control questions, not build-tooling details.
If you handle payments or wallet keys, I review build and publish paths alongside the account flows they protect, with scope and timeline back to you within a day. Send me the repo layout and who can push a release, and I'll tell you where the trust boundary is missing.