会社情報
採用情報
お問い合わせ
Article

セキュリティ強化事例：脆弱性診断と対策で情報漏洩リスクを低減

高田晃太郎
セキュリティ強化事例：脆弱性診断と対策で情報漏洩リスクを低減

IBMのCost of a Data Breach 2024では、1件あたりの平均損失が約4.88百万ドルと報告¹され、検出から封じ込めまでの期間も依然として200日超という長さが指摘されています²。VerizonのDBIRでも人の関与が多い攻撃が目立ち³、設定ミスや既知の欠陥の放置が被害の広がりを加速させています⁴。複数の公開データを突き合わせると、コード、依存関係、インフラ、そして運用という4層で同時進行の対策を取るのが現実的な落としどころだと考えられます。鍵になるのは、セキュリティの検査を“点検イベント”ではなく“開発フロー”に組み込む設計です⁵。ここでは実装に踏み込み、具体的な測定指標と修正のオペレーションまで一気通貫で示します。

識別から日常運用へ：点から線へ、線から面へ

単発のスキャンで終えると、検出の瞬間だけ強くても修正の動線が切れがちです。多くの調査で、発見から修正までの時間（MTTR）を短縮できた組織ほど再発率が低い傾向が指摘されています⁹。そこで、静的解析（SAST：ソースコードを静的に解析）、動的解析（DAST：実行中のアプリを外部から検査）、依存関係解析（SCA：OSSやライブラリの既知不具合を照合）、構成・IaCスキャン（Infrastructure as Codeの設定検査）を、リリースの都度ではなくコミットや夜間の定期診断、主要ブランチのマージ前といった時間軸で重ねます。狙いは“早い段階で広く粗く検知し”“遅い段階で深く確実に塞ぐ”という二層化にあります⁵¹⁰。必要に応じてIAST（実行中のアプリ内部での動的解析）の併用も、検出精度や再現性の面で有効です⁶。初期段階のSASTやSCAは誤検知をある程度許容して開発者への迅速なフィードバックを優先し、後段のDASTやE2Eセキュリティテストはテスト環境で精度重視の実行に回します。

参考モデルの試算では、PRレビュー後に月次の外部診断のみを実施していたケースで、CVSS 7.0以上（CVSS：脆弱性の深刻度指標）の修正に数週間を要する傾向が見られました。フロー内に検査を編み込むと、検出の位置が左側（設計・実装段階）へ移り、MTTRが大きく短縮される可能性があります⁹。ここでの数値はあくまでモデルに基づく推定であり、個々の組織の状況により変動します。

カバレッジ定義と閾値設計

何をどこまで検査するかは、資産棚卸しとデータフローの可視化から始めます。外部公開API、管理コンソール、支払いフローの3領域を最優先として、機密データに触れる箇所ほどスキャン頻度と精度を引き上げます。閾値はCVSSだけに依存せず、露出面（インターネット面か内部面か）と回避策の有無でリスクスコアを補正し、ブロッキング条件は「重大×外部露出×回避策なし」を満たすものに限定します。これにより、リリース阻害の過剰反応を防ぎつつ、止めるべきところは確実に止められます⁵。

スキャンのタイミングと実行コスト

PR作成時にSAST/SCAを即時実行し、一般的には数分程度で完了する設計にします。メインブランチへのマージ前にIaCスキャンを追加し、ステージング環境で夜間にDASTを実施します。DASTはフルスキャンを毎回行うと遅延の主因になるため、差分クローリング（前回との差分のみ探索）とハイリスクエリアのシナリオ優先で、網羅率と速度のトレードオフを最適化します。こうした左シフト運用（開発の早期段階に品質活動を寄せる）やプレコミット〜デプロイ前の自動化は、DORA系KPI（ソフトウェア配信の代表指標。とくにMTTR）の改善にも寄与します¹⁰⁹。

実装例：CI/CDにセキュリティを埋め込む

以下はGitHub Actionsを用いた最小構成の例です。PRイベントでSASTとSCA、メインブランチでIaCスキャン、夜間にDASTを走らせる流れを示します。実運用では並列化やキャッシュを活用し、実行時間のブレを抑制します⁵¹⁰。

name: security-pipeline
on:
  pull_request:
  push:
    branches: [ main ]
  schedule:
    - cron: '0 18 * * *'
jobs:
  sast_sca:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20' }
      - name: Install deps
        run: npm ci
      - name: Run Semgrep (SAST)
        run: |
          pipx install semgrep
          semgrep ci --sarif --config p/ci
      - name: Run Trivy (SCA)
        uses: aquasecurity/trivy-action@0.20.0
        with:
          scan-type: 'fs'
          format: 'sarif'
          severity: 'HIGH,CRITICAL'
  iac_scan:
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: tfsec (IaC)
        uses: aquasecurity/tfsec-action@v1.0.3
  dast:
    if: github.event_name == 'schedule'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: OWASP ZAP Baseline
        uses: zaproxy/action-baseline@v0.13.0
        with:
          target: 'https://staging.example.com'
          cmd_options: '-a -m 5'

