JavaScript ist die einzige Sprache, die überall läuft: im Browser, auf dem Server mit Node.js, in mobilen Apps mit React Native, in Cloud-Funktionen und am Netzwerkrand. Diese Allgegenwärtigkeit hat ihren Preis. Die dynamische Typisierung, die Prototypenkette und das asynchrone Ausführungsmodell von JavaScript ermöglichen es, Code zu schreiben, der unter normalen Bedingungen funktioniert, aber bei veränderten Bedingungen subtile Fehler aufweist. TypeScript ist hierbei eine wichtige Hilfe, doch Typsicherheit ist nicht gleichbedeutend mit Codequalität, Sicherheit oder einer soliden Architektur. Statische Codeanalyse schließt diese Lücke.
Die Wahl der richtigen Kombination von statischen Analysetools für ein JavaScript- oder TypeScript-Projekt ist keine einfache Entscheidung. Linting, Sicherheits-Scanning, Typüberprüfung, Erkennung von totem Code und Architekturanalyse sind unterschiedliche Probleme, die jeweils durch verschiedene Tool-Kategorien gelöst werden. Die Verwendung eines Linters, wo ein Sicherheits-Scanner benötigt wird, oder das alleinige Verlassen auf Typüberprüfung, wo Abhängigkeitsanalyse erforderlich ist, führt zu unvollständiger Abdeckung und trügerischer Sicherheit. Die Tools in diesem Leitfaden sind nach ihrer jeweiligen Funktion geordnet, sodass Teams einen Stack zusammenstellen können, der alle Qualitätsdimensionen ohne Redundanz abdeckt.
Wie SMART TS XL Unterstützt statische JavaScript-Analyse im Unternehmensmaßstab
Alle in diesem Leitfaden beschriebenen Tools arbeiten innerhalb der Grenzen von JavaScript. ESLint analysiert JavaScript-Dateien. TypeScript überprüft Typen innerhalb des TypeScript-Projekts. Semgrep durchsucht JavaScript- und TypeScript-Quellcode nach Sicherheitslücken. SonarQube erfasst Qualitätsmetriken in einer JavaScript-Codebasis. Keines dieser Tools kann jedoch über die Grenzen der JavaScript-Anwendung hinaus in die von ihr abhängigen Systeme oder die Systeme, die von ihr abhängig sind, blicken.
SMART TS XL Die statische Analyse geht den umgekehrten Weg: Sie beginnt beim Gesamtsystem und arbeitet sich bis zur Komponentenebene vor. Für JavaScript bedeutet dies, dass JavaScript- und TypeScript-Quellcode zusammen mit allen anderen Sprachen der Umgebung – COBOL, JCL, Java, Python, RPG, PL/I, SQL – eingelesen und ein einheitliches Querverweismodell erstellt wird, das die strukturellen Beziehungen zwischen all diesen Sprachen abbildet. Ein JavaScript-Modul ruft eine REST-API auf, die von einem Java-Dienst unterstützt wird. Dieser Dienst liest Daten aus einer DB2-Tabelle, die von einem COBOL-Batchprogramm befüllt wird. SMART TS XL Es werden alle vier Ebenen und die Verbindungen zwischen ihnen dargestellt. Kein JavaScript-spezifisches Tool kann diese Darstellung erzeugen.
Speziell für JavaScript-Entwicklungsteams SMART TS XL bietet mehrere Funktionen, die die Linting- und Sicherheitsprüfungsschicht ergänzen:
Sprachübergreifende Wirkungsanalyse. Bevor Sie ein JavaScript-Modul modifizieren, das eine Unternehmens-API verwendet, SMART TS XL Wirkungsanalyse Dabei werden alle anderen Systemkomponenten identifiziert, die von der Änderung betroffen sein werden, einschließlich Komponenten, die in anderen Sprachen geschrieben sind. Teams erkennen den tatsächlichen Umfang einer Änderung, bevor sie umgesetzt wird, und nicht erst, nachdem sie unerwartete Probleme im Produktivbetrieb verursacht hat.
Analyse von totem Code und Erreichbarkeit auf Systemebene. Wo Knip und ts-prune ungenutzte Exporte innerhalb des JavaScript-Projekts finden, SMART TS XL Es kann JavaScript-Funktionen und -Module identifizieren, die nirgendwo im System aufgerufen werden, einschließlich Aufrufer in Java-Diensten, Backend-APIs oder Mainframe-Programmen. Diese systemweite Analyse von totem Code ist relevant für Organisationen, in denen JavaScript-Frontends eng mit Backends in anderen Sprachen integriert sind.
Visualisierung von Abhängigkeiten über Sprachgrenzen hinweg. SMART TS XL Code-Visualisierung Erzeugt Abhängigkeitsdiagramme, die zeigen, wie JavaScript-Module mit Java-Diensten, COBOL-Programmen, gemeinsam genutzten Datenbanken und externen APIs verbunden sind, und zwar in einem einzigen navigierbaren Diagramm anstatt in separaten sprachspezifischen Ansichten.
Einheitliche Qualitätsmetriken für heterogene Stacks. Organisationen, die Kennzahlen zur Codequalität an Management- oder Compliance-Teams melden, profitieren von Kennzahlen, die den gesamten Stack abdecken, nicht nur die JavaScript-Schicht. SMART TS XL statische Code-Analyse Umfasst JavaScript und TypeScript mit den gleichen Qualitätsdimensionen, zyklomatischer Komplexität, Wartbarkeitsindex, Abhängigkeitskopplung, die in jeder Sprache der Umgebung konsistent angewendet werden.
Für Teams, die JavaScript-Anwendungen isoliert entwickeln, bieten die Open-Source- und kommerziellen Tools in diesem Leitfaden eine umfassende Abdeckung. Für Teams, die JavaScript-Anwendungen als eine Komponente in einem größeren Unternehmenssystem entwickeln, SMART TS XL bietet die architektonische Sichtbarkeitsebene, die es ermöglicht, die übrige Analyse auf Systemebene und nicht auf Dateiebene durchzuführen.
Linting vs. Statische Analyse: Worin besteht der Unterschied?
Diese Begriffe werden oft synonym verwendet, beschreiben aber unterschiedliche Analyseebenen. Die Unterscheidung ist für die Werkzeugauswahl wichtig.
Flusen Die statische Codeanalyse ist ein Teilgebiet, das sich auf stilistische Konsistenz, häufige Fehlermuster und die Einhaltung von Programmierkonventionen konzentriert. Ein Linter liest Quellcode und markiert Abweichungen von einem definierten Regelsatz. ESLint ist ein Linter. Biome ist ein Linter-Formatter. Sie erkennen Fehler. no-unused-vars, no-console und prefer-const Verstöße. Sie verfolgen weder den Datenfluss über Funktionsaufrufe hinweg noch finden sie Sicherheitslücken wie SQL-Injection.
Statische Analyse Im weiteren Sinne umfasst der Begriff „statische Analyse“ alle Funktionen eines Linters sowie tiefergehende Analysen: Kontrollflussanalyse, Datenflussanalyse (Taint-Analyse), Erstellung von Aufrufgraphen, Typanalyse und prozedurübergreifende Analyse über Dateien und Module hinweg. Tools wie CodeQL, Semgrep mit Taint-Modus und SonarQube führen statische Analysen in diesem umfassenderen Sinne durch. Sie finden Schwachstellen, die ein Verständnis dafür erfordern, wie nicht vertrauenswürdige Daten durch das Programm fließen, und nicht nur, ob eine Variable deklariert ist.
| Kategorie | Funde | Repräsentative Werkzeuge |
|---|---|---|
| Flusen | Stil, Konventionen, häufige Fehler | ESLint, Biome, OxcLint, StandardJS |
| Typprüfung | Typfehler, fehlende Typen, Typenkonflikte | TypeScript (TSC), typescript-eslint |
| SAST / Sicherheitsscanning | SQL-Injection, XSS, Prototype Pollution, unsichere Abhängigkeiten | Semgrep, CodeQL, Snyk Code, SonarQube |
| Erkennung von totem Code | Unbenutzte Exporte, nicht erreichbarer Code, ungenutzte Variablen | Knip, ts-prune, ESLint no-unused-vars |
| Architekturanalyse | Abhängigkeitsanalyse, Wirkungsanalyse, Anrufdiagramme | SMART TS XLCodeScene, Sourcetrail |
Jedes ausgereifte JavaScript-Projekt sollte mindestens die ersten drei Kategorien abdecken. Große Projekte oder Unternehmensprojekte sollten alle fünf abdecken.
ESLint: Der Industriestandard für JavaScript-Linting
ESLint ist in praktisch jedem JavaScript-Projekt installiert. Es ist der Standard-Linter in create-react-app, Next.js, Vite und den meisten Enterprise-Scaffolding-Systemen. Sein Plugin-Ökosystem deckt alle wichtigen Frameworks (React, Vue, Angular, Node.js) und Spracherweiterungen (TypeScript) ab. Ein gutes Verständnis von ESLint ist eine Grundvoraussetzung für die JavaScript-Entwicklung.
bash
# Install ESLint
npm init @eslint/config@latest
# Run on the project
npx eslint src/
# Auto-fix fixable issues
npx eslint src/ --fixESLint v9 und flache KonfigurationESLint v9 ersetzte .eslintrc.* Konfigurationsformat mit flach eslint.config.js Datei. Dies ist eine grundlegende Änderung, die viele bestehende Projekte betrifft. Das flache Konfigurationsformat ist einfacher, beseitigt das System der kaskadierenden Vererbung und macht die Konfiguration explizit:
Javascript
// eslint.config.js (ESLint v9 flat config)
import js from "@eslint/js";
import globals from "globals";
import tseslint from "typescript-eslint";
export default [
js.configs.recommended,
...tseslint.configs.recommended,
{
languageOptions: {
globals: globals.browser,
},
rules: {
"no-unused-vars": "error",
"no-console": "warn",
"prefer-const": "error",
},
},
];ESLint für TypeScript erfordert die typescript-eslint Paket, das das ältere ersetzt @typescript-eslint/eslint-plugin und @typescript-eslint/parserEs bietet über 100 TypeScript-spezifische Regeln, die TSC nicht durchsetzt:
bash
npm install --save-dev typescript-eslintESLint-Sicherheits-Plugin fügt ESLint sicherheitsorientierte Regeln hinzu und erkennt Probleme wie die Verwendung von eval()unsichere reguläre Ausdrücke und Prototyp-Injektion:
bash
npm install --save-dev eslint-plugin-securityJavascript
// eslint.config.js
import security from "eslint-plugin-security";
export default [security.configs.recommended];Was ESLint abdeckt: Programmierstil, häufige Fehler (no-undef, no-unused-vars), Anti-Patterns, Framework-Konventionen und grundlegende Sicherheitsmuster über Plugins.
Was ESLint nicht abdeckt: Datenfluss-/Taint-Analyse über Funktionsaufrufe hinweg, dateiübergreifende Auswirkungsanalyse, Abhängigkeitsschwachstellen, Architekturmapping oder asynchrone spezifische Schwachstellenmuster.
TypeScript: Statische Sicherheit auf Compilerebene
Der TypeScript-Compiler (TSC) führt die wirkungsvollste statische Analyse durch, die für JavaScript-Projekte verfügbar ist: Er beweist die Typkorrektheit im gesamten Quellcode an jeder Funktionsgrenze. strict Modus in tsconfig.json erfasst die größte Anzahl von Problemen:
JSON
{
"compilerOptions": {
"strict": true,
"noUnusedLocals": true,
"noUnusedParameters": true,
"noImplicitReturns": true,
"noFallthroughCasesInSwitch": true,
"exactOptionalPropertyTypes": true
}
}noUnusedLocals und noUnusedParameters ungenutzte Variablen und Funktionsparameter auf Compilerebene abfangen, was sich mit ESLint überschneidet. no-unused-vars aber mit mehr Präzision in Bezug auf TypeScript-spezifische Muster.
typescript-eslint Schließt die Lücke zwischen dem TypeScript-Typchecker und dem Regelsystem von ESLint. Regeln wie @typescript-eslint/no-floating-promises und @typescript-eslint/await-thenable Typinformationen verwenden, um asynchrone Programmierfehler zu erkennen, die weder TSC noch ESLint allein erfassen können:
Javascript
// eslint.config.js -- typescript-eslint with type-checked rules
import tseslint from "typescript-eslint";
export default tseslint.config(
...tseslint.configs.strictTypeChecked,
{
languageOptions: {
parserOptions: {
project: true, // enables type-aware rules
tsconfigRootDir: import.meta.dirname,
},
},
rules: {
"@typescript-eslint/no-floating-promises": "error",
"@typescript-eslint/await-thenable": "error",
"@typescript-eslint/no-misused-promises": "error",
},
}
);Diese drei Regeln befassen sich speziell mit den async/await-Fehlermustern, die in den Search Console-Daten für diesen Artikel auftreten. Falsche Promise-Behandlung ist einer der häufigsten Fehler in modernem JavaScript. typescript-eslint fängt sie auf, ohne dass separate Werkzeuge erforderlich sind.
Biome und OxcLint: Die nächste Generation von JavaScript-Tools
ESLint ist seit einem Jahrzehnt der Standard-JavaScript-Linter. Zwei neuere Tools fordern diese Position nun mit deutlich besserer Leistung heraus.
Biom Biome ist ein einzelnes Tool, das sowohl ESLint als auch Prettier ersetzt und Linting, Formatierung und Importorganisation in einer einzigen Binärdatei bietet, die für die grundlegende Nutzung keine Konfiguration erfordert. Es ist in Rust geschrieben und läuft bei großen Codebasen 25- bis 35-mal schneller als ESLint. Biome unterstützt JavaScript, TypeScript, JSX und JSON.
bash
# Install
npm install --save-dev --save-exact @biomejs/biome
# Initialize config
npx @biomejs/biome init
# Check (lint + format check)
npx @biomejs/biome check --write src/OxcLint (Teil des Oxc-Projekts) ist ein weiterer Rust-basierter Linter, der ESLint-kompatible Regeln mit 50- bis 100-facher Ausführungsgeschwindigkeit bereitstellt. Er ist als direkter Ersatz für die Kernregeln von ESLint konzipiert und soll während einer Migration parallel zu ESLint laufen, anstatt einen sofortigen vollständigen Wechsel zu erfordern.
bash
# Install
npm install --save-dev oxlint
# Run
npx oxlint src/Wann ist was zu verwenden?Für neue Projekte ist Biome die beste Wahl für Linting und Formatierung. Bei bestehenden Projekten mit umfangreicher ESLint-Konfiguration und zahlreichen Plugins erfordert die Migration zu Biome die Überprüfung der Regelabdeckung. OxcLint eignet sich besser für die schrittweise Ablösung von ESLint in großen, bestehenden Projekten, in denen das Plugin-Ökosystem nicht sofort aufgegeben werden kann.
| Werkzeug | Geschwindigkeit vs. ESLint | Ersetzt Prettier | TypeScript-Unterstützung | Plugin-Ökosystem |
|---|---|---|---|---|
| ESLint | Baseline | Nein (passend zu Prettier) | Über typescript-eslint | Größte (~3,000 Plugins) |
| Biom | 25-35x schneller | Ja | Eingebaut | Begrenzt, aber wachsend |
| OxcLint | 50-100x schneller | Nein | Eingebaut | ESLint-kompatible Teilmenge |
| StandardJS | Vergleichbar mit ESLint | Teilweise | Begrenzt | Fester Regelsatz |
Semgrep: Musterbasierter SAST für JavaScript-Sicherheit
Semgrep ist ein mehrsprachiges Tool für statische Sicherheitsanalyse (SAST), das Sicherheitslücken durch Code-Mustererkennung aufspürt. Während ESLint Stil und Konventionen durchsetzt, findet Semgrep SQL-Injection, XSS, Prototype Pollution, fest codierte Zugangsdaten, unsichere Express.js-Konfigurationen und Hunderte weiterer Sicherheitsmuster in JavaScript und TypeScript.
Der entscheidende Unterschied zu ESLint: Semgrep-Regeln werden als Codemuster in einer Syntax geschrieben, die die Zielsprache genau widerspiegelt, wodurch sie auch für Entwickler ohne tiefgreifende Kenntnisse der statischen Codeanalyse lesbar und schreibbar sind:
YAML
# Custom Semgrep rule: flag direct use of user input in SQL queries
rules:
- id: sql-injection-express
patterns:
- pattern: |
$APP.get($ROUTE, ($REQ, $RES) => {
...
$DB.query($REQ.query.$INPUT, ...);
...
})
message: User input directly used in SQL query -- use parameterized queries
languages: [javascript, typescript]
severity: ERRORbash
# Run Semgrep with the community security rule registry
semgrep scan --config=p/javascript src/
# Run with a specific rule set for Node.js
semgrep scan --config=p/nodejs src/Semgrep vs ESLintSie ergänzen sich, anstatt miteinander zu konkurrieren. Verwenden Sie ESLint für Codequalität und Konventionen. Verwenden Sie Semgrep für Sicherheitsüberprüfungen. Die meisten JavaScript-Teams sollten beide in ihrer CI-Umgebung einsetzen. GitLab hat kürzlich angekündigt, seine SAST-Analysatoren von ESLint auf Semgrep umzustellen und ESLint als Sicherheitsscanner schrittweise abzuschaffen, während es für Linting beibehalten wird. Dies spiegelt den wachsenden Konsens wider, dass ESLint das richtige Werkzeug für Linting und Semgrep das richtige Werkzeug für Sicherheitsanalysen ist.
SonarQube und SonarLint: Kontinuierliche Qualitätsgatter
SonarQube bietet ein Qualitätskontrollmodell: Jeder Pull Request wird anhand eines definierten Qualitätsprofils geprüft, und Merges werden blockiert, wenn der Code die Kriterien nicht erfüllt. Für JavaScript und TypeScript erkennt es Fehler, Code-Smells, Sicherheitslücken und Duplikate und verfolgt deren Entwicklung im Zeitverlauf.
SonarLint ist die IDE-Erweiterung, die SonarQube-Regeln lokal anzeigt, während Entwickler Code schreiben, und so sofortiges Feedback ermöglicht, anstatt auf CI warten zu müssen.
Der Vorteil von SonarQube gegenüber reinen Linting-Tools liegt in seinem kontinuierlichen Messmodell: Es verfolgt die Entwicklung von technischen Schulden, Codeabdeckung und Sicherheitslücken im Zeitverlauf. Damit ist SonarQube die optimale Lösung für Teams, die neben Entwicklerdiagnosen auch Managementberichte zur Codequalität benötigen.
Wichtige Konfigurationen für JavaScript/TypeScript-Projekte:
- Richten Sie eine Qualitätsprüfung ein, die bei jedem neuen Blocker oder kritischen Sicherheits-Hotspot fehlschlägt.
- Aktivieren Sie die
Sonar WayRegelprofil als Grundlage - Nutzen Sie SonarLint in VS Code oder IntelliJ, um Feedback direkt im Editor zu erhalten.
- Integrieren Sie GitHub Actions oder GitLab CI mithilfe von
SonarQube ScanAktion
CodeQL: Semantische Codeanalyse zur Erkennung tiefgreifender Sicherheitslücken
CodeQL, entwickelt von GitHub, führt semantische Analysen durch, indem es Code in eine abfragefähige Datenbank umwandelt und Abfragen darauf ausführt. Es unterstützt JavaScript und TypeScript und ist über GitHub Advanced Security kostenlos für Open-Source-Projekte verfügbar.
CodeQL findet Schwachstellen, die das Verständnis des Datenflusses durch das gesamte Programm erfordern: ein vom Benutzer festgelegter Wert, der über mehrere Funktionsaufrufe zu einer unsicheren Operation gelangt. Es ist das Tool, das Schwachstellen aufspürt, die Pattern-Matching-Tools wie Semgrep übersehen, wenn der Codepfad indirekt ist.
YAML
# .github/workflows/codeql.yml
name: CodeQL Analysis
on: [push, pull_request]
jobs:
analyze:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: github/codeql-action/init@v3
with:
languages: javascript-typescript
- uses: github/codeql-action/autobuild@v3
- uses: github/codeql-action/analyze@v3CodeQL hat einen höheren Einrichtungsaufwand als Semgrep und läuft langsamer, aber es erkennt eine andere Art von Schwachstellen: funktions- und dateiübergreifende Datenflüsse, die kein musterbasiertes Tool ohne vollständige Datenflussanalyse identifizieren kann.
Erkennung von totem Code: Unbenutzte Exporte und nicht erreichbarer Code
Toter Code in JavaScript- und TypeScript-Projekten ist besonders tückisch, da das Modulsystem nicht verhindert, dass sich ungenutzte Exporte anhäufen. Eine Funktion kann exportiert, aber nie importiert werden, und Standardwerkzeuge warnen nicht davor, sofern sie nicht explizit konfiguriert ist.
Schnitt ist das derzeit leistungsfähigste Werkzeug dafür. Es analysiert den gesamten Projektgraphen, um ungenutzte Exporte und Abhängigkeiten zu finden. package.jsonund nicht erreichbare Dateien:
bash
npm install --save-dev knip
npx knipts-prune zielt speziell auf TypeScript ab und findet exportierte Symbole, die nie importiert werden:
bash
npm install --save-dev ts-prune
npx ts-pruneESLint no-unused-vars und @typescript-eslint/no-unused-vars Knip erkennt zwar ungenutzte lokale Variablen in Dateien, kann aber ungenutzte Exporte auf Modulebene nicht aufspüren. Knip schließt die Lücken, die ESLint hinterlässt.
Toter Code wirkt sich direkt auf die Bundle-Größe von Frontend-Anwendungen und die kognitive Belastung der Entwickler aus. Das Entfernen von totem Code ist eine der wirkungsvollsten Wartungsmaßnahmen und lässt sich nur mithilfe von Tools aufspüren, da menschliche Prüfer die Modulnutzung in großen Codebasen nicht zuverlässig nachverfolgen können.
Async/Await und Promises: Die Herausforderung der statischen Analyse
Die Daten der Google Search Console zu diesem Artikel zeigen eine signifikante Häufung von Suchanfragen zu statischen Analysetools für asynchrones JavaScript: TAJS, Jelly Static Analyzer, SonarJS Async Rules und ähnliche. Dies verdeutlicht eine bestehende Lücke im Angebot an geeigneten Tools.
Standardmäßige Linting-Tools bilden die Interaktion von Promises und asynchronen Funktionen nicht ab. Ein fehlendes awaitEine unbehandelte Ausnahme oder eine Race Condition in nebenläufigem asynchronem Code sieht syntaktisch korrekt aus und erfüllt alle Lint-Regeln. Um solche Fehler zu erkennen, sind Werkzeuge erforderlich, die die Semantik der asynchronen Ausführung modellieren.
Der aktuelle praktische Ansatz:
typescript-eslint bietet die unmittelbar nützlichsten asynchronen Regeln:
Javascript
// Rules that catch common async mistakes
"@typescript-eslint/no-floating-promises": "error", // await or .catch() required
"@typescript-eslint/await-thenable": "error", // only await actual Promises
"@typescript-eslint/no-misused-promises": "error", // Promises in non-async contexts
"@typescript-eslint/require-await": "warn", // async functions must use awaitForschungswerkzeuge TAJS (Type Analyzer for JavaScript), Jelly und SAFE sind akademische statische Analysetools, die das asynchrone Ausführungsmodell von JavaScript modellieren, einschließlich Promise-Ketten, async/await und der Semantik der Ereignisschleife. Sie sind keine Entwicklungswerkzeuge für den Produktiveinsatz, sondern Forschungsplattformen, die in der Sicherheitslückenforschung und formalen Analyse verwendet werden. Die Suchanfragen in den Search Console-Daten zu „jelly static analyzer javascript async support paper“ und „TAJS async await support“ zeigen, dass Entwickler diese akademischen Tools erforschen oder zitieren und nicht nach Werkzeugen für die tägliche Entwicklung suchen.
SonarQube javascript:S4328 und verwandte asynchrone Regeln erkennen einige häufige asynchrone Anti-Patterns bei der Qualitätsanalyse in der Produktion.
Für den praktischen Produktionseinsatz ist die Kombination aus TypeScript-Typüberprüfung, typescript-eslintDie asynchronen Regeln von SonarQube und dessen Qualitätsgate bieten die umfassendste Abdeckung für asynchrone Sicherheit, die derzeit in Standardwerkzeugen verfügbar ist.
Snyk Code: Sicherheits-Scanning für Entwickler
Snyk Code bietet SAST-Scanning mit Fokus auf die Entwicklerfreundlichkeit: Es integriert sich in VS Code und JetBrains IDEs, zeigt Ergebnisse direkt im Code an und liefert zu jedem Ergebnis Beispiele für die Fehlerbehebung. Es verwendet eine proprietäre, ML-basierte Analyse-Engine, die Taint-Tracking in JavaScript- und TypeScript-Codebasen durchführt.
bash
# Install Snyk CLI
npm install --save-dev snyk
# Authenticate and scan
npx snyk auth
npx snyk code testSnyk Code eignet sich besonders für Teams, die Sicherheitsfeedback direkt in ihrer IDE erhalten möchten. Die Lösungsvorschläge sind benutzerfreundlicher als die abfrageorientierten Ausgaben von CodeQL und machen es daher zur besseren Wahl für Sicherheitsschulungen und die Erkennung von Schwachstellen.
Aufbau eines mehrschichtigen JavaScript-Stacks zur statischen Analyse
Der richtige Ansatz für die statische JavaScript-Analyse besteht nicht darin, ein einzelnes Tool auszuwählen, sondern Tools zu kombinieren, die verschiedene Ebenen abdecken, ohne sich wesentlich zu überschneiden:
| Schicht | Werkzeug | Wenn es läuft |
|---|---|---|
| Formatierung: | Biom oder schöner | Vorab-Commit (schnell) |
| Flusen | ESLint + typescript-eslint | Pre-Commit + CI |
| Typprüfung | tsc --noEmit | CI |
| Sicherheitsscan | Semgrep- oder Snyk-Code | CI (jeder PR) |
| Tiefen-Schwachstellenscan | CodeQL | CI (geplant oder PR) |
| Erkennung von totem Code | Schnitt | CI (wöchentlich oder monatlich) |
| Qualitätstore + Trendverfolgung | SonarQube | CI (jeder PR) |
| Scannen von Abhängigkeitsschwachstellen | npm audit + Snyk | CI (bei jedem Build) |
Ein minimaler Stack für ein Team, das bei Null anfängt: ESLint + typescript-eslint + npm auditFügen Sie Semgrep oder Snyk Code hinzu, wenn die Sicherheitsanforderungen steigen. Fügen Sie SonarQube hinzu, wenn das Team einen guten Überblick über Trends und Managementberichte benötigt.
YAML
# .github/workflows/quality.yml
name: JavaScript Code Quality
on: [push, pull_request]
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: "20" }
- run: npm ci
- run: npx tsc --noEmit
- run: npx eslint src/ --max-warnings 0
security:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: "20" }
- run: npm ci
- run: npm audit --audit-level=high
- run: npx semgrep scan --config=p/javascript --error src/Wenn JavaScript in einem größeren Unternehmenssystem eingesetzt wird
JavaScript- und TypeScript-Dienste existieren in Unternehmensumgebungen zunehmend parallel zu COBOL-Programmen, Java-Backends, Python-Datenpipelines und Legacy-Mainframe-Systemen. In diesen Kontexten bieten die oben genannten statischen Analysetools zwar umfassende Einblicke innerhalb der JavaScript-Grenze, sind aber für die Verbindungen, die diese Grenze überschreiten, völlig unzugänglich.
Ein Node.js-Dienst, der Daten aus einer Datenbank liest, die von einem COBOL-Batch-Job befüllt wird, ist auf eine Weise von diesem COBOL-Programm abhängig, die für JavaScript-Analysetools nicht sichtbar ist. Ein React-Frontend, das eine Java-API aufruft, welche wiederum ein COBOL-Programm aufruft, weist eine Abhängigkeitskette auf, die sich über drei Sprachgrenzen erstreckt und von keinem Tool, das nur eine Sprache analysiert, erkannt wird.
SMART TS XL Dies wird durch eine sprachübergreifende Abhängigkeitsanalyse für das gesamte Anwendungsportfolio gelöst. Es erstellt ein einheitliches Modell, das darstellt, wie JavaScript-Module von gemeinsamen Datenstrukturen abhängen, wie API-Verträge Frontend- und Backend-Dienste verbinden und wie sich Änderungen in einem Teil des Systems auf Komponenten in anderen Sprachen auswirken. sprachübergreifende Architekturanalyse Diese Funktionalität benötigen Enterprise-Architekturteams bei der Planung von Systemänderungen, die mehrere Sprachen und Plattformen umfassen. Sie ergänzt die JavaScript-spezifischen Tools in diesem Leitfaden, anstatt mit ihnen zu konkurrieren. Wie im Kontext von Abhängigkeitsgraphen und AnwendungsrisikoDas Verständnis der gesamten Abhängigkeitsstruktur eines Systems vor der Durchführung von Änderungen unterscheidet sicheres Refactoring von Änderungen, die zu unerwarteten Fehlern in Komponenten führen, die niemand zu testen gedacht hat.
Für JavaScript-spezifische Analysen innerhalb dieser größeren Umgebungen, SMART TS XL Enterprise-Code-Intelligenz Die Abdeckung umfasst JavaScript und TypeScript sowie COBOL, JCL, Java, Python und andere Unternehmenssprachen und bietet einheitliche Qualitätsmetriken und Transparenz der Abhängigkeiten auf einer einzigen Plattform.
Das richtige Werkzeug für Ihren Kontext auswählen
Kein einzelnes Tool deckt alle Dimensionen der statischen JavaScript-Analyse ab. Die Entscheidung hängt von der Teamgröße, den Sicherheitsanforderungen, der vorhandenen Toolchain und davon ab, ob die JavaScript-Anwendung isoliert oder als Teil eines größeren, mehrsprachigen Unternehmenssystems betrieben wird.
Für Einzelentwickler oder kleine Teams bei neuen Projekten: Beginnen Sie mit Biome (Linting + Formatierung) und dem strikten Modus von TypeScript. npm audit zur Sicherung von Abhängigkeiten.
Für ein mittelgroßes Team, das eine Webanwendung für den Produktiveinsatz entwickelt: ESLint mit typescript-eslint, Prettier, TypeScript Strict Mode, Semgrep in der CI-Pipeline für Sicherheitszwecke und Knip zur Erkennung von totem Code.
Für ein Unternehmensteam mit Compliance- und Sicherheitsanforderungen: SonarQube für Qualitätskontrollen und Trendverfolgung, CodeQL für umfassende Schwachstellenscans, Snyk Code für sicherheitsrelevantes Feedback an Entwickler und SMART TS XL wenn die JavaScript-Anwendung mit älteren oder mehrsprachigen Systemen interagiert.
Für ein Team, das aufgrund der Leistung in einem Monorepo ESLint-Alternativen evaluiert: OxcLint als geschwindigkeitsorientiertes Drop-in oder Biome als vollständiger Linter-Formatter-Ersatz.
