snyk/secure-at-inception

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 Type | Trigger Files | MCP 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 | | IaC | Infrastructure: .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.

---

Phase 1: Change Detection

Step 1.1: Gather Changed Files

Check for changes using one of these methods (in order of preference):

1. Git diff (if in a git repo):

   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

Step 1.2: Categorize Files by Scan Type

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).

---

Phase 2: Execute Scans

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).

Step 2.1: SAST Scan (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

Step 2.2: SCA Scan (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.

Step 2.3: IaC Scan (snyk_iac_scan)

• path: directory containing IaC files
• severity_threshold: "medium" (default) or as configured

---

Phase 3: Filter to New Issues

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.

---

Phase 4: Report & Decision

Step 4.1: Severity Threshold Configuration

| Mode | Block On | Warn On | Allow | |------|----------|---------|-------| | Strict | Low+ | - | - | | Standard | High+ | Medium | Low | | Relaxed | Critical only | High | Medium, Low |

Step 4.2: Generate Report

## 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]

Step 4.3: Block Decision Logic

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

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.

---

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:

  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.

---

Error Handling

| Situation | Action | |-----------|--------| | Authentication error | Run snyk_auth and retry; prompt user for manual authentication if still failing | | Scan timeout | Retry once with smaller scope; report partial results if still failing | | No changes detected | Report "No code changes detected - nothing to scan"; offer full project scan on request | | Unsupported files only | Report "No scannable files in changes" with a list of skipped file types and reasons |

---

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