Authentication & Authorization
JWT RS256 Signature Verification
All API authentication uses asymmetric RS256 (RSA-SHA256) JSON Web Tokens. The public key is fetched and cached by the API. The JWT library rejects tokens signed with the alg:none claim — no exceptions.
Implementation: NestJS JWT Guard + TenantContextGuard on all protected routes. Token validation happens before request handler execution. Invalid tokens return HTTP 401.
Multi-Tenant Row-Level Security
Every data model includes a tenantId foreign key. All queries are automatically scoped to the authenticated tenant's ID via the TenantContextGuard. A user with a valid JWT for Tenant A cannot retrieve data from Tenant B, even if they construct a direct SQL query or API call.
Implementation: Prisma where clause on every find operation. TenantContextGuard injects the tenantId into the request context. Database triggers and RLS (Row-Level Security) provide an additional enforcement layer.
Password Hashing
User passwords are hashed using bcrypt with a cost factor of 12. This means each password hash requires approximately 2^12 (4096) iterations of the bcrypt algorithm. Plaintext passwords are never logged or transmitted outside of the HTTPS tunnel.
Data Encryption
In-Transit Encryption (TLS 1.3)
All communication between client and server is encrypted using TLS 1.3. The Traefik reverse proxy terminates TLS and forwards requests to the API container over the internal Docker network. HTTP traffic is redirected to HTTPS. Mixed content (HTTP + HTTPS) is blocked by browser security policies.
Certificate: Issued by Let's Encrypt, auto-renewed via Traefik. HSTS header enforces HTTPS-only browsing for future visits.
At-Rest Encryption (AES-256)
Database files at rest are encrypted using AES-256 by the host filesystem or database encryption layer. Backup files are compressed and stored in encrypted storage (e.g., encrypted S3 buckets or encrypted local storage). Database credentials and API keys are stored in encrypted environment files (.env.docker) with restricted file permissions (chmod 600).
Data Locality
In compliance with RBI Master Direction on IT (2021) and DPDP Act 2023, all data is stored within Indian data centers. Cross-border data transfer is restricted and logged. Vendor data residency is tracked and monitored via the cross-border transfer compliance module.
API Security & Export Signing
RSA-SHA256 Signed Exports
When users export board-ready reports (PDFs), audit findings, or compliance snapshots, the export is digitally signed using RSA-SHA256. The signature is embedded in the PDF metadata. Recipients can verify the signature using the public key published on the CreativeCyber security page, confirming that the document has not been tampered with since creation and that it originated from RiskSage.
Export Integrity Verification
On every export request, the API:
- Assembles the report data (e.g., audit findings, maturity scores)
- Renders the report as HTML → PDF via Chromium
- Signs the PDF payload with the RSA-256 private key
- Embeds the signature in the PDF metadata
- Streams the PDF to the client with a content hash header
Input Validation & Output Encoding
All API endpoints use class-validator Data Transfer Objects (DTOs) to validate input. Invalid data (e.g., oversized strings, malformed UUIDs, SQL-like patterns) is rejected at the request boundary with a 400 Bad Request. HTML output is escaped to prevent XSS. Database queries use parameterized statements to prevent SQL injection.
Compliance & Audit
SOC 2 Type II Readiness
RiskSage is architected to meet SOC 2 Trust Service Criteria across the following areas:
- CC (Common Criteria): Configuration Management, Change Management, Logical Access Controls
- A (Availability): Infrastructure redundancy, incident response procedures, monitoring and alerting
- C (Confidentiality): Encryption in transit and at rest, multi-tenant isolation, access controls
- I (Integrity): Data validation, audit logging, export signing
- P (Privacy): DPDP consent management, user data rights, breach notification procedures
Status: Ready for formal SOC 2 Type II audit. Security assessment documentation available upon request for qualified auditors.
Audit Logging
All sensitive operations (authentication, data modification, export generation, exception handling) are logged with timestamps, user identity, action type, and outcome. Logs are immutable — deletion and update triggers prevent accidental or malicious alteration. Logs are retained for 180 days (CERT-In compliance) and available for forensic analysis.
Regulatory Alignment
RiskSage infrastructure is aligned with:
- RBI Master Direction on IT (2021): Data localisation, encryption, access controls, incident response
- DPDP Act 2023: Consent management, data minimisation, breach notification (within 72 hours)
- CERT-In 6-Hour Reporting: Incident logging and alert escalation
- IRDAI Cybersecurity 2023: Data protection, audit readiness, board reporting
- ISO 27001: Information security management system principles
CERT-In Empanelment Roadmap
Current Status
RiskSage is currently not yet empanelled as a CERT-In auditor/assessor under ISPIRT categories. However, the infrastructure and audit-readiness required for CERT-In empanelment are in place:
Roadmap to Empanelment
- Phase 1 (Current): SOC 2 Type II audit (3–4 months from engagement)
- Phase 2: ISO 27001 certification (concurrent with SOC 2)
- Phase 3: CERT-In competency assessment + formal empanelment application (post-Phase 1 completion, 2–3 months)
- Phase 4: CERT-In auditor training for CreativeCyber team members (optional, based on demand)
Why CERT-In Empanelment Matters
When RiskSage is empanelled as a CERT-In auditor, organisations using RiskSage can leverage its assessment modules (VAPT, threat modelling, incident response) for direct CERT-In submission, eliminating duplicate third-party audits. This roadmap is under active discussion with CERT-In (coordinated with CreativeCyber's regulatory liaison team).
Infrastructure Architecture
Container & Orchestration
RiskSage runs on Docker and Docker Compose (single-host deployment for current capacity). Key services:
- risksage_api: NestJS application (port 3000 internal)
- risksage_worker: BullMQ background job processor
- risksage_postgres: PostgreSQL 16 database (port 5432 internal)
- risksage_redis: Redis 7 cache and queue store (port 6379 internal)
- risksage_web: Nginx reverse proxy serving landing pages (port 80 external → 443 TLS)
Reverse Proxy & TLS Termination
Traefik (or nginx, depending on deployment) terminates TLS and routes traffic to services. No internal service is exposed directly to the internet. All external communication is encrypted.
Network Isolation
Internal services (API, database, Redis, worker) communicate over a private Docker network. This network is not accessible from the host or external hosts. Only Traefik has access to both the public network and the internal service network.
Secrets Management
Database credentials, JWT secrets, and API keys are stored in .env.docker (not in git). File permissions are restricted to the deployer user. Secrets are never logged in application output.
Security Certifications & Badges
Reporting a Security Vulnerability
If you discover a security vulnerability in RiskSage, please report it to security@creativecyber.in with:
- Vulnerability description and impact
- Steps to reproduce (if applicable)
- Your contact information and preferred communication method
We aim to acknowledge vulnerabilities within 24 hours and provide a fix timeline within 5 business days. Please do not publicly disclose the vulnerability until a fix is released.