SOC 2 Snyk: Automating Vulnerability Scanning for CC7.1

CC7.1 and Vulnerability Management Requirements

CC7.1 states: "The entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities." In practice, auditors expect to see: a documented vulnerability management policy with fix SLAs, automated scanning of your codebase and infrastructure, a process for triaging findings, and evidence that vulnerabilities were remediated within policy SLAs.

Snyk provides all of this in one platform: continuous scanning via GitHub integration (Snyk Projects auto-retest on every new commit), automated fix PR generation, severity scoring with CVSS and EPSS, and project reports exportable as monthly evidence. The Snyk Dashboard provides a compliance-ready view of your vulnerability posture over time.

Snyk Open Source: Dependency Scanning

Install the Snyk GitHub App on your organization. Navigate to app.snyk.io → Integrations → GitHub. After connecting, import your repositories. Snyk Open Source monitors your package manifests: `package.json`, `requirements.txt`, `pom.xml`, `go.mod`, `Gemfile.lock`, `Cargo.toml`. For each manifest, Snyk builds a dependency tree and identifies CVEs in all direct and transitive dependencies.

Configure Snyk to run on every PR and fail the pipeline on critical severity findings. In your Snyk organization settings, set "Fail open source tests" for severity = Critical. This creates a PR gate that blocks merging code with critical dependency vulnerabilities. For GitHub Actions, use the Snyk action: `- uses: snyk/actions/node@master / env: SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }} / with: args: --severity-threshold=critical`.

Enable Snyk fix PRs (also called automated remediation). Navigate to Snyk Organization → Integrations → GitHub → Settings → Enable fix PRs. When Snyk detects a vulnerability with a known fix (an upgraded version of the vulnerable package), it automatically opens a PR to your repository with the fix applied. These fix PRs include a description of the vulnerability, the CVE ID, and the remediation. Merging them creates an automatic audit trail of vulnerability remediation.

Snyk Container: Image Scanning

Snyk Container scans Docker images for vulnerabilities in both application layers (your npm packages, Python packages) and OS layers (Alpine packages, Debian packages inherited from the base image). Import container images via Snyk → Projects → Add projects → Container registry or by using `snyk container test my-image:tag` in CI.

For your CI pipeline, add: `snyk container test my-image:${{ github.sha }} --file=Dockerfile --severity-threshold=critical`. This scans the built image and fails the pipeline on critical OS or application layer CVEs. Snyk also provides base image recommendations — if your current base image has many CVEs, Snyk suggests a minor or patch upgrade of the base image that resolves the most CVEs with the least migration effort.

Configure container monitoring: import your production container images (from ECR, GCR, or Docker Hub) into Snyk Projects. Snyk re-scans them as new CVEs are published, alerting you to newly discovered vulnerabilities in images that were clean when first deployed. This continuous monitoring is critical for CC7.1 — a vulnerability may be published after your last deployment, and you need to be notified without waiting for the next image build.

Snyk IaC: Infrastructure Misconfiguration

Snyk IaC scans Terraform, Kubernetes manifests, Helm charts, CloudFormation, and ARM templates for security misconfigurations. It runs in CI alongside your tfsec/Checkov scans and provides developer-friendly findings with fix guidance. Add to GitHub Actions: `snyk iac test --severity-threshold=high ./infrastructure/`. Snyk IaC maps findings to specific lines in your Terraform files, making remediation straightforward.

Snyk IaC findings are also integrated into Snyk Projects for historical trending. You can see whether your infrastructure misconfiguration count is improving over time — a metric you can include in your monthly security report as evidence of continuous improvement in CC7.1 compliance.

Fix PRs and Remediation Workflow

Establish a vulnerability remediation workflow. Each Snyk finding should be triaged: (1) Accept and fix within SLA — assign to the responsible team, link to the Snyk issue in Jira. (2) Ignore with justification — use Snyk's built-in ignore feature (`snyk ignore --id=SNYK-JS-1234 --expiry=2026-07-01 --reason="No upgrade available"`) with an expiry date. (3) Escalate for exception — high-risk findings that cannot be fixed or ignored need a formal exception review.

The Snyk ignore feature creates a documented exception audit trail. Every ignored vulnerability has a timestamp, the user who ignored it, the reason, and an expiry date. This is the evidence for your exception management process — auditors can see that exceptions were deliberate decisions with business justification, not overlooked vulnerabilities.

Vulnerability SLA Policies

Document vulnerability fix SLAs in your vulnerability management policy: CRITICAL (CVSS 9.0+) — remediated within 7 days. HIGH (CVSS 7.0–8.9) — remediated within 30 days. MEDIUM (CVSS 4.0–6.9) — remediated within 90 days. LOW (CVSS < 4.0) — remediated within 180 days or accepted risk. Include EPSS (Exploit Prediction Scoring System) in your triage — a MEDIUM severity CVE with 80% EPSS should be treated as HIGH.

Configure Snyk to enforce these SLAs via policies. Navigate to Snyk Organization → Policies → Security policies. Create a policy: "If severity = Critical AND age > 7 days, set to failing". Link this policy to your critical project groups. This causes the Snyk test in CI to fail if a critical CVE has been open for more than 7 days, preventing new deployments until the CVE is resolved. This is automated SLA enforcement as evidence.

Exporting Vulnerability Evidence for CC7.1

Export vulnerability reports from Snyk monthly. Navigate to Snyk → Reports → Issues. Filter by organization, date range, and severity. Export to CSV. This CSV shows every vulnerability identified during the audit period, its severity, when it was discovered, when it was fixed (or ignored with justification), and the fix PR or commit reference. This is your primary CC7.1 evidence artifact.

Also export the Snyk Projects summary monthly: navigate to Snyk → Projects → [project] → Export report. This point-in-time snapshot shows the vulnerability count on a specific date. By exporting monthly throughout your audit period, you can demonstrate trending improvement (or at minimum, managed stability) in your vulnerability posture. If your vulnerability count decreased over the audit period, highlight this trend in your audit evidence narrative — it demonstrates an operating vulnerability management program, not just a one-time scan before the audit.