Vulnerability Management Policy

Purpose

This policy establishes how Close-Rate identifies, assesses, prioritizes, and remediates security vulnerabilities across our application, infrastructure, and third-party dependencies. The goal is to minimize our attack surface and reduce the window of exposure for known vulnerabilities.

Vulnerability Identification

We identify vulnerabilities through the following channels:

• Dependency Monitoring: Our automated checks (GitHub Actions) run pip-audit on the Python dependencies and npm audit on the JavaScript dependencies whenever a change can affect the code they cover. A Python package with a known vulnerability that has a fix fails those checks, unless we have recorded why its upgrade can wait and a date to review it. JavaScript audit results are reported and do not block a release.

• Container Images: Amazon ECR scans each backend image for known vulnerabilities when it is pushed.

• Code Review: Changes to sign-in, access to customer data, stored credentials and new vendors get an AI-assisted security review.

• Responsible Disclosure: External researchers can report vulnerabilities to client-services@close-rate.com.

Severity Classification

We rate a vulnerability by how it could affect Close-Rate, starting from its CVSS score.

• Critical (CVSS 9.0+): Remote code execution, authentication bypass, data breach risk.

• High (CVSS 7.0-8.9): Privilege escalation, significant data exposure.

• Medium (CVSS 4.0-6.9): Limited impact vulnerabilities, information disclosure.

• Low (CVSS 0.1-3.9): Minimal risk, defense-in-depth improvements.

Patching & Remediation

• Releases follow no fixed schedule, so a fix can be released as soon as it passes our automated checks

• Dependencies are updated when an advisory affects them and during regular maintenance

• AWS patches the servers and operating systems that run ECS Fargate and our Aurora database

• The backend runs on Python 3.11, which still receives security updates

• When a Python dependency's upgrade has to wait, we record the advisory, why it can wait and a review date at most 90 days ahead; our automated checks fail once that date passes

• A Python advisory that has no fixed version yet is reported by our automated checks and does not fail them

Secure Development Practices

• Database queries pass the values they are given as bound parameters, which prevents SQL injection

• Most API routes validate their input against Pydantic models at the API boundary

• The application's production secrets are kept in AWS Secrets Manager, not in our source code

• Stack traces stay in our server logs and are not sent to the browser. A request that fails on our side gets a generic message, or a fixed sentence saying what could not be done, instead of the text of the error that caused it; an automated test fails if a route builds such a response from the error it caught. A result that lists a problem with one item, such as one file in a batch upload, can still include that error's text. Work that continues in the background, such as uploading or importing a recording, analyzing a call or writing a script, can still show the text of the error that stopped it

• Sign-in tokens are checked on every signed-in API request: signature, expiration and issuer

Responsible Disclosure

We welcome responsible disclosure from security researchers. If you discover a vulnerability in Close-Rate:

• Email client-services@close-rate.com with a description of the vulnerability

• Include steps to reproduce, if possible

• We reply to confirm we received the report, and again with our assessment

• We ask that you do not publicly disclose until we have had a reasonable opportunity to remediate