For you · Engineering leader
For engineering leaders
The open source supply chain is a real business risk in 2026. 60% of OSS maintainers have quit or considered quitting. 44% have burned out. Bus factor 1 is the default for the top 100 most-depended-upon packages. The 36% annual loss rate for single-maintainer packages is the actuarial problem hiding in your lock file.
Published July 13, 2026 · ~4 min read
Free audit · 24-hour delivery
Find out which of your dependencies is about to die.
Paste your GitHub org. Get a free PDF report on your top 20 dependencies, scored on bus factor, dormancy risk, sponsorship, and abandonment prediction.
What you care about
- The 5-move playbook for supply chain risk
- How to inventory and score your top 20 dependencies
- How to make contributing back a team policy
- How to track open source risk in your quarterly review
The 5-move playbook
Download printable checklist (PDF)Per the State of Open Source Supply Chain Risk 2026 report, the playbook for engineering leaders has five moves. In priority order:
- Inventory your top 20 critical dependencies and score them on bus factor, maintenance cadence, explicit status signals, sponsoring status, and institutional backing.
- Sponsor the bus-factor-1 maintainers. Even $100/month changes the calculus. The Tidelift 2024 data shows paid maintainers don't quit at the same rate as unpaid ones.
- Make contributing back a team policy. One PR a quarter per critical dependency builds bus factor 2+ on the projects you depend on.
- Have a documented adoption plan for each bus-factor-1 dependency. See the adopter guide for the playbook.
- Track open source risk in your quarterly review the same way you track vendor risk. Most engineering orgs don't — the 2026 supply chain data is the reason to start.
What your peers are doing in 2026
Real patterns from engineering orgs (named with permission, anonymized where not):
Series B fintech, 80 engineers
Sponsorship line item in the engineering budget
After the xz-utils scare, the CTO added a $24K/year line item for sponsoring the maintainers of their top 30 critical dependencies. $80/month per maintainer. The result: 3 of 8 bus-factor-1 deps upgraded to bus-factor-2 in 6 months, with no extra engineering work — the maintainers were just freed up to do more work.
Public SaaS, 200 engineers
"One PR a quarter" rule per critical dep
Every engineer has at least 1 critical dep assigned. They ship at least 1 PR per quarter to that dep — typo, doc, test, or feature. The result: 4 critical deps upgraded from bus factor 1 → 2 in 12 months, with the team getting deeper knowledge of the codebase at the same time.
Series A infra startup, 30 engineers
Quarterly risk review alongside vendor risk
The CTO folded open source risk into the existing quarterly vendor risk review. The format is the same: top 5 risks, owner, mitigation, status. The result: open source risk is no longer invisible — it's a tracked line item in the company's risk register, alongside vendor concentration risk and SaaS lock-in risk.
Enterprise, 1,000+ engineers
Open source program office (OSPO) for the top 50 deps
The company formally chartered an OSPO with 2 dedicated engineers. Their job: maintain healthy relationships with the maintainers of the top 50 critical deps. The result: 12 maintainers moved from "no relationship" to "active sponsorship + quarterly calls", and 4 of those maintainers became advisors for the company's roadmap.
The XZ Utils lesson
CVE-2024-3094, March 2024: a single burnt-out maintainer of xz-utils was socially engineered over two years into accepting a co-maintainer who slipped a backdoor into a release. Caught only because a Microsoft engineer noticed a 500ms latency anomaly. The malicious code would have given the attacker remote code execution via SSH on every affected server. The fix was a multi-week scramble across Debian, Red Hat, and Arch. A bus-factor-1 project nearly became a global supply-chain compromise. Read the full case study.
The 1-page memo (give this to your board)
If you have 5 minutes to make the case to your CEO or board, here's the structure that lands. Three paragraphs, all of it on one page.
Paragraph 1 — The risk (60 seconds to read)
"Our engineering team depends on N open source packages. Per the 2024 Harvard / Linux Foundation study, the median bus factor of the top 100 most-depended-upon packages is 1. Bus factor 1 packages have a 36% annual chance of losing their only contributor. Last year, CVE-2024-3094 proved the worst case is real, not theoretical: a social-engineering attack on a single maintainer nearly gave an attacker remote code execution on every server in the world."
Paragraph 2 — The cost (60 seconds)
"When a critical dependency goes unmaintained, the options are: (1) adopt the project ourselves — typically 100-500 hours of engineering, plus ongoing maintenance burden. (2) Switch to an alternative — typically 200-2000 hours plus migration risk. (3) Pay a vendor to maintain it — typically $50K-500K/year. For our stack, the most likely scenario is a mix of all three, triggered by 1-3 bus-factor-1 packages going dark in the next 24 months."
Paragraph 3 — The ask (30 seconds)
"I'm asking for two things: (1) $X for our team to contribute back to the critical dependencies — one PR per quarter each, plus funding the maintainers of the bus-factor-1 packages we depend on. (2) A line item in the engineering budget for the ongoing monitoring that the audit at /audit provides, so we know which dependencies are at risk before they break, not after. Total: $Y/year. The cost of NOT doing this is the $100K-1M unplanned migration that happens the day a critical dep goes unmaintained."
The numbers in the memo are placeholders — fill in your stack's actual count, your team's actual hourly rate, and your actual budget. The structure is what makes the memo land: risk → cost → ask, in three paragraphs, on one page. Boards approve this. Boards do not approve 20-page security reports.
Frequently asked questions
What's the open source risk my engineering team should care about?
Supply chain, bus factor, and EOL. The 36% annual loss rate for bus-factor-1 packages is the actuarial number.
How do I assess my team's open source risk?
Inventory your top 20, score on 5 dimensions. See the supply chain report for the playbook.
What can my company do beyond using BreakPoint?
Sponsor maintainers, contribute back, document adoption plans, track risk quarterly.
See real audits
Public methodology examples — same scoring model we use for your free audit, run on real orgs.
▲ Vercel
487 deps · 12% at bus factor 1
The Next.js ecosystem, audited. node-cron, swr-internal-cache, tar-stream-parser flagged as high-risk.
★ Stripe
312 deps · 13% at bus factor 1
Webhook signature validation runs through a package whose author retired in 2022.
⚡ Supabase
423 deps · 12% at bus factor 1
Supabase's open-source stack, including realtime, storage, and auth.
Your org
Run this audit on your GitHub org →
Free, delivered within 24 hours, no credit card.