依存関係のセキュリティとソフトウェア構成分析

オープンソース依存関係のリスク

ソフトウェア構成分析とは

# SCA tool usage examples:

# npm audit (Node.js):
# npm audit
# -> Reports vulnerabilities in package.json dependencies
# -> Shows severity, CVE ID, affected package, fix version

# OWASP Dependency-Check (Java/Python/etc.):
# dependency-check --project 'MyApp' --scan ./lib/
# -> Generates HTML/XML report with CVE findings

# Snyk scan:
# snyk test
# -> Reports vulns + 'snyk fix' applies patches automatically

間接依存関係：隠れたリスク

# Dependency tree example:
# Your package.json:
#   'express': '^4.18.0'     (direct dependency)
#   'lodash':  '^4.17.21'   (direct dependency)

# Transitive dependencies (you didn't choose these):
#   express -> 'qs' 6.11.0       (URL parsing)
#   express -> 'body-parser' 1.20 -> 'qs' 6.11.0
#   lodash (self-contained in this case)

# If 'qs' 6.10.x had a prototype pollution CVE,
# you are vulnerable via express even though
# you never directly imported 'qs'.

Software Bill of Materials（SBOM）

# Generate SBOM with syft:
# syft packages . -o spdx-json > sbom.spdx.json

# SBOM content example (SPDX JSON):
# {
#   'packages': [
#     { 'name': 'express',  'version': '4.18.2', 'license': 'MIT' },
#     { 'name': 'lodash',   'version': '4.17.21','license': 'MIT' },
#     { 'name': 'log4j-core','version': '2.14.0','license': 'Apache-2.0'}
#   ]
# }

# When Log4Shell announced, query SBOM:
# grep -i 'log4j-core' sbom.spdx.json -> FOUND in 3 projects

依存関係の固定とロックファイル

# Version range vs pinned versions:

# FLEXIBLE (can pull different versions each install):
# 'express': '^4.0.0'   -> installs latest 4.x.x
# 'lodash': '*'         -> installs any version!

# PINNED (always same version):
# 'express': '4.18.2'   -> always exactly 4.18.2

# Lock file (package-lock.json):
# Records EXACT resolved version of every transitive dep.
# Commit this file! It ensures reproducible builds.
# Never .gitignore lock files (security anti-pattern).

サプライチェーン攻撃：typosquattingとDependency Confusion

# Dependency Confusion Attack (Alex Birsan 2021):
# Company uses internal package 'company-utils' v1.0.0
# Hosted on: internal.registry.company.com

# Attacker publishes 'company-utils' v9.9.9 to npmjs.com
# (public registry with higher version number)

# npm install resolves: 'find highest version across ALL registries'
# -> Installs v9.9.9 from public npm (attacker's malicious package!)
# -> Instead of v1.0.0 from internal registry

# Defense: use namespace scoping (@company/utils)
# or configure npm to ONLY use internal registry for private packages

市場で利用されているSCAツール

CI/CDパイプラインへのSCAの統合

# GitHub Actions SCA pipeline step:
# - name: Run Snyk SCA scan
#   uses: snyk/actions/node@master
#   env:
#     SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
#   with:
#     args: --severity-threshold=high
#             --fail-on=upgradable
# # Build fails if any HIGH or CRITICAL vuln found
# # that has an available fix (--fail-on=upgradable)
# # No fix available? Generates warning, doesn't block
# # (acknowledging risk explicitly is better than blocking forever)

オープンソースパッケージの健全性評価

脆弱性の修正戦略

依存関係におけるライセンスコンプライアンス

# License compliance risk levels:
# PERMISSIVE (low risk for commercial use):
#   MIT, Apache 2.0, BSD 2/3-Clause
#   -> Can use in proprietary code, just keep attribution

# WEAK COPYLEFT (medium risk - check usage):
#   LGPL -> can link dynamically without open-sourcing your code
#   MPL 2.0 -> modifications to MPL files must be open-sourced

# STRONG COPYLEFT (high risk for proprietary products):
#   GPL v2, GPL v3 -> if you distribute code using GPL library,
#                     your entire product must also be GPL
#   AGPL -> extends GPL to SaaS/network services

# SCA policy: block AGPL/GPL in commercial product
# -> Review any exception requests manually

クイックチェック

レッスンのまとめ