Security Policy (Default Enabled Alerts)

These are the default set of Enabled Alerts

Introduction

Socket's security policy is designed to help organizations manage and mitigate supply chain risks by automatically blocking or warning about potential threats. By default, Socket enables a set of alerts that are critical to maintaining the integrity and security of your codebase. These default alerts are carefully selected to minimize noise and ensure that only significant issues are brought to attention.

Customize alert actions in your organization’s security policy to block, monitor, warn, or ignore each alert type or set the action back to inherit from the default policy. Custom settings will override the default policy setting and stay in effect until you change them or remove all custom settings via the Remove Custom Settings button to the top right.

Security Policy

Default Security Policy

Socket, by default, will show alerts that are likely not noise.

Recommended for most teams, balancing robust security measures with minimized disruption to developer workflows.

Key Features:

  • Defend against supply chain risks: Monitor and alert on potential risks to protect your projects from various supply chain attacks.
  • Block malicious dependencies: Automatically block the use of known malicious dependencies to prevent them from entering your codebase.
  • Warn about critical CVEs, typosquats, protestware: Provide warnings for critical vulnerabilities (CVEs), potential typosquatting attempts, and packages containing protestware, ensuring that developers are informed about potential threats without halting the development process.

Default Security Policy Alert Actions

The table below outlines the alert types and their corresponding actions under the Default security policy:

Alert TypeDefault
Known Malware🚫
Critical CVE❗
Possible Typosquat Attack❗
Protestware/Troll Package❗
Git Dependency❗
GitHub Dependency❗
HTTP Dependency❗
Obfuscated File❗
High CVEπŸ‘οΈ
Medium CVEπŸ‘οΈ
Low CVEπŸ‘οΈ
TelemetryπŸ‘οΈ
Unpublished PackageπŸ‘οΈ
Unstable OwnershipπŸ‘οΈ
Unpopular PackageπŸ‘οΈ
DeprecatedπŸ‘οΈ
ShrinkwrapπŸ‘οΈ
AI-Detected Potential Malwareβž–
Install Scriptsβž–
Unmaintainedβž–
Potential Vulnerabilityβž–

Alert Actions

Alert ActionShows up in DashboardDevelopers see it (e.g., GitHub comment, CLI prints a warning)Developers blocked (GitHub PR fails, CLI errors)
Block πŸš«βœ…βœ…βœ…
Warn β—βœ…βœ…βŒ
Monitor πŸ‘οΈβœ…βŒβŒ
Ignore βž–βŒβŒβŒ

Legend

  • Block 🚫: This action will fail the Socket CI/CD check, preventing the merge or deployment process until the issue is resolved. All related alerts will appear in the dashboard, developers will be notified, and further actions will be blocked.
  • Warn ❗: This action indicates a potential issue that should be reviewed. It will appear in the dashboard and notify developers through comments or warnings, but it will not block the development process.
  • Monitor πŸ‘οΈ: This action is used for tracking alerts that require monitoring over time. Alerts will be visible in the dashboard, but no notifications will be sent to developers, and it won't block any processes.
  • Ignore βž–: This action is set for low-priority alerts or informational notifications. The alerts will not show up in the dashboard, and there will be no notifications or blocks applied.

Note: all other supported alert types are set to be ignored in the three new policies and will have to be enabled explicitly.

Customizing Security Policies

Organizations can adjust these default settings to meet their specific needs using the Socket dashboard. For more granular per-repository settings, the socket.yml file can be used to customize the security policies.

See: socket.yml.

Conclusion

Maintaining the default set of enabled alerts ensures your codebase is protected against common and critical security risks. Customizing the alerts should be done with caution to avoid missing potential threats. For detailed instructions on customizing your security policies and managing alerts, contact the Socket Customer Success team.

For more information, visit the Socket Documentation.