Skip to content

Security Controls

Vulnerability Management

How we continuously monitor for security vulnerabilities and how we prioritize and remediate them.

Last reviewed: July 2026

Vulnerability management is the recurring process of identifying, classifying, prioritizing, mitigating, and remediating security vulnerabilities. This page focuses on software and system vulnerabilities and the operational process we use to monitor for new vulnerabilities and address them.

Our approach

We use various vulnerability monitoring and scanning systems to continuously discover new threats. Our process is designed to promote healthy vulnerability and patch management practices along with other preventative best practices.

Monitoring for vulnerabilities

  • We perform internal vulnerability scans and package monitoring on a continuous basis.
  • We perform external vulnerability scans and penetration tests periodically.

Detected vulnerabilities and needed package updates are communicated to a vulnerability management system, where they can be tracked to resolution.

Remediating vulnerabilities

Remediation is the part of the process in which a reported vulnerability is fixed. Our engineering team remediates reported vulnerabilities and tracks them to resolution in the vulnerability management system. Service level agreements (SLAs) are in place to help prioritize vulnerabilities based on severity, which is mapped from factors such as scope and impact.

Remediation targets

Vulnerabilities are remediated against the following severity-based target timeframes, measured from the point the vulnerability is validated, and tracked to closure in the vulnerability management system:

  • Critical: remediated within 7 days.
  • High: remediated within 30 days.
  • Medium: remediated within 90 days.
  • Low: addressed within the normal maintenance cycle.

Remediation outcomes

Our engineering team addresses reported vulnerabilities and tracks them to resolution. Resolution statuses can include, but are not limited to:

  • Fixed: the reported vulnerability has been fixed via a patch or system changes.
  • Inaccurate or false positive: the reported vulnerability has been thoroughly investigated and found to be invalid.
  • Vulnerable section unused: the vulnerability affects parts of the codebase or system that are not in use, so it is no longer a threat.
  • Acceptable risk: the vulnerability has been analyzed and deemed not to pose a debilitating risk to the system. This is a rare case and occurs only in extenuating circumstances or where remediation costs are extremely high.

Questions

If you have any questions about this policy, contact us at [email protected].

← Back to Trust Center

Questions about this policy? [email protected]