Go to Qiita Advent Calendar Top
LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@yama0531in株式会社BeeX

CNAPPのCode Securityでコード段階のリスクを検出：DevSecOpsへ

Posted at

Code Securityとは

クラウドネイティブ環境を守る統合プラットフォーム CNAPP（Cloud Native Application Protection Platform） は、クラウド環境全体をカバーします。

その中でも 開発フェーズ（コードを書く／リポジトリを管理する段階） において重要な役割を果たすのが「Code Security」です。

Code Securityがカバーする領域は以下のとおりです。

  • IaCの設定ミス検出（Terraform, CloudFormation, YAML など）
  • ソースコードに含まれる秘密情報の検出（APIキー、認証情報など）
  • OSSやライブラリの脆弱性検出
  • コードレビューやブランチ保護などの開発プロセス統制

これらのリスクをコード段階で検出・修正することで、後工程での修正コストを大幅に削減できます。
これは DevSecOps実現の第一歩 です。

今回の実践テーマ

本稿では、「開発フェーズでセキュリティを自動化する仕組み」を実際に試してみます。
題材は CNAPP × GitHub連携 です。

使用するツールは Spectral。
Spectralとは、ソースコードや設定ファイルをスキャンし、SecretsやIaCの誤り、OSSの脆弱性を検出するセキュリティツールです。
元々は独立製品ですが、現在はCNAPPのCode Security機能に統合されており、クラウド環境全体のリスク管理の一部として活用できます。

全体の流れ

CNAPPとGitHubを連携すると、以下が実現できます。

  • リポジトリを自動スキャンし、問題のあるコードや設定を検出
  • プッシュやCI/CDパイプライン実行時に自動スキャン
  • 発見されたリスクをCNAPPダッシュボードで一元管理

今回の手順は次の通りです。

  1. GitHubリポジトリの準備
  2. CNAPPからDSNを取得してGitHub Actionsに登録
  3. GitHub ActionsにSpectralスキャン用のワークフローを追加
  4. プッシュやプルリクエスト時に自動スキャンが実行され、結果がCNAPPダッシュボードに反映
  5. コマンドライン（オプション）から手動スキャン

実践手順

GitHubリポジトリの準備

開発対象のリポジトリをGitHub上に作成し、初期コミットします。

git add .
git commit -m "Initial commit"
git push origin main

CNAPP側でDSNを取得

CNAPPからDSN（接続用トークン）を発行します。
これは、Spectral（スキャンエージェント）とGitHubリポジトリを接続する認証情報です。

例：

https://spu-1234567890987654321abcdefggfedcba@XXXXXXXXXXXXXXXXX.com

DSNは機密情報のため、必ずSecretsとして管理します。
GitHub Actionsに自動スキャンを設定
GitHubリポジトリのSettings > Secrets and variables > Actionsを開き、取得したDSNをSPECTRAL_DSNとして登録します。

次に、
.github/workflows/spectral_scan.yml を作成します。
画像1.png
.github/workflows/spectral_scan.yml の内容例：

name: Spectral Scan

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

env:
  SPECTRAL_DSN: ${{ secrets.SPECTRAL_DSN }}

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Install and run Spectral
        uses: spectralops/spectral-github-action@v2
        with:
          spectral-dsn: ${{ env.SPECTRAL_DSN }}
          spectral-args: github -k repo -t ${{ secrets.GITHUB_TOKEN }} https://github.com/${{ github.repository }} --engines secrets,iac,oss --include-tags base,audit,iac

コミット＆プッシュします。

git add .github/workflows/spectral_scan.yml
git commit -m "Add Spectral scan workflow"
git push origin main

これでプッシュやプルリクエスト作成時に自動スキャンが実行され、結果はCNAPPダッシュボードに反映されます。

コマンドラインからの手動スキャン

自動スキャンに加えて、開発者がローカル環境から手動スキャンを行うことも可能です。

