Skip to main content

0-Day Vulnerability Best Practices

Overview

A 0-day (or zero-day) vulnerability event is when hackers find, or the project owners announce, a previously unknown critical security vulnerability in a popular open-source component. 0-day vulnerability events are dangerous because of the popularity of the component. Even if your app doesn't use the component as a direct dependency, it will likely use the component as a transitive dependency. This means that 0-day vulnerabilities are especially sticky, and can persist long past the day they're announced.

In the ideal scenario, a Lifecycle customer is scanning their apps with CI/CD integrations generating SBOMs for all their builds, and turning on Continuous Monitoring for every app that isn't being regularly built. They'll also have notifications turned on and are blocking builds that contain critical violations. In this scenario, components that are implicated in 0-day vulnerability events are easy to find.

For that reason, the first best practice is to onboard apps quickly and efficiently so that you can find and protect yourself from these sudden vulnerability events.

Finding the Vulnerable Component

Scan all your apps regularly

  • The best defense against 0-Day Vulnerability events is to regularly scan so that your reports are always current.

  • For apps that are actively in development, integrate Lifecycle with your CI/CD tool so that a scan occurs at build time, every time.

  • For legacy apps, turn on Continuous Monitoring, which reevaluates the most recent scan for new policy violations once a day, every day

Turn on notifications, especially for high-severity security violations

  • Notifications should usually be turned on for any apps that are in production, especially for security vulnerabilities of severity 9 and 10.

  • Make sure notifications are sent to places where people will notice them.

  • Regularly review that notifications are being sent to the right people. Project owners, developers who can take remediation actions, and application security team members are good candidates.

Find the vulnerable component with the Advanced Search feature or API

  • Advanced Search allows you to look for components by name, format, coordinates, and other criteria.

  • Advanced Search uses the most recent scan data. If it has been scanned, Advanced Search can find it.

Turn on Continuous Monitoring

  • Continuous Monitoring reevaluates existing reports and calls out new violations.

  • Turn on Continuous Monitoring for apps that aren't being built regularly.

  • Turn on notifications for Continuous Monitoring so that new violations get seen.

Responding to the Event

137199729.jpg

Note

Figure 1: A graphic that places possible response strategies along a spectrum, with "Less Disruptive" on the left and "More Disruptive" on the right. The graphic is a visual aid for the table on this page.

Scope your Reaction to the Risk

  • Your strategy for responding to the event should match the event's severity and your overall risk posture. The riskier the event, the more aggressive you should be, and the more disruption you should be prepared to deal with.

    Strategy

    Details

    Remediation Only

    Create and assign remediation actions for all affected apps.

    • Low level of disruption.

    • Your apps will continue to use the implicated component for at least a while longer, which is not ideal.

    • Only appropriate for vulnerability events that pose very little risk to your apps.

    Block the Component with Repository Firewall

    Block the component with Repository Firewall, then create and assign remediation actions for all affected apps.

    • Prevents new downloads of the implicated component, but it may still exist in your local repo and package manager's cache.

    • Low level of disruption.

    • Your apps will continue to use the implicated component for at least a while longer, which is not ideal.

    • Only appropriate for vulnerability events that pose very little risk to your apps.

    Break Builds for your Critical Apps

    Create a new policy, scope it to the implicated app, and turn on enforcement for your most critical apps. Block the component with Repository Firewall, and create and assign remediation actions for all affected apps.

    • Prevents your most critcal apps from using the component past the development stage, and prevents new downloads of the component.

    • Moderate level of disruption.

    • Appropriate for vulnerability events that pose a high level of risk to your apps.

    Break Builds for Every App

    Create a new policy, scope it to the implicated component, and turn on enforcement for every app. Block the component with Repository Firewall, and create and assign remediation actions for all affected apps.

    • Prevents all your apps from using the component past the development stage, and prevents new downloads of the component.

    • High level of disruption.

    • Appropriate for vulnerability events that pose a high level of risk to your apps.

    • This should be the default response for most customers for most big 0-day vulnerability events.

    Purge Your Repo

    Delete the implicated component from your Repo and block it with Repository Firewall. Create a new policy, scope it to the implicated component, and turn on enforcement for every app. Create an assign remediation actions for all affected apps.

    • Prevents all your apps from using the component at every stage of of the software development lifecycle.

    • Will immediately break every build for every app that uses the implicated component.

    • Very high level of disruption.

    • Appropriate for vulnerability events that post a very high level of risk to your apps.

Don't use the Vulnerable Component

  • Even if you think the vulnerability doesn't apply to you, it still represents a significant risk.

Focus on Remediation

  • Regardless of your overall strategy, make remediation a priority.

  • In most cases, the owners of the implicated components will patch the component and put out a new version. Upgrading to this newer version is usually the best response.

Incident Handling

Create a playbook for handling 0-day vulnerability events

  • 0-Day Vulnerability events are inevitable. The only question is how dangerous they'll be.

  • Develop a plan now for responding to these events, and distribute it to stakeholders.

  • Include a checklist of required actions. That checklist will likely include:

    • Confirming the severity of the vulnerability with trusted sources.

    • Collecting recent SBOMs and scan reports for apps that may have been affected.

    • Rescanning apps, as necessary.

    • Determining and agreeing on a remediation strategy on a per-app basis.

Start a communications channel specifically for tracking the event

  • Take control of the event by creating a central location for all communications. Ask all side conversations to migrate to this central location.

  • Open the communications hub to everyone. Limiting access encourages side conversations, which are an anti-pattern.

Nominate a captain to organize communications and take notes for a postmortem

  • Examples of what a captain might do include:

    • Connect two people who are working on the same problem.

    • Bring new team members into the conversation as needed.

    • Create and call out action items.

    • Record and share new information as it arises.

    • Share the incident's status with the rest of the organization, as appropriate.

  • Good note-taking will make for a smooth postmortem. Save conversations for later review. Add dates and times wherever possible.