Feat/rbac v1

[Marfuen]

What does this PR do?

• Fixes #XXXX (GitHub issue number)
• Fixes COMP-XXXX (Linear issue number - should be visible at the bottom of the GitHub issue description)

Visual Demo (For contributors especially)

A visual demonstration is strongly recommended, for both the original and new change (video / image - any one).

Video Demo (if applicable):

• Show screen recordings of the issue or feature.
• Demonstrate how to reproduce the issue, the behavior before and after the change.

Image Demo (if applicable):

• Add side-by-side screenshots of the original and updated change.
• Highlight any significant change(s).

Mandatory Tasks (DO NOT REMOVE)

• I have self-reviewed the code (A decent size PR without self-review might be rejected).
• I have updated the developer docs in /docs if this PR makes changes that would require a documentation change. If N/A, write N/A here and check the checkbox.
• I confirm automated tests are in place that prove my fix is effective or that my feature works.

How should this be tested?

• Are there environment variables that should be set?
• What are the minimal test data to have?
• What is expected (happy path) to have (input and output)?
• Any other important info that could help to test that PR

Checklist

• I haven't read the contributing guide
• My code doesn't follow the style guidelines of this project
• I haven't commented my code, particularly in hard-to-understand areas
• I haven't checked if my changes generate no new warnings

^{Cursor Bugbot reviewed your changes and found no issues for commit c74407b}

[cursor]

PR Summary

High Risk
High risk because it changes core authentication flows (session/service-token auth), introduces centralized RBAC enforcement on many endpoints, and adds global audit logging that runs on most requests.

Overview
Introduces RBAC enforcement and auditing across the NestJS API. Controllers are migrated to @UseGuards(HybridAuthGuard, PermissionGuard) and annotated with @RequirePermission(...), replacing prior header-only Swagger docs and enabling permission checks via better-auth.

Authentication is reworked: the API now hosts the better-auth server (auth.server.ts) via @thallesp/nestjs-better-auth, HybridAuthGuard switches from JWKS JWT verification to better-auth session resolution (bearer or cookies), adds scoped service-to-service auth via x-service-token (replacing InternalTokenGuard), expands auth context (memberId, department, platform admin), and adds API key creation/revocation with salted hashing.

Adds global audit logging via a new AuditModule interceptor that records mutations (and opt-in reads via @AuditRead), redacts sensitive fields, computes field diffs (including member-name resolution), and special-cases comments/downloads/version actions; extensive Jest coverage is added.

Cloud Security gains new endpoints and legacy support: read endpoints for providers/findings, legacy connect/disconnect/validate-AWS, and a query service that merges “new platform” and legacy data. Controls gets a new CRUD-lite controller/service for create/delete with relationship mapping. Attachments service adds inline PDF presigned URLs and direct buffer uploads. Notification recipient filtering is tightened to exclude platform admins and pass org context to unsubscribe checks.

Also adds repository AI/dev rules docs, updates env examples to per-service tokens, and adjusts Jest module mapping / Nest CLI entry configuration.

