English for Snyk Vulnerability Scanning

Dependency-scanning alerts get dismissed or escalated based on how well someone can explain them, and Snyk reports carry precise vocabulary — severity, exploit maturity, transitive dependency — that turns a vague “there’s a vulnerability” into a decision someone can actually act on.

Key Vocabulary

Vulnerability severity — Snyk’s rating (typically Low, Medium, High, Critical) reflecting the potential impact of a vulnerability, based on factors like the CVSS score, whether it’s remotely exploitable, and whether a working exploit is publicly known. “This is rated High, not Critical, because while the vulnerability is real, it requires local access to exploit — that changes how urgently we need to patch it.”

Transitive dependency — a package your project depends on indirectly, pulled in by a direct dependency rather than listed explicitly in your own manifest, which is why a vulnerability can appear in a package you never directly installed. “We don’t use this package directly — it’s a transitive dependency pulled in by our logging library, so the fix has to come from either upgrading the logging library or overriding the version manually.”

Exploit maturity — an indicator of how usable a known vulnerability is in practice, ranging from “no known exploit” to “proof of concept” to “mature,” which affects how urgently a fix should be prioritized beyond the raw severity score. “The CVSS score alone made this look urgent, but exploit maturity is listed as ‘no known exploit,’ so we prioritized two other findings with active proof-of-concept code first.”

Fix PR — a pull request Snyk generates automatically that upgrades a vulnerable dependency to a patched version, intended to reduce the manual work of resolving a known issue. “Instead of manually bumping the version and checking for breaking changes, we just reviewed Snyk’s fix PR, ran the test suite against it, and merged it once CI was green.”

Ignore policy — a rule that suppresses a specific vulnerability finding from future scans, used when a vulnerability doesn’t apply in your context (unreachable code path, mitigated elsewhere) rather than genuinely fixing it. “We added an ignore policy for this finding with an expiry date and a documented reason — the vulnerable function is never called in our code path — rather than leaving it unresolved and re-triaged every scan.”

Common Phrases

• “Is this a direct dependency, or is it coming in transitively through something else in our manifest?”
• “What’s the exploit maturity here — is there an actual proof-of-concept, or is this theoretical for now?”
• “Can we just merge Snyk’s fix PR, or does this upgrade involve a breaking change we need to test manually?”
• “Should we fix this, or does it qualify for an ignore policy with a documented justification?”
• “Is this severity rating driven by the CVSS score alone, or does exploit maturity change how urgent it actually is?”

Example Sentences

Triaging a new alert: “This is a transitive dependency three levels deep, so a direct version bump in our manifest won’t fix it — we need to wait for the parent package to update, or override the version explicitly.”

Explaining a prioritization decision: “We’re patching the Critical finding with known exploit maturity today, and deferring the Medium finding with no known exploit to the next sprint — severity alone doesn’t set the order here.”

Documenting a suppression: “We added an ignore policy on this finding because the vulnerable code path is guarded by a feature flag that’s permanently off in production — but it’s set to expire in 90 days so we revisit it if that changes.”

Professional Tips

• Distinguish severity from exploit maturity explicitly when prioritizing fixes — a high severity score with no known exploit is a different kind of risk than a lower score with an active proof-of-concept.
• Name transitive dependency precisely when a vulnerability can’t be fixed with a simple direct upgrade — it explains why the fix requires waiting on, or overriding, an upstream package.
• Review a fix PR for breaking changes rather than merging it blindly — Snyk automates the diff, not the judgment about whether the new version is safe to adopt.
• Document every ignore policy with a reason and an expiry — an undocumented, permanent ignore is how genuinely exploitable vulnerabilities get forgotten.

Practice Exercise

1. Explain the difference between severity and exploit maturity.
2. Describe why a transitive dependency vulnerability sometimes can’t be fixed with a direct version bump.
3. Write a sentence explaining when an ignore policy is an appropriate response to a finding.