container-security

コンテナセキュリティスキャナー

OS の脆弱性、アプリケーションの依存関係、Dockerfile のベストプラクティスを網羅した、コンテナイメージの包括的なセキュリティ分析ガイドです。

基本原則：基盤からコンテナを保護します。安全なベースイメージ、最小限のパッケージ、脆弱性のない状態を目指します。

---

クイックスタート

1. Identify image to scan (local, registry, or archive)
2. Run snyk_container_scan with image name
3. Analyze results: OS packages + application deps
4. Provide remediation guidance
5. Optionally fix Dockerfile issues

---

フェーズ 1：イメージの特定

ステップ 1.1：ユーザー入力の解析

ユーザーのリクエストからイメージ参照を抽出します（例：myapp:latest、nginx:1.25、gcr.io/project/app:v1、sha256:abc123...、または ./image.tar）。

ステップ 1.2：スキャン範囲の決定

確認するか、推定します。

• アプリの脆弱性：アプリケーションの依存関係を含めますか？（デフォルト：v1.1090.0 以降では含めます）
• ベースイメージ：ベースイメージの脆弱性を個別に確認しますか？（管理できる範囲を把握するのに便利です）
• プラットフォーム：マルチアーキテクチャイメージの場合、どのプラットフォームを対象にしますか？（linux/amd64、linux/arm64）

---

フェーズ 2：スキャンの実行

ステップ 2.1：基本スキャン

mcp_snyk_snyk_container_scan を次の内容で実行します。

• image：イメージ名またはパス

ステップ 2.2：高度なスキャンオプション

より包括的な分析を行うには、mcp_snyk_snyk_container_scan を次の内容で実行します。

• image：イメージ名
• file：Dockerfile へのパス（より適切な修正方法の提案が可能になります）
• app_vulns：true（アプリの依存関係をスキャンします）
• severity_threshold："high"（高または重大な脆弱性に絞り込みます）

ステップ 2.3：ベースイメージの分析

継承した脆弱性と追加した脆弱性を切り分けるには、次の手順に従います。

1. image と exclude_base_image_vulns: true を指定して mcp_snyk_snyk_container_scan を実行します。レイヤーで追加した脆弱性のみが表示されます。
2. このフラグを指定せずに再度実行します。ベース OS を含む全体像が表示されます。

---

フェーズ 3：結果の分析

ステップ 3.1：検出結果の分類

ソース	説明	管理方法
ベース OS パッケージ	ベースイメージによってインストールされます	ベースイメージを変更します
追加の OS パッケージ	apt/yum 経由でインストールされます	更新または削除します
アプリの依存関係	Node モジュール、Python パッケージ	バージョンを更新します
Dockerfile の問題	設定ミス	直接修正します

ステップ 3.2：概要の作成

## Container Scan Results: [image:tag]

### Overview
| Category | Critical | High | Medium | Low |
|----------|----------|------|--------|-----|
| OS Packages | X | Y | Z | W |
| App Dependencies | A | B | C | D |
| **Total** | X+A | Y+B | Z+C | W+D |

### Base Image Analysis
- **Base**: [base image detected]
- **Vulnerabilities from base**: [count]
- **Vulnerabilities you added**: [count]

### Top Priority Issues

| Severity | Package | Vulnerability | Fix Available |
|----------|---------|---------------|---------------|
| Critical | openssl | CVE-2024-XXXX | Yes - 3.0.12 |
| High | libcurl | CVE-2024-YYYY | Yes - 8.5.0 |

ステップ 3.3：修正方法の特定

OS パッケージ：Dockerfile 内のパッケージを更新するか、ベースイメージをアップグレードするか、distroless または最小構成のベースを使用します。

アプリの依存関係：ソースマニフェスト内で更新し、依存関係を更新したイメージを再ビルドします。

修正方法がない場合：許容するリスクを記録し、代替パッケージを検討するか、上流での修正を待ちます。

---

フェーズ 4：修正方法の案内

ステップ 4.1：ベースイメージのアップグレード

ベースイメージに脆弱性がある場合：

## Base Image Recommendation

**Current**: node:16-alpine
**Vulnerabilities**: 15 (3 Critical, 5 High)

**Recommended**: node:20-alpine
**Vulnerabilities**: 2 (0 Critical, 1 High)

### Dockerfile Change
```dockerfile
# Before
FROM node:16-alpine

# After
FROM node:20-alpine

移行時の注意点

• Node 20 には [list] に記載された後方互換性のない変更があります
• デプロイ前に十分にテストしてください

### Step 4.2: Package Updates

For individual package vulnerabilities:

パッケージの修正：openssl

現在のバージョン：3.0.8 影響を受ける脆弱性：CVE-2024-XXXX（重大） 修正バージョン：3.0.12

Dockerfile への追加

# Add before your application layer
RUN apk update && apk upgrade openssl

### Step 4.3: Application Dependency Fixes

アプリケーションの依存関係の修正

パッケージ：lodash（npm 経由） 現在のバージョン：4.17.15 修正バージョン：4.17.21

手順

1. package.json を更新します："lodash": "^4.17.21"
2. イメージを再ビルドします：docker build -t myapp:fixed .
3. 修正を確認します：snyk container test myapp:fixed

### Step 4.4: Dockerfile Best Practices

Key improvements to recommend:

```dockerfile
# 1. Pin specific tags (not latest)
FROM node:20.10.0-alpine3.19