^{Written by Cursor Bugbot for commit 021beb9. This will update automatically on new commits. Configure here.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
app	Ready	Preview, Comment	Feb 6, 2026 8:55pm

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
portal	Skipped		Feb 6, 2026 8:55pm

[cursor]

New controllers have doubled version prefix in routes

High Severity

ControlsController uses @Controller('v1/controls') and FrameworksController uses @Controller('v1/frameworks'), but the application enables URI versioning with defaultVersion: '1' in main.ts. NestJS automatically prepends /v1/ to all versioned routes, so these controllers end up registered at /v1/v1/controls and /v1/v1/frameworks — making them unreachable at the intended paths. All other controllers in the codebase use the correct @Controller({ path: '...', version: '1' }) object format.

Additional Locations (1)

• apps/api/src/frameworks/frameworks.controller.ts#L16-L17

 

[cursor]

Audit description wrongly labels non-policy archive operations

Medium Severity

extractPolicyActionDescription checks for 'isArchived' in requestBody without verifying the request path targets a policy resource. Since this function is called for ALL resources in the AuditLogInterceptor, any PATCH request on any resource that includes an isArchived field would produce the audit description "Archived policy" or "Restored policy" and also suppress change tracking. The path parameter is available but unused for this check.

 

[cursor]

Auditor role missing member and invitation read permissions

Medium Severity

The inlined auditor role definition is missing 'read' for both member and invitation resources. The canonical definition in packages/auth/src/permissions.ts grants member: ['create', 'read'] and invitation: ['create', 'read'], noting auditors need read access to "view people for audit context." This regression means auditors are denied access to member/invitation read operations that the permission system was designed to allow.

 

[cursor]

Audit log isArchived check not scoped to policy paths

Medium Severity

extractPolicyActionDescription checks for isArchived in ANY PATCH request body without verifying the URL is a policy endpoint. The /regenerate check correctly validates the path, but the isArchived check does not. If any non-policy resource ever includes isArchived in a PATCH body, the audit log will incorrectly say "Archived policy" or "Restored policy". Worse, in the interceptor, a truthy policyActionDesc forces changes = null, completely suppressing the actual field-level change tracking for that request.

Additional Locations (1)

• apps/api/src/audit/audit-log.interceptor.ts#L128-L131

 

[cursor]

Auditor role lacks finding:delete, breaking existing delete functionality

High Severity

The auditor role is defined with finding: ['create', 'read', 'update'] but omits 'delete'. The deleteFinding endpoint now uses @RequirePermission('finding', 'delete'), so auditors are blocked by the PermissionGuard before reaching the handler. Previously, @UseGuards(RequireRoles('auditor', 'admin', 'owner')) explicitly allowed auditors to delete findings. The handler's inner code still checks isAuditor and the API description still says "Auditor or Platform Admin only", confirming this was unintentional. Auditors can no longer delete findings.

Additional Locations (1)

• apps/api/src/findings/findings.controller.ts#L313-L316

 

[cursor]

Missing cloud-security resource in access control definitions

High Severity

The cloud-security resource is used in @RequirePermission('cloud-security', ...) decorators on every CloudSecurityController endpoint, but it's not included in the access control statement object in auth.server.ts, and no role (owner, admin, auditor, etc.) is granted any cloud-security permissions. When auth.api.hasPermission is called for this resource, it will return success: false for all session-authenticated users, effectively making all cloud security endpoints return 403 Forbidden. Only API key users (which bypass permission checks) can access these endpoints.

Additional Locations (1)

• apps/api/src/cloud-security/cloud-security.controller.ts#L39-L58

 

[cursor]

Audit description wrongly hardcodes "policy" for all resources

Medium Severity

extractPolicyActionDescription is called for every resource, not just policies. The isArchived check on line 181 matches any PATCH request containing isArchived in the body, regardless of the actual resource type. If a non-policy resource (e.g., a vendor) is archived via PATCH, the audit log will incorrectly say "Archived policy" instead of the correct resource name, and the changes diff will be suppressed. The /regenerate pattern has the same issue.

Additional Locations (1)

• apps/api/src/audit/audit-log.interceptor.ts#L120-L129

 

[cursor]

Cloud security resource missing from RBAC permission definitions

High Severity

The cloud-security resource is used in @RequirePermission('cloud-security', 'read') (and other actions) on the cloud security controller, but it's not defined in the access control statement or in any role definition in auth.server.ts. Since better-auth's hasPermission returns false for undefined resources, all session-authenticated users (owner, admin, auditor, etc.) will be denied access to every cloud security endpoint. Only API keys (which bypass permission checks) and platform admins can access these routes.

Additional Locations (1)

• apps/api/src/cloud-security/cloud-security.controller.ts#L39-L40

 

[cursor]

Archive description hardcodes "policy" for all resources

Medium Severity

extractPolicyActionDescription checks for isArchived in the request body without verifying the URL path contains /policies/. This function is called for every mutation request in the interceptor, so a PATCH to any resource that includes isArchived would produce audit descriptions like "Archived policy" or "Restored policy" regardless of the actual resource. It also suppresses the changes diff via the policyActionDesc truthy check in the interceptor.

Additional Locations (1)

• apps/api/src/audit/audit-log.interceptor.ts#L128-L131

 

[cursor]

Wrong Prisma model mapping for task audit lookups

Medium Severity

RESOURCE_TO_PRISMA_MODEL maps task to 'taskItem', but the task permission resource corresponds to the Task Prisma model (accessed via db.task), not TaskItem (which is a separate entity for task management items with different IDs and fields). When fetchCurrentValues runs for a task update, it queries db.taskItem.findUnique with a tsk_-prefixed ID, which will never match a tski_-prefixed TaskItem record, so previous values are always null and audit log diffs for task changes will be missing.

 

[cursor]

Missing cloud-security and training in access control statement

High Severity

The statement object in auth.server.ts does not include cloud-security or training as resources, yet @RequirePermission('cloud-security', ...) and @RequirePermission('training', ...) are used on controller endpoints. Since these resources aren't defined in the access control, auth.api.hasPermission will return false for all session-authenticated users, making cloud security and training endpoints completely inaccessible. No built-in role grants these permissions either. The canonical packages/auth/src/permissions.ts also omits these resources.

Additional Locations (2)

• apps/api/src/cloud-security/cloud-security.controller.ts#L39-L40
• apps/api/src/training/training.controller.ts#L37-L38

 

[cursor]

Inlined permissions diverge from canonical permission definitions

Medium Severity

The auth.server.ts statement is described as "inlined from @comp/auth" but diverges from packages/auth/src/permissions.ts. The canonical source overrides member to include 'read', invitation to include 'read', and team/ac with full CRUD. The inlined version omits these overrides, relying on defaultStatements which lack 'read' for member/invitation. The auditor role also drops member:['read'] and invitation:['read']. Since auth.server.ts is the running auth server, member:read is not a valid permission at runtime, so any permission check requiring it will always fail.

Additional Locations (1)

• apps/api/src/auth/auth.server.ts#L83-L101

 

[cursor]

Audit log isArchived check lacks path restriction

Medium Severity

extractPolicyActionDescription checks for isArchived in the request body for any PATCH request without restricting to policy URLs. This function runs in a global interceptor on every request. If any non-policy resource ever accepts an isArchived field in a PATCH body, the audit log would incorrectly say "Archived policy" or "Restored policy" and would also suppress the changes diff. The path parameter is available but unused for this check, unlike the /regenerate check above it which properly validates the path.

 

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

[cursor]

Missing cloud-security and training in RBAC permission statements

High Severity

The statement object passed to createAccessControl does not include cloud-security or training as resources, yet controllers use @RequirePermission('cloud-security', ...) and @RequirePermission('training', ...). Since no built-in role (owner, admin, auditor, etc.) can be granted permissions on undefined resources, auth.api.hasPermission will deny all session-authenticated users access to cloud security and training endpoints. API key and service token paths are unaffected, but regular logged-in users will get ForbiddenException on every cloud security and training request.

Additional Locations (2)

• apps/api/src/cloud-security/cloud-security.controller.ts#L39-L40
• apps/api/src/training/training.controller.ts#L37-L38

 

[cursor]

Audit description not scoped to policy resource path

Medium Severity

extractPolicyActionDescription checks for isArchived in any PATCH request body without verifying the path corresponds to a policy endpoint. Since this function is called by the global AuditLogInterceptor for all mutation requests, any future resource that adds an isArchived field would have its audit log entries incorrectly labeled as "Archived policy" or "Restored policy" instead of referencing the actual resource. The path parameter is already available but unused for this check.