アプリ側の防御も平行して進めます。Expressでのヘッダー強化は導入効果が早く、クロスサイトスクリプティング（XSS）のリスクを下げます。以下はHelmetの設定例です⁷。

import express, { Request, Response, NextFunction } from 'express';
import helmet from 'helmet';
import crypto from 'crypto';

const app = express();

app.use(helmet());
app.use((req: Request, res: Response, next: NextFunction) => {
  const nonce = crypto.randomBytes(16).toString('base64');
  res.locals.nonce = nonce;
  res.setHeader('Content-Security-Policy', `default-src 'self'; script-src 'self' 'nonce-${nonce}'; object-src 'none'; frame-ancestors 'none'; base-uri 'self'`);
  next();
});

app.get('/healthz', (_req: Request, res: Response) => {
  try {
    res.status(200).json({ ok: true });
  } catch (e) {
    res.status(500).json({ ok: false });
  }
});

app.use((err: Error, _req: Request, res: Response, _next: NextFunction) => {
  res.status(500).json({ error: 'internal_error' });
});

app.listen(3000);

リバースプロキシでは、レート制限（一定時間当たりのリクエスト数制御）とサイズ制限が現実的な防波堤になります。Nginxでの設定例を示します。

server {
  listen 443 ssl;
  server_name api.example.com;

  client_max_body_size 2m;
  limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

  location / {
    limit_req zone=api_limit burst=20 nodelay;
    add_header X-Content-Type-Options nosniff always;
    add_header X-Frame-Options DENY always;
    proxy_pass http://app:3000;
  }
}

GraphQLや高負荷APIでは、クエリの複雑度と並列数の制御が不可欠です。Node.jsでの簡易的な複雑度チェックの例です⁸。

import { createYoga, createSchema } from 'graphql-yoga';
import { getComplexity, simpleEstimator } from 'graphql-query-complexity';
import type { Plugin } from 'graphql-yoga';

const complexityPlugin = (): Plugin => ({
  onExecute({ args }) {
    const complexity = getComplexity({
      schema: args.schema,
      operationName: args.operationName,
      query: args.document,
      variables: args.variableValues,
      estimators: [simpleEstimator({ defaultComplexity: 1 })],
    });
    if (complexity > 1000) {
      throw new Error('query too complex');
    }
  },
});

const schema = createSchema({ typeDefs: 'type Query { hello: String }', resolvers: { Query: { hello: () => 'world' } } });
export const yoga = createYoga({ schema, plugins: [complexityPlugin()] });

IaCのガードレールはビルド時に効く形で置きます。OPA Rego（ポリシー言語）によるS3の公開禁止ルールの例です。

package iac.security

default allow = false

allow {
  input.resource.type == "aws_s3_bucket"
  not input.resource.acl == "public-read"
  not input.resource.policy.public == true
}

最後に、バックエンドのタイムアウトとコンテキスト管理はDoS軽減に有効です。GoのHTTPサーバでの堅牢化例です¹¹。

package main

import (
    "context"
    "log"
    "net/http"
    "time"
)

func main() {
    srv := &http.Server{
        Addr:              ":8080",
        ReadTimeout:       3 * time.Second,
        ReadHeaderTimeout: 2 * time.Second,
        WriteTimeout:      5 * time.Second,
        IdleTimeout:       60 * time.Second,
        Handler:           http.HandlerFunc(handler),
    }

    go func() {
        if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed {
            log.Fatalf("server error: %v", err)
        }
    }()

    stop := make(chan struct{})
    <-stop

    ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
    defer cancel()
    if err := srv.Shutdown(ctx); err != nil {
        log.Printf("graceful shutdown failed: %v", err)
    }
}

func handler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("X-Content-Type-Options", "nosniff")
    w.WriteHeader(http.StatusOK)
    _, _ = w.Write([]byte("ok"))
}

発見から修正へ：MTTR短縮の運用デザイン

運用の肝はアサインと優先度付けです。検知結果はリポジトリ単位のセキュリティボードに自動集約し、ラベルで重大度、露出面、影響機能を付与します。開発のスプリント計画にセキュリティのベロシティ枠を常設し、例えばスプリントポイントの一定割合を修正キューに割り当てると、目先の機能開発に押し出される事態を避けられます。重大度の高い修正はセキュリティレビューと単体テストの追加、回帰テストの最低限シナリオ実行までを定型化し、レビュー工数を圧縮しやすくなります。左シフトと自動化の徹底は、MTTRの短縮などDORA系メトリクスの改善に直結します⁹¹⁰。

誤検知の扱いも生産性に直結します。根拠を添えた抑制コメントと期限付きの例外運用を導入し、恒久対応が完了しない例外はスプリントに自動で再浮上させます。これにより、除外が恒久化して潜在リスクが積み上がるのを防ぎます。夜間DASTの結果は翌朝のスタンドアップで短時間だけ触れるルールを設け、影響大のものは即座にイシュー化、影響小のものは週次で束ねて対応する二段構えにします。

