Back to Details

secure-at-inception

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Secure At Inception

源头安全防护

Proactively scan all newly generated or modified code to prevent security vulnerabilities before they enter the codebase. Provides intelligent scanning decisions, caching, and filtering to focus only on NEW issues.
主动扫描所有新生成或修改的代码，在漏洞进入代码库前就将其拦截。提供智能扫描决策、缓存和过滤功能，仅聚焦新问题。

File Type → Scan Type Reference

文件类型→扫描类型参考表

Scan TypeTrigger FilesMCP Tool
SAST (Code)Source files: 
.js
, 
.ts
, 
.py
, 
.java
, 
.go
, 
.rb
, 
.php
, 
.cs
, 
.swift
, 
.kt
, 
.scala
, 
.rs
, 
.c
, 
.cpp
, 
.dart
, and more
snyk_code_scan
SCA (Dependencies)Manifests: 
package.json
, 
requirements.txt
, 
pom.xml
, 
build.gradle
, 
Gemfile
, 
go.mod
, 
Cargo.toml
, 
*.csproj
, 
composer.json
, and more
snyk_sca_scan
IaCInfrastructure: 
.tf
, 
.tfvars
, K8s YAML (with 
apiVersion
/
kind
), 
template.json
/
.yaml
, ARM JSON, 
serverless.yml
snyk_iac_scan
Skip: binary files, non-IaC JSON/YAML, documentation (
.md
, 
.txt
, 
.rst
), assets, test fixtures.
扫描类型触发文件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.yml
snyk_iac_scan
跳过扫描：二进制文件、非IaC格式的JSON/YAML、文档（
.md
、
.txt
、
.rst
）、资源文件、测试用例。

Phase 1: Change Detection

阶段1：变更检测

Step 1.1: Gather Changed Files

步骤1.1：收集变更文件

Check for changes using one of these methods (in order of preference):
  1. Git diff (if in a git repo):
    bash
    git diff --name-only HEAD
git diff --name-only --cached  # staged files
git status --porcelain
  2. Session context: Track files created/modified during the current session
  3. User-specified path: If user provides a specific file or directory
通过以下方法（按优先级排序）检查变更：
  1. Git diff（若处于Git仓库中）：
    bash
    git diff --name-only HEAD
git diff --name-only --cached  # 已暂存文件
git status --porcelain
  2. 会话上下文：追踪当前会话中创建/修改的文件
  3. 用户指定路径：若用户提供了特定文件或目录

Step 1.2: Categorize Files by Scan Type

步骤1.2：按扫描类型分类文件

Use the File Type → Scan Type Reference table above to map each changed file to the appropriate scan. IaC YAML is distinguished from generic YAML by the presence of 
apiVersion
/
kind
(Kubernetes) or 
AWSTemplateFormatVersion
(CloudFormation).
使用上述“文件类型→扫描类型参考表”，将每个变更文件映射到对应的扫描类型。IaC YAML与通用YAML的区别在于是否包含
apiVersion
/
kind
（Kubernetes）或
AWSTemplateFormatVersion
（CloudFormation）字段。

Phase 2: Execute Scans

阶段2：执行扫描

Run SAST, SCA, and IaC scans in parallel — they are independent of each other. Use the parameters below for each applicable scan type (determined by the File Type → Scan Type Reference table).
并行运行SAST、SCA和IaC扫描——三者相互独立。根据“文件类型→扫描类型参考表”确定适用的扫描类型，并使用以下参数执行扫描。

Step 2.1: SAST Scan (
snyk_code_scan
)

步骤2.1：SAST扫描（
snyk_code_scan
）

  • path
    : directory containing changed source files (or project root); scan each file individually if < 5 files changed, otherwise scan the parent directory
  • severity_threshold
    : 
    "medium"
    (default) or as configured
  • path
    ：包含变更源代码的目录（或项目根目录）；若变更文件少于5个则单独扫描每个文件，否则扫描父目录
  • severity_threshold
    ：
    "medium"
    （默认）或自定义配置值

Step 2.2: SCA Scan (
snyk_sca_scan
)

