Snyk Pocket Book

Posted on by uplatzblog

Snyk Pocket Book — Uplatz

50 in-depth cards • Wide layout • Readable examples • 20-question interview Q&A included

Section 1 — Foundations

1) What is Snyk?

Developer-first security platform that finds & fixes issues across open-source deps (SCA), code (SAST), containers, and IaC. Integrates into IDEs, Git, and CI/CD.

Areas: SCA • Snyk Code • Snyk Container • Snyk IaC • License Compliance

2) Core Workflow

Authenticate → test locally & in CI → monitor projects in Git → receive PRs with upgrades/fixes → enforce quality gates.

snyk auth
snyk test
snyk monitor

3) Projects & Targets

Connect org → import repos/registries → Snyk creates Projects per manifest (package.json, pom.xml), image, or IaC file.

4) Snyk CLI

Portable scanner for local dev and CI. Supports token auth, policy files, severity thresholds, and JSON outputs.

snyk test --severity-threshold=high --json > snyk-report.json

5) Severity & Prioritization

Default by CVSS; enhance with exploit maturity, reachable paths, and environment context to focus on actionable vulns.

6) Fix PRs

Snyk can open PRs to bump versions or apply patches with release notes and risk diffs.

7) License Policies

Detect incompatible licenses, define allow/deny policies, and block merges for violations.

8) Issue Lifecycle

New → triage → assigned → fix/ignore (time-bound) → verify in monitor with baseline decreasing over time.

9) Integrations

GitHub/GitLab/Bitbucket/Azure Repos, Jenkins/GHA/CircleCI, IDEs (VS Code/JetBrains), container registries, Slack/Teams.

10) Q&A — “What’s developer-first?”

Answer: Tools run where devs work (IDE/Git/CI), produce actionable fixes (PRs), and fit existing workflows without security gatekeeping bottlenecks.

Section 2 — Open Source (SCA), Code (SAST) & Policies

11) Snyk Open Source (SCA)

Scans manifests & lockfiles to identify vulnerable packages/transitives and suggests minimal, safe upgrades.

snyk test --file=pom.xml
snyk test --file=package-lock.json

12) Reachability

Determines if vulnerable code is actually invoked in your code path to cut noise and prioritize fixes.

13) Snyk Code (SAST)

Analyzes your proprietary source for patterns like SQLi/XSS/Path traversal; fast feedback in IDE and CI.

snyk code test
snyk code test --report

14) Custom Rules (Code)

Define org rules to catch risky internal patterns, enforce sanitization, or flag banned APIs.

15) Policies & Ignoring

Use .snyk policy to ignore issues with expiry & reason. Avoid permanent ignores; set review cadence.

# .snyk
ignore:
  SNYK-JS-...:
    - reason: "False positive"
      expires: 2025-12-31

16) Severity Thresholds

Fail builds only for high/critical or when reachable; avoid blocking on low without context.

snyk test --severity-threshold=high

17) Fix PR Strategy

Prefer patch/minor upgrades; batch by app to reduce churn; use lockfile maintenance jobs.

18) Monorepos

Multiple manifests per repo; map directories to distinct Projects; enable auto-import and PR checks per package.

19) SBOM

Export SBOM (CycloneDX/SPDX) for compliance and supply-chain visibility.

snyk sbom --format=cyclonedx1.4 --file=bom.json

20) Q&A — “Fix transitive or direct?”

Answer: Prefer bumping the direct dependency to a version that pulls a safe transitive; patch only if vendor upgrade isn’t available.

Section 3 — Containers, Images, Kubernetes & Supply Chain

21) Image Scanning

Scans OS packages & language deps inside images. Integrate with registries (ECR/GCR/ACR/Docker Hub).

snyk container test repo/image:tag
snyk container monitor repo/image:tag

22) Base Image Recommendations

Snyk suggests safer base images with fewer CVEs; switch to slim/alpine where compatible.

23) Dockerfile Guidance

Best practices: pin versions, drop root, remove package caches, multi-stage builds, small base.

24) Kubernetes Workloads

Scan K8s manifests/Helm for misconfigs: privileged pods, no resource limits, wide host mounts.

snyk iac test k8s/ --report

25) Supply Chain Context

Map image → deployment → cluster; focus on images actually running in prod and internet-exposed paths.

26) Container Gate in CI

Fail pipeline if high/critical CVEs present or if fixable updates exist beyond policy thresholds.

snyk container test repo/img:tag --severity-threshold=high --fail-on=all

27) Images at Rest vs Runtime

Prioritize runtime-referenced images; deprecate unused tags; remove stale images from registries.

28) Private Registries

Auth via env/flags; store tokens/keys in CI secret store; avoid printing creds in logs.

snyk config set api=${SNYK_TOKEN}

29) Signing & Provenance

Combine Snyk with image signing (Cosign) & attestations to ensure integrity of scanned, approved artifacts.

30) Q&A — “Alpine always better?”

Answer: Often fewer CVEs, but musl vs glibc differences can break libs; prefer vendor-maintained slim images when compatibility matters.

