CS-413 [BUG] SoA shows "unavailable" to auditor account

[github-actions]

This is an automated pull request to merge chas/soa-as-auditor into dev.
It was created by the [Auto Pull Request] action.

---

Summary by cubic

Allow auditors to view the Statement of Applicability without creating data by adding a read-only get-setup API (audit:read) and updating the app to use it when the user lacks audit:create (CS-413). Also pass the trusted org ID to the service, enforce ISO 27001-only support, and show a clear empty state when setup is missing.

^{Written for commit ee5ff4f. Summary will update on new commits. Review in cubic}

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
comp-framework-editor	Ready	Preview, Comment	May 26, 2026 5:09pm

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
app	Skipped		May 26, 2026 5:09pm
portal	Skipped		May 26, 2026 5:09pm

[linear]

CS-413

[cubic-dev-ai]

1 issue found across 1 file

Confidence score: 2/5

• There is a concrete security/authorization risk: ensure-setup in apps/api/src/soa/soa.controller.ts can create SOA records while only requiring audit:read, which permits mutation under a read-level scope.
• Given the high severity (7/10) and high confidence (9/10), this is likely user-impacting and raises regression risk if merged without tightening permissions for the endpoint.
• Pay close attention to apps/api/src/soa/soa.controller.ts - align endpoint authorization with write/create behavior to avoid privilege escalation.

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[chasprowebdev]

@cubic-dev-ai please review it

[cubic-dev-ai]

@cubic-dev-ai please review it

@chasprowebdev I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

2 issues found across 8 files

Confidence score: 2/5

• There is a high-risk tenant isolation issue in apps/api/src/soa/soa.controller.ts: trusting organizationId from the request body instead of enforcing @OrganizationId() can allow cross-tenant access/update behavior.
• apps/app/src/app/(app)/[orgId]/documents/statement-of-applicability/components/SOAFrameworkTabs.tsx also has a user-facing regression risk where getSOASetup can leave tabs stuck in a perpetual loading spinner when setup is missing or fetch fails.
• Given the high severity (8/10) and high confidence (9/10) on the API scoping issue, this is not quite safe to merge without fixes.
• Pay close attention to apps/api/src/soa/soa.controller.ts, apps/app/src/app/(app)/[orgId]/documents/statement-of-applicability/components/SOAFrameworkTabs.tsx - enforce tenant scoping in the controller and ensure loading/error fallback exits spinner state.

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[tofikwest]

@cubic-dev-ai review it

[cubic-dev-ai]

@cubic-dev-ai review it

@tofikwest I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

2 issues found across 8 files

Confidence score: 3/5

• There is a concrete user-facing regression risk in apps/app/src/app/(app)/[orgId]/documents/statement-of-applicability/page.tsx: when get-setup returns a valid null for read-only users, the page treats it as an error and can show auditors a failure state instead of a missing-setup state.
• This is moderate merge risk (severity 6/10, high confidence), while the apps/api/src/soa/soa.service.ts concern is lower-impact technical debt focused on duplicated lookup logic and future drift risk.
• Pay close attention to apps/app/src/app/(app)/[orgId]/documents/statement-of-applicability/page.tsx and apps/api/src/soa/soa.service.ts - fix null-setup handling for read-only flows and consider consolidating setup lookup logic to reduce divergence.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="apps/api/src/soa/soa.service.ts">

<violation number="1" location="apps/api/src/soa/soa.service.ts:322">
P2: `getSetup` duplicates existing SOA setup lookup logic instead of reusing a shared helper, which increases drift and maintenance risk.</violation>
</file>

<file name="apps/app/src/app/(app)/[orgId]/documents/statement-of-applicability/page.tsx">

<violation number="1" location="apps/app/src/app/(app)/[orgId]/documents/statement-of-applicability/page.tsx:97">
P2: Using `get-setup` for read-only users can produce valid `null` setup data, but the existing flow still converts that into an error state. This will show a failure message for auditors when setup is simply missing.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

P2: getSetup duplicates existing SOA setup lookup logic instead of reusing a shared helper, which increases drift and maintenance risk.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/api/src/soa/soa.service.ts, line 322:

<comment>`getSetup` duplicates existing SOA setup lookup logic instead of reusing a shared helper, which increases drift and maintenance risk.</comment>

<file context>
@@ -319,6 +319,47 @@ export class SOAService {
     return { success: true, configuration, document };
   }
 
+  async getSetup(dto: EnsureSOASetupDto) {
+    const framework = await db.frameworkEditorFramework.findUnique({
+      where: { id: dto.frameworkId },
</file context>

[cubic-dev-ai]

P2: Using get-setup for read-only users can produce valid null setup data, but the existing flow still converts that into an error state. This will show a failure message for auditors when setup is simply missing.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/app/src/app/(app)/[orgId]/documents/statement-of-applicability/page.tsx, line 97:

<comment>Using `get-setup` for read-only users can produce valid `null` setup data, but the existing flow still converts that into an error state. This will show a failure message for auditors when setup is simply missing.</comment>

<file context>
@@ -90,12 +91,19 @@ export default async function StatementOfApplicabilityPage({
+      const userPermissions = await resolveCurrentUserPermissions(organizationId);
+      const canCreateSetup =
+        !!userPermissions && hasPermission(userPermissions, 'audit', 'create');
+      const setupEndpoint = canCreateSetup
+        ? '/v1/soa/ensure-setup'
+        : '/v1/soa/get-setup';
</file context>