ソフトウェアセキュリティの全体地図 — OWASP・NIST・SLSA で読み解く2026年のフレームワーク群

なぜフレームワークを学ぶのか

「セキュリティ大事ですよね」と誰もが言うけれど、実際に何から手を付けるかとなると 途端に曖昧になります。脆弱性スキャナを入れるのか、ペネトレーションテストを依頼するのか、 IaC を Terraform Compliance で固めるのか——いずれも正解ですが、 個別施策の積み重ねは「網羅性」を保証しません。

そこで登場するのが各種セキュリティフレームワークです。 OWASP・NIST・ISO・CIS など、長年の集合知が「最低限ここは押さえよう」というチェックリストや 実装指針として体系化されています。フレームワークは銀の弾丸ではありませんが、 抜け漏れを潰すための「地図」として機能します。

この記事では2026年時点で押さえておくべき主要フレームワークを4層に整理し、 それぞれの守備範囲と実装ポイントを解説します。 「自社で何を導入すべきか」を考える時の判断材料になれば嬉しいです。

セキュリティフレームワークの全体地図

まず混乱を防ぐために、主要フレームワークがどのレイヤーをカバーしているかを整理します。 「同じセキュリティでも対象が違う」を理解しておくと、各フレームワークの位置づけがスッと入ります。

graph TB
    subgraph L1["組織レベル — 経営・ガバナンス"]
        CSF["NIST CSF 2.0<br/>サイバーセキュリティ全体管理"]
        ISO["ISO/IEC 27001:2022<br/>ISMS認証"]
        CIS["CIS Controls v8<br/>具体的18コントロール"]
    end
    subgraph L2["SDLC レベル — 開発プロセス"]
        SSDF["NIST SSDF v1.1<br/>セキュア開発の実装指針"]
        SAMM["OWASP SAMM 2<br/>成熟度モデル"]
        BSIMM["BSIMM<br/>ベンチマーク"]
    end
    subgraph L3["アプリレベル — 実装・ランタイム"]
        TOP10["OWASP Top 10:2025<br/>主要10リスク"]
        ASVS["OWASP ASVS 5.0<br/>検証要件"]
        LLMTOP10["OWASP Top 10 for LLM<br/>AI固有リスク"]
    end
    subgraph L4["サプライチェーン — 依存関係"]
        SLSA["SLSA v1.1<br/>ビルド整合性の段階モデル"]
        SBOM["SBOM<br/>SPDX / CycloneDX"]
        FRSCA["NIST SP 800-204D<br/>CI/CD保護"]
    end
    L1 --> L2
    L2 --> L3
    L2 --> L4

OWASP Top 10:2025 — アプリケーション開発者の共通言語

OWASP Top 10 は3〜4年ごとに更新される、Webアプリケーションの主要リスク10選です。 2025年11月に Global AppSec DC で Top 10:2025 が正式リリースされ、 175,000件以上のCVEデータと現場のフィードバックを基に再構成されました。

2025年版の10カテゴリ

2025年版の最大の変更点は2つです。 ひとつはサプライチェーン（A03）の独立カテゴリ化。 これまで「Vulnerable and Outdated Components」として依存ライブラリの問題が含まれていましたが、 2025年版では SBOM・ビルドプロセス・CI/CDパイプライン・サードパーティサービスまで含む サプライチェーン全体のリスクとして再定義されました。

もうひとつは「Mishandling of Exceptional Conditions」(A10) の新登場。 例外処理のミスが情報漏洩・認可バイパス・DoSにつながるケースが多発しているため、 独立カテゴリに昇格しました。try/except でエラーを握り潰してしまう実装が 実際には大きなリスクになる、という長年の現場感覚が反映された形です。

NIST CSF 2.0 — 組織レベルのサイバーセキュリティ管理

NIST Cybersecurity Framework (CSF) は米国国立標準技術研究所が公開する、 組織レベルのサイバーセキュリティ管理フレームワークです。 2024年2月にバージョン2.0 が公開され、それまでの5機能（Identify/Protect/Detect/Respond/Recover）に 「Govern（統治）」が追加されて6機能になりました。

