Version: 1.0
Last Updated: 2026-01-14

1. Security Architecture
2. Authentication & Authorization
3. Data Protection
4. Network Security
5. Compliance
6. Security Controls
7. Incident Response
8. Vulnerability Management

CreditNexus implements multiple layers of security:

1. Network Layer:

   • HTTPS/TLS encryption
   • Firewall rules
   • DDoS protection
   • Rate limiting

2. Application Layer:

   • Authentication & authorization
   • Input validation
   • Output encoding
   • Security headers

3. Data Layer:

   • Database encryption
   • Access controls
   • Audit logging
   • Backup encryption

4. Infrastructure Layer:

   • Secure configuration
   • Patch management
   • Monitoring & alerting
   • Incident response

• Least Privilege: Users have minimum necessary permissions
• Defense in Depth: Multiple security layers
• Fail Secure: System fails in secure state
• Security by Design: Security built into architecture
• Privacy by Design: Privacy considerations from start

Methods:

• JWT-based authentication
• Password-based login
• Wallet-based authentication (MetaMask)
• OAuth (if configured)

Password Requirements:

• Minimum 12 characters
• Uppercase, lowercase, number, special character
• Bcrypt hashing (with SHA-256 pre-hashing for long passwords)

Account Protection:

• Account lockout after 5 failed attempts (30 minutes)
• Password change required on first login
• Session timeout (30 minutes access token, 7 days refresh token)

Role-Based Access Control (RBAC):

• Admin: Full system access
• Auditor: Read-only access to all data
• Banker: Write access to deals and documents
• Law Officer: Write/edit legal documents
• Accountant: Write/edit financial data
• Applicant: Apply and track applications
• Analyst/Reviewer: Analysis and review permissions

Permission Model:

• Role-based permissions (default)
• User-specific permissions (override)
• Resource-level access control

• Password hashes (encrypted with bcrypt)
• JWT secrets (environment variables)
• API keys (SecretStr in config)
• Financial data (CDM events)

• User email addresses
• Profile data (phone, address, company)
• Credit agreement PDFs
• Policy decisions

• Document metadata
• Workflow states
• Template data

• Database:
  • Application-level encryption using Fernet (symmetric encryption) for PII and sensitive data
  • Database server encryption (PostgreSQL) for additional layer
  • Encrypted fields: User emails, names, profile data; Document borrower info; Audit log metadata; Policy decision traces
• File Storage:
  • All files in storage/deals/ directory are encrypted at rest
  • Documents, notes, and CDM events are encrypted before storage
  • Encryption service: app/services/encryption_service.py
• Backups: Backup encryption policy (to be implemented)

• API: HTTPS/TLS required
• Database: SSL/TLS REQUIRED in production (enforced via DB_SSL_REQUIRED=true)
  • Supports all PostgreSQL SSL modes: prefer, require, verify-ca, verify-full
  • Automatic certificate generation for development
  • Manual certificate configuration for production
  • Health monitoring via /health/database/ssl endpoint
  • See Database SSL Setup Guide for configuration
• File Uploads: HTTPS via FastAPI

Current Policy:

• Audit Logs: 7 years (regulatory requirement)
• User Data: Until deletion requested (GDPR)
• Documents: Until deletion requested
• Financial Data: Per regulatory requirements

Future Enhancements:

• Automated data retention service
• Configurable retention policies
• Automated archival

Production:

• Specific allowed origins (no wildcards)
• Restricted HTTP methods
• Restricted headers
• Credentials allowed for trusted origins

Development:

• Localhost origins allowed
• More permissive for development

All responses include:

• X-Content-Type-Options: nosniff
• X-Frame-Options: DENY
• X-XSS-Protection: 1; mode=block
• Strict-Transport-Security (production)
• Content-Security-Policy
• Referrer-Policy
• Permissions-Policy

• Default: 60 requests per minute per IP
• Login Endpoint: Stricter limits (account lockout)
• File Upload: Size limits (20MB)
• Configurable: Via settings.RATE_LIMIT_PER_MINUTE

• Production: Specific domains only
• Development: Localhost and all hosts
• Middleware: TrustedHostMiddleware

Implementation Status: ✅ COMPLETE

CreditNexus enforces SSL/TLS encryption for all PostgreSQL database connections in production.

Configuration:

• SSL Modes: prefer, require, verify-ca, verify-full
• Production Mode: verify-full (recommended)
• Certificate Validation: CA certificate verification enabled
• Auto-Generation: Self-signed certificates for development
• Health Monitoring: Real-time SSL status via /health/database/ssl

Environment Variables:

DB_SSL_MODE=verify-full          # SSL mode
DB_SSL_CA_CERT=/path/to/ca.crt   # CA certificate path
DB_SSL_REQUIRED=true              # Require SSL (fail if unavailable)
DB_SSL_AUTO_GENERATE=true         # Auto-generate certs (development)

Security Features:

• ✅ Automatic certificate generation for development
• ✅ Manual certificate configuration for production
• ✅ Certificate validation (CA and hostname)
• ✅ Mutual TLS support (client certificates)
• ✅ Connection health monitoring
• ✅ Configuration validation at startup

Compliance:

• ✅ GDPR: Article 32 - Encrypted data in transit
• ✅ DORA: Article 8 - Secure communication channels
• ✅ PCI-DSS: Requirement 4 - Encrypted transmission

Documentation:

• Database SSL Setup Guide
• SSL Troubleshooting Guide

Implemented:

• ✅ Right to access (data export endpoint)
• ✅ Right to deletion (data erasure endpoint)
• ✅ Audit logging
• ✅ Data minimization principles
• ✅ Encryption at rest for PII (Fernet symmetric encryption)

In Progress:

• ⚠️ Data retention policies (automated)
• ⚠️ Breach notification automation

Endpoints:

• POST /api/gdpr/export - Export user data
• POST /api/gdpr/delete - Delete user data
• GET /api/gdpr/status - Compliance status

Implemented:

• ✅ Security testing in CI/CD
• ✅ Vulnerability management process
• ✅ Incident response plan

In Progress:

• ⚠️ Business continuity plan
• ⚠️ Third-party risk assessment
• ⚠️ Operational resilience documentation

Implemented:

• ✅ CDM event generation
• ✅ CDM-compliant data models
• ✅ Policy evaluation events
• ✅ Trade execution events

• Pydantic Models: All API inputs validated
• File Uploads: PDF magic bytes validation, structure validation
• SQL Injection: Prevented via SQLAlchemy ORM
• XSS: Output encoding, CSP headers

• Environment Variables: All secrets in environment
• Pydantic SecretStr: API keys stored as SecretStr
• No Hardcoding: Secrets never in code
• Secrets Scanning: detect-secrets in pre-commit and CI/CD

Automated Scans:

• SAST: Bandit, Semgrep (on every push)
• SCA: pip-audit, Safety, npm audit (on every push)
• Secrets: detect-secrets (pre-commit and CI/CD)
• DAST: OWASP ZAP (weekly scheduled)

Frequency:

• On Push: All SAST and SCA scans
• Weekly: DAST scans
• On PR: Full security scan suite

• Dependabot: Automated dependency updates
• Version Pinning: uv.lock and package-lock.json
• Vulnerability Scanning: Automated in CI/CD
• Update Policy: Critical/High within 30 days

See Incident Response Plan for detailed procedures.

Key Points:

• 24/7 incident response capability
• Classified severity levels (P0-P3)
• Defined response timelines
• Communication procedures
• Post-incident review process

See Vulnerability Management Process for detailed procedures.

Key Points:

• Automated vulnerability detection
• Severity classification (Critical, High, Medium, Low)
• Remediation timelines
• Responsible disclosure process
• Continuous improvement

1. Never commit secrets:

   • Use environment variables
   • Use .env files (not committed)
   • Use secret management services in production

2. Validate all input:

   • Use Pydantic models
   • Sanitize user-provided data
   • Validate file uploads

3. Follow secure coding practices:

   • Use parameterized queries (SQLAlchemy ORM)
   • Escape output
   • Implement proper error handling
   • Use security headers

4. Keep dependencies updated:

   • Review Dependabot PRs promptly
   • Update dependencies regularly
   • Test updates before merging

5. Review security scan results:

   • Check GitHub Security tab regularly
   • Fix high/critical issues immediately
   • Address medium issues within 30 days

1. Monitor security:

   • Review security scan results
   • Monitor for anomalies
   • Respond to alerts promptly

2. Maintain security:

   • Keep systems patched
   • Update security configurations
   • Review access controls regularly

3. Document security:

   • Document security changes
   • Maintain security logs
   • Update security documentation

• Email: security@creditnexus.com
• Response Time: Within 24 hours
• Process: See Vulnerability Management

• Security Lead: [Email]
• CTO: [Email]
• DevOps: [Email]

• OWASP Top 10
• OWASP ASVS
• NIST Cybersecurity Framework

• Bandit Documentation
• Semgrep Documentation
• OWASP ZAP Documentation

• GDPR Compliance Guide
• DORA Regulation

Document Owner: Security Team
Review Date: Quarterly
Next Review: [Date]