# 2. Run as non-root
RUN addgroup -g 1001 appgroup && \
    adduser -u 1001 -G appgroup -D appuser
USER appuser

# 3. Multi-stage builds (smaller image, fewer vulns)
FROM node:20 AS builder
WORKDIR /app
COPY . .
RUN npm ci && npm run build

FROM node:20-alpine
COPY --from=builder /app/dist /app
CMD ["node", "/app/index.js"]

# 4. Minimize packages
RUN apt-get install -y --no-install-recommends curl

---

フェーズ 5：検証

ステップ 5.1：イメージの再ビルド

# Rebuild with no cache to ensure fresh packages
docker build --no-cache -t myapp:fixed .

ステップ 5.2：再スキャン

mcp_snyk_snyk_container_scan を次の内容で実行します。

• image：myapp:fixed
• file：./Dockerfile

ステップ 5.3：結果の比較

## Fix Verification

| Metric | Before | After | Change |
|--------|--------|-------|--------|
| Critical | 3 | 0 | -3 ✅ |
| High | 5 | 1 | -4 ✅ |
| Medium | 12 | 8 | -4 ✅ |
| Total | 20 | 9 | -11 ✅ |

### Remaining Issues
- 1 High: No fix available upstream (document risk)
- 8 Medium: Low priority (schedule for next sprint)

---

最初から最後までの例

ユーザー：「myapp:latest イメージをスキャンして、修正を手伝ってください。」

ステップ 1 — スキャンを実行します。

mcp_snyk_snyk_container_scan(image="app:latest", app_vulns=true)

ステップ 2 — ツールの返却内容（出力例）：

{
  "summary": "Found 18 vulnerabilities (2 Critical, 6 High, 10 Medium)",
  "baseImage": "node:16-alpine",
  "vulnerabilities": [
    { "severity": "critical", "pkgName": "openssl", "version": "3.0.8",
      "fixedIn": "3.0.12", "id": "CVE-2024-0001" },
    { "severity": "high", "pkgName": "lodash", "version": "4.17.15",
      "fixedIn": "4.17.21", "id": "CVE-2021-23337" }
  ]
}

ステップ 3 — 構造化した回答を提示します。

## Scan Results: app:latest
Base image: node:16-alpine | 2 Critical · 6 High · 10 Medium

### Immediate Actions
1. Upgrade base image → node:20-alpine (eliminates ~14 vulns)
2. Pin openssl ≥ 3.0.12 in Dockerfile (CVE-2024-0001, Critical)
3. Update lodash to ^4.17.21 in package.json (CVE-2021-23337, High)

### Dockerfile patch
FROM node:20-alpine        # was node:16-alpine
RUN apk add --no-cache openssl>=3.0.12

ステップ 4 — 修正を適用した後、再ビルドして再スキャンし、解決を確認します。

---

よくあるシナリオ

シナリオ 1：「Docker イメージをスキャンする」

1. Invoke snyk_container_scan(image="app:latest")
2. Summarize findings by category
3. Recommend highest-priority fixes
4. Provide Dockerfile changes

シナリオ 2：「Dockerfile を安全にする」

1. Review Dockerfile for best practices
2. Build image if not already built
3. Invoke snyk_container_scan(image=..., file="./Dockerfile")
4. Combine scan results with Dockerfile review
5. Provide unified remediation

シナリオ 3：「より安全なベースイメージを見つける」

1. Identify current base image and vulnerabilities
2. Scan alternative base images
3. Compare vulnerability counts
4. Recommend best option with migration notes

---

ベースイメージのクイックリファレンス

ランタイム	推奨ベースイメージ	備考
Node.js	node:20-alpine	最も小さいサイズですが、一部のライブラリが不足している場合があります
Node.js	node:20-slim	Debian ベースで、互換性が高くなっています
Python	python:3.12-slim	バランスに優れています
Python	python:3.12-alpine	最も小さいサイズです
Java	eclipse-temurin:21-jre-alpine	JRE のみです
Go	gcr.io/distroless/static	シェルがなく、攻撃対象領域が最小限です
.NET	mcr.microsoft.com/dotnet/aspnet:8.0-alpine	ランタイムのみです

Distroless の選択肢（gcr.io/distroless/）：static（Go/Rust）、base（ほとんどの言語）、java、nodejs — いずれもシェルがなく、攻撃対象領域を最小限に抑えられます。

---

エラー処理

エラー	解決策
イメージがローカルに見つからない	docker pull <image> · 名前のスペルを確認 · レジストリへのアクセスを確認
レジストリの認証が必要	docker login <registry> · 認証情報と権限を確認
スキャンがタイムアウトした	再試行 · 先にイメージをローカルにプル · 代わりに .tar アーカイブをスキャン

---

制約事項

1. デプロイ前にスキャンする：スキャンしていないイメージはデプロイしないでください
2. バージョンを固定する：latest ではなく、特定のイメージタグを使用してください
3. 例外を文書化する：脆弱性を修正できない場合は、その理由を文書化してください
4. 定期的に再スキャンする：新しい CVE に備え、イメージを毎週再スキャンしてください
5. マルチステージビルド：より小さい本番用イメージを優先してください