graph LR
    G["GOVERN<br/>統治・方針"]
    I["IDENTIFY<br/>資産把握"]
    P["PROTECT<br/>防御"]
    D["DETECT<br/>検知"]
    R["RESPOND<br/>対応"]
    RC["RECOVER<br/>復旧"]
    G -.方針として全体に作用.-> I
    G -.->P
    G -.->D
    G -.->R
    G -.->RC
    I --> P --> D --> R --> RC

CSF 2.0 の特徴は「How」より「What」を定義することです。 「ID.AM-1: 物理デバイスを資産インベントリに登録する」のようなサブカテゴリが108個定義されており、 各組織が自社の状況に合わせて優先度を付け、現状（Current Profile）と目標（Target Profile）の ギャップを可視化する、という使い方をします。

NIST SSDF — SDLC にセキュリティを組み込む実装フレーム

NIST SSDF（Secure Software Development Framework）は SDLC（ソフトウェア開発ライフサイクル）の各段階に組み込むべきセキュリティプラクティスを定義した SP 800-218 という文書です。2026年4月時点の公式版は v1.1（2022年2月公開）。 v1.2 のドラフトが2025年12月17日に公開され、2026年1月30日までパブリックコメントを受け付けていました。 正式版の発行は2026年中見込みです。

SSDF は4つのプラクティスグループと、その配下の合計19のプラクティスで構成されます。

SSDF の真価は、米国の連邦政府向けソフトウェア調達において SSDF 準拠の自己宣言（self-attestation）が義務化されている点にあります（OMB Memo M-22-18 / M-23-16）。 CISA の Secure Software Development Attestation Form を提出する流れで、 実質的に米国政府にソフトウェアを売る場合の業界標準になりました。

SLSA — サプライチェーン保護の段階的成熟度モデル

SLSA（Supply-chain Levels for Software Artifacts、「サルサ」と読む）は Open Source Security Foundation（OpenSSF）がホストする、 ビルドプロセスの整合性を段階的に強化するためのフレームワークです。2026年4月現在 v1.1。

SLSA の特徴は「Provenance（成果物の出自証明）」を中心に据えていることです。 「このバイナリは、このソースから、このビルドシステムで、この時刻に作られた」を 検証可能な形で残し、改ざんを検出できるようにします。

SLSA の良いところは「全部やらなくていい」こと。L1 だけでも 「このバイナリどこから来たんだっけ？」が解決できるので、 まず L1 から始めて、重要な成果物だけ L2/L3 を目指す、という段階的導入ができます。

SBOM — 依存関係を機械可読に

SBOM（Software Bill of Materials、ソフトウェア部品表）は、 製品に含まれる全ての依存ライブラリ・コンポーネントを機械可読な形式で記述したものです。 主流フォーマットは SPDX（Linux Foundation）と CycloneDX（OWASP）の2つ。

2021年5月の米国大統領令Executive Order 14028を契機に、 連邦政府向けソフトウェアにはSBOMの提供が事実上必須となり、 EUのCyber Resilience Act（CRA、2024年成立、2027年12月から本格適用）でも 製造者にSBOM提供義務が課されます。日本でも経済産業省が2023年に 「ソフトウェア管理に向けたSBOM導入の手引」を公開しています。

セキュリティフレームワークの進化

ここまで紹介したフレームワークがどのような経緯で登場してきたかをタイムラインで整理します。 「2020年以降、サプライチェーン関連が一気に整備された」のが見て取れます。

シフトレフト — 開発に組み込む実践

フレームワークを学んでも実装に落ちなければ意味がありません。 ここからは現場で使える実践パターンを紹介します。基本思想はシフトレフト—— 脆弱性を「より早く・より安く・より自動化された場所で」検出する、というものです。

