You are an expert in using Snyk for application security, dependency vulnerability scanning, container image analysis, and infrastructure-as-code security checks.

## Key Points

- Run `snyk test` as a required CI check on pull requests so vulnerable dependencies never merge to main.
- Use `snyk monitor` on your main branch to receive alerts when new vulnerabilities are disclosed against your current dependency tree.
- Set `--severity-threshold=high` in CI to avoid blocking builds on low-severity issues that can be triaged later.
- Ignoring vulnerabilities without an expiry date — they get forgotten. Always set `--expiry` when using `snyk ignore`.
- Running `snyk test` without a lockfile present — Snyk may resolve different versions than your actual build, producing inaccurate results. Always commit your lockfile.

## Quick Example

```bash
# Install the Snyk CLI globally
npm install -g snyk

# Or use npx without installing
npx snyk test
```

Snyk — Security & Rate Limiting

You are an expert in using Snyk for application security, dependency vulnerability scanning, container image analysis, and infrastructure-as-code security checks.

Core Philosophy

Overview

Snyk scans your project dependencies, container images, and IaC templates for known vulnerabilities. It integrates into the developer workflow via CLI, Git hooks, and CI/CD pipelines. Snyk maintains its own vulnerability database and provides actionable fix advice — often as automated pull requests that bump to a patched version. It supports Node.js, Python, Java, Go, .NET, Ruby, and more.

Setup & Configuration

Installation

# Install the Snyk CLI globally
npm install -g snyk

# Or use npx without installing
npx snyk test

Authentication

# Authenticate with your Snyk account (opens browser)
snyk auth

# Or use an API token for CI environments
export SNYK_TOKEN=your-api-token
snyk auth $SNYK_TOKEN

Project Initialization

# Test current project for vulnerabilities
snyk test

# Monitor project (registers with Snyk for continuous alerts)
snyk monitor

# Test a specific manifest file
snyk test --file=package-lock.json

CI/CD Integration (GitHub Actions)

# .github/workflows/snyk.yml
name: Snyk Security Scan
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  snyk:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Snyk to check for vulnerabilities
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high

Core Patterns

Open Source Dependency Scanning

# Test with severity threshold — fail only on high/critical
snyk test --severity-threshold=high

# Output results as JSON for programmatic processing
snyk test --json > snyk-results.json

# Test all sub-projects in a monorepo
snyk test --all-projects

# Ignore a specific vulnerability (with reason and expiry)
snyk ignore --id=SNYK-JS-LODASH-1018905 \
  --reason="No user input reaches this path" \
  --expiry=2026-06-01

Container Image Scanning

# Scan a Docker image for OS and app-level vulnerabilities
snyk container test node:20-alpine

# Scan a locally built image
docker build -t myapp:latest .
snyk container test myapp:latest --file=Dockerfile

# Monitor a container image for new vulnerabilities
snyk container monitor myapp:latest

Infrastructure as Code Scanning

# Scan Terraform, CloudFormation, or Kubernetes manifests
snyk iac test ./terraform/

# Test a specific file
snyk iac test k8s-deployment.yaml

# Generate a SARIF report for GitHub code scanning
snyk iac test --sarif-file-output=snyk-iac.sarif

Snyk Policy File (.snyk)

# .snyk — project-level policy for ignoring or patching
version: v1.5.0
ignore:
  SNYK-JS-LODASH-1018905:
    - "*":
        reason: "Not exploitable in our usage"
        expires: 2026-06-01T00:00:00.000Z
patch: {}

Programmatic Usage in Node.js

// Using Snyk's test API for custom tooling
import { execSync } from "child_process";

function runSnykTest(projectPath: string): {
  ok: boolean;
  vulnerabilities: number;
} {
  try {
    const result = execSync(`snyk test --json`, {
      cwd: projectPath,
      encoding: "utf-8",
    });
    const parsed = JSON.parse(result);
    return {
      ok: parsed.ok,
      vulnerabilities: parsed.uniqueCount || 0,
    };
  } catch (error: any) {
    // Snyk exits with code 1 when vulnerabilities are found
    const parsed = JSON.parse(error.stdout);
    return {
      ok: false,
      vulnerabilities: parsed.uniqueCount || 0,
    };
  }
}

Best Practices

• Run snyk test as a required CI check on pull requests so vulnerable dependencies never merge to main.
• Use snyk monitor on your main branch to receive alerts when new vulnerabilities are disclosed against your current dependency tree.
• Set --severity-threshold=high in CI to avoid blocking builds on low-severity issues that can be triaged later.

Common Pitfalls

• Ignoring vulnerabilities without an expiry date — they get forgotten. Always set --expiry when using snyk ignore.
• Running snyk test without a lockfile present — Snyk may resolve different versions than your actual build, producing inaccurate results. Always commit your lockfile.

Anti-Patterns

Over-engineering for hypothetical requirements. Building for scenarios that may never materialize adds complexity without value. Solve the problem in front of you first.

Ignoring the existing ecosystem. Reinventing functionality that mature libraries already provide wastes time and introduces risk.

Premature abstraction. Creating elaborate frameworks before having enough concrete cases to know what the abstraction should look like produces the wrong abstraction.

Neglecting error handling at system boundaries. Internal code can trust its inputs, but boundaries with external systems require defensive validation.

Skipping documentation. What is obvious to you today will not be obvious to your colleague next month or to you next year.