spectral.exe github -k repo -t <YOUR_GITHUB_TOKEN> `
https://github.com/<YOUR_USERNAME>/<YOUR_REPO> `
--dsn <YOUR_SPECTRAL_DSN> `
--include-tags base,audit

画像2.png

今回のスキャン結果は、すべてのルールに対してPassed、つまり合格となりました。IaC、Secrets、OSSの脆弱性のいずれも検出されなかったため、現状のリポジトリは初期段階としては安全であることが確認できました。
CNAPPダッシュボードでは、検出結果を一覧で確認できます。
画像3.png

あえて脆弱ライブラリと平文シークレットを配置

ここからは、スキャン結果がFailedとなるよう以下を配置します。

  • 平文シークレット（.env）
  • 脆弱な依存関係（requirements.txt）
  • OSSライブラリの既知脆弱性

注意: 実運用での平文シークレットのコミットはNGです。本手順はあくまでローカル／検証用のダミー値です。公開リポジトリでは絶対に実行しないでください。テスト後は必ずファイルを削除し、履歴からも除去してください（git filter-repoやBFG推奨）。

環境準備（PowerShell の例）

# 作業ディレクトリ
cd C:\Users\yusuke.yamashita\github\CNAPP_DevSecOps_Test

# テスト用ファイル作成（ダミー値を使用）
@'
# 平文シークレットのテスト（ダミー）
AWS_ACCESS_KEY_ID=AKIAEXAMPLEKEY123
AWS_SECRET_ACCESS_KEY=SECRETEXAMPLEKEY123
'@ | Out-File -Encoding UTF8 .env

@'
# 脆弱な依存関係を意図的に入れる（例）
requests==2.18.4
flask==0.12
'@ | Out-File -Encoding UTF8 requirements.txt

# Git に追加
git add .env requirements.txt
git commit -m "Add vulnerable dependencies and test secrets"
git push origin main

Spectralでスキャン（PowerShell の例）

$REPO = "https://github.com/yama0531/CNAPP_DevSecOps_Test"

spectral.exe github $REPO `
    --kind repo `
    --token $GITHUB_TOKEN `
    --dsn $SPECTRAL_DSN `
    --engines secrets,oss `
    --include-tags base,audit,open-source
  • --engines secrets,oss でシークレット検出とOSS依存関係（脆弱ライブラリ）の両方をスキャン
  • --include-tags base,audit,open-sourceは検査対象のタグ指定

環境変数について

  • $GITHUB_TOKEN や $SPECTRAL_DSN は環境変数（PowerShell）あるいは CI のシークレットから読み込む想定です。Windows PowerShell で直接設定する例：
$env:GITHUB_TOKEN = "ghp_xxx"        # テスト用ダミー／非公開
$env:SPECTRAL_DSN = "spu-xxxxxxxx..." # テスト用ダミー／非公開

Bash（WSL / Linux / macOS）の例（参考）

cd ~/github/CNAPP_DevSecOps_Test

cat > .env <<'EOF'
AWS_ACCESS_KEY_ID=AKIAEXAMPLEKEY123
AWS_SECRET_ACCESS_KEY=SECRETEXAMPLEKEY123
EOF

cat > requirements.txt <<'EOF'
requests==2.18.4
flask==0.12
EOF

git add .env requirements.txt
git commit -m "Add vulnerable dependencies and test secrets"
git push origin main

REPO="https://github.com/yama0531/CNAPP_DevSecOps_Test"

spectral github "$REPO" \
  --kind repo \
  --token "$GITHUB_TOKEN" \
  --dsn "$SPECTRAL_DSN" \
  --engines secrets,oss \
  --include-tags base,audit,open-source

注意事項

  1. 公開リポジトリに平文シークレットを残さない — テストは必ずプライベート・一時リポジトリで実施してください。
  2. コミットしてしまった場合は、git filter-repo や BFG を使って履歴から除去する。単純な git rm では履歴に残ります。
  3. 実際の検証ではダミー値を使い、Secretsは必ずGitHub Actionsなどのシークレットストアに入れて実施してください。
  4. テスト終了後は .env と requirements.txt（テスト用）が不要であれば削除し、リポジトリのクリーンアップを実施してください。

スキャン結果の確認

Spectralによるスキャンで、以下の脆弱性が検出されました。

High: flask [CVE-2018-1000656]
    ╭─[C:\requirements.txt]
    │
      Flask is vulnerable to Denial of Service via incorrect encoding of JSON data
      ── Fix:
      Upgrade to 0.12.3
      ── More Info:
      https://github.com/advisories/GHSA-562c-5r94-xh97
────╯
High: requests [CVE-2018-18074]
    ╭─[C:\requirements.txt]
    │
      Insufficiently Protected Credentials in Requests
      ── Fix:
      Upgrade to 2.20.0
      ── More Info:
      https://github.com/advisories/GHSA-x84v-xcm2-53pg
────╯
High: flask [CVE-2019-1010083]
    ╭─[C:\requirements.txt]
    │
      Pallets Project Flask is vulnerable to Denial of Service via Unexpected memory usage
      ── Fix:
      Upgrade to 1.0
      ── More Info:
      https://github.com/advisories/GHSA-5wv5-4vpf-pj6m
────╯
High: flask [CVE-2023-30861]
    ╭─[C:\requirements.txt]
    │
      Flask vulnerable to possible disclosure of permanent session cookie due to missing Vary: Cookie header
      ── Fix:
      Upgrade to 2.2.5
      ── More Info:
      https://github.com/advisories/GHSA-m2qf-hxjv-5gpq
────╯
Medium: requests [CVE-2023-32681]
    ╭─[C:\requirements.txt]
    │
      Unintended leak of Proxy-Authorization header in requests
      ── Fix:
      Upgrade to 2.31.0
      ── More Info:
      https://github.com/advisories/GHSA-j8r2-6x86-q33q