步骤2.2：SCA扫描（
snyk_sca_scan
）

  • path
    : project root or directory containing the manifest
  • all_projects
    : 
    true
    (for monorepos)
  • severity_threshold
    : 
    "medium"
    (default) or as configured
  • Note: SCA scans the entire dependency tree, not just direct changes.
  • path
    ：项目根目录或包含清单文件的目录
  • all_projects
    ：
    true
    （适用于单体仓库）
  • severity_threshold
    ：
    "medium"
    （默认）或自定义配置值
  • 注意：SCA扫描整个依赖树，而非仅直接变更的依赖。

Step 2.3: IaC Scan (
snyk_iac_scan
)

步骤2.3：IaC扫描（
snyk_iac_scan
）

  • path
    : directory containing IaC files
  • severity_threshold
    : 
    "medium"
    (default) or as configured
  • path
    ：包含IaC文件的目录
  • severity_threshold
    ：
    "medium"
    （默认）或自定义配置值

Phase 3: Filter to New Issues

阶段3：过滤新问题

Apply these filters before reporting to surface only issues introduced by the current changes.
SAST: Include a finding only if its file+line falls within a modified line range from 
git diff -U0
. Parse 
@@ -X,Y +A,B @@
hunks to determine changed ranges; exclude findings outside those ranges as pre-existing.
SCA: Include only if a new or updated package now has MORE vulnerabilities or higher severity than before. Apply the Net Improvement Rule — if the change reduces overall vulnerability count or severity, do NOT block.
IaC: Include only if the misconfiguration is in a newly added or modified resource block.
在报告前应用以下过滤规则，仅展示当前变更引入的问题。
SAST：仅当发现问题的文件+行号落在
git diff -U0
输出的修改行范围内时，才纳入结果。解析
@@ -X,Y +A,B @@
代码块确定变更范围；排除该范围外的预存在问题。
SCA：仅当新增或更新的包出现更多漏洞或更高严重级别的漏洞时才纳入结果。应用净改进规则——若变更减少了整体漏洞数量或降低了严重级别，则不阻止提交。
IaC：仅当配置错误存在于新增或修改的资源块中时才纳入结果。

Phase 4: Report & Decision

阶段4：报告与决策

Step 4.1: Severity Threshold Configuration

步骤4.1：严重级别阈值配置

ModeBlock OnWarn OnAllow
StrictLow+--
StandardHigh+MediumLow
RelaxedCritical onlyHighMedium, Low
模式阻止条件警告条件允许条件
严格模式低及以上级别--
标准模式高及以上级别中级别低级别
宽松模式仅严重级别高级别中、低级别

Step 4.2: Generate Report

步骤4.2：生成报告

undefined
undefined

Secure At Inception Scan Results

源头安全防护扫描结果

Summary

摘要

Scan TypeNew IssuesBlocked
Code (SAST)XYes/No
Dependencies (SCA)YYes/No
Infrastructure (IaC)ZYes/No
扫描类型新问题数量是否阻止
代码扫描（SAST）X是/否
依赖扫描（SCA）Y是/否
基础设施扫描（IaC）Z是/否

New Code Vulnerabilities (SAST)

新增代码漏洞（SAST）

SeverityTypeFileLineDescription
HighSQL Injectionsrc/db.ts45User input in query
严重级别类型文件行号描述
高SQL注入src/db.ts45用户输入直接用于查询

New Dependency Vulnerabilities (SCA)

新增依赖漏洞（SCA）

SeverityPackageVulnerabilityFix Version
Criticallodash@4.17.15Prototype Pollution4.17.21
严重级别包名漏洞类型修复版本
严重lodash@4.17.15原型污染4.17.21

New Infrastructure Issues (IaC)

新增基础设施问题（IaC）

SeverityResourceIssueRecommendation
Highaws_s3_bucketPublic access enabledSet block_public_access
严重级别资源问题描述修复建议
高aws_s3_bucket开启了公共访问权限设置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
  1. /snyk-fix SNYK-JS-LODASH-1234
    - 修复lodash漏洞
  2. 检查
    src/db.ts:45
    以修复SQL注入问题

Decision: [BLOCKED / ALLOWED]

决策：[阻止 / 允许]

[Reason based on severity threshold]
undefined
[基于严重级别阈值的原因说明]
undefined

