How Nark fits in your stack

Nark occupies the "misuse of trusted packages" layer. It complements SAST tools (Semgrep, Snyk Code, CodeQL), package-vulnerability scanners (Socket, Dependabot, Snyk Open Source), and lint tools (ESLint, TypeScript compiler). It does not replace any of them. If you have all four categories in place, Nark still adds a surface none of them cover: the calling code's treatment of packages you already trust.

The stack, top to bottom

A modern TypeScript project typically layers several kinds of correctness checks. Each layer answers a different question.

• Package-integrity layer. Socket, Dependabot, Snyk Open Source. Are the packages you install safe versions, free of known CVEs and supply-chain tampering?
• Custom-code taint layer. Semgrep, Snyk Code, CodeQL. Does the flow of untrusted input through your own code create a vulnerability (SQL injection, XSS, SSRF)?
• Style and correctness layer. ESLint, TypeScript compiler, Prettier. Is the code syntactically valid, type-safe, and consistent with team style?
• Package-misuse layer (Nark). Does the calling code correctly handle the errors, timeouts, and return shapes that each package documents? Every scan runs against a curated Nark Profile library of 169+ packages.
• Runtime layer. Sentry, Datadog, New Relic. When something did break in production, do you know it, and can you reconstruct why?

What sits above Nark: dependency-side tools

Socket and Dependabot watch your package.json and lockfiles. They flag known-vulnerable versions, malicious package updates, and supply-chain risk signals like new maintainers or install-script changes. Snyk Open Source and GitHub Advanced Security offer similar coverage with different feed sources and remediation UX.

Nark does not do any of this. It assumes your dependencies are already at safe versions. If axios 1.6.0 has a known CVE, Socket or Dependabot tells you. Nark tells you nothing about that. Nark asks the different question: given that axios 1.6.0 is installed and trusted, does your code actually catch the errors axios's docs say it can throw?

Run both. They do not overlap.

What sits alongside Nark: code-side tools

Semgrep and CodeQL analyze the dataflow of your own code. They catch tainted input reaching a sink, unsafe deserialization, hard-coded secrets, and framework-specific misuses (unsafe HTML in React, missing CSRF tokens, and similar). Snyk Code is in the same family. Their surface is broad and their strength is finding classes of vulnerability that live in the shape of your code, not in any specific package.

ESLint and the TypeScript compiler catch syntactic and style violations plus type errors. Rules like @typescript-eslint/no-floating-promises get close to Nark territory, but they operate on generic promise-return patterns, not on specific package APIs. ESLint has no knowledge that a particular axios call can throw a specific error and needs a specific catch shape.

Nark's surface starts where these end. It is grounded in the docs and changelogs of specific npm packages. A Nark Profile for stripe says (roughly) "stripe.charges.create can throw StripeCardError, StripeRateLimitError, StripeConnectionError; the calling code must handle these before returning success." Semgrep does not know that. TypeScript does not know that. ESLint does not know that.

What sits below Nark: runtime

Sentry, Datadog, and New Relic tell you what broke in production. They are the last line. Nark catches at build time, before code merges. Observability catches at runtime, after code ships. The two are complementary. Nark reduces the volume of preventable errors reaching Sentry. Sentry catches the residual classes Nark cannot know about (network flakes, user data quirks, provider outages).

What Nark uniquely catches

Specifically, the patterns that only appear when you know a package's documented failure modes:

• Empty catch blocks around package calls that swallow real error signals.
• Missing catches on package methods documented to throw (openai rate limits, stripe declined cards, prisma constraint violations, and similar).
• Missing await on package methods that return promises the calling code treats as sync.
• Wrong assumptions about what a package throws versus what it returns (returning null on a method that actually throws, or catching an error on a method that only returns a result object).
• Version-specific behavior changes where a package's error contract shifted in a major release.

Composability: three combinations customers run

Nark + Semgrep + Socket. The audit-grade static stack. Socket handles dependency integrity, Semgrep handles custom-code taint analysis, Nark handles package-misuse. Three tools, three distinct surfaces, no overlap. Common shape for teams pursuing SOC 2 or ISO 27001 who want their CC7.1 evidence pile to reflect coverage across all three layers.

Nark + Sentry. The catch-at-build-then-catch-at-runtime story. Nark blocks known failure modes before merge; Sentry catches the rest. Teams that adopt this pattern typically see the Sentry inbox get quieter as Nark-covered packages get their error paths tightened up.

Nark + Vanta (or Drata). The CC7.1 and CC8.1 evidence pipeline. Nark scan artifacts pipe into your compliance evidence store as timestamped, queryable audit records. Every PR scan is CC8.1 change-management evidence. Every scheduled main-branch scan is CC7.1 monitoring evidence. See the SOC 2 page for the full mapping.

Decision framework

"Should I add Nark if I already have X?"

• If you already have Semgrep or CodeQL: yes. They catch code-flow classes. Nark catches package-behavior classes. Different surface, no overlap.
• If you already have Snyk, Socket, or Dependabot: yes. They catch known-vulnerable versions. Nark catches misuse of safe versions. Different surface, no overlap.
• If you already have ESLint plus strict TypeScript: yes. They catch style and type violations. Nark catches package-specific error-handling violations grounded in each package's documented behavior. Different surface, no overlap.
• If you already have Sentry or Datadog: yes. They catch failures at runtime, after ship. Nark catches them at build time, before merge.
• If you have all four categories: still yes. The package-behavior surface is not covered by any of them.

The only case where Nark is not additive: your codebase does not call any of the 169+ packages in the profile library. That is rare in practice. If you are running a modern TypeScript stack, you are almost certainly calling axios, prisma, stripe, openai, a cloud SDK, or a queue client, all of which have profiles.

Next steps

Wire Nark into your CI in under 10 minutes with the CI setup guide. For compliance-adjacent buyers, the SOC 2 page covers the CC7.1 and CC8.1 evidence mapping. For subprocessor and security-posture questions, see the trust page. To see Nark in action against your own repo, run npx nark from the project root.