Section 4 — IaC, CI/CD Integration, IDEs & Governance

31) Snyk IaC

Scans Terraform, CloudFormation, ARM/Bicep, K8s, Helm for misconfig. Map to CIS/NIST controls.

snyk iac test terraform/ --severity-threshold=high

32) Drift & Posture

Monitor IaC repos & live cloud to catch config drift. Fix in code, not in the console.

33) Git PR Checks

Block merges when new high/critical introduced; auto-comment with fix advice & links.

34) GitHub Actions

Use official action to test on push/PR; upload SARIF to code scanning.

- uses: snyk/actions/node@master
  with: { command: test }
  env: { SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }} }

35) Jenkins

Run CLI in pipeline; fail by threshold; archive JSON reports for dashboards.

sh 'snyk test --json > snyk.json'; archiveArtifacts 'snyk.json'

36) IDE Plugins

VS Code/JetBrains show inline issues and quick-fixes; teach devs to fix pre-commit.

37) Reporting & Trends

Org dashboards, aging SLAs, mean time to remediate (MTTR), license posture, reachable vuln counts.

38) Governance

Define org policies for severity, licenses, and auto-fix windows; enforce exceptions with expiry.

39) Multi-Org & Teams

Map Snyk orgs to business units; RBAC for readers/developers/admins; scope tokens narrowly.

40) Q&A — “Block all criticals?”

Answer: Block on critical/high that are reachable or fixable; log & track the rest to avoid developer fatigue and pipeline deadlocks.

Section 5 — Recipes, Tips, and Interview Q&A

41) Recipe: Node.js CI Gate

Fail pipeline on new high vulns; generate SBOM; attach HTML report artifact.

snyk test --severity-threshold=high
snyk sbom --format=cyclonedx1.4 --file=bom.json

42) Recipe: Java + Maven

Scan both SCA & SAST; break build on reachable highs; allow report-only on lows.

snyk test --file=pom.xml --severity-threshold=high
snyk code test --severity-threshold=high

43) Recipe: Docker Image Gate

Scan, suggest base image, enforce no criticals; push only on pass.

snyk container test app:tag --severity-threshold=high --fail-on=all

44) Recipe: IaC in PRs

Scan Terraform plan files for precise drift; annotate PR with failing controls.

terraform plan -out=tfplan
terraform show -json tfplan > plan.json
snyk iac test plan.json

45) Common Pitfalls

Blocking on low severity, permanent ignores, not enabling monitor, scanning only root (missing submodules/dirs).

46) Performance Tips

Cache dependencies, test only changed paths for monorepos, run SAST in parallel with builds.

47) Secrets Handling

Use CI secret stores; pass SNYK_TOKEN via env; never commit tokens or include in logs.

48) Compliance Mapping

Map Snyk controls & license policies to SOC2/ISO; export evidence for audits with project snapshots.

49) Rollout Plan (30 Days)

Week 1: enable IDE + PR checks • Week 2: add CI gates (high only) • Week 3: container/IaC • Week 4: policy & dashboards.

50) Interview Q&A — 20 Practical Questions (Expanded)

1) Snyk vs generic scanners? Developer-focused, rich fix PRs, ecosystem depth, reachability & license intelligence.

2) SCA vs SAST? SCA = open-source/3rd-party deps; SAST = your custom code. Both needed.

3) What is reachability? Whether vulnerable code path is invoked; helps reduce noise and prioritize.

4) CLI vs Git integration? CLI for dev/CI checks; Git integration for continuous monitoring & fix PRs.

5) When to block a build? On reachable high/critical or fixable issues per policy; warn on others.

6) Handling transitive vulns? Upgrade direct deps to bring safe transitives; patch if no upgrade.

7) Base image advice matters? Yes—switching base can remove hundreds of OS CVEs at once.

8) What does snyk monitor do? Snapshots dependencies to track newly disclosed vulns over time.

9) License policy breach? Block merges, notify owners, suggest compliant alternatives.

10) How to avoid dev fatigue? Set thresholds, use reachability, batch fixes, time-bound ignores.

11) IaC vs runtime? Fix posture in code first; monitor runtime for drift and exceptions.

12) SBOM value? Visibility for supply chain, contractual compliance, faster incident response.

13) Secure token handling? CI secrets, least privilege, rotation; never echo; scope per org/project.

14) On-prem or cloud? Snyk SaaS is default; evaluate connectivity/security requirements for alternatives.

15) False positives? Use reachability, custom rules, and policy ignore with expiry + justification.

16) Monorepo setup? Import per subdir; separate Projects; run partial tests per changed path.

17) Container fix order? 1) base image 2) package updates 3) drop dev tools 4) permissions.

18) KPIs to track? MTTR, open high/critical, reachable high, % repos monitored, license violations.

19) Rollout strategy? Start IDE/PR checks → CI gates for high/critical → expand to containers/IaC.

20) Biggest gotcha? Scanning only at release—shift-left in IDE/PR to avoid late-cycle fire drills.