SnykとKiroとの統合によるIaCセキュリティスキャン
はじめに
背景・目的
Snykのユーザーガイドに新たに追加されていた、SnykとKiroとの統合(Snyk Studio for Kiro)について、IaCコードに対するセキュリティスキャンを通じて使用感を試してみます。
前提条件
- Kiro IDEがインストール済みであること
- Snykのアカウントを所持しており、アカウント内でSnyk Codeが有効化されていること
- FreeライセンスでもOKです
- Snyk CLIがインストール済みであること
Snyk MCPのインストール
KiroのMCP Configを編集して、Snyk MCPをインストールします。
なお、筆者の環境(Apple M4, macOS Sequoia 15.5)では、v1.1301.0を指定しない場合、接続エラーExpected array, received nullが発生しました。

{
"mcpServers": {
"Snyk": {
"command": "npx",
"args": ["-y", "snyk@v1.1301.0", "mcp", "-t", "stdio"],
"env": {}
}
}
}
Snyk IaCでのスキャン
それでは、IaCコードに対してセキュリティスキャンを実施しています。
Snyk IaCはCDK未対応のため、一度CloudFormationテンプレートを生成してからスキャンをかけてみます。


Snyk IaCスキャン結果
スキャン対象: StatefulStack CloudFormationテンプレート
検出された問題: 5件(すべて低重要度)
検出された脆弱性・設定問題
ECRリポジトリが顧客管理キーで暗号化されていない
重要度: 低
問題: ECRリポジトリがカスタマー管理のKMSキーで暗号化されていません
影響: KMS/IAMポリシーを通じてキーの使用範囲を制御できません
対処法: Properties.EncryptionConfiguration.KmsKey属性をカスタマー管理のKMSキーに設定
S3バケットのバージョニングが無効
重要度: 低
問題: S3バケットのバージョニングが無効になっています
影響: オブジェクトの変更や削除が元に戻せません
対処法: Properties.VersioningConfiguration.Status属性をEnabledに設定
Lambda関数のX-Rayトレーシングが無効
重要度: 低
問題: Lambda関数でAmazon X-Rayトレーシングが有効になっていません
影響: 調査時にトレースログが利用できません
対処法: Properties.TracingConfig.Mode属性をActiveまたはPassThroughに設定
S3サーバーアクセスログが無効
重要度: 低
問題: S3アクセスログが収集されません
影響: S3オブジェクトへのアクセスの監査証跡がありません
対処法: Properties.LoggingConfiguration属性を設定
ECRイメージスキャンが無効
重要度: 低
問題: ECRの既知の脆弱性に対するイメージスキャンが無効です
影響: 既知の脆弱性が自動的に発見されません
対処法: Properties.ImageScanningConfiguration属性をtrueに設定
総合評価
ファイル数: 1件
問題のあるファイル: 1件
総問題数: 5件(重要度:低5件)
無視された問題: 0件
すべての問題が低重要度であり、セキュリティ上の重大な脅威はありませんが、セキュリティのベストプラクティスに従って修正することを推奨します。
結果に対して、追加で質問してみます。

以下の修正コードを提案してくれました。

import * as cdk from 'aws-cdk-lib';
import { Stack, StackProps } from 'aws-cdk-lib';
import { Construct } from 'constructs';
import {
aws_s3 as s3,
aws_ecr as ecr,
aws_kms as kms,
} from 'aws-cdk-lib';
export interface StatefulStackProps extends StackProps {
}
export class StatefulStack extends Stack {
constructor(scope: Construct, id: string, props: StatefulStackProps) {
super(scope, id, props);
// アクセスログ用バケット(ログバケットのアクセスログを保存)
const accessLogsBucket = new s3.Bucket(this, "AccessLogsBucket", {
enforceSSL: true,
removalPolicy: cdk.RemovalPolicy.DESTROY,
autoDeleteObjects: true,
});
// ------------ ECR ---------------
const ecrRepo = new ecr.Repository(this, "EcrRepo", {
imageTagMutability: ecr.TagMutability.IMMUTABLE,
removalPolicy: cdk.RemovalPolicy.DESTROY,
// カスタマー管理KMSキーによる暗号化
encryptionConfiguration: {
encryptionType: ecr.EncryptionType.KMS,
},
// イメージスキャンを有効化
imageScanOnPush: true
});
// ------------ S3 ---------------
// Bucket for Logging
const logBucket = new s3.Bucket(this, "LogBucket", {
enforceSSL: true,
removalPolicy: cdk.RemovalPolicy.DESTROY,
autoDeleteObjects: true,
// バージョニングを有効化
versioned: true,
// アクセスログ設定
serverAccessLogsBucket: accessLogsBucket,
serverAccessLogsPrefix: 'log-bucket-access-logs/'
});
}
}
Lambda関数のX-Rayトレーシングについて
判定結果: 対応不要
CustomS3AutoDeleteObjectsCustomResourceProviderHandler9D90184Fという名前のLambda関数は、CDKによって自動的に作成される内部リソースです。
理由:
自動生成リソース: この関数はautoDeleteObjects: trueオプションを使用した際にCDKが自動的に作成するカスタムリソース用のLambda関数です
開発者の制御外: 開発者が明示的に作成したものではなく、CDKの内部実装によるものです
設定変更不可: この関数のX-Rayトレーシング設定を開発者が直接制御することはできません
機能的影響なし: このLambda関数はS3バケットのオブジェクト削除のみを行う一時的な処理であり、X-Rayトレーシングが無効でもアプリケーションの機能に影響しません
結論
Lambda関数のX-Rayトレーシングの問題は、CDKの内部実装に起因するものであり、開発者による対応は不要です。他の4つの問題(ECR暗号化、S3バージョニング、S3アクセスログ、ECRイメージスキャン)については上記の修正を適用することを推奨します
KiroへのAskを通じて、CDKベースでの対処法を提案してくれたり、CDKによって自動作成されるリソースは対応不要と分類してくれたりしました。
上記回答ベースでコード修正を依頼してみます。
当初の回答には不正確な情報(encryptionConfigurationを指定することで、エラー'encryptionConfiguration' does not exist in type 'RepositoryProps'が発生する)も含まれていましたが、筆者からの指示なしに自律的に設定是正してくれたようです。

とはいえ、MCP Serverとの連携や、人間による有識者レビューと組み合わせて品質向上を図ることが重要だと思料します。
また、Snykの設定画面(Snyk IaC > Severity settings > AWS)から、各検出項目に対して重大度をカスタマイズできる点が魅力的に感じました。組織・システムの特性に合わせてチューニングするのが良さそうですね。

チューニング後に再度KiroでSnyk MCPを用いたスキャンを実行したところ、重大度の変更が反映されていました。

参考
Discussion