────╯
Medium: requests [CVE-2024-35195]
    ╭─[C:\requirements.txt]
    │
      Requests `Session` object does not verify requests after making first request with verify=False
      ── Fix:
      Upgrade to 2.32.0
      ── More Info:
      https://github.com/advisories/GHSA-9wx4-h78v-vm56
────╯
Medium: requests [CVE-2024-47081]
    ╭─[C:\requirements.txt]
    │
      Requests vulnerable to .netrc credentials leak via malicious URLs
      ── Fix:
      Upgrade to 2.32.4
      ── More Info:
      https://github.com/advisories/GHSA-9hjg-9r4m-mvj7
────╯
Medium: Environment configuration file [SENF073]
    ╭─[C:\Users\yusuke.yamashita\github\CNAPP_DevSecOps_Test\6bbee496-9504-45e4-aa4a-473c05ea5679\CNAPP_DevSecOps_Test\.env]
    │
────╯
[x] secrets: found 1 matches
  scanned 2011 bytes and 9 files in 54ms
  out of 701 detectors, 700 passed, 1 failed, 0 ignored
                  passed   failed   ignored
  HIGH            479      0        0
  MEDIUM          188      1        0
  LOW             2        0        0
  INFORMATIONAL   31       0        0
[x] oss: found 7 matches in 1 manifest file

スキャン結果の分析

requirements.txt に含まれる古い FlaskおよびRequestsに、複数のCVE（脆弱性）が検出されました。主にバージョンが古いというものであり、既知の脆弱性が多数報告されています。ちなみに、CVE（Common Vulnerabilities and Exposures） とは、
ソフトウェアやライブラリに存在する既知の脆弱性に一意なIDを付与した識別子のことです。
例：CVE-2018-1000656
各CVEには以下のような情報が公開されています。

  • 脆弱性の内容
  • 影響範囲
  • 修正（アップデート）方法

これにより、開発者やセキュリティ担当者は脆弱性を効率的に把握・管理できます。
CVEは国際的なセキュリティ基準として、セキュリティ運用・脆弱性管理として広く利用されています。
CNAPPの方にも結果が現れました。
画像1.png
画像2.png

なお、今回の脆弱性スキャン（SpectralによるSecrets/OSSスキャン）は GitHub単体でも十分に検出・管理が可能 です。

例えば：

  • PRやコミット時に自動スキャンして平文シークレットや脆弱な依存関係を検出
  • スキャン結果をGitHub IssuesやPRコメントでチームに通知
  • 高・中・低リスクの分類や修正の進捗を追跡

つまり、GitHubだけでも「検出 → 通知 → 修正」のフローは完結できます。

ただし、ここで実施したいことは DevSecOpsであり継続的なセキュリティ運用 です。
CNAPPと統合することにより以下のようなメリット が実現できます。

1.マルチクラウド／マルチリポジトリ対応
GitHub以外にも、AWS、Azure、GCPなど、複数環境のリスクを統合的に可視化可能
2. 継続的コンプライアンス／ポリシー適用
OSSライブラリ、IaC、クラウド設定、コンテナイメージなど幅広い対象でポリシー違反を継続監視
3. 一元的なダッシュボードとレポート
GitHub単体では分散してしまう情報を、CNAPP側で統合して脆弱性傾向や優先度を一目で把握

つまり、小規模開発ではGitHub単体でも十分ですが、組織全体でセキュリティリスクを統合的に管理する場合は、CNAPPの導入が有効です。

では、最後に今回の脆弱性を潰します。
.envをGitHubから削除し、代わりに.env.exampleを置きます。

# .envを削除してリポジトリから除去
git rm .env
git commit -m "Remove plaintext secrets (.env) - replace with .env.example"
# 安全なサンプル環境変数を作成
@'
AWS_ACCESS_KEY_ID=REPLACE_WITH_AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY=REPLACE_WITH_AWS_SECRET_ACCESS_KEY
'@ | Out-File -Encoding UTF8 .env.example
git add .env.example
git commit -m "Add .env.example to guide secure env setup"
git push origin main

シークレットは、リポジトリに置かないのが一般的です。

@'
requests==2.32.4
flask==2.2.5
'@ | Out-File -Encoding UTF8 requirements.txt
git add requirements.txt
git commit -m "Upgrade vulnerable libs"
git push origin main

再スキャンします。
画像3.png
正常な状態となりました。

まとめ

今回の実践を通じて、コード段階でのセキュリティ対策がDevSecOpsの第一歩であることを確認できました。
GitHub単体でも一定のセキュリティ運用は可能ですが、CNAPPと統合することで、より広範かつ継続的なセキュリティ管理を実現できます。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?