spinny:~/writing $ less devsecops-shift-left-security-guide.md
12コードを書いている最中に発見された脆弱性は、修正に数分しかかかりません。同じ脆弱性が本番環境で見つかると、スプリント全体を消費します。そして攻撃者に先に発見されれば、数百万ドルのコストが発生します。これが**shift-leftセキュリティ**の核心的な主張です - セキュリティチェックを開発ライフサイクルのできるだけ早い段階に前倒しするという考え方です。34DevSecOpsはこのアイデアを実践に変えます。セキュリティは最後にある独立したフェーズではなく、コードの最初の一行から本番デプロイまで、開発のあらゆる段階に織り込まれた継続的なプロセスです。56## 遅いセキュリティのコスト78IBMのデータ侵害コストレポートは、セキュリティ問題の修正コストが発見の遅れに比例して指数関数的に増大することを一貫して示しています。910| 段階 | 修正コスト | 修正時間 |11|-------|------------|-------------|12| **IDE / ローカル開発** | 数分 | 数秒から数分 |13| **コードレビュー / PR** | 数時間 | 数分から数時間 |14| **CI/CDパイプライン** | 数日 | 数時間から数日 |15| **ステージング / QA** | 数週間 | 数日 |16| **本番環境** | 数ヶ月 | 数週間から数ヶ月 |17| **侵害後** | 数百万ドル | 数ヶ月から数年 |1819結論は明確です。セキュリティを一段階前倒しするごとに、コストと時間が桁違いに削減されます。2021## DevSecOpsパイプライン2223成熟したDevSecOpsパイプラインは、あらゆる段階にセキュリティチェックを統合します。2425```mermaid26graph LR27 IDE[IDE / Editor] --> PC[Pre-commit Hooks]28 PC --> PR[Pull Request]29 PR --> CI[CI Pipeline]30 CI --> Build[Build / Package]31 Build --> Deploy[Deploy]32 Deploy --> Runtime[Runtime / Production]3334 IDE -.- S1[SAST\nSecret Detection\nLinting]35 PC -.- S2[Secrets Scan\nFormat Check]36 PR -.- S3[Code Review\nDependency Audit]37 CI -.- S4[SAST\nSCA\nContainer Scan\nSBOM]38 Build -.- S5[Image Signing\nArtifact Verification]39 Deploy -.- S6[Policy Enforcement\nAdmission Control]40 Runtime -.- S7[DAST\nWAF\nMonitoring]41```4243各段階を具体的なツールと設定で解説していきましょう。4445## ステージ1: IDEでのセキュリティ4647最も高速なフィードバックループです。ファイルを保存する前に脆弱性を検出します。4849### 推奨ツール5051- **Semgrep**: OWASPの脆弱性に対応したコミュニティルールを持つ軽量静的解析ツール52- **Snyk IDE Extension**: リアルタイムの依存関係脆弱性スキャン53- **GitLens + GitLeaks**: エディタ内でのsecret検出54- **ESLint Security Plugins**: Node.js向けの`eslint-plugin-security`、DOM XSS向けの`eslint-plugin-no-unsanitized`5556### 例: ESLintセキュリティ設定5758```json59{60 "extends": ["eslint:recommended"],61 "plugins": ["security", "no-unsanitized"],62 "rules": {63 "security/detect-object-injection": "warn",64 "security/detect-non-literal-regexp": "warn",65 "security/detect-unsafe-regex": "error",66 "security/detect-buffer-noassert": "error",67 "security/detect-eval-with-expression": "error",68 "security/detect-no-csrf-before-method-override": "error",69 "security/detect-possible-timing-attacks": "warn",70 "no-unsanitized/method": "error",71 "no-unsanitized/property": "error"72 }73}74```7576## ステージ2: Pre-commit Hooks7778第二の防衛線です。すべてのcommitの前に自動実行され、危険なコードがリポジトリに入るのを防ぎます。7980### Gitleaks: Secretがgitに入る前にキャッチ8182コードベースで最も一般的なセキュリティミスは、secretのcommitです - APIキー、データベースパスワード、トークンなど。一度secretがgit履歴に入ると、完全に削除するのは非常に困難です(force pushしても、forkやキャッシュに残る可能性があります)。8384```yaml85# .pre-commit-config.yaml86repos:87 - repo: https://github.com/gitleaks/gitleaks88 rev: v8.21.089 hooks:90 - id: gitleaks9192 - repo: https://github.com/semgrep/semgrep93 rev: v1.90.094 hooks:95 - id: semgrep96 args: ['--config', 'auto']97```9899インストールと有効化:100101```bash102pip install pre-commit103pre-commit install104```105106これで`git commit`するたびに、漏洩したsecretと一般的な脆弱性が自動的にスキャンされます。何か見つかった場合、commitはブロックされます。107108### カスタムGitleaksルール109110組織固有のsecretに対するカスタムパターンを追加できます。111112```toml113# .gitleaks.toml114title = "Custom Gitleaks Config"115116[[rules]]117id = "internal-api-key"118description = "Internal API key detected"119regex = '''INTERNAL_KEY_[A-Za-z0-9]{32}'''120tags = ["key", "internal"]121```122123## ステージ3: CI/CDパイプラインセキュリティ124125ここが本格的な作業の場です。CIパイプラインは、すべてのpull requestに対して複数のセキュリティスキャンを実行すべきです。126127### SAST (Static Application Security Testing)128129SASTツールはソースコードを実行せずに解析し、脆弱性を示すパターンを探します。130131```yaml132# .github/workflows/security.yml133name: Security Scan134on:135 pull_request:136 branches: [main]137138jobs:139 sast:140 name: Static Analysis141 runs-on: ubuntu-latest142 steps:143 - uses: actions/checkout@v4144145 - name: Run Semgrep146 uses: semgrep/semgrep-action@v1147 with:148 config: >-149 p/owasp-top-ten150 p/typescript151 p/nodejs152 p/react153 generateSarif: true154155 - name: Upload SARIF156 uses: github/codeql-action/upload-sarif@v3157 with:158 sarif_file: semgrep.sarif159```160161Semgrepの`p/owasp-top-ten`ルールセットは、最も一般的な脆弱性を検出します: SQL injection、XSS、SSRF、path traversal、insecure deserializationなど。162163### SCA (Software Composition Analysis)164165SCAは依存関係の既知の脆弱性をスキャンします。これは非常に重要です - 現代のアプリケーションコードの80%以上はオープンソースの依存関係から来ています。166167```yaml168 dependency-scan:169 name: Dependency Audit170 runs-on: ubuntu-latest171 steps:172 - uses: actions/checkout@v4173174 - name: Run Snyk175 uses: snyk/actions/node@master176 env:177 SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}178 with:179 args: --severity-threshold=high180181 - name: npm audit182 run: npm audit --audit-level=high183```184185### Trivyによるコンテナセキュリティ186187Dockerイメージをビルドする場合、脆弱性のスキャンは不可欠です。**Trivy**は最も人気のあるオープンソースコンテナスキャナーです。188189```yaml190 container-scan:191 name: Container Security192 runs-on: ubuntu-latest193 steps:194 - uses: actions/checkout@v4195196 - name: Build image197 run: docker build -t my-app:${{ github.sha }} .198199 - name: Run Trivy200 uses: aquasecurity/trivy-action@master201 with:202 image-ref: my-app:${{ github.sha }}203 format: 'sarif'204 output: 'trivy-results.sarif'205 severity: 'CRITICAL,HIGH'206 exit-code: '1'207208 - name: Upload Trivy SARIF209 uses: github/codeql-action/upload-sarif@v3210 with:211 sarif_file: trivy-results.sarif212```213214### SBOM生成215216**Software Bill of Materials (SBOM)** は、アプリケーション内のすべてのコンポーネントの完全な目録です。コンプライアンスフレームワークや政府規制によってますます要求されるようになっています(米国のサイバーセキュリティに関する大統領令は、連邦ソフトウェアにSBOMを義務付けています)。217218```yaml219 sbom:220 name: Generate SBOM221 runs-on: ubuntu-latest222 steps:223 - uses: actions/checkout@v4224225 - name: Generate SBOM with Syft226 uses: anchore/sbom-action@v0227 with:228 format: spdx-json229 output-file: sbom.spdx.json230231 - name: Upload SBOM232 uses: actions/upload-artifact@v4233 with:234 name: sbom235 path: sbom.spdx.json236```237238## ステージ4: セキュアなDockerイメージ239240本番用のDockerイメージは最小権限の原則に従うべきです。強化されたDockerfileの例を示します。241242```dockerfile243# Build stage244FROM node:22-alpine AS builder245WORKDIR /app246COPY package.json package-lock.json ./247RUN npm ci248COPY . .249RUN npm run build250251# Production stage252FROM node:22-alpine AS runner253WORKDIR /app254255# Install dumb-init before dropping root256RUN apk add --no-cache dumb-init257258# Don't run as root259RUN addgroup -S app && adduser -S app -G app260261# Copy only what's needed262COPY --from=builder --chown=app:app /app/dist ./dist263COPY --from=builder --chown=app:app /app/node_modules ./node_modules264COPY --from=builder --chown=app:app /app/package.json ./265266# Drop to non-root user267USER app268ENTRYPOINT ["dumb-init", "--"]269270# Health check271HEALTHCHECK --interval=30s --timeout=3s --retries=3 \272 CMD wget -qO- http://localhost:3000/health || exit 1273274EXPOSE 3000275CMD ["node", "dist/server.js"]276```277278主要なプラクティス:2792801. **マルチステージビルドを使用**: builderステージには開発依存関係、runnerステージには本番コードのみ2812. **rootで実行しない**: 非rootユーザーを作成して切り替え2823. **Alpineイメージを使用**: 攻撃対象領域が小さい(デフォルトでインストールされるパッケージが少ない)2834. **イメージバージョンを固定**: サプライチェーン攻撃を避けるため、`node:latest`ではなく`node:22-alpine`を使用2845. **`npm ci`を使用**: lockファイルからの決定論的インストール、`npm install`ではなく285286## ステージ5: Secret管理287288ハードコードされたsecretは、開発者起因のインシデントにおける侵害の最大の原因です。289290### やってはいけないこと291292```typescript293// NEVER do this294const API_KEY = "sk-1234567890abcdef";295const DB_PASSWORD = "supersecret123";296297const client = new Client({298 connectionString: `postgres://admin:${DB_PASSWORD}@db.example.com/prod`299});300```301302### 代わりにやるべきこと303304```typescript305// Use environment variables306const client = new Client({307 connectionString: process.env.DATABASE_URL308});309310// Or use a secret manager311import { SecretManagerServiceClient } from '@google-cloud/secret-manager';312313const client = new SecretManagerServiceClient();314const [version] = await client.accessSecretVersion({315 name: 'projects/my-project/secrets/db-password/versions/latest',316});317const dbPassword = version.payload?.data?.toString();318```319320### Secret管理の階層321322```mermaid323graph TD324 A[Secret Manager\nAWS Secrets Manager\nGCP Secret Manager\nHashiCorp Vault] --> B[Best: Rotated, audited, centralized]325 C[Environment Variables\nInjected at deploy time] --> D[Good: Not in code, but static]326 E[.env files\nWith .gitignore] --> F[Acceptable: Local development only]327 G[Hard-coded in source] --> H[NEVER: Instant breach risk]328329 style A fill:#d4edda330 style C fill:#fff3cd331 style E fill:#ffeeba332 style G fill:#f8d7da333```334335## OWASP Top 10: クイックリファレンス336337すべての開発者がOWASP Top 10を知っておくべきです。要約版:338339| # | 脆弱性 | 概要 | 対策 |340|---|--------------|-----------|------------|341| 1 | **Broken Access Control** | ユーザーがアクセスすべきでないリソースにアクセスする | デフォルトで拒否、サーバー側で検証 |342| 2 | **Cryptographic Failures** | 弱い暗号化、平文データ | 強力なアルゴリズム(AES-256、bcrypt)を使用、TLSをあらゆる場所で |343| 3 | **Injection** | SQL、NoSQL、OSコマンドインジェクション | パラメータ化クエリ、入力検証 |344| 4 | **Insecure Design** | 欠陥のあるアーキテクチャ | 脅威モデリング、セキュアデザインパターン |345| 5 | **Security Misconfiguration** | デフォルト認証情報、公開されたクラウドバケット | 強化されたデフォルト、自動化された設定監査 |346| 6 | **Vulnerable Components** | 依存関係の既知のCVE | SCAスキャン、定期的な更新 |347| 7 | **Auth Failures** | 弱いパスワード、壊れたセッション | MFA、レート制限、セキュアなセッション管理 |348| 8 | **Data Integrity Failures** | 未署名の更新、信頼できないCI/CD | コード署名、SBOM、パイプライン整合性 |349| 9 | **Logging Failures** | 監査証跡がない | 構造化ログ、異常に対するアラート |350| 10 | **SSRF** | Server-side request forgery | 送信先URLのallowlist、入力検証 |351352## 完全なGitHub Actionsセキュリティワークフロー353354上記すべてを組み合わせた、本番対応のワークフロー:355356```yaml357# .github/workflows/security.yml358name: Security Pipeline359on:360 pull_request:361 branches: [main]362 push:363 branches: [main]364365permissions:366 contents: read367 security-events: write368369jobs:370 secrets-scan:371 name: Secret Detection372 runs-on: ubuntu-latest373 steps:374 - uses: actions/checkout@v4375 with:376 fetch-depth: 0377 - uses: gitleaks/gitleaks-action@v2378 env:379 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}380381 sast:382 name: Static Analysis (SAST)383 runs-on: ubuntu-latest384 steps:385 - uses: actions/checkout@v4386 - uses: semgrep/semgrep-action@v1387 with:388 config: p/owasp-top-ten p/typescript p/nodejs389390 dependency-audit:391 name: Dependency Scan (SCA)392 runs-on: ubuntu-latest393 steps:394 - uses: actions/checkout@v4395 - uses: actions/setup-node@v4396 with:397 node-version: 22398 - run: npm ci399 - run: npm audit --audit-level=high400 - uses: snyk/actions/node@master401 env:402 SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}403 with:404 args: --severity-threshold=high405 continue-on-error: true406407 container-scan:408 name: Container Scan409 runs-on: ubuntu-latest410 needs: [sast, dependency-audit]411 steps:412 - uses: actions/checkout@v4413 - run: docker build -t app:${{ github.sha }} .414 - uses: aquasecurity/trivy-action@master415 with:416 image-ref: app:${{ github.sha }}417 severity: CRITICAL,HIGH418 exit-code: '1'419420 sbom:421 name: SBOM Generation422 runs-on: ubuntu-latest423 needs: [container-scan]424 steps:425 - uses: actions/checkout@v4426 - uses: anchore/sbom-action@v0427 with:428 format: spdx-json429 output-file: sbom.spdx.json430```431432```mermaid433graph TD434 PR[Pull Request] --> S1[Secret Detection]435 PR --> S2[SAST - Semgrep]436 PR --> S3[SCA - Snyk + npm audit]437 S2 --> S4[Container Scan - Trivy]438 S3 --> S4439 S4 --> S5[SBOM Generation]440 S5 --> Deploy[Deploy]441442 S1 -.- F1[Block if secrets found]443 S2 -.- F2[Block on critical vulns]444 S3 -.- F3[Block on high severity]445 S4 -.- F4[Block on critical CVEs]446```447448## 追跡すべきメトリクス449450DevSecOpsプログラムが機能しているかどうかをどう判断するか?以下のメトリクスを追跡しましょう。451452- **平均修復時間 (MTTR)**: 検出後の脆弱性修正速度453- **脆弱性エスケープ率**: 本番環境に到達した脆弱性の割合454- **False positive率**: false positiveが多すぎるとアラート疲れと警告の無視につながる455- **依存関係の鮮度**: 依存関係の平均経過年数(古いほど既知のCVEが存在する可能性が高い)456- **SBOMカバレッジ**: 最新のSBOMを持つプロジェクトの割合457458## 始め方: 実践的なロードマップ459460すべてを一度に導入しようとしないでください。段階的なアプローチが効果的です。461462```mermaid463flowchart TD464 A[Week 1-2: Foundations] --> B[Week 3-4: CI/CD Integration]465 B --> C[Month 2: Container Security]466 C --> D[Month 3+: Advanced]467468 A --> A1[Add Gitleaks pre-commit hooks]469 A --> A2[Enable npm audit in CI]470 A --> A3[Add .gitignore for .env files]471472 B --> B1[Add Semgrep to GitHub Actions]473 B --> B2[Add Snyk dependency scanning]474 B --> B3[Set up SARIF upload to GitHub]475476 C --> C1[Add Trivy container scanning]477 C --> C2[Harden Dockerfiles]478 C --> C3[Generate SBOMs]479480 D --> D1[Secret manager integration]481 D --> D2[Runtime protection - DAST]482 D --> D3[Policy as code - OPA]483```484485## まとめ486487DevSecOpsは、パイプラインにツールを追加することではありません - セキュリティをソフトウェア構築の自然な一部にすることです。目標は、すべてのPRをセキュリティ警告でブロックすることではなく、コードがまだ頭の中に新鮮なうちに問題を修正できるよう、開発者に迅速なフィードバックを提供することです。488489基本から始めましょう: secretのためのpre-commit hooks、CIでの依存関係スキャン、Dockerイメージのコンテナスキャン。そしてチームの必要に応じて反復改善していきましょう。490491セキュリティは一度だけリリースする機能ではありません。すべてのcommitに組み込む実践です。492493> **DevSecOpsスターターチェックリスト:**494>495> - [x] Gitleaks pre-commit hooksのインストール496> - [x] .envとsecretファイルを.gitignoreに追加497> - [x] CIパイプラインにSemgrep SASTを導入498> - [x] Snykまたはnpm auditによる依存関係スキャン499> - [x] Trivyによるコンテナイメージスキャン500> - [x] Dockerfileで非rootユーザーを使用501> - [x] 環境変数またはsecret managerにsecretを保管502> - [x] リリースごとのSBOM生成503> - [x] チーム全体でのOWASP Top 10の理解504
:開発者のためのDevSecOps: Shift-Leftセキュリティ実践ガイドlines 1-504 (END) — press q to close