This course is designed to serve as a comprehensive guide for Snyk Administrators. To ensure you get the most relevant information for your role, the content is organized into two distinct workflow paths:

The Administrator Workflow: Focused on advanced configuration and governance. This path covers organizational mapping, enforcing security policies, and optimizing global settings to ensure team-wide consistency and pipeline parity.

The Developer Workflow: For more information on the developer workflow please visit Using Snyk in an IDE (Developer)

Note to Learners: While Developers may only need the developer section to begin securing code, we recommend that Administrators complete both courses to understand the end-user experience they are supporting.

The Snyk Security IDE plugin empowers your organization to enforce security standards by default, integrating directly into developer workflows to eliminate late-stage remediation bottlenecks. By surfacing critical vulnerabilities in real-time and providing actionable guidance at the source, Snyk enables your teams to secure applications long before they reach production, reducing the burden on security and operations teams.

• Reduced Remediation Overhead: Prevent vulnerabilities from entering the codebase, significantly lowering the volume of security debt and emergency patches.
• Standardized Security Posture: Drive consistent security practices across the entire engineering organization with automated, AI-driven fix recommendations (available for Enterprise customers).
• Optimized Developer Productivity: Minimize "context switching" and friction between security and dev teams by providing developers the tools to self-serve their own security fixes.

For organizations requiring deeper governance, Snyk runs several background processes to ensure alignment with security standards:

• Security & License Policies: Automated enforcement based on your Team or Enterprise plan.
• Pipeline Guardrails: Integrated PR and CI/CD features that automate enforcement and prevent vulnerable code from progressing.

Before getting started, ensure you have the following ready:

• A Supported IDE: VS Code, Eclipse, JetBrains, etc.
• A Snyk Account: Available for all tiers (Free, Team, and Enterprise).
• Snyk Code Activation: Ensure Snyk Code is enabled in your Snyk Web UI organizational settings
  • Note: For Team and Enterprise users, this is typically managed by your admin. Free users will need to toggle this on manually in their account settings.

• Data Privacy: How Snyk handles your data
• Documentation: Snyk IDE Plugins and Extensions

With the local environment ready, we'll now shift to the administrative side to ensure your team's IDEs are fully aligned with your organization's security posture. This workflow covers organization management and advanced settings to ensure every developer is working within your established enterprise guardrails.

If the standard OAuth2 authentication fails to initialize, Snyk provides alternative authentication methods to ensure your IDE remains connected to the platform. For more information, see Authentication for VS Code extension.

By default, Snyk automatically detects your required regional endpoint based on your authentication email. This ensures your IDE connects to the correct data residency instance without manual intervention. If the automated discovery fails or you are working within a restricted network, you may need to explicitly define the Custom Endpoint to point your IDE to the correct Snyk region. For more information, see IDE URL.

Setting the Organization within the IDE is essential for ensuring your local scans align with your company's security posture. This setting dictates which "ignores", custom rules, and license policies Snyk applies to your workspace.

Default vs. Explicit Configuration

By default, the IDE inherits the "Default Organization" from your Snyk web profile. However, you can explicitly override this in the IDE settings to ensure your environment stays pinned to a specific project context.

• Use the Web Default: If you consistently work within a single organization, setting your default in the Snyk Web UI is the most efficient "set-and-forget" method.
• Explicit IDE Setting: If you frequently switch between different organization or business units, explicitly defining the organization in your IDE settings provides better visibility and prevents policy drift.

Organization ID vs. URL Slug

You can identify your organization using either the URL Slug (human-readable) or the Organization ID (UUID).

• Organization ID:
  • Best for consistency & tooling.
  • Recommended as the ID is immutable and works across all Snyk integrations, the CLI, and the API
• URL Slug:
  • Best for rapid switching.
  • The slug is easier for humans to read at a glance, making it useful if you need to verify your current context quickly within the IDE.

In this demo, we'll head into the Snyk Web UI Settings to locate your Organization ID and Slug, then map them to your IDE configuration to activate your team's custom security policies.

While the standard developer workflow covers the basics, administrators must often tune the plugin's advanced behavior to suit specific infrastructure or performance requirements. In this section, we'll move beyond the UI to look at the underlying engine settings that drive the Snyk experience.

Core Administrative Controls

This list provides the settings that govern how Snyk interacts with your local environment and the Snyk platform:

• Snyk Account & Endpoint: Manage your identity context and regional API routing (as covered in the Connectivity section).
• Token Storage: Configure how and where authentication secrets are stored locally to comply with your organization's security standards.
• Scan Configuration: Define the scope of local analysis (balancing between deep security insights and IDE performance).
• Issue View Options: Control the "signal-to-noise" ratio by filtering issues based on severity, status, organizational "ignores".
• User Experience (UX): Toggle automatic scans on start-up or save to integrate Snyk into the developer's natural coding rhythm.
• Automatic Dependency Management: Control how the plugin handles the Snyk CLI and Language Server binaries. For restricted environments, you may choose to manage these manually rather than allowing automatic updates.
• MCP Service (Model Context Protocol): Enable the Snyk MCP Server to provide security context directly to agentic development tools (like Cursor or Claude Desktop) using the Model Context Protocol.

In this demo, we will navigate through these advanced menus to show you how to lock down specific binary paths, toggle AI-context features, and ensure your team's IDEs are configured for maximum efficiency and security.

The final step in a mature Snyk implementation is ensuring parity between the local IDE and your organizational "guardrails." This ensures that a developer's local scan results match exactly what they will encounter during a CI/CD pipeline check or a PR gate.

IDE-to-Pipeline Parity

To audit an inherited codebase or prepare for a major release, you may need to move beyond "Net New" filtering. We'll walk through how to configure the IDE for a full-stack security audit:

• Disabling "Net New" Filters: Shift from viewing only new vulnerabilities to a comprehensive audit of the entire legacy codebase.
• Severity Tuning: Adjust filters to focus exclusively on Critical and High severity issues to prioritize remediation efforts on the most impactful blockers.
• Visualizing "All Issues": Toggle visibility to ensure every known vulnerability is accounted for, providing a transparent view of the project's current security debt.

Enterprise Security Policies

For organizations on the Enterprise Plan, global governance is handled through Snyk Security Policies. These allow administrators to define rules at the organizational level that are automatically inherited by every IDE plugin in the fleet:

• Global Ignores: Automatically suppress specific vulnerabilities (e.g., internal-only tools or accepted risks) across all developer environments.
• Issue Re-prioritization: Dynamically escalate or de-escalate the severity of specific issues based on your internal compliance requirements.
• Centralized Enforcement: Ensure that when a policy is updated in the Snyk Web UI, the change is reflected in real-time within the developer's IDE, eliminating "it worked on my machine" security discrepancies.

In this final demo, we'll demonstrate how to configure your scan settings to match a production pipeline and show how Enterprise Security Policies seamlessly govern local scan results to keep your team aligned with corporate standards.