security-devsecops

セキュリティ／DevSecOps

このスキルでは、安全なソフトウェア開発ライフサイクル（SSDLC）に必要なセキュアコーディングの実践、依存関係とシークレットの管理、認証と認可、セキュリティツールについて、日々のコーディング習慣から CI/CD のゲート、運用環境のモニタリングまで取り上げます。

新機能を安全に追加するワークフロー

1. 信頼境界を特定する — 新しいコードがユーザー、別のサービス、ファイルから入力を受け取るすべての箇所と、出力（HTML、ログ、別のサービス）を送るすべての箇所を記録します。
2. 境界で検証とサニタイズを行う — 信頼できない入力はすべて受け取る時点で検証し、出力は出力先のコンテキスト（HTML、JS、SQL、シェル）に合わせてエスケープします。
3. 既存のセキュリティ機能を使う — 新たに作成するのではなく、プロジェクトで確立されている認証フレームワーク、ORM、シークレット管理の方法を利用します。
4. シークレットをコードやログに含めない — 認証情報は環境変数またはシークレット保管庫から読み込み、機密情報がログやエラーメッセージに含まれないことを確認します。
5. プッシュ前にローカルでセキュリティチェックを実行する — 利用可能であれば、リンター、SAST、シークレットスキャンツール（gitleaks、semgrep、npm audit、pip-audit など）を実行します。
6. CI ゲートを実行させる — SAST、SCA、シークレットスキャン、IaC スキャンはすべての PR で実行する必要があります。失敗は抑制を提案するものではなく、ブロッカーとして扱います。
7. セキュリティに関わる判断を記録する — 後で監査できるよう、認証／認可の変更、新しい依存関係、デフォルトで安全なパターンからの逸脱について、PR の説明に記載します。

セキュリティの基本原則

• シークレット、認証情報、API キーをソースコードにハードコードしないでください。機密データには環境変数または安全な保管庫（AWS Secrets Manager、HashiCorp Vault、Doppler など）を使用します。
• .env ファイル、シークレットを含む設定ファイル、正体の分からないトークンをソース管理にコミットしないでください。ステージングする前に .gitignore に追加します。
• アプリケーションログに機密データ、シークレット、セッショントークンを記録しないでください。後からではなく、ログを記録する時点でマスキングするか除外します。
• ユーザー入力はすべてシステムに入る時点で検証し、サニタイズします。出力はコンテキストに応じて適切にエスケープします。HTML には HTML エンコード、インラインスクリプトには JS エンコード、SQL にはプレースホルダーを使用します。
• exec、eval、Function()、信頼できないデータに対する pickle.loads、ユーザー入力のシェルへの埋め込みなど、安全でない動的実行関数を避けます。

# Unsafe — string interpolation into a query
query = f"SELECT * FROM users WHERE email = '{email}'"
cursor.execute(query)

# Safe — parameterized query
cursor.execute("SELECT * FROM users WHERE email = %s", (email,))

シークレットの取り扱い

• シークレットは環境変数（process.env.API_KEY、os.environ["API_KEY"]）または保管庫クライアントから読み込み、リテラルとして記述しないでください。
• バージョン管理に一度でもコミットされた認証情報は、後からコミットを削除した場合でもローテーションしてください。履歴には残っています。
• マージ前に、gitleaks、trufflehog、CI プロバイダー組み込みのシークレットスキャンなどのツールを使い、誤ってコミットされたシークレットがないかスキャンします。
• 認証情報の権限は必要最小限にします。CI のデプロイキーにはデプロイのみを許可し、クラウドアカウント全体の管理権限を与えないでください。

データベースのセキュリティ

• すべてのデータベースアクセスに、パラメーター化クエリまたは ORM を使用します。ユーザー入力を含む文字列連結や f 文字列でクエリを構築しないでください。
• データベースユーザーには、各役割に必要な最小限の権限を付与します（レポートサービスに DROP TABLE の権限を与えてはいけません）。
• チームのメンバーやサービスの責任範囲の変化に合わせて、データベースのアクセス方針を定期的に見直し、更新します。

依存関係の管理

• 検証済みの信頼できる提供元からのみパッケージを追加します。新しい依存関係を追加する前に、ダウンロード数、メンテナンス状況、既知の CVE の履歴を確認します。
• 新しい依存関係は、明示的な承認と簡単なセキュリティレビューなしに追加しないでください。特に、昇格された権限で実行するパッケージや、信頼できない入力を処理するパッケージでは徹底します。
• 依存関係を定期的に更新し、npm audit、pip-audit、Dependabot、Snyk、Trivy などのソフトウェア構成分析（SCA）ツールを使って既知の脆弱性をスキャンします。

# Node.js
npm audit --audit-level=high

# Python
pip-audit

# Container image
trivy image myapp:latest

