npm Staged Publishing und 2FA: Neue Abwehr gegen Supply-Chain-Angriffe – und warum Email-Authentifizierung das Fundament ist

npm verschärft die Sicherheit beim Package-Publishing

npm hat zwei neue Mechanismen eingeführt, die Supply-Chain-Angriffe deutlich erschweren sollen: Staged Publishing und 2FA-Gating. Wer ein Paket veröffentlicht, muss künftig einen zweistufigen Prozess durchlaufen – und an einem bestimmten Punkt einen Zwei-Faktor-Code bestätigen, bevor das Paket für alle Nutzer sichtbar wird.

Das klingt nach einer rein technischen Maßnahme auf Plattformebene. Doch dahinter steckt eine Schwachstelle, die viele Teams übersehen: Wenn die Email-Authentifizierung des npm-Kontos nicht sauber konfiguriert ist, kann 2FA seinen Schutz nicht vollständig entfalten.

Was ist Staged Publishing – und wie funktioniert das 2FA-Gating?

Beim klassischen npm-Publishing landet ein Paket sofort im öffentlichen Registry. Staged Publishing hält das Paket zunächst in einem Zwischenstatus. Erst wenn der Maintainer den Veröffentlichungsschritt aktiv bestätigt – inklusive 2FA-Code – wird es freigegeben.

Das gibt Maintainern ein kurzes Zeitfenster, um:

• unbeabsichtigte Releases zurückzuziehen,
• automatisierte Angriffe auf kompromittierte Accounts zu unterbrechen,
• und CI/CD-Pipelines mit einem menschlichen Kontrollpunkt zu versehen.

Das 2FA-Gating greift genau an der kritischsten Stelle: beim tatsächlichen Publish-Vorgang, nicht nur beim Login. Ein Angreifer, der ein npm-Passwort erbeutet, kann damit allein kein Paket mehr veröffentlichen.

Die unterschätzte Rolle von Email-Authentifizierung

Hier kommt der Punkt, den viele DevSecOps-Teams nicht auf dem Schirm haben: 2FA-Codes werden in vielen Setups per Email zugestellt. Das gilt für npm-Benachrichtigungen, Passwort-Reset-Links und Kontobestätigungen.

Wenn die Domain, von der npm diese Emails versendet, kein DMARC-Enforcement hat – oder wenn der Empfänger-Account auf einer Domain liegt, die SPF und DKIM nicht korrekt konfiguriert hat – entstehen Angriffsvektoren:

• Phishing auf 2FA-Codes: Ein Angreifer fälscht eine npm-Benachrichtigung und leitet den Entwickler auf eine gefälschte Bestätigungsseite. Ohne DMARC-Enforcement auf der Absender-Domain ist diese Email kaum von einer echten zu unterscheiden.
• Account-Takeover über Passwort-Reset: Reset-Links kommen per Email. Wer die Email-Kommunikation manipulieren kann, umgeht 2FA vollständig.
• MitM auf unsicheren Mailservern: Ohne MTA-STS und TLS-RPT kann die Email-Übertragung abgehört oder manipuliert werden, bevor der 2FA-Code beim Entwickler ankommt.

Das ist kein theoretisches Szenario. Supply-Chain-Angriffe wie der SolarWinds-Vorfall oder die Kompromittierung von ua-parser-js haben gezeigt, dass Angreifer gezielt schwache Glieder in der Kette suchen – und Email ist oft das schwächste.

Was Maintainer und Teams konkret tun sollten

Für npm-Maintainer:

Aktiviert 2FA auf eurem npm-Konto – und zwar nicht nur für den Login, sondern explizit für Publishing-Aktionen. npm erlaubt es, 2FA-Anforderungen granular zu setzen. Nutzt Staged Publishing, sobald es für euren Account verfügbar ist.

Für die Email-Seite:

Prüft die Domain, über die ihr npm-Benachrichtigungen empfangt. Ist SPF korrekt gesetzt? Ist DKIM aktiv? Steht DMARC auf p=quarantine oder p=reject? Wenn nicht, ist der 2FA-Code, der in euer Postfach kommt, potenziell angreifbar.

Dasselbe gilt für die Absender-Domain von npm selbst: Seriöse Plattformen wie npm setzen DMARC-Enforcement ein – aber ihr könnt das selbst prüfen, indem ihr einen DNS-Lookup auf _dmarc.npmjs.com macht.

Für MSPs und IT-Admins, die Entwicklerteams betreuen:

Stellt sicher, dass die Email-Domains eurer Kunden DMARC, SPF und DKIM korrekt konfiguriert haben. Ein Entwickler, dessen Firmen-Email-Domain kein DMARC-Enforcement hat, ist ein offenes Einfallstor – egal wie gut npm selbst abgesichert ist.

DMARC ist kein Dev-Tool – aber ein DevSecOps-Enabler

Es ist verlockend, DMARC als reines IT-Security-Thema abzutun, das nichts mit Software-Entwicklung zu tun hat. Staged Publishing und 2FA-Gating zeigen das Gegenteil: Moderne DevSecOps-Workflows bauen auf Email-Kommunikation auf. Deployment-Benachrichtigungen, CI/CD-Alerts, Paket-Freigaben – all das läuft über Email.

Wenn diese Emails gefälscht oder abgefangen werden können, ist der beste 2FA-Mechanismus nur so stark wie die schwächste Email-Konfiguration in der Kette.

Ein konkretes Beispiel: Ein Entwickler erhält eine gefälschte npm-Email mit dem Betreff “Action required: Confirm your package release”. Die Email sieht identisch aus wie eine echte npm-Benachrichtigung. Ohne DMARC-Enforcement auf der Absender-Domain landet sie problemlos im Posteingang. Der Entwickler klickt, gibt seinen 2FA-Code auf einer Phishing-Seite ein – und der Angreifer hat alles, was er braucht.

Mit DMARC p=reject auf der npm-Absender-Domain würde diese Email den Posteingang nie erreichen.

Fazit: Zwei Schrauben, die zusammengehören

npm Staged Publishing und 2FA-Gating sind sinnvolle, überfällige Maßnahmen. Sie schließen eine reale Lücke im Publishing-Prozess. Aber sie funktionieren nur dann zuverlässig, wenn die Email-Authentifizierung – auf Absender- und Empfänger-Seite – stimmt.

DMARC, SPF, DKIM, MTA-STS und TLS-RPT sind keine optionalen Extras. Sie sind die Grundlage, auf der 2FA-basierte Sicherheitsmechanismen überhaupt funktionieren können.

Prüft jetzt, ob eure Domain diese Grundlage bietet: Kostenloser Domain-Check auf DMARCPulse