Secure At Inception

File Type → Scan Type Reference

.js

.ts

.py

.java

.go

.rb

.php

.cs

.swift

.kt

.scala

.rs

.c

.cpp

.dart

snyk_code_scan

package.json

requirements.txt

pom.xml

build.gradle

Gemfile

go.mod

Cargo.toml

*.csproj

composer.json

snyk_sca_scan

.tf

.tfvars

apiVersion

kind

template.json

.yaml

serverless.yml

snyk_iac_scan

.md

.txt

.rst

Phase 1: Change Detection

Step 1.1: Gather Changed Files

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

Step 1.2: Categorize Files by Scan Type

apiVersion

kind

AWSTemplateFormatVersion

Phase 2: Execute Scans

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

git diff -U0

@@ -X,Y +A,B @@

Phase 4: Report & Decision

Step 4.1: Severity Threshold Configuration

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 | lodash@4.17.15   | 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

snyk_send_feedback

• path

  : project root (absolute path)

• preventedIssuesCount

  : count of NEW issues found (delta, not cumulative)

• fixedExistingIssuesCount

  :

  0

  (this skill prevents, doesn't fix existing issues)

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.

Error Handling

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