SOC 2 and Nark

Nark is a scanner, not a compliance platform. But its output is exactly the machine-checkable evidence auditors expect for CC7.1 (detection of newly introduced vulnerabilities) and CC8.1 (change management with test gates). This page explains where Nark fits in a SOC 2 program, and what Nark's own compliance status is today.

What SOC 2 is

SOC 2 is an attestation report, not a certification. A licensed CPA firm examines your controls and issues an opinion on whether those controls are designed and operating effectively. The framework is the AICPA Trust Services Criteria, most recently updated in 2017 and still current. Vendors who say "SOC 2 certified" are misusing the term. The correct phrasing is "we have a SOC 2 Type II report."

Two report types. Type I is a point-in-time snapshot of control design. Type II covers a period, usually 3, 6, or 12 months, and evaluates both control design and operating effectiveness across that window. Enterprise buyers almost always want Type II. A vendor showing only Type I typically reads as "in progress" to procurement, not "done."

There are five Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Only Security (the Common Criteria) is mandatory. Most SaaS companies at 100 to 300 headcount scope in Security, Availability, and Confidentiality. Processing Integrity and Privacy are added when the business handles payments, financial data, or regulated personal information.

The Common Criteria that matter for scanners

Within the Security TSC, two Common Criteria are directly relevant to a tool like Nark.

CC7.1 requires that the entity use detection and monitoring procedures to identify changes to configurations that introduce new vulnerabilities, and susceptibilities to newly discovered vulnerabilities. This is where SAST tools, dependency scanners, and vulnerability management platforms cite themselves.

CC8.1 requires that the entity authorize, design, develop, test, approve, and implement changes to infrastructure, data, software, and procedures. This is where PR-gate controls, code review requirements, and CI/CD pipeline gates cite themselves.

Nark contributes to both. It is SAST-adjacent for CC7.1, catching a specific class of vulnerability: misuse of safe versions of packages, where the package is up to date and CVE-free but the calling code does not handle the errors the package documents. For CC8.1, every Nark scan on a pull request is a timestamped, testable, documented change gate. The scan blocks the merge in enforcing mode or reports in advisory mode. That is exactly the shape of evidence CC8.1 expects.

Nark does not satisfy CC7.1 or CC8.1 on its own. It contributes to the evidence pile. Your auditor decides whether the evidence is sufficient. Our position is that Nark output is the same shape of evidence your auditor already accepts from your test runner or CI pipeline, and that overlaying it on top of your existing dependency scanner (Snyk, Dependabot, Socket) closes a specific gap those tools do not cover: correct usage of packages that are themselves at safe, non-vulnerable versions.

What Nark's PR-scan audit trail looks like as evidence

• Every pull request triggers a scan.
• Every scan writes a timestamped, immutable audit record to your evidence store.
• Every audit record cites the exact violation: file and line, which Nark Profile matched, and which postcondition was breached.
• Auditors get a queryable log covering the full observation window. There is nothing to reconstruct at audit time.
• The scanner rules themselves are versioned. Our public release ledger tracks every scanner update with citations to the source evidence (docs, CVE, changelog entry) that motivated it. Auditors can trace a specific rule back to a specific source.

What Nark is not

• Not a compliance platform. Vanta, Drata, and Secureframe fill that role. They automate evidence collection across your stack. Nark plugs into them as one more evidence source.
• Not a SAST tool. Snyk Code and Semgrep handle taint analysis and traditional static analysis. Nark focuses on package behavior, not code flow.
• Not a vulnerability scanner. Socket, Dependabot, and Snyk Open Source handle known CVEs in your dependencies. Nark assumes your dependencies are already at safe versions and asks the different question: is the calling code using them correctly?

Put simply: Nark is package-behavior enforcement. Your code correctly uses the packages you already trust.

Nark's own SOC 2 status

Nark is not yet SOC 2 attested. We are pre-audit. What we have today:

• All infrastructure runs on SOC 2 Type II subprocessors. See the full list on our trust page.
• Access controls are enforced by Clerk and GitHub organization roles, with MFA required for all human production access.
• Data in transit is TLS 1.3. Data at rest is AES-256 through our subprocessors.

Planned path: Vanta or Drata onboarding follows the first paid design partner. Type I attestation after three months of continuous evidence collection. Type II after twelve months.

If you need a security questionnaire (SIG Lite, CAIQ) or subprocessor DPAs before that, we can share them under mutual NDA. See the trust page for how to request.

How to use Nark in your audit prep

1. Install Nark in CI. See our CI setup guide for GitHub Actions, GitLab, and CircleCI examples.
2. Pipe scan artifacts to your compliance evidence store. Options include a Vanta custom integration, a Drata custom connection, a Secureframe custom control, or a plain S3 archive with a scheduled sync. Every scan writes structured JSON that maps cleanly into any of these targets.
3. Cite scan-audit records as CC7.1 and CC8.1 supporting evidence in your SOC 2 report. The control narrative already lists PR checks required to merge. Nark becomes one of the enumerated checks, and the scan log becomes the artifact.
4. For CC7.1 specifically, run Nark on a schedule against your main branch (nightly or weekly) in addition to PR-time. Those scan logs contribute as ongoing vulnerability monitoring evidence.

A note on adding Nark mid-observation-window

Adding Nark to CI part way through your Type II observation period is fine. Document when it was added and what it now covers as part of your standard change-management record. Introducing it a week before the auditor arrives is the pattern that raises questions. The earlier in the window Nark is generating evidence, the more of the window is covered.

Contact

Compliance-specific questions: compliance@nark.sh. Security posture and subprocessor questions: security@nark.sh. General questions: hello@nark.sh.