Iran Sanctions Just Broke Your Supply Chain

In 2019, Stripe sent a single email to thousands of developers at midnight. No warning. No grace period. "Your account has been flagged for sanctions compliance review." Iranian engineers building on AWS woke up to suspended accounts, broken CI pipelines, and npm packages they couldn't publish. Not because they did anything wrong. Because of where they lived.

That was the preview. What's happening now is the full feature.

The Actual Mechanism Nobody's Explaining

When the US tightens Iran sanctions in response to weapons shipments, OFAC (Office of Foreign Assets Control) updates its SDN list. That list gets ingested — automatically, often within hours — by every major payment processor, cloud provider, and increasingly, by OSS infrastructure like GitHub, npm, and PyPI.

GitHub already geo-blocks Iranian accounts under US export control law. This isn't new. But enforcement intensity correlates directly with geopolitical temperature. More sanctions pressure means more aggressive automated flagging, more accounts reviewed, more repositories made private "pending review" with zero notice.

The code path is roughly: OFAC publishes SDN delta → compliance vendors like Comply Advantage and Refinitiv ingest it → your cloud provider's compliance API queries it → your Iranian teammate's account gets suspended at 2am their time.

What's Actually Breaking Right Now

Three concrete surfaces where this hits software engineers:

Package registries. If a maintainer of a dependency you rely on is in Iran and their npm or PyPI account gets suspended, their ability to push security patches disappears. You're now frozen on a vulnerable version with no upstream fix path. Check your package-lock.json. How many transitive deps have a single maintainer?

SaaS tooling. Datadog, PagerDuty, Linear, Vercel — all US companies, all OFAC-compliant. Iranian engineers at companies with international teams lose access. Not "limited access." Gone. Your on-call rotation just got a hole in it.

GitHub Actions / CI. Runners are AWS infrastructure. AWS is US-domiciled. If your pipeline touches resources that get flagged, builds fail silently. Not a permissions error you'd recognize. Just... nothing.

The Dependency Graph Problem Is Worse Than You Think

Run this right now:

You will find packages maintained by people in sanctioned regions. Not because anyone was being reckless. Because open source is global and that's the whole point. The OSS social contract assumes contributors can actually contribute. Sanctions break that contract at the infrastructure layer, not the human layer.

The Babel maintainer situation in 2019-2020 is a documented case study. Several contributors lost GitHub access. Patches sat unmerged. Nobody at the companies consuming Babel noticed until a CVE dropped.

What You Should Do This Week

Audit your critical path dependencies for single-maintainer risk. Not just Iranian maintainers — any single point of failure where a compliance action could orphan a package. Tools like npx better-npm-audit or Snyk's dependency graph view give you this. Fork anything critical. Mirror it internally. Treat geopolitical risk like you treat bus factor.

For your team: if you have engineers in affected regions, get their access provisioned through your company's legal entity, not personal accounts. A corporate GitHub seat under a US company's contract has different (not zero, but different) risk exposure than a personal account.

What I'd Do Differently

The OSS community needs a sanctions resilience protocol the same way we have a bus factor convention. A structured process for emergency maintainership transfer when a contributor loses access due to reasons outside their control. Not charity. Infrastructure hygiene. I'm going to propose exactly this in the OpenSSF working group next month. If you care about this, show up.