Step 4.3: Block Decision Logic

步骤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
如果存在任何新增问题的严重级别 >= 阈值：
  阻止提交 - 修复完成前不允许继续
  提供具体修复命令
否则：
  允许提交 - 可安全继续
  记录需后续关注的警告信息

Phase 5: Track Metrics

阶段5：指标追踪

After each scan that finds and helps fix issues, run 
snyk_send_feedback
with:
  • path
    : project root (absolute path)
  • preventedIssuesCount
    : count of NEW issues found (delta, not cumulative)
  • fixedExistingIssuesCount
    : 
    0
    (this skill prevents, doesn't fix existing issues)
Only count issues found in NEW code that would have been committed without this scan.
每次扫描发现并协助修复问题后，运行
snyk_send_feedback
并传入以下参数：
  • path
    ：项目根目录（绝对路径）
  • preventedIssuesCount
    ：发现的新增问题数量（增量，非累计）
  • fixedExistingIssuesCount
    ：
    0
    （本技能仅阻止新问题，不修复已存在问题）
仅统计若未进行本次扫描就会被提交的新增代码中的问题。

Best Practices

最佳实践

  • Run automatically after generating or modifying code, and before suggesting a commit; also on request for explicit security checks.
  • Cache results keyed by 
    file + content_hash
    with a 12-hour TTL; only rescan changed files and batch by directory.
  • False positives: Use a 
    .snyk
    policy file to suppress confirmed false positives, then re-run to verify:
    yaml
    ignore:
  SNYK-JS-EXAMPLE-12345:
    - '*':
        reason: 'False positive - input is validated upstream'
        expires: 2025-12-31
  • Threshold tuning: Start with Standard mode; switch to Relaxed if blocks are too frequent, or Strict after low/medium severity incidents.
  • CI/CD integration: Invoke on pull request creation or pushes to feature branches; block merge if threshold is exceeded.
  • 自动运行：在生成或修改代码后、建议提交前自动运行；也可响应明确的安全检查请求运行。
  • 缓存结果：以
    file + content_hash
    为键缓存结果，TTL为12小时；仅重新扫描变更文件，并按目录批量处理。
  • 误报处理：使用
    .snyk
    策略文件屏蔽已确认的误报，然后重新扫描验证：
    yaml
    ignore:
  SNYK-JS-EXAMPLE-12345:
    - '*':
        reason: '误报 - 输入已在上游验证'
        expires: 2025-12-31
  • 阈值调整：初始使用标准模式；若频繁出现阻止情况可切换为宽松模式，若发生低/中级别漏洞事件则切换为严格模式。
  • CI/CD集成：在创建拉取请求或推送至特性分支时触发扫描；若超过阈值则阻止合并。

Error Handling

错误处理

SituationAction
Authentication errorRun 
snyk_auth
and retry; prompt user for manual authentication if still failing
Scan timeoutRetry once with smaller scope; report partial results if still failing
No changes detectedReport "No code changes detected - nothing to scan"; offer full project scan on request
Unsupported files onlyReport "No scannable files in changes" with a list of skipped file types and reasons
场景处理动作
认证错误运行
snyk_auth
并重试；若仍失败则提示用户手动认证
扫描超时缩小范围重试一次；若仍失败则报告部分结果
未检测到变更报告“未检测到代码变更 - 无需扫描”；应用户请求可提供全项目扫描
仅包含不支持的文件报告“变更中无可扫描文件”，并列出跳过的文件类型及原因

Constraints

约束条件

  1. New Issues Only: Never block on pre-existing issues (that's remediation's job)
  2. Minimal Noise: Filter aggressively to avoid alert fatigue
  3. Fast Feedback: Complete scan within 30 seconds for typical changes
  4. Non-Destructive: Never modify code, only report findings
  5. Actionable Output: Every finding must have a clear fix path
  1. 仅关注新问题：绝不因已存在的问题阻止提交（修复已有问题属于 remediation 范畴）
  2. 最小化干扰：严格过滤以避免告警疲劳
  3. 快速反馈：针对典型变更，扫描需在30秒内完成
  4. 非破坏性：绝不修改代码，仅报告发现的问题
  5. 可执行输出：每个发现的问题必须有明确的修复路径