Announcing New Default Security Policies

Socket is introducing three new customizable default security policies: Low Noise (traditional SCA), Default (ideal for most customers), and Higher Noise (for more engaged teams.)

These new policies leverage Socket's four alert actions (Block, Warn, Monitor, Ignore) to offer teams greater flexibility in managing dependency security, from focused CVE monitoring to comprehensive supply chain risk management.

These changes aim to reduce alert noise, manage false positives more effectively, and enable several new alert types that were previously disabled.

The new policies will be made available on August 28, 2024, and existing organizations will be transitioned from the old default policy to the new one on that day. During the two-week transition period (August 14 - August 28), organizations can review the changes and "lock-in" their existing settings if desired.

Building on Our Recent Alert System Enhancements#

As you may recall from our previous announcement, we recently expanded our alert system to include four distinct actions: Block, Warn, Monitor, and Ignore. These actions were designed to give organizations more precise control over how to handle notifications:

• Block (formerly "Error"): Fails the Socket CI/CD check, blocking Pull Requests (PRs) or Merge Requests (MRs) until resolved.
• Warn: Highlights issues in PRs/MRs without blocking them, allowing for context-specific decisions.
• Monitor: Displays alerts in the Socket Dashboard for evaluation without cluttering the development workflow.
• Ignore: Filters out irrelevant alerts entirely.

Introducing Three New Security Policy Options#

Building on this foundation, we're now introducing three customizable security policies that make full use of these alert actions. The policies are designed to cater to different team needs and security approaches:

1. Low Noise (Traditional SCA)

Ideal for teams that want to focus solely on CVEs and malicious dependencies:

• Blocks the use of known malicious dependencies
• Warns developers about critical CVEs
• Monitors CVEs of all severity levels

2. Default (Recommended for Most Teams)

Our new default policy balances robust security measures with minimized disruption to developer workflows:

• Blocks the use of known malicious dependencies
• Warns developers about critical CVEs, potential typosquats, and protestware (without blocking them)
• Monitors a wider range of potential issues

3. Higher Noise (For More Engaged Teams)

Designed for teams where developers are more actively involved in security vetting:

• Blocks the use of dependencies with critical CVEs or known malicious intent
• Provides more warning alerts to developers for a wider range of potential issues
• Monitors an extensive set of quality and maintenance issues

Understanding "Inherit" vs. Explicit Alert Actions#

When configuring your security policy, you have two options for each alert type:

1. Inherit: If you set an alert action to "Inherit", it will automatically adopt the action specified in the chosen security policy (Low Noise, Default, or Higher Noise). This allows your policy to flexibly update if you switch between default policies. It also ensures that any future changes to the chosen policy will be reflected in your organization.
2. Explicit Setting: If you explicitly set an alert action (Block, Warn, Monitor, or Ignore), this setting will remain constant even if you switch between default policies. This allows you to customize specific alerts while still benefiting from the overall structure of the three available policies.

For example, if you set "Critical CVEs" to "Inherit" and choose the "Default" policy, it will be set to "Warn". If you later switch to the "Higher Noise" policy, it will automatically update to "Block". However, if you explicitly set "Critical CVEs" to "Monitor", it will remain as "Monitor" regardless of which default policy you choose.

Detailed Breakdown of New Policies#

The following table provides a detailed breakdown of the default alert actions specified in each of the three new security policies that you will be able to choose from:

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

Changes from Current to New Default Policy#

We've made several adjustments in our new default policy based on analysis of user data and customer feedback. Here are the key differences:

• CVE Handling:
  • Critical CVEs: Changed from "Ignore" to "Warn"
  • High CVEs: Changed from "Ignore" to "Monitor"
  • Medium CVEs: Changed from "Ignore" to "Monitor"
  • Low CVEs: Changed from "Ignore" to "Monitor"
• Supply Chain Risks:
  • Possible typosquat attack: Changed from "Block" to "Warn"
  • Git dependency: Changed from "Block" to "Warn"
  • GitHub dependency: Changed from "Ignore" to "Warn"
  • AI-detected potential malware: Changed from "Ignore" to "Monitor"
  • HTTP dependency: Changed from "Block" to "Warn"
  • Install scripts: Changed from "Block" to "Ignore"
  • Telemetry: Changed from "Block" to "Monitor"
  • Protestware/Troll package: Changed from "Block" to "Warn"
  • Unpublished package: Changed from "Ignore" to "Monitor"
  • Unstable ownership: Changed from "Ignore" to "Monitor"
  • Obfuscated code: Changed from "Ignore" to "Warn"
  • NPM Shrinkwrap: Changed from "Ignore" to "Monitor"
• Quality and Maintenance:
  • Unpopular package: Changed from "Ignore" to "Monitor"
  • Deprecated: Changed from "Ignore" to "Monitor"

These changes were made to strike a balance between security and developer productivity. Our analysis showed that some alerts, while useful, were causing unnecessary disruptions when set to "Block" due to being too noisy (e.g. Install scripts.) At the same time, we've increased visibility on several previously ignored alerts that we believe will be valuable for teams to be aware of.

What This Means For Your Organization#

We're rolling out this update in two key phases:

Phase 1: Transition Period (August 14 - August 28, 2024)

1. Review the Changes: We encourage you to review the changes in the new default policy detailed earlier in this announcement. This will help you understand how the upcoming changes might affect your organization.
2. Lock In Your Preferences: During this two-week period, if there are specific alert types you want to keep at their current settings, you can set them explicitly in your Security Policy page. Any alert types that do not have an explicit action set but are configured to inherit from the default policy will adopt the new default policy action after August 28.

Phase 2: New Policies Take Effect (From August 28, 2024)

1. Automatic Update: Unless you've locked in specific settings, your policy will automatically update to the new default policy on this date.
2. New Options Available: You'll gain the ability to switch between the three new policy options: Low Noise, Default, and Higher Noise. Consider which might be the best fit for your team and make the switch if desired.
3. Ongoing Management: You can continue to fine-tune your policy settings or switch between the three options as your needs evolve. Remember, you can always choose between inheriting from the default policies or setting explicit actions for each alert type.

We're excited about this update and believe it will significantly enhance your experience with Socket. As always, we welcome your feedback as we continue to improve our service.

If you have any questions about, need assistance with this rollout, or have feedback on these changes, please don't hesitate to reach out to our support.