# Why I run Snyk on the garden

> Snyk scans two things I cannot fully review by hand: the code I wrote and the hundreds of dependencies I did not.

Snyk is the dependency-and-code scanner in my [repo security setup](/garden/securing-the-repo). It runs on every pull request and every push to main. Here is what it does and why a static site still earns one.

## Snyk scans your dependencies and your own code

Snyk is a developer security platform. Two of its scanners matter here. Snyk Open Source (SCA) checks my open-source libraries for known vulnerabilities and license issues. Snyk Code (SAST) reads my own source for security flaws ([Snyk docs](https://docs.snyk.io/scan-with-snyk)). One tool, two blind spots covered: the code I shipped, and the code I pulled in.

## Why I need it: I did not write most of what ships

A modern `npm install` drags in hundreds of transitive packages, the dependencies of my dependencies. That is where the risk hides. Snyk's own research found that 78% of vulnerabilities live in indirect dependencies, not the ones you picked directly ([Snyk](https://snyk.io/blog/78-of-vulnerabilities-are-found-in-indirect-dependencies-making-remediation-complex/)). I will never read that tree by hand. A scanner that tracks the public CVE feeds reads it for me on every push.

The SAST half covers the other gap. Code review catches design mistakes and misses the security-shaped ones: an unsafe sink, a leaked token. Snyk Code flags those against known patterns before I merge.

## How it runs here

Two commands in the CI job:

* `snyk test` (SCA) scans the dependency tree.
* `snyk code test .` (SAST) scans my source.

Both are gated at `--severity-threshold=high`, so only high and critical findings fail the build. Both pin `--org=weijie-ng`, because the CI token otherwise resolves no org and the code scan 403s. A repo-root `.snyk` file excludes the vendored third-party skills, so Snyk Code scans only what I actually wrote, not tooling I bundled but did not author.

## The honest limit

Snyk is one layer, not a promise. The high-severity gate is deliberate: lows and mediums still log, but they do not block a merge, so a non-exploitable transitive dep will not stall my work. It scans against known vulnerabilities and known bad patterns, so a novel bug or a logic flaw walks straight past it. It narrows the odds without closing them.

## The bottom line

I run Snyk because I cannot personally audit a dependency tree I did not build, or catch every security-shaped mistake in my own code. It reads both on every push, fails the build only when a finding is worth failing over, and hands the ongoing dependency watch to [Dependabot watches my dependencies so I do not have to](/garden/dependabot).