graph LR
    A["IDE<br/>ローカル"] --> B["Pre-commit<br/>Hook"]
    B --> C["Pull Request<br/>CI"]
    C --> D["Pre-deploy<br/>ステージング"]
    D --> E["Production<br/>監視"]
    A:::cheap
    B:::cheap
    C:::medium
    D:::expensive
    E:::expensive
    classDef cheap fill:#10b981,stroke:#047857,color:#fff
    classDef medium fill:#f59e0b,stroke:#b45309,color:#fff
    classDef expensive fill:#ef4444,stroke:#991b1b,color:#fff

右に行くほど修正コストが指数関数的に増加します。 プロダクションで見つかったSQLインジェクションは、IDEで気付いたケースの数百倍コストがかかります。 だからこそ「左側」での自動検出を厚くする、というのがシフトレフトの本質です。

CI/CD でのセキュリティチェック例

以下は GitHub Actions で実装する典型的なセキュリティパイプライン例です。 SAST・依存スキャン・IaCスキャン・SBOM生成・コンテナスキャンを並列実行します。

name: Security Pipeline
on: [pull_request]

jobs:
  sast:
    name: SAST (Static Application Security Testing)
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - name: Run Semgrep
        uses: semgrep/semgrep-action@v1
        with:
          config: >-
            p/owasp-top-ten
            p/cwe-top-25
            p/secrets

  sca:
    name: SCA (Software Composition Analysis)
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - name: Trivy filesystem scan
        uses: aquasecurity/trivy-action@0.30.0
        with:
          scan-type: fs
          severity: CRITICAL,HIGH
          exit-code: '1'

  iac:
    name: IaC Misconfiguration Scan
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - name: Checkov scan
        uses: bridgecrewio/checkov-action@v12
        with:
          framework: terraform,kubernetes,dockerfile

  sbom:
    name: Generate SBOM
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - name: Generate CycloneDX SBOM
        uses: CycloneDX/gh-node-module-generatebom@v3
        with:
          output: sbom.cdx.json
      - uses: actions/upload-artifact@v5
        with:
          name: sbom
          path: sbom.cdx.json

  container:
    name: Container Image Scan
    runs-on: ubuntu-latest
    needs: [sast, sca]
    steps:
      - uses: actions/checkout@v5
      - name: Build image
        run: docker build -t app:${{ github.sha }} .
      - name: Trivy container scan
        uses: aquasecurity/trivy-action@0.30.0
        with:
          image-ref: app:${{ github.sha }}
          severity: CRITICAL,HIGH
          exit-code: '1'

明日から使えるベストプラクティス10選

フレームワークと実装ツールが揃ったところで、最後に 「読んだ次の日から効果が出る」レベルの実践原則を10個に絞ってまとめます。

1. 認可は「拒否デフォルト」で書く

A01:2025 Broken Access Control は不動の1位。 認可ロジックは明示的に許可されたものだけ通す方針で書きます。 「条件にマッチしない時は許可」のロジックは絶対に避け、 if not authorized: return 403 を関数の最初に置きます。

2. シークレットはコードに置かない・環境変数で渡す・スキャンする

GitHub Secret Scanning や gitleaks を CI に組み込み、 万が一の漏洩を即座に検知できるようにします。 本番のシークレットは AWS Secrets Manager / HashiCorp Vault / Vercel Environment Variables などで管理します。

3. 依存ライブラリは Renovate / Dependabot で自動更新

SCA で「脆弱性ありのライブラリ」を検出するだけでなく、 自動でPRを上げる仕組みを入れることで「忘れていた」という事故をゼロにします。 major bump は手動承認、minor/patch は CI 通過で自動マージ、が現実的な設定です。

4. 入力検証は「型」で表現する

TypeScript の Zod、Python の Pydantic、Rust の型システムなど、 「不正な値はそもそも構造化できない」設計にします。 Stringly-typed なままifで弾く方式はバグの温床です。

5. SQL は ORM またはプリペアドステートメント、文字列連結は禁止

