06 - サプライ チェーン セキュリティ: npm 監査、SBOM、依存関係管理
2025 年 9 月はソフトウェア セキュリティの歴史の転換点となりました: 18 のパッケージ npm は世界で最もダウンロードされているものの 1 つです。 チョーク, デバッグ e アンシスタイルは、メンテナーをターゲットとしたフィッシング キャンペーンを通じて侵害されます。 わずか数時間で、毎週 26 億件を超えるダウンロードが JavaScript コードにさらされる 暗号通貨トランザクションを傍受するように設計された難読化されたもの。これは攻撃ではありません アプリケーションだけでなく、それをサポートするエコシステムにも影響を与えます。
このシナリオは、サプライ チェーン攻撃の基本的な性質を示しています。攻撃のターゲットはターゲットではありません。
自分が書いたコードだけでなく、自分が信頼できるコードでもあります。 Every dependency you install with
npm install 他の人によって書かれ、他の人によって保守され、潜在的にはコードを表します。
他人によって妥協された。中規模の Node.js プロジェクトでは、直接の依存関係は次のとおりです。
通常は 20 ～ 50 パケットですが、完全な推移的な依存関係グラフは到達可能です
簡単に 500 ～ 1000 のライブラリが対象になります。本当にこのコードをすべてチェックしているのでしょうか?
OWASP Top 10:2025 によると、このカテゴリは A03: ソフトウェアとデータの整合性障害 サプライチェーンの障害が重要なベクトルとして明示的に含まれています。これは 2 つのうちの 1 つです 2025 年版で導入された新しいカテゴリーでは、安全性が明確に認識されています。 コードは依存関係の安全性を無視できなくなりました。この記事では、 あなたを守るための具体的なツール。
何を学ぶか
- サプライチェーン攻撃の構造: タイポスクワッティング、依存関係の混乱、ロックファイルポイズニング
- npm 監査、yarn 監査、pnpm 監査: 高度な使用と自動化
- npm ci を使用したロックファイルの整合性とハッシュの検証
- SBOM: CycloneDX および SPDX による生成、NTIA 標準
- Snyk と dependabot: 継続的な脆弱性監視
- GitHub Actions の強化: SHA ピン留めと最小限の権限
- コンテナイメージのセキュリティ: Trivy、Syft、Cosign/Sigstore による署名
- 依存関係の混乱とプライベート npm スコープを防御する方法
サプライチェーン攻撃の構造
サプライ チェーン攻撃がどのように機能するかを理解することは、身を守るための第一歩です。 いくつかの主要なカテゴリがあり、それぞれに異なる特性と攻撃ベクトルがあります。
タイポスクワッティング: タイプミスの危険性
タイポスクワッティングは、一般的な入力エラーを悪用します。攻撃者が公開する
lodahs （の代わりに lodash), requst （の代わりに
request）、 または colerrs （の代わりに colors）。 2025年には、
セキュリティ研究者は、次の目的で設計された一連のタイポスクワッティング パッケージを特定しました。
スクリプト経由で隠しターミナルを起動する一般的なライブラリを模倣する postinstall
サイレントに認証情報を抜き出すため。
主な防御策は、パッケージをインストールする前に名前を徹底的に確認することです。 Snyk や Socket.dev などのツールは、名前の類似性を自動的に分析します。 既存のパッケージを確認し、インストール前にタイポスクワッティングの可能性を報告します。
依存関係の混乱: パブリック スコープとプライベート スコープ
依存関係の混乱 (または名前空間の混乱) は、より高度な攻撃として文書化されています。 2021 年に Alex Birsan によって初めて。攻撃者が npm でパッケージを公開 ターゲット企業のプライベート社内パッケージと同じ名前ですが、 上位バージョン。 npm はデフォルトでパブリック レジストリから最新バージョンを解決します。 悪意のあるパッケージが正規のパッケージに置き換わるように導きます。
実際のケース: 大規模な依存関係の混乱
2021 年、Alex Birsan は Microsoft、Apple、PayPal を含む 35 以上の主要企業を侵害しました Shopify はこの手法を使用して、バグ報奨金として 130,000 ドル以上を獲得しました。 メカニズムは単純でした。構成ファイル内の内部パッケージ名を検索します。 public (package.json、pyproject.toml) を作成し、バージョン 9.9.9 でパブリック レジストリに公開します。
メンテナーアカウントの乗っ取り
2025 年の最も陰湿な攻撃は、メンテナーをターゲットにしたフィッシングがいかに危険であるかを示しました。 が優先キャリアとなっています。正規のメンテナのアカウントが侵害されると、 攻撃者は、すでに信頼されているパッケージの悪意のあるバージョンを公開します。コミュニティは信頼しています パッケージのセキュリティ テストに合格し、悪意のあるコードが本番環境に入ります。
ロックファイルポイズニング
ロックファイル ポイズニング攻撃では、悪意のある投稿者がファイルを直接変更します。
package-lock.json o yarn.lock プルリクエストでポイントする
侵害されたバージョンまたは予想とは異なるハッシュ。レビュープロセスに以下が含まれていない場合
ロックファイルをチェックすると、悪意のあるコードは気づかれません。
npm Audit: 高度な使用法
npm audit しかし、それを正しく使用するには、それ以上のものが必要です。
単純な実行。これを開発ワークフローに効果的に統合する方法を見てみましょう。
# Audit base con output JSON per processing automatico
npm audit --json
# Audit solo production dependencies (esclude devDependencies)
npm audit --omit=dev
# Fissa automaticamente le vulnerabilità patchabili
npm audit fix
# Fix anche di breaking changes (usare con cautela)
npm audit fix --force
# Audit con soglia di severita: exit code 1 se ci sono critical
npm audit --audit-level=critical
# Audit con soglia moderate
npm audit --audit-level=moderate
# Output in formato per CI/CD
npm audit --json | jq '.metadata.vulnerabilities'
多くの依存関係を持つプロジェクトの場合、脆弱性の数は膨大になる可能性があり、
管理が難しい。効果的な戦略は、ファイルを構成することです。 .npmrc
プロジェクトの監査ポリシーを使用するか、 npm audit ファイル付き
例外構成。
# .nsprc (Node Security Project configuration)
# Oppure usa audit-resolve.json con npm-audit-resolver
# Installazione di npm-audit-resolver per gestire eccezioni
npm install -g npm-audit-resolver
# Processo interattivo per gestire ogni vulnerabilità
audit-resolve
# Verifica successiva (usa le eccezioni salvate)
audit-resolve --ci
# Script package.json per CI sicuro
# package.json
{
"scripts": {
"audit:ci": "npm audit --audit-level=high --omit=dev",
"audit:full": "npm audit --json > audit-report.json",
"audit:check": "npm audit --audit-level=critical"
}
}pnpm監査とyarn監査
pnpm または Yarn を使用する場合、監査コマンドは似ていますが、いくつかの重要な違いがあります。 pnpm は依存関係をより詳細に制御できますが、yarn v2/v3 (Berry) は依存関係をより詳細に制御します。 ハッシュ管理が大幅に改善されました。
# pnpm audit
pnpm audit
pnpm audit --audit-level high
pnpm audit --prod # solo production
# yarn audit (classic v1)
yarn audit
yarn audit --level high
# yarn audit (Berry v2/v3)
yarn npm audit
yarn npm audit --severity high
# Output JSON per processing
pnpm audit --json | jq '.advisories | length'ロックファイルの整合性: 防御の第一線
ロックファイル (package-lock.json, yarn.lock, pnpm-lock.yaml)
ビルドの再現性とセキュリティにとって重要です。ロックファイル内のすべてのエントリ
正確なバージョンだけでなく、パッケージ内容のハッシュも含まれます。
npm ci と npm install: 重要な違い
運用環境および CI/CD では、常に使用します。 npm ci の代わりに npm install.
npm ci ロックファイルで指定されたバージョンを正確にインストールし、確認してください
各パケットの暗号化ハッシュ、ロックファイルが同期していない場合は失敗します。
package.json。 npm install ロックファイルをサイレントに更新できます。
# CORRETTO per CI/CD: verifica integrita lockfile
npm ci
# Verifica manuale degli hash nel lockfile
# package-lock.json contiene entries come:
# "node_modules/lodash": {
# "version": "4.17.21",
# "resolved": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz",
# "integrity": "sha512-v2kDEe57lecTulaDIuNTPy3Ry4gLGJ6Z1O3vE1krgXZNrsQ+LFTGHVxVjcXPs17LhbZboqV76wE2wDvQ6",
# }
# Verifica che il lockfile non sia stato modificato
git diff package-lock.json | head -50
# Pre-commit hook per prevenire modifiche non autorizzate al lockfile
# .husky/pre-commit
#!/bin/sh
if git diff --cached --name-only | grep -q "package-lock.json"; then
echo "WARNING: package-lock.json modificato. Verifica le dipendenze."
npm audit --audit-level=high
fiセキュリティのための .npmrc 構成
ファイル .npmrc セキュリティ ポリシーを使用して npm を構成できます。
プロジェクト全体または現在のユーザーに適用されます。
# .npmrc - configurazione sicurezza progetto
# Richiedi sempre HTTPS per il registro
registry=https://registry.npmjs.org/
# Abilita strict-ssl (default: true, non disabilitare mai!)
strict-ssl=true
# Audit automatico dopo ogni install
audit=true
# Fund messages: disabilita per CI
fund=false
# Usa lockfile (default: true)
package-lock=true
# Per workspace con pacchetti privati su registro Artifactory/Nexus
# @mycompany:registry=https://npm.mycompany.internal/
# //npm.mycompany.internal/:_authToken={NPM_TOKEN}
# Prevenzione dependency confusion: scope sempre sul registro privato
# @internal:registry=https://npm.internal.company.com/依存関係の混乱: プライベート スコープで身を守る
依存関係の混乱に対する最も効果的な防御策は、パッケージがプライベートであることを確認することです。 常に専用のスコープを使用し、そのスコープを解決するように npm が構成されていること 内部レジスタからのみ。
# package.json con scope privato corretto
{
"dependencies": {
"@mycompany/auth-utils": "^2.1.0",
"@mycompany/api-client": "^1.5.0"
}
}
# .npmrc - scope privati sempre sul registro interno
@mycompany:registry=https://npm.mycompany.internal/
//npm.mycompany.internal/:_authToken=${INTERNAL_NPM_TOKEN}
# Verifica che un pacchetto @mycompany NON esista su npm pubblico
npm view @mycompany/auth-utils --registry https://registry.npmjs.org/
# Deve restituire 404 - se restituisce un pacchetto, qualcuno ha fatto typosquatting!
# GitHub Actions: verifica automatica assenza pacchetti privati su npm pubblico
# - name: Check private packages not on public npm
# run: |
# for pkg in $(cat package.json | jq -r '.dependencies | keys[]' | grep "^@mycompany"); do
# if npm view $pkg --registry https://registry.npmjs.org/ 2>/dev/null; then
# echo "ALERT: $pkg trovato su npm pubblico!" && exit 1
# fi
# doneSBOM: ソフトウェア部品表
ソフトウェア部品表 (SBOM) とすべてのコンポーネントの完全な正式な一覧表 アプリケーション内のソフトウェア: サードパーティのライブラリ、推移的な依存関係、バージョン、ライセンス そして既知の脆弱性。これは企業セキュリティの事実上の要件となっており、 一部の分野 (米国政府、重要インフラ) では、法律で義務付けられています。
主な基準は次の 2 つです。 SPDX (ソフトウェア パッケージ データ交換、Linux Foundation) e サイクロンDX (OWASP)。 SPDX はライセンス準拠を重視しており、 CycloneDX は、セキュリティと脆弱性管理のために最適化されています。 Web アプリケーションの場合、 一般的には CycloneDX が最良の選択です。
SBOM が重要な理由
SBOM を使用して依存関係を管理するプロジェクトは 264 日の短縮を達成 SBOM を使用しない場合と比較して、重大な脆弱性の平均修復時間 (MTTR) が向上します。 新しい CVE (Log4Shell など) の場合、SBOM により数分で識別できます。 数週間にわたる手動分析の代わりに、影響を受けるすべてのプロジェクトを対象にします。
CycloneDXによるSBOM生成
# Installazione CycloneDX CLI per Node.js
npm install -g @cyclonedx/cyclonedx-npm
# Generazione SBOM in formato JSON (CycloneDX v1.6)
cyclonedx-npm --output-format json --output-file sbom.json
# Generazione SBOM in formato XML
cyclonedx-npm --output-format xml --output-file sbom.xml
# Con dipendenze di sviluppo escluse
cyclonedx-npm --omit dev --output-format json --output-file sbom-prod.json
# Verifica del SBOM generato
cat sbom.json | jq '.metadata.component.name'
cat sbom.json | jq '.components | length'
cat sbom.json | jq '.vulnerabilities | length'
# Esempio output SBOM JSON (struttura CycloneDX v1.6)
# {
# "bomFormat": "CycloneDX",
# "specVersion": "1.6",
# "serialNumber": "urn:uuid:1a2b3c4d-...",
# "version": 1,
# "metadata": {
# "timestamp": "2026-02-25T10:30:00Z",
# "tools": [...],
# "component": {
# "type": "application",
# "name": "my-app",
# "version": "1.0.0"
# }
# },
# "components": [
# {
# "type": "library",
# "name": "express",
# "version": "4.18.2",
# "purl": "pkg:npm/express@4.18.2",
# "hashes": [
# { "alg": "SHA-256", "content": "abc123..." }
# ],
# "licenses": [{ "license": { "id": "MIT" } }]
# }
# ]
# }SYFT による SBOM の生成
Anchore の Syft は、SBOM を生成するための最も完全なツールの 1 つです。 コンテナイメージ、ファイルシステム、npm/pip/go/java アーティファクトのサポート。
# Installazione Syft
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
# SBOM da directory progetto (formato CycloneDX JSON)
syft dir:. -o cyclonedx-json=sbom.json
# SBOM da container image
syft nginx:latest -o spdx-json=sbom-nginx.json
# SBOM da immagine locale Docker
syft docker:my-app:latest -o cyclonedx-json=sbom.json
# Output in più formati simultaneamente
syft dir:. \
-o cyclonedx-json=sbom-cdx.json \
-o spdx-json=sbom-spdx.json \
-o table
# Filtrare solo componenti npm
syft dir:. -o cyclonedx-json | jq '.components[] | select(.purl | startswith("pkg:npm"))'Snyk と dependabot: 継続的な監視
1 回限りの監視では不十分: 新たな脆弱性が発見される 毎日。 Snyk と GitHub dependabot は自動アラートによる継続的な監視を提供します プルリクエストを更新します。
Snyk CLI と統合
# Installazione Snyk CLI
npm install -g snyk
# Autenticazione
snyk auth
# Test vulnerabilità progetto
snyk test
# Test con soglia: exit 1 se vulnerabilità high/critical
snyk test --severity-threshold=high
# Monitor continuo (invia snapshot a Snyk dashboard)
snyk monitor
# Fix automatico con patch
snyk fix
# Generazione report HTML
snyk test --json | snyk-to-html -o report.html
# Test container image
snyk container test nginx:latest --severity-threshold=high
# Generazione SBOM via Snyk
snyk sbom --format cyclonedx1.6+json
# Integrazione in package.json
# {
# "scripts": {
# "security:test": "snyk test --severity-threshold=high",
# "security:monitor": "snyk monitor",
# "security:container": "snyk container test $IMAGE_NAME"
# }
# }GitHub dependabot: 最適な構成
# .github/dependabot.yml
version: 2
updates:
# npm/Node.js dependencies
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
day: "monday"
time: "09:00"
timezone: "Europe/Rome"
open-pull-requests-limit: 10
# Raggruppa aggiornamenti di patch e minor
groups:
production-dependencies:
dependency-type: "production"
update-types:
- "minor"
- "patch"
dev-dependencies:
dependency-type: "development"
update-types:
- "minor"
- "patch"
# Label automatiche per PR
labels:
- "dependencies"
- "security"
# Revisori automatici
reviewers:
- "security-team"
# Ignora major updates di alcune librerie critiche
ignore:
- dependency-name: "webpack"
update-types: ["version-update:semver-major"]
# GitHub Actions
- package-ecosystem: "github-actions"
directory: "/"
schedule:
interval: "weekly"GitHub Actions セキュリティ: SHA ピン留めと強化
GitHub Actions は、サプライ チェーン上の重要な攻撃ベクトルとなります。
2024 年には、 tj-actions/changed-files どのようにして実証したか
広く使用されているアクションが危険にさらされ、秘密を漏洩するために使用される可能性があります。
何千ものリポジトリ。主な防御と SHA ピンニング: 参照の代わりに
タグごとに 1 つのアクション (@v4)、コミットの不変ハッシュが使用されます。
# .github/workflows/security-ci.yml
name: Security CI Pipeline
on:
push:
branches: [main, develop]
pull_request:
branches: [main]
# Permissions minime (principio del minimo privilegio)
permissions:
contents: read
security-events: write # Per upload SARIF a GitHub Security tab
jobs:
dependency-audit:
name: Dependency Security Audit
runs-on: ubuntu-latest
permissions:
contents: read
steps:
# SHA-pinned: usa hash commit, non tag!
# actions/checkout@v4 -> SHA esatto del commit
- name: Checkout code
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
- name: Setup Node.js
uses: actions/setup-node@39370e3970a6d050c480ffad4ff0ed4d3fdee5af # v4.1.0
with:
node-version: '22'
cache: 'npm'
# Usa npm ci (non npm install) per verifica lockfile
- name: Install dependencies (strict lockfile)
run: npm ci --ignore-scripts
# Audit con exit code per bloccare la build
- name: npm audit
run: npm audit --audit-level=high --omit=dev
# Snyk test (richiede SNYK_TOKEN secret)
- name: Snyk Security Test
uses: snyk/actions/node@b98d498629f1c5e3943f89a5c62b5e5d4e2f86c0 # SHA pinned
env:
SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
with:
args: --severity-threshold=high --fail-on=upgradable
sbom-generation:
name: Generate SBOM
runs-on: ubuntu-latest
needs: dependency-audit
permissions:
contents: write
id-token: write # Per OIDC (Sigstore)
attestations: write
steps:
- name: Checkout code
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
- name: Setup Node.js
uses: actions/setup-node@39370e3970a6d050c480ffad4ff0ed4d3fdee5af # v4.1.0
with:
node-version: '22'
- name: Install dependencies
run: npm ci --ignore-scripts
- name: Generate SBOM (CycloneDX)
run: |
npm install -g @cyclonedx/cyclonedx-npm
cyclonedx-npm --omit dev --output-format json --output-file sbom.json
# Attesta il SBOM con OIDC (GitHub native attestation)
- name: Attest SBOM
uses: actions/attest-build-provenance@1c608d11d69870c2092266b3f9a6f3abbf17002c # v1.4.3
with:
subject-path: sbom.json
- name: Upload SBOM as artifact
uses: actions/upload-artifact@4cec3d8aa04e39d1a68397de0c4cd6fb9dce8ec1 # v4.6.0
with:
name: sbom
path: sbom.jsonアンチパターン: サードパーティのアクションではタグを使用しないでください
uses: some-org/some-action@v2 脆弱性: メンテナのアカウントの場合
侵害された場合、タグが更新されて悪意のあるコードを指す可能性があります。
常にフォーマットを使用する uses: some-org/some-action@SHA_HASH # v2.0.0
読みやすくするためにタグをコメントとして含めます。のようなツール
pinact e action-pins このプロセスを自動化します。
ワークフローの最小権限
# Imposta permissions di default a read-only per tutto il workflow
# SEMPRE aggiungere questo al livello top del workflow
permissions:
contents: read
# Poi concedi permissions aggiuntive solo ai job che le necessitano
jobs:
build:
permissions:
contents: read
packages: write # Solo se deve pubblicare su GitHub Packages
# Esempio job che NON ha bisogno di scrivere
test:
permissions:
contents: read # Solo lettura
# Variabili d'ambiente: mai hardcodare secrets
# SBAGLIATO:
# env:
# API_KEY: "sk-prod-abc123"
# CORRETTO: usa sempre GitHub Secrets
# env:
# API_KEY: ${{ secrets.API_KEY }}
# Limita anche GITHUB_TOKEN
# SBAGLIATO: permissions non specificati (default read+write)
# CORRETTO: specifica esplicitamente il minimo necessarioコンテナイメージのセキュリティ
アプリケーションが Docker コンテナにデプロイされている場合、攻撃対象領域は 基本イメージとインストールされた OS パッケージも含まれます。トリビーとグライプは、 コンテナイメージの脆弱性をスキャンするための主要なツール。
# Installazione Trivy
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin
# Scansione immagine locale
trivy image my-app:latest
# Solo vulnerabilità CRITICAL e HIGH
trivy image --severity HIGH,CRITICAL my-app:latest
# Output in formato SARIF per GitHub Security tab
trivy image --format sarif --output trivy-results.sarif my-app:latest
# Scansione del filesystem (anche senza Docker)
trivy fs --scanners vuln,secret,misconfig .
# Scansione con SBOM output
trivy image --format cyclonedx --output sbom.json my-app:latest
# Dockerfile best practices: usa immagini distroless
# FROM node:22-alpine AS builder
# WORKDIR /app
# COPY package*.json ./
# RUN npm ci --omit=dev
# COPY . .
# RUN npm run build
# Usa distroless come runtime (superficie minima di attacco)
# FROM gcr.io/distroless/nodejs22-debian12
# COPY --from=builder /app/dist /app
# EXPOSE 3000
# CMD ["/app/server.js"]
# Firma immagine con Cosign/Sigstore
cosign sign --yes my-registry/my-app:latest
# Verifica firma
cosign verify my-registry/my-app:latest --certificate-identity-regexp=".*" --certificate-oidc-issuer="https://accounts.google.com"Angular チェックリスト: サプライ チェーンのセキュリティ
Angular プロジェクトの場合、ツールチェーンに特有の考慮事項があります (Angular CLI、webpack/esbuild、ng-packagr) および npm エコシステム。
# Angular Supply Chain Security Checklist
# 1. Verifica la versione di Angular CLI e dipendenze
ng version
npm audit
# 2. Aggiorna Angular alla versione LTS più recente
ng update @angular/core @angular/cli
# 3. Controlla i peer dependencies
npm ls --depth=0
# 4. Identifica dipendenze deprecate
npm outdated
# 5. Usa npm ci in tutti i CI/CD pipeline Angular
npm ci
# 6. Verifica integrità del lockfile prima di ogni build
git diff package-lock.json
# 7. Configura angular.json per production build con source-map disabilitato
# angular.json
# "configurations": {
# "production": {
# "sourceMap": false,
# "optimization": true,
# "buildOptimizer": true
# }
# }
# 8. Scansiona le dipendenze Angular specifiche
snyk test --file=package.json
# 9. Genera SBOM del progetto Angular
cyclonedx-npm --output-format json --output-file sbom-angular.json
# 10. Aggiungi Content-Security-Policy nel server Angular SSR
# Per Express server in server.ts:
# app.use((req, res, next) => {
# res.setHeader('Content-Security-Policy',
# "default-src 'self'; script-src 'self'");
# next();
# });完全なワークフロー: CI/CD のセキュリティ ゲート
これらすべてのツールを一貫したセキュリティ ゲートに統合することで、 ビルドはサプライ チェーンのセキュリティ チェックを通過せずに本番環境に到達します。
# .github/workflows/supply-chain-security.yml
name: Supply Chain Security Gate
on:
push:
branches: [main]
pull_request:
branches: [main]
schedule:
# Esegui ogni giorno alle 6:00 UTC per monitoraggio continuo
- cron: '0 6 * * *'
permissions:
contents: read
security-events: write
jobs:
security-gate:
name: Supply Chain Security Gate
runs-on: ubuntu-latest
timeout-minutes: 15
steps:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
- uses: actions/setup-node@39370e3970a6d050c480ffad4ff0ed4d3fdee5af # v4.1.0
with:
node-version: '22'
cache: 'npm'
# Verifica integrita lockfile
- name: Verify lockfile integrity
run: |
if [ ! -f "package-lock.json" ]; then
echo "ERROR: package-lock.json mancante!" && exit 1
fi
npm ci --ignore-scripts
# Audit npm - blocca su HIGH/CRITICAL
- name: npm audit (production)
run: npm audit --audit-level=high --omit=dev
continue-on-error: false
# Snyk test
- name: Snyk vulnerability scan
uses: snyk/actions/node@b98d498629f1c5e3943f89a5c62b5e5d4e2f86c0
env:
SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
with:
args: --severity-threshold=high --sarif-file-output=snyk.sarif
# Upload risultati a GitHub Security tab
- name: Upload Snyk results to GitHub Security
uses: github/codeql-action/upload-sarif@dd746615b1a4b1e1c5d3b87432fe040f4c04082 # v3.28.0
with:
sarif_file: snyk.sarif
# Genera SBOM
- name: Generate SBOM
run: |
npm install -g @cyclonedx/cyclonedx-npm
cyclonedx-npm --omit dev \
--output-format json \
--output-file sbom-${{ github.sha }}.json
# Salva SBOM come artifact
- name: Archive SBOM
uses: actions/upload-artifact@4cec3d8aa04e39d1a68397de0c4cd6fb9dce8ec1 # v4.6.0
with:
name: sbom-${{ github.sha }}
path: sbom-${{ github.sha }}.json
retention-days: 90
# License check
- name: Check licenses
run: |
npx license-checker --onlyAllow 'MIT;Apache-2.0;BSD-2-Clause;BSD-3-Clause;ISC;0BSD' \
--excludeDevDependencies \
--json > licenses.json || {
echo "ALERT: Licenze non conformi trovate!"
cat licenses.json
exit 1
}タイポスクワッティング検出の見積もり
新しいパッケージをインストールする前に、ツールを使用してテストすることをお勧めします。 専用の分析。 Socket.dev は最高のセキュリティ分析ツールの 1 つです インストールする前に npm パッケージを削除してください。
# Socket.dev CLI per analisi preventiva
npm install -g @socketsecurity/cli
# Analizza un pacchetto prima di installarlo
socket npm info lodash
# Scansione del progetto esistente
socket scan create --view
# npm-check per pacchetti outdated e typosquatting
npm install -g npm-check
npm-check
# Verifica manuale: controlla chi ha pubblicato il pacchetto
npm view express maintainers
npm view express time # storia delle pubblicazioni
# Red flags da cercare:
# - Pacchetto pubblicato pochi giorni fa con molti download
# - Maintainer con storia breve
# - Nessuna homepage o repository
# - Scripts postinstall/preinstall sospetti
# Verifica scripts nel package.json della dipendenza
npm view lodash scripts
# Installa senza eseguire lifecycle scripts (postinstall, preinstall)
npm install --ignore-scripts
# Verifica il contenuto del pacchetto prima di usarlo
npm pack lodash --dry-runnpm パッケージの危険信号
- インストール後のスクリプト: インストール時にコードを実行します
- 環境変数へのアクセス:
process.env必要のないパッケージに入っている - 不明なドメインへの HTTP リクエスト: UI パッケージはインストール時にネットワーク呼び出しを行うべきではありません
- ネイティブの依存関係 (バインディング): システムアクセスを使用して C/C++ コードをコンパイルします
- バージョン 0.0.1 (1,000 万ダウンロード)：不可能、統計操作信号
- 有名なパッケージに似た名前: インストールする前に必ず npm.im を確認してください
結論と次のステップ
サプライ チェーンのセキュリティは 1 回限りの活動ではなく、継続的なプロセスです。 2025年 最も信頼できるパケットでも危険にさらされる可能性があること、および 防御は階層化する必要があります: ロックファイルの検証、自動監査、生成された SBOM 各リリースでは、SHA-pinning を使用した GitHub Actions、および Snyk または dependabot による継続的な監視が可能です。
最も簡単な手順から始めます。 npm audit --audit-level=high あなたへ
CI/CD、常に使用 npm ci の代わりに npm install パイプラインで、
リポジトリ上で dependabot を有効にします。これら 3 つの変更は大部分をカバーします
最小限の時間投資で攻撃ベクトルを排除します。
次のステップは、リリースごとに SBOM を生成し、実装することです。 この記事で紹介したような完全なセキュリティ ゲート。 OWASP A03 電源あり Chain Failures は 2025 年のトップ 10 に正式にランクインしました。これはもはや「あったら便利」ではありません。 そしてすべての開発者の専門的責任。
シリーズは続きます: 開発者のための Web セキュリティ
- 01 - OWASP トップ 10 2025: 開発者ガイド
- 02 - XSS、CSRF、CSP: フロントエンドのセキュリティ
- 03 - SQL インジェクションと入力検証: バックエンドのセキュリティ
- 04 - 安全な認証: セッションと Cookie
- 05 - API セキュリティ: OAuth 2.1、JWT、レート制限
- 06 - サプライ チェーン セキュリティ: npm 監査と SBOM （この記事）
- 07 - 暗号エラー: ハッシュ、暗号化、トークン
- 08 - 開発者向け DevSecOps: CI/CD の SAST、DAST
シリーズの詳細もご覧ください DevOps フロントエンド (ID 250 ～ 255) 導入ワークフローにセキュリティを統合します。