認証と認可

• 実績があり、監査済みの認証フレームワーク（Auth0、Passport、Devise、ASP.NET Identity など）を使用してください。カスタムの暗号認証をゼロから実装してはいけません。
• パスワードは、ソルト付きの強力な適応型ハッシュで保存してください。Argon2id または bcrypt を使用し、MD5、SHA1、ソルトなしの SHA256 は使用しないでください。
• 機密性の高い操作には、ロールベースアクセス制御（RBAC）、またはより細かな制御が必要な場合は属性ベースアクセス制御を実装してください。
• API エンドポイントと UI 操作の両方で最小権限の原則を徹底してください。すべてのリクエストでサーバー側の認可を確認し、非表示の UI 要素をアクセス制御として信頼してはいけません。
• 以前に許可された操作であっても、すべてのリクエストで認可を再確認してください。セッションの状態やロールは、セッション中に変更される可能性があります。

// Missing authorization check — any authenticated user can access any order
app.get("/orders/:id", requireAuth, async (req, res) => {
  const order = await Order.findById(req.params.id);
  res.json(order);
});

// Correct — verify the resource belongs to the requester
app.get("/orders/:id", requireAuth, async (req, res) => {
  const order = await Order.findById(req.params.id);
  if (!order || order.userId !== req.user.id) {
    return res.status(404).end();
  }
  res.json(order);
});

セキュア SDLC の実践

リリース前に手動で確認するチェックリストではなく、これらを CI/CD パイプラインに組み込んでください。

• SAST（静的アプリケーションセキュリティテスト） — PR ごとにソースコードをスキャンし、既知の危険なパターンを検出します（Semgrep、CodeQL、SonarQube など）。
• SCA（ソフトウェア構成分析） — 依存関係をスキャンし、既知の脆弱性やライセンス上の問題を検出します（Snyk、Dependabot、OWASP Dependency-Check など）。
• シークレットスキャン — マージ前に、誤ってコミットされた認証情報がないか、すべてのコミットと PR の差分をスキャンします（Gitleaks、GitHub secret scanning、TruffleHog など）。
• IaC スキャン — Terraform／CloudFormation／Kubernetes のマニフェストをスキャンし、適用前に設定ミスを検出します（Checkov、tfsec、Trivy config scan など）。
• DAST（動的アプリケーションセキュリティテスト） — CD パイプラインで、デプロイ済みアプリケーションの実行インスタンスをスキャンし、悪用可能な動作を検出します（OWASP ZAP、Burp Suite など）。
• Policy as Code（PaC） — セキュリティポリシーとコンプライアンスポリシーを、バージョン管理され、自動的に適用されるルールとして記述します（OPA/Rego、Sentinel など）。誰も読み返さない文書のままにしないでください。

監視とフィードバック

• 依存関係と稼働中のインフラストラクチャの両方について、継続的な脆弱性監視とアラートを有効にしてください。
• デプロイ先とトラフィックの特性に応じて、ランタイムアプリケーション自己保護（RASP）と Web アプリケーションファイアウォール（WAF）を導入してください。
• 大規模リリース前の一度きりの監査だけでなく、定期的な脆弱性評価と侵入テストを実施してください。
• フィードバックループを維持してください。本番環境や侵入テストで繰り返し見つかる脆弱性の種類に応じて、リンティングルール、SAST ポリシー、コードレビューチェックリストを更新してください。一度パッチを適用するだけで終わらせてはいけません。

コンプライアンスとドキュメント

• プロジェクトの規制要件に応じて、OWASP Top 10、OWASP ASVS、NIST SSDF、ISO 27001 など、業界で認知された標準に管理策を適合させてください。
• セキュリティ管理策や判断を行う際に、その内容を文書化してください（脅威モデルに関するメモ、例外を認めた理由、既知のリスクを補う代替管理策など）。そうすることで、監査時に記憶を頼りに再構築するのではなく、後から判断の根拠を監査できます。

注意すべき一般的な脆弱性の種類

種類	注意点
インジェクション（SQL／NoSQL／コマンド）	ユーザー入力を含む文字列連結で構築されたクエリやシェルコマンド
アクセス制御の不備	リクエストごとの認可チェックがない、予測可能な ID による IDOR
暗号化の失敗	弱いハッシュ、ハードコードされたキー、TLS の欠如、独自の暗号処理
安全でないデシリアライゼーション	pickle、実行コンテキストへの未検証の JSON.parse、安全でない YAML ローダー
セキュリティ設定の不備	デフォルトの認証情報、本番環境での詳細なエラーページ、過度に許可的な CORS
脆弱な依存関係	既知の CVE がある古いパッケージ、バージョンが固定されていない依存関係
ログ記録の不足	認証イベントの監査証跡がない、機密データが平文で記録される