mcpField
S
secure-at-inception

secure-at-inception

github.com/snykセキュリティ68139 回インストール1 週間前に更新
リポジトリ

secure-at-inception について

secure-at-inception は、コード変更をコードベースに取り込む前に検査するセキュリティスキャンスキルです。ファイル種別に応じて SAST、SCA、IaC スキャンを選び、既存の問題を除外します。

主な機能

  1. 01ファイル種別に応じたスキャン選択
  2. 02SAST、SCA、IaC の並列実行
  3. 03変更で生じた問題のみ報告
  4. 04結果のキャッシュとファイルの絞り込み
  5. 05重大度に応じたブロック判定
  6. 06スキャン後のフィードバック指標送信

活用シーン

  1. 01コミット前の新規コード検査
  2. 02CI/CD でのプルリクエスト確認
  3. 03新規脆弱性と既存問題の区別

MCP 対応

Snyk MCP ツールを使ってコード、依存関係、IaC をスキャンし、フィードバック指標を送信します。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/snyk/studio-recipes --skill secure-at-inception

インストール後、Claude Code で/secure-at-inceptionを入力して読み込まれたか確認します。

同梱ファイルreferences/severity-thresholds.mdreferences/supported-languages.md

詳細

開発開始時からのセキュリティ確保

新たに生成または変更されたすべてのコードを事前にスキャンし、セキュリティ脆弱性がコードベースに混入するのを防ぎます。インテリジェントなスキャン判断、キャッシュ、フィルタリングにより、新たな問題だけに注力できます。

ファイルの種類 → スキャンの種類の対応表

スキャンの種類対象となるファイルMCP ツール
SAST（コード）ソースファイル：.js、.ts、.py、.java、.go、.rb、.php、.cs、.swift、.kt、.scala、.rs、.c、.cpp、.dart などsnyk_code_scan
SCA（依存関係）マニフェスト：package.json、requirements.txt、pom.xml、build.gradle、Gemfile、go.mod、Cargo.toml、*.csproj、composer.json などsnyk_sca_scan
IaCインフラストラクチャ：.tf、.tfvars、K8s YAML（apiVersion／kind を含む）、template.json／.yaml、ARM JSON、serverless.ymlsnyk_iac_scan

スキップ：バイナリファイル、IaC ではない JSON／YAML、ドキュメント（.md、.txt、.rst）、アセット、テスト用フィクスチャ。

フェーズ 1：変更の検出

ステップ 1.1：変更されたファイルを収集する

次のいずれかの方法で変更を確認します（優先順）。

  1. Git diff（git リポジトリ内の場合）： 
    git diff --name-only HEAD
git diff --name-only --cached  # staged files
git status --porcelain
  2. セッションのコンテキスト：現在のセッション中に作成または変更されたファイルを追跡する
  3. ユーザー指定のパス：ユーザーが特定のファイルまたはディレクトリを指定した場合
ステップ 1.2：スキャンの種類ごとにファイルを分類する

上記の「ファイルの種類 → スキャンの種類の対応表」を使用して、変更された各ファイルを適切なスキャンに対応付けます。IaC の YAML は、apiVersion／kind（Kubernetes）または AWSTemplateFormatVersion（CloudFormation）の有無によって、一般的な YAML と区別します。

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

SAST、SCA、IaC の各スキャンは互いに独立しているため、並行して実行します。該当する各スキャンの種類について（「ファイルの種類 → スキャンの種類の対応表」に基づいて判断）、以下のパラメーターを使用します。

ステップ 2.1：SAST スキャン（snyk_code_scan）
  • path：変更されたソースファイルを含むディレクトリ（またはプロジェクトのルート）。変更されたファイルが 5 件未満の場合は各ファイルを個別にスキャンし、それ以外の場合は親ディレクトリをスキャンします
  • severity_threshold："medium"（デフォルト）または設定値
ステップ 2.2：SCA スキャン（snyk_sca_scan）
  • path：プロジェクトのルート、またはマニフェストを含むディレクトリ
  • all_projects：true（モノレポの場合）
  • severity_threshold："medium"（デフォルト）または設定値
  • 注：SCA は直接の変更箇所だけでなく、依存関係ツリー全体をスキャンします。
ステップ 2.3：IaC スキャン（snyk_iac_scan）
  • path：IaC ファイルを含むディレクトリ
  • severity_threshold："medium"（デフォルト）または設定値

フェーズ 3：新たな問題に絞り込む

現在の変更によって持ち込まれた問題だけを提示するため、報告前に次のフィルターを適用します。

SAST：検出結果のファイルと行が、git diff -U0 の変更行範囲に含まれる場合のみ対象とします。@@ -X,Y +A,B @@ のハンクを解析して変更範囲を特定し、その範囲外の検出結果は既存の問題として除外します。

