Secure Software Development Lifecycle (SSDLC)

Overview

These are the security practices and automated checks Close-Rate uses when it designs, builds, releases and maintains its software.

1. Design & Architecture

• We review changes to sign-in, access to customer data, stored credentials and new vendors with AI-assisted security review tools

• Zoom and RingCentral connections ask only for read access

• Customer requests are checked against the workspace of the person making them, in our application code. Close-Rate staff can open a customer's workspace to support that customer, and our internal admin tools and background jobs can read across workspaces

2. Secure Coding Practices

• SQL Injection Prevention: Database queries pass the values they are given as bound parameters, never pasted into the SQL text. Most queries use the SQLAlchemy ORM; hand-written SQL statements, such as those for transcript search, bind their values the same way.

• Input Validation: Most API routes validate their input against Pydantic models, which reject malformed data before the route's code runs. The others check their fields in code.

• Authentication: Requests to our API for a workspace's data must carry a JWT signed with RS256 (asymmetric keys), validated against Clerk's JWKS endpoint: signature, expiration and issuer are verified on every such request. A running Zoom import's progress can also be read with a token issued for that import. Webhooks from Stripe, Clerk and Zoom are checked against the sender's signature instead; a Zoom uninstall notice without a valid signature is confirmed with Zoom before anything is deleted.

• Secret Management: The application's production secrets (the database password, API keys and the token encryption key) are kept in AWS Secrets Manager, not in our source code; local development uses environment variables. Sign-in tokens, OAuth codes and signed download links are replaced with REDACTED in the web addresses our logs record.

• Error Handling: 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.

• Encryption: OAuth tokens are encrypted using Fernet symmetric encryption (AES-128-CBC + HMAC-SHA256) before database storage. The encryption key is stored separately from the database.

• CORS: Browsers can call our API only from an explicit list of Close-Rate's own web addresses. Wildcard origins are refused in production.

3. Code Review

• All code changes are tracked in Git version control

• Changes are reviewed by the engineer who makes them, with AI-assisted code review. Changes to sign-in, access to customer data, stored credentials and new vendors also get an AI-assisted security review

4. Dependency and Code Checks

• npm audit: Our automated checks (GitHub Actions) run npm audit on the JavaScript dependencies whenever a change can affect the frontend. Its results are reported and do not block a release.

• pip-audit: Our automated checks run pip-audit on the Python dependencies, against the PyPI and OSV vulnerability databases, whenever a change can affect the backend. A package with a known vulnerability that has a fix fails the checks, unless we have recorded why its upgrade can wait and a date, at most 90 days ahead, to review it.

• TypeScript Compiler: The TypeScript compiler (tsc --noEmit) runs in our automated checks, catching type errors and potential runtime issues before release.

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

• ESLint: Create React App's lint rules run in the frontend production build, and our automated checks treat their warnings as errors.

• Our build does not run static security analysis on our own code.

• Scan results are kept in our automated check logs, and we keep dated copies of selected scans.

5. Dependency Management

• Python dependencies are installed at exact versions pinned in our requirements and constraints files, for reproducible builds

• JavaScript dependencies are locked via package-lock.json for deterministic installs

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

• How we rate and fix vulnerabilities, including those in dependencies, is set out in our Vulnerability Management Policy

6. Deployment & Operations

• CI/CD Pipeline: Releases normally run from a deploy workflow (GitHub Actions) that we start by hand. For the backend it builds a Docker image, pushes it to Amazon ECR, runs database migrations and updates the AWS ECS service; it then starts an AWS Amplify build of the frontend.

• Build Verification: Our automated checks run ruff, pytest, the TypeScript compiler, the Jest tests and a frontend production build with ESLint warnings treated as errors, skipping a suite that a change cannot affect. The deploy workflow will not release a commit unless those checks passed on that exact commit.

• Zero-Downtime Deploys: AWS ECS performs rolling deployments with ALB health checks. Traffic is only shifted to new tasks after health verification passes.

• Failed Releases: If new tasks fail their health checks, the tasks already running keep serving traffic and the deploy workflow reports the release as failed.

• Secret Storage: The application's production secrets are stored in AWS Secrets Manager and given to the ECS tasks when they start.

• Monitoring: Application logs stream to AWS CloudWatch with 90-day retention. CloudWatch alarms email us on server errors, failed reports and AI Insights answers, failed imports and payment events, unhealthy or missing backend tasks, search errors, and our database or our transcription provider rejecting our credentials.

7. Incident Response & Continuous Improvement

• Security incidents follow our Incident Management & Response Policy

• After an incident that affects customers, we write down what happened, what we found about its cause, what we changed and the follow-up work that is still open

• We update these practices after incidents and as the product changes