ユーザー影響を伴う修正には段階的リリースとモニタリングが欠かせません。フィーチャーフラグを用い、影響範囲を最小限のテナントまたはトラフィックの一部から始め、エラー率、レイテンシ、例外ログ、セキュリティ関連イベントのメトリクスを監視します。例えばCSP（Content Security Policy）導入時には、初期のブロック率を観測しつつ許可リストを調整することで、業務影響を抑えながら堅牢化を進められます。パフォーマンスへの影響も、P95レイテンシへの影響が小さい範囲で運用するのが現実的です。

効果測定とROI：リスクをビジネス言語に翻訳する

技術施策を経営に伝えるには、リスクの金額換算が有効です。年次期待損失（ALE）を、侵害確率と影響額の積で見積もります。試算例として、導入前の侵害確率を12%、想定影響額を150万ドルとすると、ALEは18万ドルです。対策後に既知の欠陥の滞留が半減し、公開面の脆弱なエンドポイント数も減少したと仮定すると、侵害確率を5%に下げ、ALEは7.5万ドルとなります。差分10.5万ドルが年次のリスク削減効果で、施策コスト（ツールと運用の増分）を年6.8万ドルとすれば、純便益3.7万ドル、単年度ROIは約54%というイメージです。前提値により振れ幅は出ますが、投資判断は業界の動向（侵害コストの増加と封じ込めリードタイムの長期化）とも整合します¹²。

プロセスKPIとしては、重大脆弱性のMTTR、CVSS 7.0+の流入率、PRあたりのセキュリティ修正ポイント、夜間DASTの陽性率、誤検知率、そして例外の平均滞留日数を追います。さらに、危険関数の利用回数、直近変更ファイルへの検出偏り、脆弱パターンの再発率をチームごとにフィードバックすると、教育投資の効果測定にもつながります。

現場が回るための小さな工夫：失敗からの学習

導入途上では、過剰なブロッキングでリリースが滞り、現場の支持を失うことがあります。そこで、初期は警告モードで可視化に徹し、重大度と露出面の積が一定値を超えた場合のみブロックに切り替える段階導入を取ります。スキャン結果の通知はチャネルを分け、PRコメント、ダッシュボード、朝会の三点に限定して情報過多を防ぎます。自動修正が効く領域は積極的に使い、依存パッケージの欠陥はbotによるPR自動作成と影響範囲自動推定で、人手の判断をレビューに集中させます。障害時は、セキュリティ回りの設定変更をすべてフラグで切り戻せるようにし、万一の互換性問題に備えます。こうした小さな工夫が、日常運用の摩擦を減らし、持続可能な改善ループを支えます⁵。

【まとめ】

データ侵害のコストが高まり続ける中で、セキュリティ評価はイベントではなく仕組みとして機能させる必要があります¹²。SAST、DAST、SCA、IaCスキャンを開発フローに編み込み、早く広く見つけ、遅く深く塞ぐという二層化を徹底すると、MTTRの短縮が期待でき、ビジネスとしてのリスク低減効果も定量化できます⁵¹⁰。今日からできる一歩は、PRでのSAST/SCAの即時実行と、夜間DASTの定期化です。次の四半期に向けて、重大度のブロッキング条件と例外の期限ルールを定め、効果測定のKPIをダッシュボードで可視化してみてください。どのチームにも固有の制約がありますが、仕組みに落とし込んだ小さな前進が、組織の大きな安全余裕を生みます。あなたの現場では、どのスキャンから左シフトを始めますか。

参考文献

  1. IBM Security, Cost of a Data Breach Report 2024 summary https://newsroom.ibm.com/2024-07-30-ibm-report-escalating-data-breach-disruption-pushes-costs-to-new-highs
  2. IBM Security, Time to identify and contain (2024 report context) https://newsroom.ibm.com/2024-07-30-ibm-report-escalating-data-breach-disruption-pushes-costs-to-new-highs
  3. Verizon 2024 Data Breach Investigations Report (DBIR) https://www.verizon.com/business/resources/reports/dbir/
  4. Verizon DBIR 2024: Misconfiguration and known vulnerability trends https://www.verizon.com/business/resources/reports/dbir/
  5. OWASP DevSecOps Guideline https://owasp.org/www-project-devsecops-guideline/
  6. OWASP Interactive Application Security Testing (IAST) Project https://owasp.org/www-project-interactive-application-security-testing/
  7. Express official docs: Security best practices (Helmet) https://expressjs.com/en/advanced/best-practice-security.html
  8. GraphQL Security: Complexity limiting and rate limiting https://graphql.org/learn/security/
  9. Checkmarx blog: Tuning AppSec to boost your DORA metrics (MTTR) https://checkmarx.com/blog/tuning-appsec-to-boost-your-dora-metrics/
  10. Checkmarx blog: Pre-commit and pre-deployment automation guidance https://checkmarx.com/blog/tuning-appsec-to-boost-your-dora-metrics/
  11. Go net/http Server documentation (timeouts) https://pkg.go.dev/net/http#Server
  12. IBM Security, Cost escalation and disruption context from 2024 report https://newsroom.ibm.com/2024-07-30-ibm-report-escalating-data-breach-disruption-pushes-costs-to-new-highs