SCA：新規または更新されたパッケージの脆弱性数が増加しているか、重要度が上がっている場合のみ対象とします。純改善ルールを適用し、変更によって全体の脆弱性数または重要度が低下する場合は、ブロックしません。

IaC：新規追加または変更されたリソースブロックに設定ミスがある場合のみ対象とします。

フェーズ 4：報告と判断

ステップ 4.1：重要度のしきい値設定
モードブロック対象警告対象許可
厳格低以上--
標準高以上中低
緩和重大のみ高中、低
ステップ 4.2：レポートの生成
## Secure At Inception Scan Results

### Summary
| Scan Type            | New Issues | Blocked |
|----------------------|------------|---------|
| Code (SAST)          | X          | Yes/No  |
| Dependencies (SCA)   | Y          | Yes/No  |
| Infrastructure (IaC) | Z          | Yes/No  |

### New Code Vulnerabilities (SAST)
| Severity | Type          | File       | Line | Description           |
|----------|---------------|------------|------|-----------------------|
| High     | SQL Injection | src/db.ts  | 45   | User input in query   |

### New Dependency Vulnerabilities (SCA)
| Severity | Package          | Vulnerability        | Fix Version |
|----------|------------------|----------------------|-------------|
| Critical | [email protected]   | Prototype Pollution  | 4.17.21     |

### New Infrastructure Issues (IaC)
| Severity | Resource       | Issue                 | Recommendation           |
|----------|----------------|-----------------------|--------------------------|
| High     | aws_s3_bucket  | Public access enabled | Set block_public_access  |

### Recommended Actions
1. `/snyk-fix SNYK-JS-LODASH-1234` - Fix lodash vulnerability
2. Review `src/db.ts:45` for SQL injection fix

### Decision: [BLOCKED / ALLOWED]
[Reason based on severity threshold]
ステップ 4.3：ブロック判断ロジック
If any NEW issue severity >= threshold:
  BLOCKED - do not proceed until fixed
  Provide specific fix commands
Else:
  ALLOWED - safe to proceed
  Note any warnings for future attention

フェーズ 5：メトリクスの追跡

問題を検出し、その修正に役立った各スキャンの後に、次の値を指定して snyk_send_feedback を実行します。

  • path：プロジェクトのルート（絶対パス）
  • preventedIssuesCount：検出された新たな問題の数（累積ではなく差分）
  • fixedExistingIssuesCount：0（このスキルは既存の問題を修正するのではなく、防止します）

このスキャンがなければコミットされていた可能性のある、新しいコード内で検出された問題のみを数えます。

ベストプラクティス

  • 自動実行：コードの生成後や変更後、コミットを提案する前に実行します。明示的なセキュリティチェックの依頼があった場合も実行します。
  • 結果のキャッシュ：file + content_hash をキーにして、TTL を 12 時間に設定します。変更されたファイルだけを再スキャンし、ディレクトリ単位でまとめて処理します。
  • 誤検知：.snyk ポリシーファイルを使って、確認済みの誤検知を抑制し、再実行して確認します。 
    ignore:
  SNYK-JS-EXAMPLE-12345:
    - '*':
        reason: 'False positive - input is validated upstream'
        expires: 2025-12-31
  • しきい値の調整：Standard モードから始めます。ブロックされる頻度が高すぎる場合は Relaxed に切り替え、低または中程度の深刻度のインシデントが発生した後は Strict に切り替えます。
  • CI/CD との統合：プルリクエストの作成時、またはフィーチャーブランチへのプッシュ時に実行します。しきい値を超えた場合はマージをブロックします。

エラー処理

状況対応
認証エラーsnyk_auth を実行して再試行します。それでも失敗する場合は、ユーザーに手動での認証を促します
スキャンのタイムアウト対象範囲を縮小して 1 回再試行します。それでも失敗する場合は、部分的な結果を報告します
変更が検出されない「コードの変更が検出されませんでした。スキャン対象はありません」と報告し、依頼があればプロジェクト全体のスキャンを提案します
サポート対象外のファイルのみスキップされたファイル形式と理由の一覧を添えて、「変更にスキャン可能なファイルはありません」と報告します

制約

  1. 新たな問題のみ：既存の問題を理由にブロックしてはいけません（既存の問題への対処は修正作業の役割です）。
  2. ノイズを最小限に：アラート疲れを防ぐため、積極的にフィルタリングします。
  3. 迅速なフィードバック：一般的な変更では、スキャンを 30 秒以内に完了します。
  4. 非破壊的：コードは変更せず、検出結果のみを報告します。
  5. 実行可能な出力：すべての検出結果に、明確な修正方法を示します。

コメント

Markdown 対応