"What Should OSS Developers Do Now? Thinking About Software Supply Chain Compromise Countermeasures" Participation Report #oss_supplychain
This page has been translated by machine translation. View original
On June 23, 2026, the event "What Should OSS Developers Do Now? Thinking About Software Supply Chain Compromise Countermeasures," hosted by GMO Flatt Security, was held at the event space provided by LayerX.
Entering 2026, a series of OSS supply chain compromises occurred one after another.
Against this backdrop, I imagine many companies have already adopted Takumi Guard, which is available starting for free, to block malicious packages before installation.
The trigger for this event was the following tweet by @yusukebe.
Security-themed events tend to stay at the level of abstract or general discussion, but every session here drilled down to concrete approaches, with content that was truly characteristic of practitioners who deal with supply chain countermeasures on a daily basis.
Supply Chain Security Initiatives in the Corporate Engineering Department (Yuya Takeyama / LayerX)
The first session was a sponsor session by Yuya Takeyama from LayerX, who also provided the venue.
Supply chain efforts differ by business unit, and this session covered the initiatives of the Corporate Engineering department to which the speaker belongs.
While the other presentations leaned toward the perspective of those who develop OSS, this session was presented from the perspective of those who use OSS.
- Separating library update methods into security-related (Dependabot) and non-security-related (Renovate) updates (Dependabot is said to be more timely)
- Version pinning, specifying GitHub Actions (pinact) and container images by hash value
- Setting cooldown periods
These and other defensive measures from the perspective of an OSS consumer were introduced.
All of these are frequently cited as best practices, but actually adopting and operating them as a matter of course is no easy feat.
In the age of AI agents, the approach of narrowing down technologies and achieving more with fewer combinations of technology is also something worth referencing.
It was also mentioned that since rolling out GitHub Enterprise company-wide would be costly, they also use Forgejo, which provides a GitHub-like development experience, in combination.
Why I Became Scared of Merging PRs, and What Comes Next (Kyohei / pdfme)
The second session was "Why I Became Scared of Merging PRs, and What Comes Next" by Kyohei (@labelmake), maintainer of pdfme, a PDF generation library.
Why I Became Scared of Merging PRs (Presentation Slides / Google Slides)
In the once-idyllic era of OSS development, PRs from users were something to be welcomed, but in recent times, OSS supply chains have become targets, making it hard to simply rejoice at receiving a PR.
The problem of AI slop has also emerged, and the ways OSS is operated in the broader sense are changing.
- Not accepting PRs (Ladybird)
- Having contributors waive their rights in order to maintain public domain status (SQLite)
- Rewriting PRs yourself (SQLite)
- Not publishing test cases (SQLite)
- Not publishing source code, but only providing a place for communication (Typora)
Kyohei believes that "many people develop OSS because they want to give back to society." The fact that TanStack published a postmortem at lightning speed when the incident occurred is itself one form of giving back by OSS developers. Kyohei, who is not a security engineer, says that his own interest in security was sparked by receiving a security report for his own OSS.
Kyohei's message is that in an era being dramatically transformed by AI, you should not cling to the past but operate OSS in whatever form suits you.
Kyohei has also re-presented this on his own YouTube channel, so please do give it a watch.
Supply Chain Compromise Countermeasures in Hono ~ Learning from Three Libraries (yusukebe / Cloudflare)
The third session was "Supply Chain Compromise Countermeasures in Hono ~ Learning from Three Libraries" by Yusuke Wada (@yusukebe), creator of Hono and Developer Advocate at Cloudflare.
While Hono, the framework developed by the speaker, has no external dependencies, it is depended upon by a vast number of libraries and services, with monthly downloads exceeding 100 million. In other words, if Hono were compromised, the damage would cascade across a wide range.
For this reason, the session was structured around introducing the countermeasures Hono has taken in its GitHub and npm operations, drawing lessons from the following three recent incidents.
- axios
- Cause: PC takeover via social engineering
- Countermeasure: Publishing via OIDC trusted publishing from GitHub Actions, etc.
- TanStack
- Cause: Cache poisoning via
pull_request_targetin GitHub Actions - Countermeasure: Not using
pull_request_target, etc. (newer versions such asactions/checkout@v7already include mitigations)
- Cause: Cache poisoning via
- Mastra
- Cause: Exploitation of dependencies via npm account takeover
- Countermeasure: Zero library dependencies. Few contributors, and only the speaker themselves as an npm contributor, making the risk of any other account being taken over essentially nonexistent
Hardening npm Publishing: Protecting the Publishing Flow from Supply Chain Compromises (azu)
The final session was "Hardening npm Publishing" by azu (@azu_re), author of jsprimer and JSer.info, who publishes approximately 90 packages per month.
Azu's session took a more technical and systematic approach than yusukebe's presentation, centered around npm, with a focus on setting appropriate boundaries and implementing countermeasures through multiple layers.
- Local environment: Rather than storing raw credentials locally, manage them with a password manager such as 1Password or Bitwarden
- GitHub authentication: While Personal Access Tokens (PATs) are used for GitHub API operations, avoid using classic PATs with overly broad permissions as much as possible, and instead issue read-only fine-grained PATs for each specific use case. Achieving the equivalent of fine-grained PATs is also possible using the GitHub App-based ghtkn, but it is not used due to the coordination required with the GitHub Organization management team (information shared at the after-party)
- npm authentication: Rather than issuing npm access tokens, use OIDC Trusted Publishing, where npm and GitHub Actions exchange tokens via OIDC
- Publishing flow: Introduce operation steps on both the GitHub side and the npm side (multi-stage), so that an attacker who compromises only one account cannot publish on their own
Session materials
In Closing
Although OSS supply chain compromise countermeasures is a rather niche theme for an event, all four sessions had their own distinctive character, with each speaker presenting concrete details of their daily practices from their respective standpoints — making for an extremely dense and valuable event.
Whether you develop OSS or use it (via AI agents), there were many topics you could take back to your day-to-day development, and the attendees were all taking notes eagerly.
Thank you to the organizers at GMO Flatt Security, to LayerX for providing the venue, and to all the speakers.
References
- What Should OSS Developers Do Now? Thinking About Software Supply Chain Compromise Countermeasures - connpass
- Supply Chain Security at LayerX Corporate Engineering - Speaker Deck
- Why I Became Scared of Merging PRs (Kyohei / Google Slides)
- Supply Chain Compromise Countermeasures in Hono ~ Learning from Three Libraries - Speaker Deck
- Hardening npm Publishing (slides)
- "Hardening npm Publishing" — A Talk I Gave - Web Scratch