Secure Software Development Lifecycle (SSDLC)

Overview

Close-Rate follows a Secure Software Development Lifecycle (SSDLC) that integrates security practices into every phase of our development process. This document describes the controls, tools, and procedures we use to ensure that security is addressed from design through deployment and maintenance.

1. Design & Architecture

• New features and integrations undergo a security design review before implementation, evaluating data flow, authentication requirements, and attack surface

• We follow the principle of least privilege for all API scopes, IAM roles, and database permissions

• Third-party integrations (Zoom, OpenAI, Anthropic) are designed to request only the minimum scopes required for functionality

• Multi-tenant data isolation is enforced at the application layer — all database queries are scoped to the requesting user's organization

• Sensitive data (OAuth tokens, API credentials) is classified at design time and designated for encrypted storage

2. Secure Coding Practices

• SQL Injection Prevention: All database interactions use SQLAlchemy ORM with parameterized queries. No raw SQL is used anywhere in the codebase.

• Input Validation: All API endpoints enforce input validation using Pydantic models, which reject malformed or unexpected data before it reaches business logic.

• Authentication: Every API request is authenticated via JWT tokens signed with RS256 (asymmetric keys) and validated against Clerk's JWKS endpoint. Token expiration, issuer, and signature verification are enforced on every request.

• Secret Management: Secrets and credentials are stored in environment variables (local) or AWS Secrets Manager (production). Secrets are never committed to source control or logged.

• Error Handling: Error responses returned to clients contain generic messages only. Detailed stack traces and diagnostic information are logged server-side and never exposed to end users.

• 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: Cross-origin resource sharing is restricted to an explicit allowlist of known frontend domains. Wildcard origins are never used in production.

3. Code Review

• All code changes are tracked in Git version control with a complete audit trail of commits

• Security-sensitive changes (authentication, authorization, token handling, data access patterns, encryption) undergo dedicated review with a focus on common vulnerability patterns (OWASP Top 10)

• Changes to CORS configuration, allowed origins, and API endpoint permissions require explicit review and justification

• New third-party dependencies are reviewed for known vulnerabilities, maintenance status, and license compatibility before adoption

4. Static & Dynamic Analysis (SAST/DAST)

• npm audit: JavaScript/TypeScript dependency vulnerabilities are scanned in CI using npm's built-in audit tool. Results are reviewed each build, and fixable high/critical advisories are remediated. (Most remaining frontend advisories are build-time-only transitives of react-scripts/Create React App that are not in the shipped production bundle and are tracked for a Vite migration.)

• pip-audit: Python dependency vulnerabilities are scanned in CI using pip-audit against the OSV (Open Source Vulnerabilities) database. Results are reviewed each build, and fixable high/critical advisories are remediated.

• TypeScript Compiler: The TypeScript compiler (tsc --noEmit) runs as part of the build process, catching type errors and potential runtime issues at compile time.

• ESLint: Static analysis rules enforce coding standards and catch common security anti-patterns in frontend code.

• Scan results are documented and retained as evidence for compliance review.

5. Dependency Management

• Python dependencies are pinned to specific versions in requirements.txt for reproducible builds

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

• Dependencies are reviewed and updated at least monthly

• Critical security patches (CVSS 9.0+) are applied within 24 hours of disclosure

• High-severity patches (CVSS 7.0-8.9) are applied within 72 hours

• We use only well-maintained, widely-adopted open-source libraries with active security advisory programs

6. Deployment & Operations

• CI/CD Pipeline: Frontend deployments are automated via AWS Amplify's Git-triggered pipeline. Backend deployments are driven by GitHub Actions workflows that build a Docker image, push to Amazon ECR, and update the AWS ECS service.

• Build Verification: The frontend production build runs TypeScript compilation (tsc --noEmit), ESLint with warnings-as-errors, and Jest tests; a failure in any of these fails the build and blocks deployment. Dependency audits (npm audit, pip-audit) run separately in CI and are reported.

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

• Automatic Rollback: If new tasks fail health checks, ECS stops the rollout and keeps the previous working task definition serving traffic.

• Environment Isolation: Production secrets are stored in AWS Secrets Manager and injected into ECS task definitions as environment variables, completely separate from source code.

• Monitoring: Application logs stream to AWS CloudWatch with 90-day retention. Error patterns and authentication failures are monitored.

7. Incident Response & Continuous Improvement

• Security incidents follow our Incident Management & Response Policy

• Post-incident reviews identify root causes and produce concrete action items to prevent recurrence

• Vulnerability findings from scans, reviews, or external reports are tracked through remediation and verification

• Security practices are reviewed and updated quarterly based on evolving threats, new dependencies, and lessons learned