{“lastseen”:”2025-10-10T16:53:54″,”description”:”Lack of memory safety is such a predominant cause of security issues that we have a responsibility as professional software engineering to robustly mitigate it in security-sensitive use cases\u2014by using memory safe languages.\\n\\nSimilarly, I have the growing impression that software supply chain compromises have a few predominant causes which we might have a responsibility as a professional open source maintainers to robustly mitigate.\\n\\nTo test this impression and figure out any such mitigations, I collected all 2024\/2025 open source supply chain compromises I could find, and categorized their root cause. (If you find more, do email me!)\\n\\nSince I am interested in mitigations we can apply as maintainers of depended-upon projects to avoid compromises, I am ignoring: intentionally malicious packages (e.g. typosquatting), issues in package managers (e.g. internal name shadowing), open source infrastructure abuse (e.g. using package registries for post-compromise exfiltration), and isolated app compromises (i.e. not software that is depended upon).\\n\\nAlso, I am specifically interested in how an attacker got their first unauthorized access, not in what they did with it. Annoyingly, there is usually a lot more written about the latter than the former.\\n\\n## 2024\/2025 Open Source Supply Chain Compromises\\n\\nIn no particular order, but kind of grouped.\\n\\nXZ Utils \\nLong term pressure campaign on the maintainer to hand over access. \\n**Root cause** : control handoff. \\nContributing factor: non-reproducible release artifacts.\\n\\nNx S1ingularity \\nShell injection in GitHub Action with `pull_request_target` trigger and unnecessary read\/write permissions4, used to extract a npm token. \\n**Root cause** : pull_request_target. \\nContributing factors: read\/write CI permissions, long-lived credential exfiltration, post-install scripts.\\n\\nShai-Hulud \\nWorm behavior by using compromised npm tokens to publish packages with malicious post-install scripts, and compromised GitHub tokens to publish malicious GitHub Actions workflows. \\n**Root cause** : long-lived credential exfiltration. \\nContributing factor: post-install scripts.\\n\\nnpm debug\/chalk\/color \\nMaintainer phished with an \\”Update 2FA Now\\” email. Had TOTP 2FA enabled. \\n**Root cause** : phishing.\\n\\npolyfill.io \\nAttacker purchased CDN domain name and GitHub organization. \\n**Root cause** : control handoff.\\n\\nMavenGate \\nExpired domains and changed GitHub usernames resurrected to take control of connected packages. \\n**Root causes** : domain resurrection, username resurrection.\\n\\nreviewdog and tj-actions\/changed-files \\nContributors deliberately granted automatic write access for GitHub Action repository5. Malicious tag re-published to compromise GitHub PAT of more popular GitHub Action6. \\n**Root cause** : control handoff. \\nContributing factors: read\/write CI permissions, long-lived credential exfiltration, mutable GitHub Actions tags.\\n\\nUltralytics \\nShell injection in GitHub Action with `pull_request_target` trigger (which required read\/write permissions), pivoted to publishing pipeline via GitHub Actions cache poisoning. Compromised again later using an exfiltrated PyPI token. \\n**Root cause** : pull_request_target. \\nContributing factors: GitHub Actions cache poisoning, long-lived credential exfiltration.\\n\\nKong Ingress Controller \\nGitHub Action with `pull_request_target` trigger restricted to trusted users but bypassed via Dependabot impersonation7, previously patched but still available on old branch. GitHub PAT exfiltrated and used. \\n**Root causes** : pull_request_target, Dependabot impersonation. \\nContributing factors: per-branch CI configuration, long-lived credential exfiltration.\\n\\nRspack \\nPwn request1 against `issue_comment` workflow2 in other project, leading to a GitHub classic token of a maintainer with permissions to the web-infra-dev organization8 (kindly confirmed via email by the Rspack Team). Similar to previously reported and fixed vulnerability3 in the Rspack repository. \\n**Root causes** : issue_comment. \\nContributing factor: long-lived credential exfiltration.\\n\\neslint-config-prettier \\n\\”Verify your account\\”9 npm phishing. \\n**Root cause** : phishing.\\n\\nnum2words \\n\\”Email verification\\” PyPI phishing. \\n**Root cause** : phishing.\\n\\n@solana\/web3.js \\nA \\”phishing attack on the credentials for publishing npm packages.\\” \\n**Root cause** : phishing.\\n\\nrustfoundation.dev \\nFake compromise remediation10 Crates.io phishing. Unclear if successful. \\n**Root cause** : phishing.\\n\\nReact Native ARIA \\u0026 gluestack-ui \\n\\”[U]nauthorized access to publishing credentials.\\” Colorful and long Incident Report lacks any details on \\”sophisticated\\” entry point. Presumably an exposed npm token. \\n**Root cause** : long-lived credential exfiltration(?).\\n\\nlottie-player \\nUnclear, but mitigation involved \\”remov[ing] all access and associated tokens\/services accounts of the impacted developer.\\” \\n**Root cause** : long-lived credential exfiltration(?) or control handoff(?).\\n\\nrand-user-agent \\nUnclear. Malicious npm versions published, affected company seems to have deleted the project. Presumably npm token compromise. \\n**Root cause** : long-lived credential exfiltration(?).\\n\\nDogWifTool \\nGitHub token extracted from distributed binary. \\n**Root cause** : long-lived credential exfiltration.\\n\\n## Summary of vectors and mitigations\\n\\n### Phishing (5 root)\\n\\nSurprising no one, the most popular confirmed initial compromise vector is phishing. It works against technical open source maintainers. It works against 2FA TOTP. It. Works. It is also very fixable.\\n\\nIt\u2019s 2025 and every professional open source maintainer should be using phishing-resistant authentication (passkeys or WebAuthn 2FA) on all developer accounts, and accounts upstream of them.\\n\\nUpstream accounts include email, password manager, passkey sync (e.g. Apple iCloud), web\/DNS hosting, and domain registrar.\\n\\nSome services, such as GitHub, require a phishable 2FA method along with phishing-resistant ones. In that case, the best option is to enable TOTP, and delete the secret or write it down somewhere safe and never ever use it\u2014effectively disabling it. This does _not_ work with SMS, since SIM jacking is possible even without action by the victim.\\n\\n### Control handoff (3+1? root)\\n\\nActually surprisingly\u2014to me\u2014a number of compromises are due to, effectively, giving access to the attacker.\\n\\nThis is a nuanced people issue. The solution is obviously \u201cdon\u2019t do that\u201d but that really reduces to the decades-old issue of open source maintenance sustainability. In a sense, since this analysis is aimed at professional maintainers who can afford it, control handoff is easily avoided by not doing it. \\n\\n### pull_request_target and issue_comment (4 root)\\n\\nKind of incredible that a specific feature has a top 3 spot, but projects get compromised by \u201cpwn requests\u201d all the time.\\n\\nThe `pull_request_target` workflow trigger runs privileged CI with a context full of attacker-controlled data in response to pull requests. It makes a meek attempt to be safer by not checking out the attacker\u2019s code, instead checking out the upstream target. That\u2019s empirically not enough, with shell injection attacks causing multiple severe compromises. \\n\\nThe zizmor static analyzer can help detect injection vulnerabilities, but it seems clear that `pull_request_target` is unsafe at any speed, and should just never be used.\\n\\nOther triggers that run privileged with attacker-controlled context should be avoided for the same reason. The Rspack compromise, for example, was due to checking out attacker-controlled code on an `issue_comment` trigger if the PR receives a comment.\\n \\n \\n on:\\n issue_comment:\\n types: [created]\\n jobs:\\n issue_comment:\\n if: github.event.issue.pull_request \\u0026\\u0026 contains(github.event.comment.body, ‘!canary’)\\n runs-on: ubuntu-latest\\n steps:\\n – uses: actions\/checkout@v3\\n with:\\n ref: refs\/pull\/${{ github.event.issue.number }}\/head\\n \\n\\nWhat are the alternatives?\\n\\n * One option is to implement an external service in a language that can safely deal with untrusted inputs (i.e. not YAML\u2019d shell), and use webhooks. That unfortunately requires long-lived credentials (see below).\\n * GitHub itself recommends using the unprivileged `pull_request` trigger followed by the `workflow_run` trigger, but it\u2019s unclear to me how safer that would actually be against injection attacks.\\n * Finally, since two out of three compromises were due to shell injection, it might be safer to use a proper programming language, like JavaScript with actions\/github-script, or any other language accessing the context via environment variables instead of YAML interpolation. This means not using any third-party actions, as well.\\n * Allowlisting actors and read-only steps are not robust mitigations, see _Read\/write CI permissions_ and _Dependabot impersonation_ below.\\n\\n\\n\\nOverall, none of the mitigations are particularly satisfactory, so the solution might be simply to eschew features that require `pull_request_target` and other privileged attacker-controlled triggers. (To be honest, I am not a fan of chatty bots on issues and PRs, so I never needed them.)\\n\\n### Long-lived credential exfiltration (2+3? root, 5 contributing)\\n\\nAttackers love to steal tokens. There is no universal solution, but it\u2019s so predominant that we can consider piecemeal solutions.\\n\\nLong-lived credentials are only a root cause when they are accidentally exposed. Otherwise, they are a secondary compromise mechanism for lateral movement or persistence, after the attacker got privileged code execution. Mitigating the latter is somewhat less appealing because an attacker with code execution can find more creative ways to carry out an attack, but we can prune some low-hanging fruit.\\n\\nGo removes the need for package registry tokens by simply not having accounts. (Instead, the go command fetches modules directly from VCS, with caching by the Go Modules Proxy and universality and immutability guaranteed by the Go Checksum Database.) In other ecosystems Trusted Publishing replaces long-lived private tokens with short-lived OIDC tokens, although there is no way to down-scope the capabilities of an OIDC token.\\n\\nGitHub Personal Access Tokens are harder to avoid for anything that\u2019s not supported by GitHub Actions permissions. Chainguard has a third-party Security Token Service that trades OIDC tokens for short-lived tokens, and their article has a good list of cases in which PATs end up otherwise necessary. Given the risk, it might be worth giving up on non-critical features that would require powerful tokens.\\n\\nGerrit \u201cgit cookies\u201d (which are actually just OAuth refresh tokens for the Gerrit app) can be replaced with\u2026 well, OAuth refresh tokens but kept in memory instead of disk, using git-credential-oauth. They can also be stored a little more safely in the platform keychain by treating them as an HTTP password, although that\u2019s not well documented.\\n\\nIn the long term, it would be great to see the equivalent of Device Bound Session Credentials for developer and automated workflows.\\n\\n### Dependabot impersonation (1 root)\\n\\nTurns out you can just exfiltrate a token from a GitHub Actions runner to impersonate Dependabot with arbitrary PRs???\\n\\nI guess! Fine! Just don\u2019t allowlist Dependabot. Not sure what a deeper meta-mitigation that didn\u2019t require knowing this factoid would have been.\\n\\n### Domain and username resurrection (1 root)\\n\\nMultiple ecosystems (Go and Maven, for example) are vulnerable to name takeovers, whether expired domain names or changed GitHub user\/org names. The new owner of the name gets to publish updates for that package.\\n\\nFrom the point of view of the maintainer, the mitigation is just not to change GitHub names (at least without registering the old one), and to register critical domains for a long period, with expiration alerting.\\n\\n### Read\/write CI permissions (0 root, 2 contributing)\\n\\nSome CI compromises happened in contexts that could or should have been read-only. It _sounds_ like giving GitHub Actions workflows only read permissions like `contents: read` should be a robust mitigation for any compromise of the code they run.\\n\\nUnfortunately, and kind of incredibly, even a read-only workflow is handed a token that can write to the cross-workflow cache for any key. This cache is then used implicitly by a number of official actions, allowing cross-workflow escalation by **GitHub Actions cache poisoning**.\\n\\nThis contradicts some of GitHub\u2019s own recommendations, and makes the existence of a setting to make GitHub Actions read-only by default more misleading than useful.\\n\\nThe behavior does not extend to regular `pull_request` triggers, which are actually read-only (otherwise anyone could poison caches with a PR). GitHub simply doesn\u2019t seem to offer a way to opt in to it.\\n\\nI can see no robust mitigation in the GitHub ecosystem. I would love to be wrong, this is maddening.\\n\\n### Post-install scripts (0 root, 2 contributing)\\n\\nTwo compromises propagated by injecting npm post-install scripts, to obtain code execution as soon as a dependency was installed.\\n\\nThis can be disabled with\\n \\n \\n npm config set ignore-scripts true\\n \\n\\nwhich is worth doing for defense in depth. However, it\u2019s only useful if the dependency is not going to be executed in a privileged context, e.g. to run tests in Node.js.\\n\\nGo, unlike most ecosystems, considers code execution during fetch _or compilation_ to be a security vulnerability, so has this safety margin by default.\\n\\n### Non-reproducible release artifacts (0 root, 1 contributing)\\n\\nThe XZ backdoor was hidden in a release artifact that didn\u2019t match the repository source. It would be great if that was more detectable, in the form of reproducible artifacts.\\n\\nThe road to a fail-closed world where systems automatically detect non-reproducing artifacts is still long, though.\\n\\n### Mutable GitHub Actions tags (0 root, 1 contributing)\\n\\nHow supply chain attacks usually work these days is that an attacker gets the ability to publish new versions for a package, publishes a malicious version, and waits for dependents to update (maybe with the help of Dependabot) or install the latest version ex novo.\\n\\nNot with GitHub Actions! The recommended and most common way to refer to a GitHub Action is by its major version, which is resolved to a git tag that is _expected to change arbitrarily_ when new versions are published. This means that an attacker can instantly compromise every dependent workflow.\\n\\nThis was an unforced error already in 2019, when GitHub Actions launched while Go had already shipped an immutable package system. This has been discussed many times since and most other ecosystems have improved somewhat. A roadmap item for immutable Actions has been silent since 2022. The new immutable releases feature doesn\u2019t apply to non-release tags, and the GitHub docs still recommend changing tags for Actions.\\n\\nAs maintainers, we can opt in to pinning where it\u2019s somehow still not the default. For GitHub Actions, that means using unreadable commit hashes, which can be somewhat ameliorated with tooling. For npm, it means using `npm ci` instead of `npm install`.\\n\\n### Per-branch CI configuration (0 root, 1 contributing)\\n\\nOne compromise was due to a vulnerability that was already fixed, but had persisted on an old branch. Any time we make a security improvement (including patching a vulnerable Action) on a GitHub Actions workflow, we need to remember to cherry-pick it to all branches, including stale ones.\\n\\nCan\u2019t think of a good mitigation, just yet another sharp edge of GitHub Actions you need to be aware of, I suppose.\\n\\n## Summary\\n\\nThere are a number of useful mitigations, but the ones that appear to be as clearly a professional responsibility as memory safety are\\n\\n 1. phishing-resistant authentication;\\n 2. not handing over access to attackers; and\\n 3. avoiding privileged attacker-controlled GitHub Actions triggers (e.g. `pull_request_target`).\\n\\n\\n\\nThis research was part of an effort to compile a Geomys Standard of Care that amongst other things mitigates the most common security risks to the projects we are entrusted with. We will publish and implement it soon, to keep up to date follow me on Bluesky at @filippo.abyssdomain.expert or on Mastodon at @filippo@abyssdomain.expert.\\n\\n## The Picture\\n\\nOn Saturday, between 250,000 and 1,000,000 people (depending on who you believe, 0.4\u20131.7% of the whole population of Italy) took part in a demonstration against the genocide unfolding in Gaza. Anyway, here’s a picture of the Archbasilica of San Giovanni in Laterano at the end of the march.\\n\\n\\n\\nMy work is made possible by Geomys, an organization of professional Go maintainer, which is funded by Smallstep, Ava Labs, Teleport, Tailscale, and Sentry. Through our retainer contracts they ensure the sustainability and reliability of our open source maintenance work and get a direct line to my expertise and that of the other Geomys maintainers. (Learn more in the Geomys announcement.)\\n\\nHere are a few words from some of them!\\n\\nTeleport \u2014 For the past five years, attacks and compromises have been shifting from traditional malware and security breaches to identifying and compromising valid user accounts and credentials with social engineering, credential theft, or phishing. Teleport Identity is designed to eliminate weak access patterns through access monitoring, minimize attack surface with access requests, and purge unused permissions via mandatory access reviews.\\n\\nAva Labs \u2014 We at Ava Labs, maintainer of AvalancheGo (the most widely used client for interacting with the Avalanche Network), believe the sustainable maintenance and development of open source cryptographic protocols is critical to the broad adoption of blockchain technology. We are proud to support this necessary and impactful work through our ongoing sponsorship of Filippo and his team.\\n\\n* * *\\n\\n 1. https:\/\/github.com\/module-federation\/core\/pull\/3324 \u21a9\\n\\n 2. https:\/\/github.com\/module-federation\/core\/tree\/c3aff14a4b9de2588122ec24cf456dc1fdd742f0\/.github\/workflows \u21a9\\n\\n 3. https:\/\/www.praetorian.com\/blog\/compromising-bytedances-rspack-github-actions-vulnerabilities\/ \u21a9\\n\\n 4. https:\/\/github.com\/nrwl\/nx\/security\/advisories\/GHSA-cxm3-wv7p-598c#:~:text=20%20AM%20EDT-,Attack%20Vector,-Vulnerable%20Workflow \u21a9\\n\\n 5. https:\/\/github.com\/reviewdog\/reviewdog\/issues\/2079 \u21a9\\n\\n 6. https:\/\/github.com\/tj-actions\/changed-files\/issues\/2464#issuecomment-2727020537 \u21a9\\n\\n 7. https:\/\/www.synacktiv.com\/publications\/github-actions-exploitation-dependabot \u21a9\\n\\n 8. https:\/\/github.com\/web-infra-dev\/rspack\/issues\/8767#issuecomment-2563345582 \u21a9\\n\\n 9. https:\/\/github.com\/prettier\/eslint-config-prettier\/issues\/339#issuecomment-3090304490 \u21a9\\n\\n 10. https:\/\/github.com\/rust-lang\/crates.io\/discussions\/11889#discussion-8886064 \u21a9”,”published”:”2025-10-10T14:33:11″,”modified”:”2025-10-10T14:33:11″,”type”:”filippoio”,”title”:”A Retrospective Survey of 2024\/2025 Open Source Supply Chain Compromises”,”source”:””,”references”:””,”id”:”FILIPPOIO:12633262B361F59CF582F3010928BD7A”,”bulletinFamily”:”blog”,”cwe”:null,”cvelist”:[],”sourceData”:””,”sourceHref”:””,”cvss”:{“score”:0,”severity”:”NONE”,”vector”:”NONE”,”version”:”NONE”},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:”https:\/\/words.filippo.io\/compromise-survey\/”,”category_name”:”News”,”post_link”:””,”product”:””,”version”:””,”vendor”:””,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:”2025-10-10T16:53:54″,”description”:”Lack of memory safety is such a predominant cause of security issues that we have a responsibility as professional software engineering to robustly mitigate it…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[6,8,12,162,13,33,7,11,5],"class_list":["post-21056","post","type-post","status-publish","format-standard","hentry","category-category_news","tag-cve","tag-cvss","tag-exploit","tag-filippoio","tag-news","tag-none","tag-security","tag-tapic","tag-vulnerability"],"yoast_head":"\n