Integrations / Security & monitoring
Screenata + SnykHow do you turn Snyk into SOC 2 and ISO 27001 evidence?
Quick answer
Snyk does the detecting. SOC 2 CC7.1 and ISO 27001 A.8.8 then ask you to prove the vulnerability management program around it operates, which is a different question from whether the scanner is switched on. Having Snyk is not the control. The control is the enforced configuration, such as every project in scanning coverage and severity-based remediation inside your policy timelines, plus the record that the configuration operated across the whole audit period. Screenata runs 5 native checks against that configuration on a schedule and turns each result into signed evidence mapped to the control it satisfies.
Screenata connects to Snyk read-only and runs 5 native checks against your organization: project coverage, vulnerability scanning activity, and fix rate. Each finding becomes a signed, timestamped evidence artifact mapped to SOC 2, HIPAA, and ISO 27001 controls, turning your dependency scanning into the vulnerability management record auditors ask for.
5 native checks · read-only · signed evidence
What it proves
Snyk evidence, mapped to controls.
Whether the repositories and projects your policy says are scanned actually are, so coverage matches the asset register.
The coverage report auditors sample: no repository silently outside the vulnerability management program.
Scanning activity and open findings across projects, tracked over time.
Proof that scanning runs on the cadence your vulnerability management policy commits to.
How findings trend from open to resolved, against the remediation timelines your policy sets.
The remediation record that turns a scanner from a dashboard into an operating control.
Control references are the requirements each evidence area supports, via the shared control catalog. Your auditor decides sufficiency; the artifacts are theirs to verify.
Compliance checks
What Screenata checks on Snyk, and why each matters.
Project Coverage
Verifies every active project is monitored by Snyk. A repository outside scanning is an unmonitored path for vulnerable dependencies, and an auditor checks that scanning coverage matches your asset register.
Auto-Fix PRs Enabled
Confirms Snyk opens and tests pull requests to fix vulnerable dependencies. Without automated fix and PR testing, remediation lags and regressions slip in, and an auditor looks for an active remediation workflow, not just detection.
Critical Vulnerabilities Resolved
Checks that no open critical vulnerabilities remain unaddressed. Unresolved criticals are directly exploitable, and an auditor verifies severity-based remediation runs within your policy timelines.
License Compliance Policy
Verifies a license policy is configured to block high-risk licenses. Without it, dependencies can introduce legal and supply-chain risk unnoticed, and an auditor checks that dependency governance is enforced.
SAST Scanning Enabled
Confirms Snyk Code static analysis is enabled to scan application code. Without SAST, code-level flaws ship undetected, and an auditor verifies source code is scanned for security defects.
Drawn from Screenata’s Snyk check library. Control refs are the requirements each check produces evidence for; your auditor decides sufficiency.
How it connects
Read-only, revocable, yours.
Read-only by construction
OAuth scopes and IAM roles are scoped to read. Vera never gets write access to your systems.
Signed findings
SHA-256 per artifact, RSA/ECDSA signatures, RFC 3161 timestamps. Verifiable without a Screenata account.
Mapped to controls
Each finding lands on the shared control catalog, so one scan satisfies SOC 2, HIPAA, and ISO 27001 at once.
What access does Screenata need to Snyk?
A read-scoped API token that you create and control. Screenata uses it for scheduled scans and never receives write access. You can revoke the token at any time from your Snyk settings.
Does Screenata replace Snyk?
No. Snyk finds the vulnerabilities; Screenata proves the program around them operates: coverage, cadence, and remediation against your policy's timelines, recorded as signed evidence.
Is dependency scanning enough for SOC 2 vulnerability management?
It is one layer. Auditors look for a documented process covering scanning, severity triage, and remediation timelines across your stack, which usually also includes infrastructure-level findings from your cloud provider. The shared control catalog assembles all of it under the same control.
What are the steps to implement SOC 2 with Snyk?
First, create a read-scoped API token and connect it. Second, let the first scan run so the baseline shows which projects are actually monitored rather than which ones you believe are. Third, fix what fails: bring every active repository into project coverage so nothing sits outside the program, resolve the open critical vulnerabilities, enable automated fix pull requests so remediation is a workflow and not a backlog, configure a license policy that blocks high-risk licenses, and turn on Snyk Code static analysis. Fourth, leave the scheduled scans running so passing results accumulate as signed evidence across the observation window, which for a Type 2 report is usually three to twelve months. Fifth, hand the evidence package to an independent auditor. The audit is a separate engagement with a licensed CPA firm, which issues the report; Screenata prepares and holds the evidence it asks for.
What evidence do auditors ask for about vulnerability management?
Three things. Coverage across the whole estate, so the scanned population matches the asset register and no repository or service sits quietly outside the program. A documented severity triage with remediation timelines, so critical and high findings have a defined window rather than an open-ended one. And a record showing findings were actually worked down inside those timelines, not just discovered. Detection is the easy half. The finding auditors write up is the open critical that sat past its own deadline.
Do auditors accept evidence Screenata collects from Snyk?
Yes. Every finding is exported as a signed, timestamped artifact, a SHA-256 hash with an RSA or ECDSA signature and an RFC 3161 timestamp, that an auditor verifies outside Screenata with a free CLI. A person reviews and approves the evidence before it reaches the auditor. Screenata collects and signs it; it does not decide the audit result.