"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 LayerX's event space.
In 2026, a series of OSS supply chain compromises occurred in quick succession.
Against this backdrop, I imagine many companies have adopted Takumi Guard, which is available starting for free, to block malicious packages before installation.
The event was sparked by the following tweet from @yusukebe.
Security-themed events tend to become abstract and general, but every session drilled down to concrete approaches, delivering content that only practitioners who deal daily with supply chain countermeasures could provide.
Supply Chain Security Initiatives at the Corporate Engineering Division (Yuya Takeyama / LayerX)
The first session was a sponsor session by Yuya Takeyama from LayerX, who provided the venue.
Supply chain initiatives differ by business division, and this session covered the efforts of the Corporate Engineering Division 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) categories (Dependabot is reportedly 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 implementing and operating them as a matter of course is no easy task.
In the age of AI agents, the approach of narrowing down technologies and achieving more with fewer technology combinations is also something worth emulating.
It was also mentioned that since deploying GitHub Enterprise company-wide would be costly, they use Forgejo, which provides a GitHub-like development experience, in parallel.
Why I Became Afraid to Merge PRs, and What Comes Next (Kyohei / pdfme)
The second session was "Why I Became Afraid to Merge PRs, and What Comes Next" by Kyohei (@labelmake), maintainer of the PDF generation library pdfme.
Why I Became Afraid to Merge PRs (Presentation Slides / Google Slides)
In the once-pastoral 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 PRs.
With the issue of AI slop, how OSS is managed in the broader sense is also changing.
- Not accepting PRs (Ladybird)
- Having contributors waive their rights in order to maintain the public domain (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 an incident occurred is itself one form of giving back by OSS developers. Kyohei, who is not a security engineer, became interested in security because he received a security report about his own OSS.
Kyohei's message is that in an era of great change driven by AI, you don't need to cling to the past — you should operate your OSS in whatever form suits you best.
Kyohei has also re-presented this session on his own YouTube channel, so please check it out.
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), the creator of Hono and a Developer Advocate at Cloudflare.
While Hono, developed by the speaker, has no external dependencies, it is depended upon by a large 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 adopted in its GitHub and npm operations, drawing from the following three recent incidents.
- axios
- Cause: PC takeover via social engineering
- Countermeasure: Publishing via GitHub Actions using OIDC trusted publishing, etc.
- TanStack
- Cause: Cache poisoning via
pull_request_targetin GitHub Actions - Countermeasure: Not using
pull_request_target, etc. (newer versions such asactions/checkout@v7have already addressed this)
- Cause: Cache poisoning via
- Mastra
- Cause: Exploitation of dependencies via npm account takeover
- Countermeasure: Zero library dependencies. Few contributors, with only the speaker as an npm contributor, meaning there is zero risk of another account being taken over
Hardening npm Publishing — Protecting the Publishing Flow from Supply Chain Compromises (azu)
The final session was "Hardening npm Publishing" by azu (@azu_re), the author of jsprimer and JSer.info, who publishes approximately 90 packages per month.
Azu's session focused primarily on npm, presenting a more technical and systematic approach than yusukebe's talk, centered on properly setting boundaries and implementing layered defenses.
- 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 classic PATs with overly broad permissions as much as possible, and instead issue read-only fine-grained PATs for each specific use case. Using GitHub App-based ghtkn can achieve the equivalent of fine-grained PATs, but it involves coordination with the GitHub Organization management team, so it is not used (information from the networking session)
- npm authentication: Rather than issuing npm access tokens, use OIDC Trusted Publishing, where npm and GitHub Actions exchange tokens via OIDC
- Publishing flow: Inserting operation steps on both the GitHub side and the npm side (multi-stage), so that an attacker who has compromised only one account cannot publish
Session materials
- I gave a presentation called "Hardening npm Publishing" - Web Scratch
- Hardening npm Publishing (Slides)
Closing
Although the event covered the somewhat niche topic of OSS supply chain compromise countermeasures, all four sessions had their own distinctive character, with each presenter concretely sharing their daily practices from their own perspective, resulting in extremely rich content.
Whether you develop OSS or use it (via AI agents), there were many topics to bring back to your daily development work, and participants were busily taking notes.
Thank you to the organizer GMO Flatt Security, venue provider LayerX, and 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 Afraid to Merge PRs (Kyohei / Google Slides)
- Supply Chain Compromise Countermeasures in Hono ~ Learning from Three Libraries - Speaker Deck
- Hardening npm Publishing (Slides)
- I gave a presentation called "Hardening npm Publishing" - Web Scratch