A05:2025 Injection の主要因は依然として SQL インジェクションです。 例外なくプリペアドステートメントを使い、文字列連結でクエリを組まないルールを ESLint / linter で強制します。

6. 認証は OIDC / OAuth2 を使い、自前実装しない

Auth0 / Clerk / NextAuth / Supabase Auth など信頼性の高いライブラリ・サービスを使います。 パスワードハッシュは bcrypt / argon2id を使い、SHA-256 などの汎用ハッシュは絶対に使いません。

7. ログに個人情報・シークレットを書かない

ログ収集基盤は意外と多くの人が見られます。 クレジットカード番号・パスワード・APIキー・JWTトークンは ログ出力前にマスクするミドルウェアを入れ、誤って書いた時もリダクションされる体制にします。

8. 例外は「握り潰さない」「内部情報を返さない」

A10:2025 Mishandling of Exceptional Conditions の対策。 例外は必ずログに残し、ユーザーには汎用的なエラーメッセージのみ返します。 スタックトレースをHTTPレスポンスに含めるのは絶対NGです。

9. SBOM を毎ビルドで生成し、CVEと突合する

Dependency-Track のようなツールを内製で運用すると、 「Log4Shell相当の事案が起きた時に自社製品が影響するか」を5分で答えられます。 これは経営報告レベルでも非常に強い武器になります。

10. インシデント対応プレイブックを書いて訓練する

「何かあった時にどう動くか」を文書化し、四半期に一度は机上訓練（テーブルトップ演習）をします。 CSF 2.0 の RESPOND / RECOVER 機能の中核です。 発見・封じ込め・根絶・復旧・教訓化の5ステップで型化しておきます。

補足 — AI/LLM 固有のセキュリティ

2026年現在、LLMアプリケーションが急速に増えており、 従来のWebセキュリティだけでは対応できないAI固有のリスクが顕在化しています。 OWASPは 「OWASP Top 10 for LLM Applications」を独立プロジェクトとして公開しており、 LLMアプリを開発する場合は通常の Top 10 と併読が必須です。

• LLM01: Prompt Injection — ユーザー入力でシステムプロンプトを上書きされる
• LLM02: Sensitive Information Disclosure — モデルが学習データの個人情報を漏洩
• LLM03: Supply Chain — 改ざんされたモデル・データセットの利用
• LLM06: Excessive Agency — エージェントに過剰な権限を持たせる
• LLM08: Vector and Embedding Weaknesses — RAGのベクトルDBに対する攻撃

まとめ — 「地図」を持って一歩ずつ進む

セキュリティフレームワークの森は広大ですが、 4つのレイヤーに整理すれば見通しがよくなります。

• 組織レベル: NIST CSF 2.0 / ISO 27001 / CIS Controls — 経営・統治の枠組み
• SDLCレベル: NIST SSDF / OWASP SAMM — 開発プロセスへの組み込み
• アプリレベル: OWASP Top 10:2025 / ASVS / LLM Top 10 — 実装上のリスク
• サプライチェーン: SLSA / SBOM — ビルド・配布の整合性

そして実装の指針はシンプルです:

• シフトレフト: 早い段階で自動検出する仕組みを CI に組み込む
• 段階的導入: SLSA L1 → L2 → L3 のように、現実的なステップで成熟度を上げる
• 拒否デフォルト: 認可・例外処理・入力検証は明示的な許可だけ通す
• 機械可読化: SBOM・Provenance を残し、後から検証・追跡可能にする
• AI固有リスクへの追加対応: LLMを使うなら OWASP Top 10 for LLM を併読

全部を一気に整備しようとすると確実に挫折します。 まずは「OWASP Top 10:2025 を読む」「Secret スキャンを CI に入れる」「SBOM を出力する」 の3つから始めれば、組織のセキュリティ成熟度は確実に1段上がります。 フレームワークは目的ではなく地図——使いこなして自社の現在地と次の一歩を見極めましょう。