
Third Party NPM-Pakete sind ein wesentlicher Bestandteil der modernen Webentwicklung. Ob große Frameworks wie React, Angular oder Next.js oder Utility-Bibliotheken
wie Lodash und Axios - sie alle helfen Entwicklern, schneller und effizienter zu arbeiten. Doch die Verwendung von Drittanbieter-Paketen bringt auch Sicherheitsrisiken mit sich
wie einige prominente Beispiele in der Vergangenheit gezeigt haben.

# Risiken bei der Verwendung von Third Party NPM-Paketen

Ein prominentes Beispiel ist der [Shai-Hulud](https://www.golem.de/news/shai-hulud-npm-wurm-erbeutet-rund-400-000-zugangsdaten-2512-202869.html) NPM-Wurm, der rund 400.000 Zugangsdaten erbeutet hat.
Angreifer können bösartigen Code in NPM-Pakete einschleusen, die dann von Entwicklern unwissentlich in ihre Projekte integriert werden. Dies kann dazu führen,
dass sensible Daten kompromittiert werden oder sogar ganze Unternehmen lahmgelegt werden. Ein gezielter Angriff um sensible Daten zu stehlen war der
[S1ngularity Vorfall](https://nx.dev/blog/s1ngularity-postmortem). Hier wurde ein post-install Skript in ein populäres NPM-Paket eingeschleust, welches dann bei der Installation
sensible Daten von Entwicklern an einen Angreifer sendete.

Doch nicht nur bösartiger Code stellt ein Risiko dar. Auch unabsichtliche Sicherheitslücken in Drittanbieter-Paketen können ausgenutzt werden. Eine im Dezember 2025
entdeckte Schwachstelle in React Server Components [CVE-2025-55182](https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2025/2025-304569-1032.pdf?__blob=publicationFile&v=3)
auch bekannt als "React2Shell" ermöglicht es Angreifern, Code auf dem Server auszuführen. Die Schwachstelle wurde zwar schnell behoben, aber Systeme die nicht
direkt aktualisiert wurden, bleiben anfällig. AWS hat berichtet das Stunden nach der Veröffentlichung der Schwachstelle bereits [erste Angriffe von chinesischen Hackern](https://aws.amazon.com/de/blogs/security/china-nexus-cyber-threat-groups-rapidly-exploit-react2shell-vulnerability-cve-2025-55182/)
beobachtet wurden.

# Wie kann eine sichere NPM-Entwicklung gewährleistet werden?

Die große Abhängigkeit von Third Party NPM-Paketen macht es schwierig, eine sichere NPM-Entwicklung zu gewährleisten. Dennoch gibt es einige bewährte Methoden,
die jeder Entwickler befolgen sollte, um die Sicherheit seiner Projekte zu verbessern. Wenn NPM-Pakete eingesetzt werden muss man sich einerseits von Supply-Chain-Angriffen schützen,
andererseits aber auch sicherstellen, dass keine Schwachstellen durch veraltete Pakete entstehen.

## Best Practices für sichere NPM-Entwicklung

#### Post-Install Skripte deaktivieren

Eine der effektivsten Maßnahmen gegen bösartigen Code in NPM-Paketen ist das Deaktivieren von Post-Install Skripten. Diese Skripte werden automatisch ausgeführt,
wenn ein Paket installiert wird. Dies kann dazu genutzt werden, bösartigen Code auszuführen. Durch das Deaktivieren dieser Skripte kann das Risiko minimiert werden.

Es wird empfohlen, die Post-Install Skripte global zu deaktivieren, um sicherzustellen, dass alle Projekte im Team geschützt sind. Dies kann durch den folgenden Befehl erreicht werden:

```bash
$ npm config set ignore-scripts true
```

In deinem User .npmrc File sollte sich dann folgender Eintrag befinden:

```
ignore-scripts=true
```

#### Cooldown Perioden für neue Pakete einführen

Bevor ein neues NPM-Paket in einem Projekt verwendet wird, sollte es eine Cooldown Periode geben. Da sich Schadcode oft in neuen Releases versteckt, ist es sinnvoll,
eine Wartezeit von einigen Tagen oder Wochen einzuführen, bevor ein neues Paket in einem Projekt verwendet wird. In dieser Zeit kann die Community das Paket überprüfen
und eventuelle Sicherheitslücken identifizieren.

npm bietet dafür ein --before Flag an, mit dem Pakete nur installiert werden, wenn sie vor einem bestimmten Datum veröffentlicht wurden. Zum Beispiel:

```bash
$ npm install express --before=2025-11-01
```

#### npm ci verwenden

Anstatt `npm install` zu verwenden, sollte `npm ci` genutzt werden. Dieser Befehl installiert die Abhängigkeiten basierend auf der `package-lock.json` Datei.
Wenn lockfiles und package.json nicht synchron sind, schlägt der Befehl fehl. Dies stellt sicher, dass nur die getesteten und genehmigten Versionen der Pakete installiert werden.

```bash
$ npm ci
```

#### Nicht jedes Paket blind übernehmen

Alle Pakete auf einmal aktualisieren mag verlockend klingen, aber es ist wichtig, jedes Paket sorgfältig zu überprüfen, bevor es aktualisiert wird. Entwickler sollten die Release-Notes lesen,
die Community-Aktivität überprüfen und sicherstellen, dass keine neuen Sicherheitslücken eingeführt werden.

#### Monitoring und automatisierte Sicherheitsprüfungen einführen

Ein laufendes Monitoring der verwendeten NPM-Pakete ist entscheidend. Tools wie [Snyk](https://snyk.io/), [Dependabot](https://dependabot.com/) oder [npm audit](https://docs.npmjs.com/cli/v11/commands/npm-audit)
können dabei helfen, bekannte Sicherheitslücken in den verwendeten Paketen zu identifizieren und automatisch Updates vorzuschlagen.

#### Software Bill of Materials (SBOM) pflegen

Eine Software Bill of Materials (SBOM) ist eine detaillierte Liste aller Komponenten, Bibliotheken und Abhängigkeiten, die in einem Softwareprojekt verwendet werden. Dies ist übrigens
verpflichtend für viele Unternehmen die vom [Cyber Resilience Act (CRA)](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act) betroffen sind.
Die Pflege einer SBOM hilft dabei, den Überblick über alle verwendeten NPM-Pakete zu behalten und erleichtert die Identifizierung von potenziellen Sicherheitsrisiken.

#### Weniger ist mehr

Bei jeder npm Installation sollte hinterfragt werden, ob das Paket wirklich benötigt wird. Jedes zusätzliche Paket erhöht die Angriffsfläche.
Weniger Pakete bedeuten weniger potenzielle Schwachstellen. Node.js und das JavaScript-Ökosystem bieten immer mehr native Funktionen, die den Einsatz von Drittanbieter-Paketen überflüssig machen.

## Fazit

Eine sichere Softwareentwicklung mit NPM-Paketen erfordert Aufmerksamkeit und Sorgfalt. Durch die Implementierung der oben genannten Best Practices können Entwickler
das Risiko von Sicherheitslücken erheblich reduzieren. Falls du Unterstützung bei der Implementierung dieser Maßnahmen in deinem Team benötigst oder eine
Sicherheitsüberprüfung einer existierenden Codebasis wünschst, stehen wir dir gerne zur Verfügung. Kontaktiere uns einfach für eine Beratung!


Sichere NPM-Entwicklung: Best Practices für mehr Sicherheit in deinem Projekt


#### Anforderungen

Seit mehreren Jahren liegt unser Fokus bei FORTIX auf der Entwicklung von **Enterprise-Applikationen mit Angular**. Dabei stehen vor allem drei Ziele im Vordergrund: Die Anwendungen sollen über ihre gesamte Lebensdauer hinweg **skalierbar** bleiben, sich **einfach warten** und erweitern lassen und gleichzeitig einen **leichten Einstieg** für neue Teammitglieder ermöglichen – unabhängig davon, wie groß oder wie wechselhaft ein Team aufgestellt ist.

Gerade in großen Projekten verändern sich Teams im Laufe der Zeit. Rollen verändern sich, neue Mitarbeiter kommen hinzu und Anforderungen wachsen. Deshalb ist es wichtig, bereits zu Beginn des Projekts die nötige **Flexibilität im Setup** zu berücksichtigen. Eine gut strukturierte und wartungsfreundliche Architektur zahlt sich langfristig aus. Es gibt kaum etwas Ärgerlicheres als technische Altlasten, die zukünftige Weiterentwicklungen erschweren oder blockieren.

#### Das Setup

Unser bevorzugtes Setup basiert auf einem **NX Monorepo**, das mehrere Vorteile vereint. Es ermöglicht eine klare Trennung zwischen Anwendungen und Bibliotheken, sorgt für einheitliche und wiederverwendbare Standardbefehle und bietet effizientes Caching sowie schnelle Build-Prozesse. Durch diese Struktur lassen sich neue Anwendungen und Komponenten konsistent integrieren, was Wartung und Erweiterungen deutlich vereinfacht.

##### Typische Struktur

- **Component Library** – zentrale UI-Komponenten
- **Style Library** – Themes, Layout, Variablen
- **Utils Library** – generische Funktionen & Helfer
- **Signal Stores** – schlankes State-Management
- **NSwag-Generierung** – gemeinsame API-Typdefinitionen für Client & Server

##### Warum NX Monorepo?

Mit NX erreichen wir bereits die wesentlichen Projektanforderungen:

- **Trennung zwischen Apps und Libraries** - Einfachere Wartung & Fehlersuche
- **Wiederverwendbare Komponenten** - Schneller Aufbau neuer Anwendungen
- **Team-freundliche Struktur** - Leichter Einstieg für neue Teammitglieder

Neue Anwendungen können innerhalb des Monorepos **mit denselben UI-Komponenten und Tools** erstellt werden.
Das steigert Konsistenz und reduziert Aufwand.

##### Component Library

Für die Component Library setzen wir häufig auf **DevExtreme** als Basis.
Diese liefert eine große Auswahl an vorgefertigten UI-Komponenten wie Tabellen, Data Grids und Formularelementen.

Wir erstellen **eigene Wrapper-Komponenten**, um Controls gezielt zuzuschneiden.
Das spart Zeit und sorgt für **ein durchgängiges UI-Verhalten** im gesamten System.

![](/images/blog/angular-at-scale/component-library-schema.jpg 'Schema der Struktur mit Component Library')

##### Warum Signal Store?

Mit den **Angular Signal Stores** steht ein schlankes und sehr intuitives State-Management zur Verfügung.

**Vorteile:**

- Stores werden **feature-spezifisch** aufgebaut
- sehr **übersichtliche Syntax**
- weniger Boilerplate als NgRx
- Migration von NgRx **schrittweise möglich**

Der Store befindet sich **nah an der Komponente** → das verbessert Lesbarkeit und Testbarkeit.

![](/images/blog/angular-at-scale/signal-store.png 'Auszug Migration von NgRx zu Signal Stores')

##### Instruction Files

Damit Vorschläge von **GitHub Copilot** oder anderen AI-Tools den Projektstandards entsprechen, verwenden wir ein **instructions.md** im Repository.

- Projektbeschreibung & Struktur
- Coding-Guidelines
- Namenskonventionen
- Beispielcode

So wird AI-generierter Code **direkt in der gewünschten Form** erzeugt.

![](/images/blog/angular-at-scale/instructions.jpg 'Beispiel eines instruction.md Files für AI-Unterstützung')

#### Testing & Wartung

Für langfristig stabile Anwendungen setzen wir auf:

- **Unit Tests** für Kernlogik & Helper
- **E2E Tests** für kritische Userflows
- **Regelmäßige Angular Updates**, um Tech Debt gering zu halten

Eine klare Architektur erleichtert Testbarkeit automatisch.

#### Wesentliche Punkte (Zusammenfassung)

- **UI** - Basiskomponenten aus Library (DevExtreme + Wrapper)
- **Zustand** - **Signal Stores**, nach Features getrennt
- **Architektur** - Standalone Components + Library-Aufteilung
- **AI-Unterstützung** - _instructions.md_ zur Regelung von Copilot-Vorschlägen

#### Ausblick: Micro Frontends

Für sehr große Systeme oder mehrere unabhängige Teams kann der Einsatz von **Micro Frontends** sinnvoll sein. Dabei werden mehrere Frontend-Anwendungen separat entwickelt und deployt, aber in eine gemeinsame Shell eingebettet. So können Teams unabhängig arbeiten, Features releasen und gleichzeitig die Anwendungen als ein zusammenhängendes System präsentieren.

Mit **Webpack Module Federation** lassen sich diese Micro Frontends zur Laufzeit laden und dynamisch kombinieren. Dies ermöglicht nicht nur unabhängige Deployments, sondern erlaubt auch den Einsatz unterschiedlicher Technologien innerhalb desselben Projekts und schafft klare Verantwortlichkeiten pro Team.

Typische Anwendungsbeispiele sind Webshops, bei denen Checkout, Artikelverwaltung und Userverwaltung als separate Frontends implementiert werden, oder Plattformen wie Netflix, bei denen Startseite, Suche, Player und Profile voneinander entkoppelt sind und unabhängig weiterentwickelt werden können.

#### Links

- [Angular instruction example](https://angular.dev/ai/develop-with-ai/)
- [Nx Monorepo](https://nx.dev/)
- [DevExtreme Angular Components](https://js.devexpress.com/Overview/Angular/)
- [Angular Signal Stores](https://angular.dev/guide/signals)
- [Micro Frontends with Angular](https://www.angulararchitects.io/blog/micro-frontends-with-modern-angular-part-1-standalone-and-esbuild/)


Angular at Scale – Best Practices für Enterprise-Applikationen


Angular gehört seit Jahren zu den führenden Frameworks für skalierbare Webanwendungen – besonders im Enterprise-Umfeld. Die neue Version 20 setzt den Fokus nicht auf große Umbrüche, sondern auf Stabilität, moderne Standards und eine verbesserte Developer Experience.

Wir bei **FORTIX** haben uns die Neuerungen angesehen – hier unser Überblick und unsere Einschätzung.

### Was bringt Angular 20?

#### Zoneless Angular – ein großer Schritt näher

Mit Angular 20 ist zoneless change detection offiziell im Developer Preview angekommen. Die neue API `provideZonelessChangeDetection` ersetzt die bisher experimentelle Version – und zeigt: Angular macht ernst.  
Google nutzt Zoneless Angular bereits produktiv (z. B. bei Google Fonts), und erste Projekte berichten von spürbar besseren Lighthouse Scores.  
Auch in der Angular CLI ist das Thema angekommen: Beim Erstellen neuer Projekte (`ng new`) wird direkt gefragt, ob man eine zonenfreie App starten möchte.

#### Server-Side Rendering – stabiler und flexibler

Angular 20 bringt deutliche Verbesserungen im Bereich Server-Side Rendering (SSR). Zwei zentrale Features – **inkrementelle Hydration** und **Rendering-Konfiguration pro Route** – sind jetzt offiziell stabil.

Was bedeutet das in der Praxis?

- Komponenten können nachgeladen und hydratisiert werden, **wenn sie wirklich gebraucht werden**
- Entwickler:innen können flexibel steuern, **welche Seiten serverseitig, clientseitig oder vorgerendert** ausgeliefert werden

Das spart Ressourcen, verbessert die Ladezeiten und macht Angular-Anwendungen effizienter – besonders bei großen, dynamischen Webapps.

#### Developer Experience: smarter & klarer

Angular 20 bringt viele kleine, aber wirkungsvolle Verbesserungen für den Entwicklungsalltag – quer durchs gesamte Framework: Routing, Forms, HTTP, API-Design.  
Ein echtes Highlight: **Die neue Integration mit den Chrome DevTools**.  
Angular-spezifische Infos wie **Change Detection-Zyklen**, **Komponenten-Rendering** oder **Event-Handling** sind jetzt direkt im Performance-Panel sichtbar – farblich markiert und im Kontext anderer Prozesse im Browser.  
Das macht die Analyse komplexer Apps deutlich einfacher und präziser.

### Unsere Einschätzung

Angular 20 ist kein lauter Hype-Release – und genau das gefällt uns.  
Die Richtung stimmt: Angular entwickelt sich mit Bedacht weiter, bleibt dabei aber **stabil, modern und zukunftssicher**.  
Besonders spannend: die Fortschritte bei **SSR** und **Signals** – Themen, die in vielen unserer Kundenprojekte eine zentrale Rolle spielen.

## Was heißt das für unsere Kunden?

✅ Bestehende Angular-Projekte lassen sich **gezielt und sicher auf Angular 20 migrieren**  
✅ Neue Projekte setzen wir gerne direkt mit Angular 20 auf  
✅ Wir beraten, ob **SSR oder Zoneless Architecture** für dein Projekt sinnvoll sind

##### Offizielle Release-Dokumentation

- [Offizieller Angular Blog: Angular 20 Announcement](https://blog.angular.dev/announcing-angular-v20-b5c9c06cf301)

Du planst ein neues Angular-Projekt oder möchtest bestehende Anwendungen modernisieren?  
**Lass uns sprechen – wir unterstützen dich gerne.**


Angular 20 – die Jubiläumsversion im Überblick


Für die meisten Entwickler ist eine UUID einfach eine zufällige Zeichenkette, die als eindeutiger Schlüssel verwendet wird. Doch hinter einer UUID kann mehr stecken, als
nur ein paar zufällige Zeichen. Lasst uns das "Rabbit-Hole" der UUIDs erkunden und uns die verschiedenen Versionen ansehen.

# Welche UUID Versionen gibt es?

Es gibt insgesamt 8 verschiedene Versionen von UUIDs, die in der Spezifikation [RFC 9562](https://tools.ietf.org/html/rfc9562) definiert sind.
Höhere Versionen sind nicht unbedingt besser als niedrigere Versionen, sondern dienen dazu, verschiedene Anwendungsfälle zu unterstützen.

### Version 1

[UUID Version 1 (v1)](https://datatracker.ietf.org/doc/html/rfc9562#name-uuid-version-1) wird aus der MAC-Adresse des Computers und der aktuellen Zeit generiert.
Somit kann aus diesem UUID-Typ abgeleitet werden, wann und wo die UUID generiert wurde. Dies kann für einige Anwendungsfälle nützlich sein, aber auch ein Sicherheitsrisiko darstellen.

### Version 2

[UUID Version 2 (v2)](https://datatracker.ietf.org/doc/html/rfc9562#name-uuid-version-2) ist reserviert für [DCE](https://de.wikipedia.org/wiki/Distributed_Computing_Environment)-Sicherheits-UUIDs.

### Version 3

[UUID Version 3 (v3)](https://datatracker.ietf.org/doc/html/rfc9562#name-uuid-version-3) werden aus MD5-Hashes generiert. Als Basis können beliebige Werte verwendet werden.
Häufig werden damit URLs oder andere eindeutige Schlüssel in UUIDs umgewandelt.

Achtung! Verwende diese Version nicht, wenn du sensible Informationen (z.B.: Passwörter) in der UUID speichern möchtest, da MD5 als unsicher gilt.

### Version 4

[UUID Version 4 (v4)](https://datatracker.ietf.org/doc/html/rfc9562#name-uuid-version-4) sind rein zufällige UUIDs. Diese Version ist die am häufigsten verwendete Version von UUIDs.
Sie enthalten keinerlei Informationen über den Ersteller oder den Zeitpunkt der Erstellung.

Diese Version ist am besten geeignet, wenn eine zufällige ID benötigt wird. Somit sollte sie als **Standard** verwendet werden, wenn keine speziellen Anforderungen bestehen.

<div className="text-center w-full mb-6">
  <img
    className="max-h-64 m-auto"
    alt="UUIDv4 - Zufällige IDs sind am besten geeignet, wenn keine speziellen Anforderungen bestehen."
    src="/images/blog/8-verschiedene-uuids/uuids.png"
  />
</div>

### Version 5

[UUID Version 5 (v5)](https://datatracker.ietf.org/doc/html/rfc9562#name-uuid-version-5) werden aus SHA-1-Hashes generiert. Ähnlich wie bei Version 3 können beliebige Werte als Basis verwendet werden.

Achtung! Verwende diese Version nicht, wenn du sensible Informationen (z.B.: Passwörter) in der UUID speichern möchtest, da SHA-1 als unsicher gilt.

### Version 6

[UUID Version 6 (v6)](https://datatracker.ietf.org/doc/html/rfc9562#name-uuid-version-6) fast identisch mit Version 1, jedoch ist die Reihenfolge vertauscht damit die IDs leichter
nach Datum sortiert werden können.

### Version 7

[UUID Version 7 (v7)](https://datatracker.ietf.org/doc/html/rfc9562#name-uuid-version-7) kombiniert zufällige Daten (wie in Version 4) mit einem Zeitstempel. Somit wird ein
sortierbarer UUID generiert ohne sensible Informationen wie die MAC-Adresse zu enthalten.

Diese Version ist nützlich, wenn eine UUID benötigt wird, die sortierbar sein soll, z.B. für Datenbanken. Da die MAC-Adresse nicht enthalten ist, ist sie "sicherer" als Version 1.

### Version 8

[UUID Version 8 (v8)](https://datatracker.ietf.org/doc/html/rfc9562#name-uuid-version-8) eine Anwendungsspezifische UUID. In dieser Version hat der Ersteller
die Freiheit wie er die UUID generieren möchte.

# Wann sollte ich nun welche Version verwenden?

Mit 8 verschiedenen Versionen von UUIDs kann es schwer sein, die richtige Version für den jeweiligen Anwendungsfall zu finden. Es gibt jedoch einige Faustregeln, die dir helfen können.

- Meistens wird Version 4 als Standard verwendet, wenn eine zufällige UUID benötigt wird. Falls du einfach eine ID benötigst, verwende Version 4.
- Falls die ID sortierbar sein soll, verwende Version 7. Diese Version enthält einen Zeitstempel, der es ermöglicht, die UUIDs nach Datum zu sortieren.
- v5 oder v8 können verwendet werden, um eigene Daten darin zu verpacken. Diese Versionen sind jedoch weniger verbreitet und sollten nur verwendet werden, wenn du genau weißt, was du tust.

Wenn dieser Post dir geholfen hat, teile ihn mit deinen Kollegen. Falls du Fragen hast, schreibe mir gerne eine <a href="mailto:adrian.natter@fortix.io">E-Mail</a>.


Sichere NPM-Entwicklung: Best Practices für mehr Sicherheit in deinem Projekt

Angular at Scale – Best Practices für Enterprise-Applikationen

Angular 20 – die Jubiläumsversion im Überblick

UUID Versionen: Welche gibt es und wann sollte ich welche verwenden?