OpenDocket — supabase

Compliance Risk Analysis

supabase

https://github.com/supabase/supabase
Scanned 2026-03-23 · OpenDocket V1 · Primary: Claude Sonnet · Review: Gemini 2.5 Flash

Important Limitations of This Report

This report is not legal advice and is not defensible in court. It provides directional guidance only. To obtain a defensible compliance assessment, engage a licensed attorney and certified auditor.

Scope limitations: Only public repository content was analyzed. Infrastructure configuration, deployment settings, operational policies, vendor contracts, and staff training are outside scope.

A true compliance audit would also review: vendor contracts and BAAs, staff training records, incident response procedures, physical security controls, and system audit logs — none of which are visible in source code.

Risk Assessment

This analysis identified 56 compliance patterns across GDPR, HIPAA, PCI-DSS, SOC2, SOX, TCPA. After independent verification by Gemini 2.5 Flash, 2 high-severity findings were confirmed and 52 were identified as possible false positives — likely pattern matches in documentation or configuration files rather than application source code. The 2 confirmed findings represent the primary areas requiring attention.

MODERATE RISK

2 confirmed high-severity findings
47 total patterns identified · 52 flagged as possible false positives by independent review

What This Means If Unaddressed

Framework	Regulatory Body	Max Penalty	Enforcement Trend
GDPR (9 high)	EU DPAs	Up to EUR 20M or 4% turnover	Cross-border enforcement rising
TCPA (8 high)	FCC	$500-$1,500 per violation	Class action filings at record levels
SOX (8 high)	SEC / PCAOB	Criminal penalties, delisting	IT controls under increased scrutiny
SOC2 (8 high)	AICPA	Loss of enterprise contracts	Mandatory for enterprise SaaS sales
PCI-DSS (7 high)	PCI SSC	Fines $5K-$100K/month	v4.0 enforcement accelerating
HIPAA (7 high)	HHS / OCR	Fines up to $1.5M/year per category	Increasing enforcement, record penalties in 2024

Top Findings

High RiskPCI-DSSPCIDSS-008apps/docs/app/api/revalidate/route.utils.ts:27 · Review: CONFIRMED

Implement a comprehensive cryptographic key management system that covers the full lifecycle: key generation using cryptographically secure methods, secure distribution mechanisms, encrypted storage w

High RiskTCPATCPA-006No specific file cited · Review: CONFIRMED

Implement a comprehensive consent management system that captures and stores all required TCPA consent elements in a structured database. This should include creating database schemas to store consent

High RiskGDPRGDPR-001.claude/skills/telemetry-standards/SKILL.md:61 · Review: POSSIBLE FALSE POSITIVE

Conduct a comprehensive data processing audit to identify all personal data processing activities (authentication, user profiles, analytics, AI interactions, etc.) and document the specific Article 6

Gemini Verification Layer

How to read this: The confirmed count is your action list. The false positive count shows where the scanner found keyword patterns in documentation rather than application source code. Click any finding to see exactly what evidence was found and why Gemini made its determination.

4Confirmed

0Context dependent

52Possible false positives

0Additional risk

Primary: Claude Sonnet (Anthropic). Verification: Gemini 2.5 Flash (Google). Neither constitutes legal advice.

Recommended Actions

High

Establish and document a comprehensive key management lifecycle for the `DOCS_REVALIDATION_OVERRIDE_KEYS` found in `apps/docs/app/api/revalidate/route.utils.ts`. This must include secure generation, distribution, storage, rotation, and destruction of these and any similar secrets, to ensure compliance with PCI DSS Requirements 3.6 and 3.7.

PCI-DSS · PCIDSS-008 · Confirmed

High

Design and integrate a robust consent management mechanism within Supabase's database schemas, ensuring records capture TCPA-required elements like date, time, method, and specific consent language presented to consumers; failure to do so risks significant regulatory penalties for non-compliant communication practices.

TCPA · TCPA-006 · Confirmed

Medium

Modify the `sendToLogflare` calls in `apps/docs/app/api/graphql/route.ts` and other relevant API endpoints to capture granular details for all access, creation, modification, and deletion of ePHI, including user and timestamp information. This specific logging enhancement is required to meet HIPAA's audit control standard for safeguarding electronic Protected Health Information.

HIPAA · HIPAA-006 · Confirmed

Medium

Modify the `input-otp` component referenced in `apps/design-system/__registry__/index.tsx` by ensuring it is fully integrated with a robust backend authentication service that enforces Multi-Factor Authentication for all user access, particularly for privileged accounts. This change is necessary to satisfy SOC2 CC6.1 requirements for logical access security.

SOC2 · SOC2-009 · Confirmed

Risk Scorecard

Framework	High Risk	Confirmed	False Pos.	Medium	Concern	No Issue
GDPR	9	0	10	0	1	0
HIPAA	7	1	9	1	1	1
PCI-DSS	7	1	9	2	0	1
SOC2	8	1	9	1	1	0
SOX	8	0	8	0	0	0
TCPA	8	1	7	0	0	0

Domains Detected

Saas

92.2%

Ecommerce

76.5%

Fintech

60.7%

Communication

46.0%

Healthcare

40.8%

Gdpr

16.7%

Sox

5.9%

HIPAA

HHS / OCR · Fines up to $1.5M/year per category

10 findings · 9 possible FP

HIPAA-006

Medium Risk›

Regulatory Standard

Gemini Verification

CONFIRMED

Application source code (route.ts) directly uses a logging mechanism (`sendToLogflare`) within a repository explicitly linked to the healthcare domain, indicating an application-level function that must meet HIPAA audit control requirements for ePHI.

Gemini 2.5 Flash · Confidence: HIGH

Evidence

[CONFIG] .gitignore:141 # For self-hosted logs: https://github.com/supabase/supabase/blob/86e3ab20abfdb9c3e666334d3d2f8efeef [SOURCE] apps/docs/app/api/graphql/route.test.ts:3 vi.mock('~/lib/logger', async () => { [SOURCE] apps/docs/app/api/graphql/route.test.ts:4 const actual = await vi.importActual<typeof import('~/lib/logger')>('~/lib/logger') [SOURCE] apps/docs/app/api/graphql/route.ts:16 import { LOGGING_CODES, sendToLogflare } from '~/lib/logger' [SOURCE] apps/docs/app/api/graphql/route.ts:257 sendToLogflare(LOGGING_CODES.CONTENT_API_REQUEST_RECEIVED, { [SOURCE] apps/docs/app/api/graphql/route.ts:16 import { LOGGING_CODES, sendToLogflare } from '~/lib/logger' [DOCS] apps/docs/components/AuthSmsProviderConfig/MessageBirdConfig.mdx:22 Start by logging into your MessageBird account and verify the mobile number you'll be using to test [DOCS] apps/docs/components/AuthSmsProviderConfig/TwilioConfig.mdx:57 Start by logging into your Twilio account and starting a new project: https://www.twilio.com/console

Finding

Does the system implement hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use electronic Protected Health Information, as required under the audit controls standard?

Remediation

Remediation refined by Gemini review

Possible False Positives (9)Gemini flagged these as likely pattern matches in non-source-code files. Review before acting.

›

HIPAA-001 · Possible False Positive

No Issue Found›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence consists solely of documentation files (.md) discussing front-end styling classes and component composition, which are entirely unrelated to Protected Health Information (PHI) or HIPAA compliance.

Evidence

[DOCS] .agents/skills/vitest/references/advanced-environments.md:106 el.className = 'test' [DOCS] .agents/skills/vitest/references/advanced-environments.md:107 expect(el.className).toBe('test') [DOCS] .agents/skills/vitest/references/advanced-environments.md:229 classNameStrategy: 'non-scoped', [DOCS] .claude/skills/vercel-composition-patterns/AGENTS.md:863 return <footer className='flex'>{children}</footer> [DOCS] .claude/skills/vercel-composition-patterns/AGENTS.md:812 Use `children` for composition instead of `renderX` props. Children are more [DOCS] .claude/skills/vercel-composition-patterns/SKILL.md:63 of renderX props [DOCS] .claude/skills/vercel-composition-patterns/rules/patterns-children-over-render-props.md:59 return <footer className='flex'>{children}</footer> [DOCS] .claude/skills/vercel-composition-patterns/rules/patterns-children-over-render-props.md:10 Use `children` for composition instead of `renderX` props. Children are more

Finding

Does this system collect, store, process, or transmit individually identifiable health information as defined under 45 CFR §160.103, and if so, are adequate technical safeguards in place to protect the confidentiality of such Protected Health Information?

Remediation

The documentation files `.agents/skills/vitest/references/advanced-environments.md` and `.claude/skills/vercel-composition-patterns/AGENTS.md` describe styling classes and component patterns. No modifications are needed to these files as they do not involve the collection, storage, or transmission of Protected Health Information, thus posing no risk under HIPAA.

HIPAA-002 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited is from example UI component files containing descriptive text ('All transactions are secure and encrypted') or irrelevant comments, which do not reflect the actual implementation of encryption at rest for ePHI, a backend/infrastructure concern.

Evidence

[SOURCE] apps/design-system/registry/default/example/accordion-demo.tsx:20 Yes. It comes with default styles that matches the other components' aesthetic. [SOURCE] apps/design-system/registry/default/example/field-demo.tsx:26 <FieldDescription>All transactions are secure and encrypted</FieldDescription> [SOURCE] apps/design-system/registry/default/example/field-demo.tsx:26 <FieldDescription>All transactions are secure and encrypted</FieldDescription> [SOURCE] apps/design-system/registry/default/example/select-scrollable.tsx:55 <SelectItem_Shadcn_ value="aest"> [SOURCE] apps/design-system/registry/default/example/select-scrollable.tsx:56 Australian Eastern Standard Time (AEST) [SOURCE] apps/design-system/registry/default/example/toc-demo.tsx:104 proper authentication, encryption, and access controls. [SOURCE] apps/design-system/registry/default/example/toc-single-demo.tsx:104 proper authentication, encryption, and access controls. [SOURCE] apps/docs/components/AppleSecretGenerator/AppleSecretGenerator.tsx:56 const privateKey = await globalThis.crypto.subtle.importKey(

Finding

Is electronic Protected Health Information encrypted when stored at rest using methods consistent with NIST Special Publication 800-111, as required for addressable implementation under the HIPAA Security Rule?

Remediation

Review the descriptive text 'All transactions are secure and encrypted' in `apps/design-system/registry/default/example/field-demo.tsx` to clarify its illustrative nature, preventing misinterpretation by automated scanners and avoiding future false positive findings related to the HIPAA Security Rule for encryption at rest.

HIPAA-003 · Possible False Positive

Pattern of Concern›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited consists solely of documentation files (.md), and the URLs referenced within these documents explicitly use HTTPS, indicating encrypted transit, which contradicts the finding's implied concern regarding encryption in transit.

Evidence

[DOCS] .agents/skills/vitest/SKILL.md:7 source: Generated from https://github.com/vitest-dev/vitest, scripts located at https://github.com/a [DOCS] .agents/skills/vitest/references/advanced-environments.md:263 - https://vitest.dev/guide/environment.html [DOCS] .agents/skills/vitest/references/advanced-projects.md:212 apiUrl: 'https://staging.api.com', [DOCS] .agents/skills/vitest/references/advanced-projects.md:221 apiUrl: 'https://api.com', [DOCS] .agents/skills/vitest/references/advanced-projects.md:299 - https://vitest.dev/guide/projects.html [DOCS] .agents/skills/vitest/references/advanced-type-testing.md:235 - https://vitest.dev/guide/testing-types.html [DOCS] .agents/skills/vitest/references/advanced-type-testing.md:236 - https://vitest.dev/api/expect-typeof.html [DOCS] .agents/skills/vitest/references/advanced-vi.md:248 - https://vitest.dev/api/vi.html

Finding

Are all transmissions of electronic Protected Health Information encrypted using transport-level security consistent with NIST guidelines, preventing unauthorized access during transmission across electronic communications networks?

Remediation

Review documentation files such as `.agents/skills/vitest/SKILL.md` and `.agents/skills/vitest/references/advanced-projects.md` to confirm all referenced URLs for API endpoints or external resources consistently use HTTPS. Any discovery of HTTP URLs must be updated to HTTPS to prevent unencrypted transmission of potential ePHI, avoiding HIPAA violations.

HIPAA-004 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of documentation and configuration files, not application source code, which prevents confirmation of the actual implementation of HIPAA-compliant access controls.

Evidence

[DOCS] .agents/skills/vitest/references/core-describe.md:40 test('shows login page', () => {}) [DOCS] .agents/skills/vitest/references/features-filtering.md:30 vitest -t "login" [DOCS] .agents/skills/vitest/references/features-filtering.md:183 vitest user -t "login" --changed [CONFIG] .claude/settings.json:3 "SessionStart": [ [DOCS] .claude/skills/e2e-studio-tests/SKILL.md:72 1. **`getByRole` with accessible name** - Most robust, tests accessibility [DOCS] .claude/skills/e2e-studio-tests/SKILL.md:74 page.getByRole('button', { name: 'Save' }) [DOCS] .claude/skills/e2e-studio-tests/SKILL.md:75 page.getByRole('button', { name: 'Configure API privileges' }) [DOCS] .claude/skills/e2e-studio-tests/SKILL.md:104 element.locator('..').getByRole('button')

Finding

Does the system implement technical policies and procedures for electronic information systems that maintain electronic Protected Health Information to allow access only to those persons or software programs that have been granted access rights as specified in 45 CFR §164.312(a)(1)?

Remediation

Confirm that actual code backing `test('shows login page', () => {})` in `.agents/skills/vitest/references/core-describe.md` and `SessionStart` in `.claude/settings.json` rigorously enforces user authentication, role-based access control, and session validation to restrict access to electronic PHI, as mandated by 45 CFR §164.312(a)(1) to prevent unauthorized disclosure.

HIPAA-005 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited refers to test timeouts within Vitest documentation and test configurations, not actual application session management code or configuration related to user inactivity for PHI-accessing interfaces.

Evidence

[DOCS] .agents/skills/vitest/references/advanced-projects.md:133 testTimeout: 10000, [DOCS] .agents/skills/vitest/references/advanced-vi.md:106 setTimeout(() => console.log('done'), 1000) [DOCS] .agents/skills/vitest/references/advanced-vi.md:172 }, { timeout: 5000, interval: 100 }) [DOCS] .agents/skills/vitest/references/advanced-vi.md:177 { timeout: 5000 } [DOCS] .agents/skills/vitest/references/advanced-vi.md:205 testTimeout: 10_000, [DOCS] .agents/skills/vitest/references/advanced-vi.md:206 hookTimeout: 10_000, [DOCS] .agents/skills/vitest/references/core-cli.md:160 - Both camelCase (`--testTimeout`) and kebab-case (`--test-timeout`) work [DOCS] .agents/skills/vitest/references/core-config.md:76 // Test timeout in ms

Finding

Does the system implement electronic procedures that terminate an electronic session after a predetermined time of inactivity, as required for PHI-accessing interfaces under the HIPAA Security Rule?

Remediation

The timeouts referenced in `.agents/skills/vitest/references/advanced-projects.md` and `.agents/skills/vitest/references/advanced-vi.md` are related to the Vitest testing framework's execution limits, not application-level user session timeouts. Consequently, no changes are required within these specific documentation or test configuration files to meet the HIPAA Security Rule's requirement for automatic session termination.

HIPAA-007 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited exclusively refers to documentation for a testing framework (Vitest) and discusses technical aspects like test execution scope ('only reruns affected tests,' 'only type check') or project exclusion, which bear no direct relation to the disclosure or access of Protected Health Information (PHI) under HIPAA's minimum necessary standard.

Evidence

[DOCS] .agents/skills/vitest/SKILL.md:15 - Smart watch mode: Only reruns affected tests based on module graph [DOCS] .agents/skills/vitest/SKILL.md:29 | Test API | test/it function, modifiers like skip, only, concurrent | [core-test-api](references/co [DOCS] .agents/skills/vitest/references/advanced-environments.md:229 classNameStrategy: 'non-scoped', [DOCS] .agents/skills/vitest/references/advanced-projects.md:195 # Exclude project [DOCS] .agents/skills/vitest/references/advanced-type-testing.md:32 // Only type check [DOCS] .agents/skills/vitest/references/advanced-type-testing.md:33 only: false, [DOCS] .agents/skills/vitest/references/advanced-type-testing.md:199 # Type tests only [DOCS] .agents/skills/vitest/references/advanced-type-testing.md:200 vitest --typecheck.only

Finding

Does the system limit the Protected Health Information disclosed or accessed to the minimum necessary to accomplish the intended purpose, consistent with the minimum necessary standard under the Privacy Rule?

Remediation

In documentation files such as `.agents/skills/vitest/SKILL.md` and related `.md` references, explicitly clarify that terms like 'only' or 'exclude' pertain solely to test environment configurations and development processes. This ensures no misinterpretation regarding the application of HIPAA's minimum necessary standard for PHI access and disclosure, thus preventing ambiguity concerning regulatory compliance.

HIPAA-008 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited exclusively consists of documentation files (.md) related to the Vitest testing framework, specifically mentioning 'integration' configurations for tests, which does not constitute direct evidence of actual third-party service integration handling PHI or addressing BAA requirements.

Evidence

[DOCS] .agents/skills/vitest/SKILL.md:27 | Configuration | Vitest and Vite config integration, defineConfig usage | [core-config](references/ [DOCS] .agents/skills/vitest/references/advanced-projects.md:30 name: 'integration', [DOCS] .agents/skills/vitest/references/advanced-projects.md:31 include: ['tests/integration/**/*.test.ts'], [DOCS] .agents/skills/vitest/references/advanced-projects.md:190 vitest --project integration [DOCS] .agents/skills/vitest/references/core-config.md:152 name: 'integration', [DOCS] .agents/skills/vitest/references/core-config.md:153 include: ['tests/integration/**/*.test.ts'], [DOCS] .agents/skills/vitest/references/core-expect.md:213 - Use context's `expect` in concurrent tests for correct tracking [DOCS] .agents/skills/vitest/references/features-coverage.md:171 ## CI Integration

Finding

Does the system integrate with third-party services that may receive, maintain, or transmit Protected Health Information, and if so, is there evidence that Business Associate Agreement requirements are addressed in the code or configuration?

Remediation

Review `.agents/skills/vitest/SKILL.md`, `.agents/skills/vitest/references/advanced-projects.md`, and `.agents/skills/vitest/references/core-config.md` to explicitly clarify that mentions of 'integration' refer solely to testing configurations and do not imply live third-party services processing Protected Health Information. This clarification is crucial to avoid misinterpretations that could lead to unaddressed Business Associate Agreement requirements under HIPAA.

HIPAA-009 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The provided evidence consists solely of documentation for a testing framework (Vitest) describing cleanup operations within a test environment, not the final disposition of production data or Protected Health Information (PHI).

Evidence

[DOCS] .agents/skills/vitest/references/advanced-environments.md:156 delete globalThis.myGlobal [DOCS] .agents/skills/vitest/references/advanced-vi.md:98 await vi.dynamicImportSettled() [DOCS] .agents/skills/vitest/references/core-hooks.md:30 await cleanupMocks() [DOCS] .agents/skills/vitest/references/core-hooks.md:34 ## Cleanup Return Pattern [DOCS] .agents/skills/vitest/references/core-hooks.md:36 Return cleanup function from `before*` hooks: [DOCS] .agents/skills/vitest/references/core-hooks.md:143 test('with cleanup', () => { [DOCS] .agents/skills/vitest/references/core-hooks.md:158 ### Reusable Cleanup Pattern [DOCS] .agents/skills/vitest/references/core-hooks.md:236 - Return cleanup function from `before*` to avoid `after*` duplication

Finding

Does the system implement policies and procedures to address the final disposition of electronic Protected Health Information and the hardware or electronic media on which it is stored, as well as removal of PHI before media is available for reuse?

Remediation

The evidence cited (documentation files within .agents/skills/vitest/references/) describes cleanup procedures solely within a testing context and does not indicate a lack of data retention or disposal policies for PHI in a production system. Therefore, no specific changes are warranted to these documentation files to address the HIPAA-009 standard, as the finding is not applicable to the evidence provided.

HIPAA-010 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited exclusively refers to `vitest` mock restoration in documentation files, which is unrelated to actual security incident detection, reporting, or emergency access procedures for Protected Health Information.

Evidence

[DOCS] .agents/skills/vitest/references/advanced-vi.md:35 fn.mockRestore() // Restore original (for spies) [DOCS] .agents/skills/vitest/references/advanced-vi.md:126 // Restore [DOCS] .agents/skills/vitest/references/advanced-vi.md:217 vi.restoreAllMocks() // Restore originals (spies) [DOCS] .agents/skills/vitest/references/core-config.md:109 // Restore mocks between tests [DOCS] .agents/skills/vitest/references/core-config.md:110 restoreMocks: true, [DOCS] .agents/skills/vitest/references/features-context.md:137 Override fixtures per project: [DOCS] .agents/skills/vitest/references/features-context.md:162 Override fixture for specific suite: [DOCS] .agents/skills/vitest/references/features-mocking.md:51 // Restore original

Finding

Does the system implement procedures for detecting, reporting, and responding to suspected or known security incidents involving electronic Protected Health Information, and does it provide for emergency access to PHI during system disruptions?

Remediation

The cited documentation files (`.agents/skills/vitest/references/advanced-vi.md`, `.agents/skills/vitest/references/core-config.md`) detail `vitest` testing mock restoration and are not relevant to live system breach detection, reporting, or emergency access procedures. Therefore, no changes are required in these specific files to address the HIPAA-010 regulatory standard for incident response.

PCI-DSS

PCI SSC · Fines $5K-$100K/month

10 findings · 9 possible FP

PCIDSS-008

High Risk›

Regulatory Standard

Gemini Verification

CONFIRMED

The evidence shows usage of `DOCS_REVALIDATION_OVERRIDE_KEYS` from environment variables for authorization in a revalidation process. In a PCI DSS context, especially for domains like fintech and ecommerce, all such access tokens or 'keys' used in the system, even for documentation, must be subject to robust key management practices including generation, distribution, storage, rotation, and destruction, which are not evidenced in the provided source code snippets.

Gemini 2.5 Flash · Confidence: HIGH

Evidence

[SOURCE] apps/docs/app/api/revalidate/route.utils.ts:27 const overrideKeys = process.env.DOCS_REVALIDATION_OVERRIDE_KEYS?.split(/\s*,\s*/) ?? [] [SOURCE] apps/docs/app/api/revalidate/route.utils.ts:28 if (basicKeys.length === 0 && overrideKeys.length === 0) { [SOURCE] apps/docs/app/api/revalidate/route.utils.ts:37 if (overrideKeys.includes(token)) { [SOURCE] apps/docs/components/AuthSmsProviderConfig/AuthSmsProviderConfig.tsx:24 const AuthSmsProviderConfig = () => { [SOURCE] apps/docs/components/AuthSmsProviderConfig/AuthSmsProviderConfig.tsx:89 export default AuthSmsProviderConfig [DOCS] apps/docs/components/AuthSmsProviderConfig/MessageBirdConfig.mdx:2 import { CostWarning } from './AuthSmsProviderConfig.Warnings' [DOCS] apps/docs/components/AuthSmsProviderConfig/TextLocalConfig.mdx:2 import { CostWarning } from './AuthSmsProviderConfig.Warnings' [DOCS] apps/docs/components/AuthSmsProviderConfig/TwilioConfig.mdx:2 import { CostWarning } from './AuthSmsProviderConfig.Warnings'

Finding

Does the system implement cryptographic key management procedures including key generation, distribution, storage, rotation, and destruction, consistent with PCI DSS Requirement 3.6 and 3.7?

Remediation

Remediation refined by Gemini review

Possible False Positives (9)Gemini flagged these as likely pattern matches in non-source-code files. Review before acting.

›

PCIDSS-001 · Possible False Positive

No Issue Found›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence consists solely of documentation files (.md) with content related to UI testing, which does not directly involve the storage, processing, or transmission of cardholder data as per PCI DSS requirements.

Evidence

[DOCS] .claude/skills/e2e-studio-tests/SKILL.md:80 page.getByTestId('table-editor-side-panel') [DOCS] .claude/skills/e2e-studio-tests/SKILL.md:135 // Good - scoped to side panel [DOCS] .claude/skills/e2e-studio-tests/SKILL.md:136 const sidePanel = page.getByTestId('table-editor-side-panel') [DOCS] .claude/skills/e2e-studio-tests/SKILL.md:137 const toggle = sidePanel.getByRole('switch') [DOCS] .claude/skills/studio-testing/SKILL.md:89 For the complete guide with all rules expanded: `AGENTS.md` [DOCS] .claude/skills/vercel-composition-patterns/SKILL.md:89 For the complete guide with all rules expanded: `AGENTS.md` [DOCS] .cursor/rules/studio/best-practices/RULE.md:95 <UserSettingsPanel /> [DOCS] .cursor/rules/studio/best-practices/RULE.md:107 ├── UserPanel.tsx

Finding

Does this system store, process, or transmit cardholder data including primary account numbers (PAN), and if so, are adequate protections in place to render stored PAN unreadable, as required under PCI DSS Requirement 3.5?

Remediation

The documentation files, such as `.claude/skills/e2e-studio-tests/SKILL.md` and `.claude/skills/studio-testing/SKILL.md`, do not require any changes as they do not handle cardholder data. If the system's core functionality is extended to store, process, or transmit cardholder data, applicable components must then implement strong encryption for stored PANs to avoid PCI DSS Requirement 3.5 non-compliance.

PCIDSS-002 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of documentation files (.md), which cannot inherently demonstrate a lack of strong encryption for cardholder data in transit or at rest, leading to a likely false positive for this specific PCI DSS requirement.

Evidence

Finding

Is cardholder data encrypted using strong cryptography during transmission over open public networks and when stored at rest, consistent with PCI DSS Requirements 3.5 and 4.2?

Remediation

Within `.agents/skills/vitest/references/advanced-projects.md`, ensure any `apiUrl` examples are accompanied by context indicating that live API endpoints processing cardholder data use strong cryptography (e.g., TLS 1.2+ with AES-256) to comply with PCI DSS Requirements 3.5 and 4.2.

PCIDSS-003 · Possible False Positive

Medium Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of a Markdown documentation file for end-to-end tests (`.md`), specifically demonstrating UI element selection techniques rather than application source code or configuration related to access controls for cardholder data.

Evidence

[DOCS] .claude/skills/e2e-studio-tests/SKILL.md:72 1. **`getByRole` with accessible name** - Most robust, tests accessibility [DOCS] .claude/skills/e2e-studio-tests/SKILL.md:74 page.getByRole('button', { name: 'Save' }) [DOCS] .claude/skills/e2e-studio-tests/SKILL.md:75 page.getByRole('button', { name: 'Configure API privileges' }) [DOCS] .claude/skills/e2e-studio-tests/SKILL.md:104 element.locator('..').getByRole('button') [DOCS] .claude/skills/e2e-studio-tests/SKILL.md:111 popover.getByRole('combobox') [DOCS] .claude/skills/e2e-studio-tests/SKILL.md:127 page.getByRole('button', { name: 'Configure API privileges' }) [DOCS] .claude/skills/e2e-studio-tests/SKILL.md:137 const toggle = sidePanel.getByRole('switch') [DOCS] .claude/skills/e2e-studio-tests/SKILL.md:141 const roleSection = popover.getByText('Anonymous (anon)', { exact: true })

Finding

Does the system restrict access to cardholder data to only those individuals and systems whose job requires such access, implementing role-based access controls consistent with PCI DSS Requirement 7?

Remediation

Review `.claude/skills/e2e-studio-tests/SKILL.md` (specifically line 75 mentioning 'Configure API privileges') to ensure test documentation does not inadvertently imply direct or unrestricted access to sensitive systems or cardholder data, which could be misinterpreted as a lack of role-based access controls. Misleading documentation about privilege configuration could suggest a compliance gap against PCI DSS Requirement 7.

PCIDSS-004 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The provided evidence files, consisting of internal AI testing documentation and source code for the project's public documentation application, do not contain any information relevant to network segmentation, infrastructure configuration, or the handling of cardholder data environments (CDE) as described in PCI-DSS Requirement 1.

Evidence

[DOCS] .claude/skills/studio-testing/rules/testing-exhaustive-permutations.md:4 impactDescription: catches edge cases and regressions in business logic [SOURCE] apps/docs/app/guides/functions/[[...slug]]/page.tsx:12 const FunctionsGuidePage = async (props: { params: Promise<Params> }) => { [SOURCE] apps/docs/app/guides/functions/[[...slug]]/page.tsx:25 export default FunctionsGuidePage [SOURCE] apps/docs/app/guides/integrations/[[...slug]]/page.tsx:12 const IntegrationsGuidePage = async (props: { params: Promise<Params> }) => { [SOURCE] apps/docs/app/guides/integrations/[[...slug]]/page.tsx:25 export default IntegrationsGuidePage [SOURCE] apps/docs/components/Navigation/NavigationMenu/NavigationMenu.constants.ts:1965 name: 'Bandwidth & Storage Egress', [SOURCE] apps/docs/components/Navigation/NavigationMenu/NavigationMenu.constants.ts:2637 name: 'Egress', [SOURCE] apps/docs/components/Navigation/NavigationMenu/NavigationMenu.constants.ts:2638 url: '/guides/platform/manage-your-usage/egress' as `/${string}`,

Finding

Does the system implement network segmentation to isolate the cardholder data environment (CDE) from other network segments, reducing the scope of PCI DSS compliance as described in Requirement 1?

Remediation

No changes are warranted within `.claude/skills/studio-testing/rules/testing-exhaustive-permutations.md`, `apps/docs/app/guides/functions/[[...slug]]/page.tsx`, or `apps/docs/app/guides/integrations/[[...slug]]/page.tsx`, as these files are part of internal tooling/documentation rendering and do not relate to network segmentation architecture, thus preventing misapplication of PCI DSS compliance requirements to irrelevant code.

PCIDSS-005 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The provided evidence consists solely of documentation files (.md) describing features of the `vitest` testing framework (e.g., test grouping, mocking, assertions), which offer no direct insight or support regarding the presence or absence of vulnerability management practices like patching, dependency updates, or vulnerability scanning as required by PCI DSS Requirement 6.

Evidence

[DOCS] .agents/skills/vitest/SKILL.md:30 | Describe API | describe/suite for grouping tests and nested suites | [core-describe](references/co [DOCS] .agents/skills/vitest/references/advanced-vi.md:234 // Partial mock typing [DOCS] .agents/skills/vitest/references/core-describe.md:3 description: describe/suite for grouping tests into logical blocks [DOCS] .agents/skills/vitest/references/core-expect.md:214 - `toThrow` requires wrapping sync code in a function [DOCS] .agents/skills/vitest/references/features-filtering.md:203 - Tags provide semantic test grouping [DOCS] .claude/skills/e2e-studio-tests/SKILL.md:110 // Could consider scoping down the container or filtering the combobox more specifically [DOCS] .claude/skills/studio-error-handling/SKILL.md:26 | `ErrorMatcher.tsx` | Component — reads `errorType`, looks up mapping, renders [DOCS] .claude/skills/studio-error-handling/SKILL.md:27 | `error-mappings.tsx` | `Record<KnownErrorType, { id, Troubleshooting: ComponentTy

Finding

Does the system demonstrate evidence of vulnerability management practices including regular patching, dependency updates, and vulnerability scanning, consistent with PCI DSS Requirement 6?

Remediation

To demonstrate adherence to PCI DSS Requirement 6 for vulnerability management, update `.agents/skills/vitest/SKILL.md` and its associated reference documentation (e.g., `advanced-vi.md`, `core-describe.md`) to explicitly detail how security testing, such as integrated vulnerability scanning or security-specific test cases, is incorporated into the described test workflows. A lack of clear documentation on security testing within established development practices can hinder compliance efforts for maintaining secure systems.

PCIDSS-006 · Possible False Positive

Medium Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of documentation files (.md) related to developer testing tools (Vitest and lint-staged). These files do not directly demonstrate the absence or presence of comprehensive security testing controls, such as SAST, DAST, formal code reviews, or penetration testing practices, as required by PCI DSS Requirements 6.3 and 11.4.

Evidence

[DOCS] .agents/skills/vitest/references/core-cli.md:39 Run tests that import specific files (useful with lint-staged): [DOCS] .agents/skills/vitest/references/core-cli.md:159 - Use `--run` flag to ensure single run (important for lint-staged) [DOCS] .agents/skills/vitest/references/core-describe.md:119 ## Parameterized Suites [DOCS] .agents/skills/vitest/references/core-test-api.md:122 ## Parameterized Tests [DOCS] .agents/skills/vitest/references/features-filtering.md:59 Useful with lint-staged: [DOCS] .agents/skills/vitest/references/features-filtering.md:62 // .lintstagedrc.js [DOCS] .agents/skills/vitest/references/features-snapshots.md:158 escapeString: false, [DOCS] .claude/skills/studio-testing/rules/testing-component-tests-ui-only.md:64 test('closes on Escape key', async () => {

Finding

Does the system implement security testing controls including code review, static analysis, and penetration testing practices, as required under PCI DSS Requirement 6.3 and 11.4?

Remediation

To meet PCI DSS Requirements 6.3 and 11.4, integrate automated static application security testing (SAST) tools and formal security code review requirements into the CI/CD pipeline, ensuring these security practices complement existing development testing processes referenced in documentation like `.agents/skills/vitest/references/core-cli.md`.

PCIDSS-007 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited consists solely of a `.gitignore` file (config) with a comment referencing log documentation and several unrelated documentation files (`.mdx`) discussing chart component properties, none of which directly demonstrate a failure in audit logging for cardholder data access.

Evidence

[CONFIG] .gitignore:141 # For self-hosted logs: https://github.com/supabase/supabase/blob/86e3ab20abfdb9c3e666334d3d2f8efeef [DOCS] apps/design-system/content/docs/components/chart.mdx:431 Use `labelKey` and `nameKey` to use a custom key for the tooltip label and name. [DOCS] apps/design-system/content/docs/components/chart.mdx:449 | `labelKey` | string | The config or data key to use for the label. | [DOCS] apps/design-system/content/docs/components/chart.mdx:461 To use a custom key for tooltip label and names, use the `labelKey` and `nameKey` props. [DOCS] apps/design-system/content/docs/components/chart.mdx:485 <ChartTooltip content={<ChartTooltipContent labelKey="visitors" nameKey="browser" />} /> [SOURCE] apps/design-system/registry/default/example/chart-tooltip-demo.tsx:134 labelKey?: string [SOURCE] apps/docs/app/api/graphql/route.test.ts:3 vi.mock('~/lib/logger', async () => { [SOURCE] apps/docs/app/api/graphql/route.test.ts:4 const actual = await vi.importActual<typeof import('~/lib/logger')>('~/lib/logger')

Finding

Does the system implement audit trail mechanisms that record all individual access to cardholder data, all actions taken by any individual with root or administrative privileges, and all access to audit trails, as required under PCI DSS Requirement 10?

Remediation

Review the comprehensive logging mechanisms detailed in `supabase/supabase/blob/86e3ab20abfdb9c3e666334d3d2f8efeef/docs/guides/platform/logs.mdx` (as indicated by the comment in `.gitignore:141`) to confirm that all individual access to cardholder data and administrative actions are robustly audited with user identification, timestamps, and relevant data elements, to prevent non-compliance with PCI DSS Requirement 10.

PCIDSS-009 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of documentation files related to a testing framework (vitest), which do not directly indicate the presence or management of third-party service providers with access to cardholder data as required by PCI DSS Requirement 12.8.

Evidence

[DOCS] .agents/skills/vitest/SKILL.md:40 | Coverage | Code coverage with V8 or Istanbul providers | [features-coverage](references/features-c [DOCS] .agents/skills/vitest/SKILL.md:27 | Configuration | Vitest and Vite config integration, defineConfig usage | [core-config](references/ [DOCS] .agents/skills/vitest/references/advanced-environments.md:210 provider: 'playwright', [DOCS] .agents/skills/vitest/references/advanced-projects.md:119 provider: 'playwright', [DOCS] .agents/skills/vitest/references/advanced-projects.md:30 name: 'integration', [DOCS] .agents/skills/vitest/references/advanced-projects.md:31 include: ['tests/integration/**/*.test.ts'], [DOCS] .agents/skills/vitest/references/advanced-projects.md:190 vitest --project integration [DOCS] .agents/skills/vitest/references/advanced-vi.md:148 vi.stubEnv('API_KEY', 'test')

Finding

Does the system manage third-party service providers that have access to cardholder data with appropriate controls, agreements, and monitoring, consistent with PCI DSS Requirement 12.8?

Remediation

Review the documentation files such as `.agents/skills/vitest/SKILL.md` and those referenced, to confirm they contain no actual information pertaining to the management or engagement of third-party service providers accessing cardholder data, thereby ensuring accurate assessment against PCI DSS Requirement 12.8.

PCIDSS-010 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence consists solely of documentation files detailing UI alerts and does not directly prove or disprove the existence or adequacy of a comprehensive incident response plan for cardholder data breaches, as required by PCI DSS Requirement 12.10.

Evidence

[DOCS] .cursor/rules/studio-useStaticEffectEvent.mdc:23 showNotification('Connected!', theme) // `theme` causes unwanted re-runs [DOCS] .cursor/rules/studio/RULE.md:32 - `studio/alerts` [DOCS] .cursor/rules/studio/alerts/RULE.md:2 description: "Studio: alert/admonition usage and placement" [DOCS] .cursor/rules/studio/alerts/RULE.md:8 # Studio alerts [DOCS] .cursor/rules/studio/best-practices/RULE.md:154 return <AlertError error={error} subject="Failed to load data" /> [DOCS] .cursor/rules/testing/e2e-studio/RULE.md:303 // ✅ Good - don't fail if API doesn't respond [DOCS] .github/instructions/studio-telemetry.instructions.md:15 3. **Feature-flagged rollouts without outcome tracking.** If a flag gates new behavior, there should [CONFIG] .github/workflows/dashboard-pr-reminder.yml:44 run: pnpm tsx scripts/actions/find-stale-dashboard-prs.ts | pnpm tsx scripts/actions/send-slack-pr-n

Finding

Does the system implement an incident response plan that addresses suspected or confirmed cardholder data breaches, including detection, containment, and notification procedures, as required under PCI DSS Requirement 12.10?

Remediation

The documentation files (e.g., `.cursor/rules/studio-useStaticEffectEvent.mdc`) describe alert usage and placement, but do not inherently constitute a lack of an incident response plan; therefore, no direct modification to these specific files is indicated to meet PCI DSS Requirement 12.10, which could otherwise lead to regulatory non-compliance.

SOC2

AICPA · Loss of enterprise contracts

10 findings · 9 possible FP

SOC2-009

Medium Risk›

Regulatory Standard

Gemini Verification

CONFIRMED

The application source code, specifically `apps/design-system/__registry__/index.tsx`, includes an `input-otp` component, which indicates support for Multi-Factor Authentication (MFA) functionality, aligning with the 'support' aspect of the SOC2 CC6.1 requirement, despite the inclusion of irrelevant documentation evidence.

Gemini 2.5 Flash · Confidence: HIGH

Evidence

[DOCS] .agents/skills/vitest/references/features-snapshots.md:187 resolveSnapshotPath: (testPath, snapExtension) => { [DOCS] .agents/skills/vitest/references/features-snapshots.md:187 resolveSnapshotPath: (testPath, snapExtension) => { [SOURCE] apps/design-system/__registry__/index.tsx:965 "input-otp-demo": { [SOURCE] apps/design-system/__registry__/index.tsx:966 name: "input-otp-demo", [SOURCE] apps/design-system/__registry__/index.tsx:968 registryDependencies: ["input-otp"], [SOURCE] apps/design-system/__registry__/index.tsx:969 component: React.lazy(() => import("@/registry/default/example/input-otp-demo")), [SOURCE] apps/design-system/__registry__/index.tsx:971 files: ["registry/default/example/input-otp-demo.tsx"], [SOURCE] apps/design-system/__registry__/index.tsx:976 "input-otp-pattern": {

Finding

Does the system implement or support multi-factor authentication for user access, particularly for privileged accounts and administrative interfaces, consistent with CC6.1 requirements for logical access security?

Remediation

Remediation refined by Gemini review

Possible False Positives (9)Gemini flagged these as likely pattern matches in non-source-code files. Review before acting.

›

SOC2-001 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The primary analysis identified a high-risk SOC2 question regarding user authentication controls but only provided evidence from documentation files (.md), which do not confirm the presence or absence of actual security controls in application source code or configuration.

Evidence

[DOCS] .agents/skills/vitest/references/core-describe.md:40 test('shows login page', () => {}) [DOCS] .agents/skills/vitest/references/features-filtering.md:30 vitest -t "login" [DOCS] .agents/skills/vitest/references/features-filtering.md:183 vitest user -t "login" --changed [DOCS] .claude/skills/vercel-composition-patterns/SKILL.md:6 designing reusable APIs. Triggers on tasks involving compound components, [DOCS] .claude/skills/vercel-composition-patterns/SKILL.md:28 - Designing flexible component APIs [DOCS] .cursor/rules/docs/docs-embeddings-generation/RULE.md:47 - Uses GitHub App authentication for access [DOCS] .cursor/rules/docs/docs-embeddings-generation/RULE.md:68 - **`page_section`** table: Stores individual sections with embeddings, token counts [DOCS] .cursor/rules/studio/styling/RULE.md:2 description: "Studio: styling rules (Tailwind + semantic tokens + typography/focus utilities)"

Finding

Does the system implement logical access security controls over user authentication that are suitably designed and operating effectively to restrict access to authorized users, consistent with the Common Criteria CC6.1 requirement for logical and physical access controls?

Remediation

Review the API design patterns described in `.claude/skills/vercel-composition-patterns/SKILL.md` to ensure they explicitly incorporate robust authentication controls and verify that the tests referenced in `.agents/skills/vitest/references/core-describe.md` and `features-filtering.md` include comprehensive checks for secure login/logout functions and session management to mitigate SOC2 non-compliance.

SOC2-002 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence exclusively cites documentation files (.md) for the Vitest testing framework, discussing technical scoping within test environments and hooks, which is unrelated to user role-based access control for application functions and data as required by SOC2 CC6.3.

Evidence

[DOCS] .agents/skills/vitest/references/advanced-environments.md:229 classNameStrategy: 'non-scoped', [DOCS] .agents/skills/vitest/references/core-describe.md:186 - Hooks are scoped to their suite and nested suites [DOCS] .agents/skills/vitest/references/core-hooks.md:56 ## Scoped Hooks [DOCS] .agents/skills/vitest/references/features-context.md:101 ## Scoped Fixtures [DOCS] .agents/skills/vitest/references/features-context.md:103 ### File Scope [DOCS] .agents/skills/vitest/references/features-context.md:115 { scope: 'file' } [DOCS] .agents/skills/vitest/references/features-context.md:120 ### Worker Scope [DOCS] .agents/skills/vitest/references/features-context.md:130 { scope: 'worker' }

Finding

Does the system implement role-based or attribute-based access controls that restrict system functions and data access based on authorized user roles, consistent with the principle of least privilege as required under CC6.3?

Remediation

The provided evidence in files like `.agents/skills/vitest/references/advanced-environments.md` discusses internal scoping within the Vitest testing framework, not application-level RBAC. Therefore, no specific change is needed in these documentation files to address SOC2 CC6.3 requirements for access control.

SOC2-003 · Possible False Positive

Pattern of Concern›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence consists solely of documentation files (.md) within an internal agents directory, not core application code or production configuration. Crucially, the cited `apiUrl` examples explicitly demonstrate the use of `https://`, which indicates encryption in transit rather than a lack thereof, suggesting a misinterpretation of the evidence by the primary analysis.

Evidence

Finding

Does the system protect data during transmission over networks using encryption or other equivalent security measures, consistent with the CC6.7 requirement for protection of information during transmission?

Remediation

Update the documentation within `.agents/skills/vitest/references/advanced-projects.md` and related skill documentation to explicitly state the policy of mandating HTTPS for all API communications, clarifying expectations for encryption in transit to meet SOC2 CC6.7 control requirements.

SOC2-004 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited consists solely of documentation files pertaining to testing frameworks (Vitest assertions and Playwright test traces), which are unrelated to the implementation of production security logging, monitoring, and alerting mechanisms for compliance.

Evidence

[DOCS] .agents/skills/vitest/SKILL.md:31 | Expect API | Assertions with toBe, toEqual, matchers and asymmetric matchers | [core-expect](refer [DOCS] .agents/skills/vitest/references/core-expect.md:3 description: Assertions with matchers, asymmetric matchers, and custom matchers [DOCS] .agents/skills/vitest/references/core-expect.md:103 ## Asymmetric Matchers [DOCS] .claude/skills/e2e-studio-tests/SKILL.md:180 ### View trace [DOCS] .claude/skills/e2e-studio-tests/SKILL.md:183 cd e2e/studio && pnpm exec playwright show-trace <path-to-trace.zip> [DOCS] .cursor/rules/studio-useStaticEffectEvent.mdc:23 showNotification('Connected!', theme) // `theme` causes unwanted re-runs [DOCS] .cursor/rules/studio/RULE.md:32 - `studio/alerts` [DOCS] .cursor/rules/studio/alerts/RULE.md:2 description: "Studio: alert/admonition usage and placement"

Finding

Does the system implement logging, monitoring, and alerting mechanisms that detect and record security events, anomalies, and unauthorized activities, as required under CC7.2 for monitoring system components for anomalies?

Remediation

The documentation files, such as `.agents/skills/vitest/SKILL.md` and `.claude/skills/e2e-studio-tests/SKILL.md`, should be updated to clearly reference or describe the comprehensive security logging and monitoring infrastructure, including detection of security events and anomalies, to adequately demonstrate compliance with SOC2 CC7.2.

SOC2-005 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited consists solely of documentation files (.md), which describe system components but do not directly prove or disprove the existence and effectiveness of actual change management controls (version control, code review, deployment procedures) as required by SOC2 CC8.1.

Evidence

[DOCS] .agents/skills/vitest/SKILL.md:6 version: "2026.1.28" [DOCS] .agents/skills/vitest/SKILL.md:13 - Vite-native: Uses Vite's transformation pipeline for fast HMR-like test updates [DOCS] .agents/skills/vitest/references/advanced-environments.md:23 // Environment-specific options [DOCS] .agents/skills/vitest/references/advanced-environments.md:236 ## Fixing External Dependencies [DOCS] .agents/skills/vitest/references/advanced-projects.md:162 ## Project-Specific Dependencies [DOCS] .agents/skills/vitest/references/advanced-projects.md:164 Each project can have different dependencies inlined: [DOCS] .agents/skills/vitest/references/advanced-projects.md:185 ## Running Specific Projects [DOCS] .agents/skills/vitest/references/advanced-projects.md:188 # Run specific project

Finding

Does the system demonstrate evidence of change management controls including version control, code review processes, and controlled deployment procedures, as required under CC8.1 for managing changes to infrastructure, data, software, and procedures?

Remediation

To adequately demonstrate change management controls for SOC2 CC8.1, update .agents/skills/vitest/SKILL.md and related reference documents to explicitly detail the established version control system, mandatory code review processes, and controlled deployment procedures, ensuring clear evidence of compliance.

SOC2-006 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of documentation files (.md) related to testing methodology, specifically 'Logic Extraction (CRITICAL)' and 'Test Coverage (CRITICAL)' for 'critical shared features', which does not directly demonstrate the presence or absence of incident detection, response, and recovery procedures as required by SOC2 CC7.3 and CC7.4.

Evidence

[DOCS] .claude/skills/studio-testing/SKILL.md:30 | 1 | Logic Extraction | CRITICAL | `testing-` | [DOCS] .claude/skills/studio-testing/SKILL.md:31 | 2 | Test Coverage | CRITICAL | `testing-` | [DOCS] .claude/skills/studio-testing/SKILL.md:37 ### 1. Logic Extraction (CRITICAL) [DOCS] .claude/skills/studio-testing/SKILL.md:42 ### 2. Test Coverage (CRITICAL) [DOCS] .claude/skills/studio-testing/rules/testing-e2e-shared-features.md:4 impactDescription: ensures critical shared features work across deployment targets [DOCS] .claude/skills/studio-testing/rules/testing-exhaustive-permutations.md:3 impact: CRITICAL [DOCS] .claude/skills/studio-testing/rules/testing-extract-logic.md:3 impact: CRITICAL [DOCS] .claude/skills/vercel-composition-patterns/AGENTS.md:47 **Impact: CRITICAL (prevents unmaintainable component variants)**

Finding

Does the system implement incident detection, response, and recovery procedures that enable timely identification and remediation of security incidents, consistent with CC7.3 requirements for evaluating security events and CC7.4 for responding to identified incidents?

Remediation

In `.claude/skills/studio-testing/SKILL.md` and `rules/testing-e2e-shared-features.md`, ensure a dedicated section or clear references are added that explicitly link the testing of 'critical shared features' to the organization's incident response and recovery procedures, detailing how failures in these critical areas are handled as security incidents to satisfy SOC2 CC7.3 and CC7.4 requirements.

SOC2-007 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited exclusively consists of documentation files about a testing framework, not application source code, configuration files, or direct evidence of a failure in dependency vulnerability management practices.

Evidence

[DOCS] .agents/skills/vitest/SKILL.md:30 | Describe API | describe/suite for grouping tests and nested suites | [core-describe](references/co [DOCS] .agents/skills/vitest/references/advanced-vi.md:234 // Partial mock typing [DOCS] .agents/skills/vitest/references/core-cli.md:115 ## Package.json Scripts [DOCS] .agents/skills/vitest/references/core-describe.md:3 description: describe/suite for grouping tests into logical blocks [DOCS] .agents/skills/vitest/references/core-describe.md:3 description: describe/suite for grouping tests into logical blocks [DOCS] .agents/skills/vitest/references/core-expect.md:214 - `toThrow` requires wrapping sync code in a function [DOCS] .agents/skills/vitest/references/features-coverage.md:146 ## Package.json Scripts [DOCS] .agents/skills/vitest/references/features-filtering.md:203 - Tags provide semantic test grouping

Finding

Does the system assess and manage risks associated with third-party vendors, libraries, and service providers, including dependency vulnerability management, consistent with CC9.2 requirements for risk assessment of third-party service providers?

Remediation

Update the `.agents/skills/vitest/SKILL.md` file to explicitly document the process for assessing and managing vulnerabilities and risks associated with the `vitest` dependency itself, to satisfy SOC2 CC9.2 requirements for third-party risk assessment.

SOC2-008 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited exclusively refers to documentation for 'Vitest' snapshot testing, which is a development and quality assurance practice to ensure UI or data consistency, and not a mechanism for production data backup, replication, or recovery as required by SOC2-008.

Evidence

[DOCS] .agents/skills/vitest/GENERATION.md:4 - **Git SHA:** `4a7321e10672f00f0bb698823a381c2cc245b8f7` [DOCS] .agents/skills/vitest/SKILL.md:19 - Snapshot testing, mocking, and spy utilities [DOCS] .agents/skills/vitest/SKILL.md:39 | Snapshots | Snapshot testing with toMatchSnapshot and inline snapshots | [features-snapshots](refe [DOCS] .agents/skills/vitest/SKILL.md:10 Vitest is a next-generation testing framework powered by Vite. It provides a Jest-compatible API wit [DOCS] .agents/skills/vitest/SKILL.md:42 | Concurrency | Concurrent tests, parallel execution, sharding | [features-concurrency](references/f [DOCS] .agents/skills/vitest/SKILL.md:50 | Environments | Test environments: node, jsdom, happy-dom, custom | [advanced-environments](referen [DOCS] .agents/skills/vitest/references/advanced-environments.md:146 export default <Environment>{ [DOCS] .agents/skills/vitest/references/advanced-environments.md:178 export default <Environment>{

Finding

Does the system implement data backup, replication, and recovery controls that ensure availability and recoverability of data, consistent with the A1.2 criterion for recovery of infrastructure and data to meet objectives?

Remediation

The files `.agents/skills/vitest/GENERATION.md` and `.agents/skills/vitest/SKILL.md` detail snapshot testing capabilities of a development framework, which are distinct from production data backup and recovery controls. No specific changes are required within these documentation files to address SOC2-008 data backup compliance, as they are not relevant to the operational criteria.

SOC2-010 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided (CONTRIBUTING.md, PR templates, and configuration files) pertains to external project contributions and development workflow, not internal security policies on acceptable use, data classification, or access management as required for SOC2 CC1.1.

Evidence

[DOCS] .github/pull_request_template.md:1 ## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.m [CONFIG] .github/workflows/external-pr-comment.yml:20 Thanks for contributing to Supabase! ❤️ Our team will review your PR. [CONFIG] .prettierignore:18 apps/docs/CONTRIBUTING.md [DOCS] CONTRIBUTING.md:1 # CONTRIBUTING.md [DOCS] CONTRIBUTING.md:3 Thank you for contributing to Supabase! We’re a big, exciting open source project and we’d love to h [DOCS] CONTRIBUTING.md:11 To ensure a positive and inclusive environment, please read our [code of conduct](https://github.com [DOCS] CONTRIBUTING.md:11 To ensure a positive and inclusive environment, please read our [code of conduct](https://github.com [DOCS] DEVELOPERS.md:31 To ensure a positive and inclusive environment, please read our [code of conduct](https://github.com

Finding

Does the system demonstrate evidence of documented security policies, including acceptable use, data classification, and access management policies, as required under CC1.1 for the entity's commitment to integrity and ethical values?

Remediation

The existing `CONTRIBUTING.md` and `.github/pull_request_template.md` provide external contribution guidelines but do not contain or refer to formal internal security policies for acceptable use, data classification, or access management. To meet SOC2 CC1.1, the organization should establish and document these specific security policies in a dedicated, accessible location, as their absence could lead to control deficiencies.

SOX

SEC / PCAOB · Criminal penalties, delisting

8 findings · 8 possible FP

Possible False Positives (8)Gemini flagged these as likely pattern matches in non-source-code files. Review before acting.

›

SOX-001 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited exclusively comprises documentation (.md) files, discussing general data integrity concepts, testing practices, and internal tool rules, rather than direct application source code handling financial data or demonstrating a failure in SOX-relevant controls.

Evidence

[DOCS] .agents/skills/vitest/references/core-hooks.md:89 // Wrap each test in database transaction [DOCS] .agents/skills/vitest/references/core-hooks.md:91 await db.beginTransaction() [DOCS] .claude/skills/studio-testing/rules/testing-component-tests-ui-only.md:21 validation that happens to live inside a component. Extract that logic into a [DOCS] .claude/skills/telemetry-standards/SKILL.md:134 connectionMethod: 'transaction_pooler', [DOCS] .cursor/rules/docs/docs-embeddings-generation/RULE.md:15 2. **Processing content** into structured sections with checksums [DOCS] .cursor/rules/docs/docs-embeddings-generation/RULE.md:57 - Checksum for change detection [DOCS] .cursor/rules/docs/docs-embeddings-generation/RULE.md:60 3. **Change Detection**: Compares checksums against existing database records [DOCS] .cursor/rules/docs/docs-embeddings-generation/RULE.md:67 - **`page`** table: Stores page metadata, content, checksum, version

Finding

Does the system implement controls to ensure the integrity, accuracy, and completeness of financial data and transactions, consistent with SOX Section 302 requirements for management certification of financial statements?

Remediation

No direct changes are required in the referenced documentation files (.agents/skills/vitest/references/core-hooks.md, .claude/skills/studio-testing/rules/testing-component-tests-ui-only.md, etc.) as they discuss general data integrity practices and testing, not a failure of SOX-relevant financial data controls within application source code, thus mitigating the perceived SOX Section 302 risk.

SOX-002 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited is exclusively from a documentation file (.md) describing a test setup for creating an admin user, which does not directly demonstrate a lack of access controls in a production financial system.

Evidence

[DOCS] .agents/skills/vitest/references/features-context.md:215 // admin-test.ts [DOCS] .agents/skills/vitest/references/features-context.md:218 export const test = dbTest.extend<{ admin: User }>({ [DOCS] .agents/skills/vitest/references/features-context.md:219 admin: async ({ db }, use) => { [DOCS] .agents/skills/vitest/references/features-context.md:220 const admin = await db.createAdmin() [DOCS] .agents/skills/vitest/references/features-context.md:221 await use(admin) [DOCS] .claude/skills/e2e-studio-tests/SKILL.md:72 1. **`getByRole` with accessible name** - Most robust, tests accessibility [DOCS] .claude/skills/e2e-studio-tests/SKILL.md:74 page.getByRole('button', { name: 'Save' }) [DOCS] .claude/skills/e2e-studio-tests/SKILL.md:75 page.getByRole('button', { name: 'Configure API privileges' })

Finding

Does the system implement access controls that restrict access to financial systems and data to authorized personnel, with appropriate authentication and authorization mechanisms, as required under SOX Section 404 internal controls?

Remediation

To prevent any potential misinterpretation, update `.agents/skills/vitest/references/features-context.md` to explicitly confirm that the `db.createAdmin()` functionality described is strictly confined to isolated test environments and cannot impact production financial system access controls. Lacking such clarity could be misinterpreted as a control weakness, potentially violating SOX Section 404 requirements for internal controls over financial reporting.

SOX-003 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited exclusively refers to documentation for `vitest` mocking functions (`fn.mockClear()`, `fn.mockReset()`, `vi.clearAllMocks()`), which are used to manage test doubles and their call history within a testing framework, not to clear production operational logs or financial audit trails.

Evidence

[DOCS] .agents/skills/vitest/references/advanced-vi.md:33 fn.mockClear() // Clear call history [DOCS] .agents/skills/vitest/references/advanced-vi.md:34 fn.mockReset() // Clear history + implementation [DOCS] .agents/skills/vitest/references/advanced-vi.md:215 vi.clearAllMocks() // Clear all mock call history [DOCS] .agents/skills/vitest/references/features-mocking.md:211 fn.mockClear() // Clear call history [DOCS] .agents/skills/vitest/references/features-mocking.md:212 fn.mockReset() // Clear history + implementation [DOCS] .claude/skills/studio-testing/rules/testing-exhaustive-permutations.md:18 - Edge cases (timestamps with colons, special characters, boundary values) [DOCS] .claude/skills/studio-testing/rules/testing-exhaustive-permutations.md:41 test('handles timestamp with colons in value', () => { [DOCS] .claude/skills/studio-testing/rules/testing-exhaustive-permutations.md:79 test('detects timestamp', () => { ... }) // multiple formats -> timestamptz

Finding

Does the system maintain a complete and tamper-evident audit trail of all financial transactions, modifications, and access events, sufficient to support the audit requirements under SOX Section 802?

Remediation

The documentation for `vitest` mocking functions (`fn.mockClear`, `fn.mockReset`, `vi.clearAllMocks`) describes test utilities and does not indicate a risk to SOX Section 802 audit trails. No changes are required to these documentation files for compliance with SOX-003, as they do not impact production audit log immutability.

SOX-004 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence consists solely of documentation files related to a testing framework, which does not directly demonstrate a failure in SOX change management controls for financial software.

Evidence

Finding

Does the system implement change management controls for software that processes financial data, including version control, code review, testing, and controlled deployment, consistent with SOX IT general controls?

Remediation

Clarify in `.agents/skills/vitest/SKILL.md` and related documentation, particularly concerning 'version' and 'advanced-environments.md', how the change management for testing environments and their dependencies is formally integrated into the SOX-compliant process. This integration prevents unauthorized modifications that could compromise financial reporting integrity.

SOX-005 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited refers to documentation for a testing framework's coverage thresholds and concurrency limits, which does not directly pertain to Segregation of Duties controls for financial transactions or system deployments under SOX.

Evidence

[DOCS] .agents/skills/vitest/references/features-concurrency.md:73 Limit concurrent tests: [DOCS] .agents/skills/vitest/references/features-coverage.md:45 // Thresholds [DOCS] .agents/skills/vitest/references/features-coverage.md:46 thresholds: { [DOCS] .agents/skills/vitest/references/features-coverage.md:95 ## Thresholds [DOCS] .agents/skills/vitest/references/features-coverage.md:97 Fail tests if coverage is below threshold: [DOCS] .agents/skills/vitest/references/features-coverage.md:101 thresholds: { [DOCS] .agents/skills/vitest/references/features-coverage.md:102 // Global thresholds [DOCS] .agents/skills/vitest/references/features-coverage.md:108 // Per-file thresholds

Finding

Does the system implement segregation of duties controls that prevent any single individual from having the ability to both authorize and execute financial transactions, or to both develop and deploy changes to financial systems?

Remediation

The provided documentation files (.agents/skills/vitest/references/features-concurrency.md and features-coverage.md) discussing test thresholds and limits do not indicate a deficiency in Segregation of Duties controls, therefore specific changes to these files are not required to address SOX-005.

SOX-006 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of documentation files containing code coverage ignore comments, which are entirely unrelated to data retention policies or SOX financial recordkeeping requirements.

Evidence

[DOCS] .agents/skills/vitest/references/features-coverage.md:122 /* v8 ignore next -- @preserve */ [DOCS] .agents/skills/vitest/references/features-coverage.md:127 /* v8 ignore start -- @preserve */ [DOCS] .agents/skills/vitest/references/features-coverage.md:129 /* v8 ignore stop -- @preserve */ [DOCS] .agents/skills/vitest/references/features-coverage.md:135 /* istanbul ignore next -- @preserve */ [DOCS] .agents/skills/vitest/references/features-coverage.md:138 /* istanbul ignore if -- @preserve */ [DOCS] .agents/skills/vitest/references/features-coverage.md:144 Note: `@preserve` keeps comments through esbuild. [DOCS] .agents/skills/vitest/references/features-coverage.md:202 - Use `@preserve` comment to keep ignore hints [DOCS] .claude/skills/studio-error-handling/SKILL.md:46 - Do not pass `error.message` to `ErrorMatcher` — pass the full `error` object so the class is prese

Finding

Does the system implement data retention policies that preserve financial records, audit work papers, and supporting documentation for the minimum retention period required under SOX Section 802 (not less than 7 years)?

Remediation

The cited evidence in `.agents/skills/vitest/references/features-coverage.md` consists of code coverage directives, not financial records or retention policies, thus no specific changes are required within this file to address SOX-006. Actual data retention policies for financial records, audit work papers, and supporting documentation must be implemented in relevant application or database configurations to prevent severe fines and legal action under SOX Section 802.

SOX-007 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence consists solely of technical documentation files (.md) describing software testing frameworks (Vitest, E2E tests), which are not typically where formal SOX-mandated internal control documentation over financial reporting would reside. The analysis appears to misinterpret technical 'controls' in testing as financial reporting controls.

Evidence

[DOCS] .agents/skills/vitest/SKILL.md:3 description: Vitest fast unit testing framework powered by Vite with Jest-compatible API. Use when w [DOCS] .agents/skills/vitest/SKILL.md:10 Vitest is a next-generation testing framework powered by Vite. It provides a Jest-compatible API wit [DOCS] .agents/skills/vitest/references/features-concurrency.md:141 Control test order: [DOCS] .agents/skills/vitest/references/features-snapshots.md:196 - Commit snapshot files to version control [DOCS] .claude/skills/e2e-studio-tests/SKILL.md:224 The test framework automatically resets the database when running `pnpm run e2e`. This matches CI be [DOCS] .claude/skills/telemetry-standards/SKILL.md:4 PRs for telemetry compliance or implementing new event tracking. Covers event naming, [DOCS] .cursor/rules/docs/docs-embeddings-generation/RULE.md:8 # Documentation Embeddings Generation System [DOCS] .cursor/rules/docs/docs-embeddings-generation/RULE.md:12 The documentation embeddings generation system processes various documentation sources and uploads t

Finding

Does the system provide evidence of documented internal controls over financial reporting, including control objectives, control activities, and monitoring procedures, as required under SOX Section 404(a)?

Remediation

Review .agents/skills/vitest/SKILL.md, .agents/skills/vitest/references/features-concurrency.md, .agents/skills/vitest/references/features-snapshots.md, and .claude/skills/e2e-studio-tests/SKILL.md to ensure the terminology clearly distinguishes software testing procedures from formal internal controls over financial reporting. This clarification is essential to prevent misinterpretation of SOX Section 404(a) documentation requirements.

SOX-008 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited (documentation describing checksums for content generation and a GitHub workflow configuration) does not pertain to financial records or core application logic, thus it does not directly support a high-risk SOX anti-tampering control finding related to financial data.

Evidence

[DOCS] .cursor/rules/docs/docs-embeddings-generation/RULE.md:15 2. **Processing content** into structured sections with checksums [DOCS] .cursor/rules/docs/docs-embeddings-generation/RULE.md:57 - Checksum for change detection [DOCS] .cursor/rules/docs/docs-embeddings-generation/RULE.md:60 3. **Change Detection**: Compares checksums against existing database records [DOCS] .cursor/rules/docs/docs-embeddings-generation/RULE.md:67 - **`page`** table: Stores page metadata, content, checksum, version [CONFIG] .github/workflows/studio-e2e-test.yml:77 key: ${{ runner.os }}-nextjs-${{ hashFiles('pnpm-lock.yaml') }}-${{ hashFiles('apps/studio/**/*.js', [CONFIG] .github/workflows/studio-e2e-test.yml:80 ${{ runner.os }}-nextjs-${{ hashFiles('pnpm-lock.yaml') }}- [CONFIG] .gitignore:81 # Yarn Integrity file [CONFIG] .gitignore:82 .yarn-integrity

Finding

Does the system implement controls to prevent unauthorized alteration or destruction of financial records, including integrity verification, immutable storage, and tamper detection mechanisms, consistent with SOX Section 802 anti-destruction requirements?

Remediation

The evidence in `.cursor/rules/docs/docs-embeddings-generation/RULE.md` describes checksums for documentation processing, not financial records, therefore no specific change is needed in this file for SOX-008 compliance. The identified checksums do not relate to preventing unauthorized alteration of financial records under SOX Section 802.

TCPA

FCC · $500-$1,500 per violation

8 findings · 7 possible FP

TCPA-006

High Risk›

Regulatory Standard

Gemini Verification

CONFIRMED

The primary analysis correctly identifies a high-risk compliance gap for TCPA consent record-keeping, as no code evidence was found for this crucial requirement in a system operating in domains (e.g., communication, SaaS) where such consent is mandatory. The absence of an identifiable implementation for this control in relevant contexts constitutes a confirmed risk.

Gemini 2.5 Flash · Confidence: HIGH

Evidence

No matching code patterns found.

Finding

Does the system maintain records of consent that would be sufficient to demonstrate compliance in the event of a dispute, including the date, time, method of consent, and the specific consent language presented to the consumer?

Remediation

Remediation refined by Gemini review

Possible False Positives (7)Gemini flagged these as likely pattern matches in non-source-code files. Review before acting.

›

TCPA-001 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited from the LICENSE file refers to the terms of the software's licensing agreement, not the collection of user consent for SMS marketing messages within the application's user interface or backend logic as required by TCPA.

Evidence

[CONFIG] LICENSE:135 the terms of any separate license agreement you may have executed [CONFIG] LICENSE:144 agreed to in writing, Licensor provides the Work (and each [CONFIG] LICENSE:156 negligent acts) or agreed to in writing, shall any Contributor be [CONFIG] LICENSE:171 of any other Contributor, and only if You agree to indemnify, [CONFIG] LICENSE:197 Unless required by applicable law or agreed to in writing, software [SOURCE] apps/design-system/registry/default/example/checkbox-with-text.tsx:17 You agree to our Terms of Service and Privacy Policy. [DOCS] apps/docs/content/guides/auth/auth-web3.mdx:37 It defines the wallet address, timestamp, browser location where the sign-in occurred and includes a [DOCS] apps/docs/content/guides/auth/auth-web3.mdx:185 Providing a `statement` is required for most Solana wallets and this message will be shown to the us

Finding

Does the system obtain prior express written consent before sending marketing or promotional text messages, including a clear and conspicuous disclosure that consent is being sought, as required under 47 U.S.C. §227(b)(1) and 47 CFR §64.1200(a)(2)?

Remediation

No changes are needed to `LICENSE` lines 135, 144, 156, 171, and 197 as they pertain to software licensing terms and do not provide a mechanism for obtaining prior express written consent for SMS marketing communications under 47 U.S.C. §227(b)(1). Falsely interpreting these lines as consent for SMS could lead to TCPA violations if actual SMS marketing occurs without proper consent mechanisms.

TCPA-002 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited (Vitest documentation) refers to stopping test execution after failures, not to a mechanism for users to opt out of communications, which is the subject of TCPA compliance.

Evidence

[DOCS] .agents/skills/vitest/references/core-cli.md:94 --bail <n> # Stop after n failures [DOCS] .agents/skills/vitest/references/core-config.md:115 // Stop after first failure [DOCS] .agents/skills/vitest/references/features-concurrency.md:230 Stop after first failure: [DOCS] .agents/skills/vitest/references/features-concurrency.md:233 vitest --bail 1 # Stop after 1 failure [DOCS] .agents/skills/vitest/references/features-concurrency.md:234 vitest --bail # Stop on first failure (same as --bail 1) [DOCS] .agents/skills/vitest/references/features-coverage.md:129 /* v8 ignore stop -- @preserve */ [DOCS] .claude/skills/vercel-composition-patterns/AGENTS.md:132 <Composer.CancelEdit /> [DOCS] .claude/skills/vercel-composition-patterns/AGENTS.md:532 <CancelButton />

Finding

Does the system provide a clear and easy mechanism for recipients to opt out of receiving further messages, and does it honor opt-out requests promptly, as required under TCPA and CTIA guidelines?

Remediation

The entries in .agents/skills/vitest/references/core-cli.md, core-config.md, and features-concurrency.md refer to stopping test execution, not user communication opt-outs. No changes are required in these files to address TCPA-002 requirements, as they pose no compliance risk for opt-out mechanisms in user messaging.

TCPA-003 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited is a documentation file (`.md`) referencing UI component files (`.tsx`) related to charts within a design system, which bears no relation to initiating outbound calls, SMS messages, or checking phone numbers against a Do Not Call list as required by TCPA.

Evidence

[DOCS] .cursor/rules/studio/charts/RULE.md:14 - `apps/design-system/__registry__/default/block/chart-composed-demo.tsx` [DOCS] .cursor/rules/studio/charts/RULE.md:15 - `apps/design-system/__registry__/default/block/chart-composed-basic.tsx` [DOCS] .cursor/rules/studio/charts/RULE.md:16 - `apps/design-system/__registry__/default/block/chart-composed-states.tsx` [DOCS] .cursor/rules/studio/charts/RULE.md:17 - `apps/design-system/__registry__/default/block/chart-composed-metrics.tsx` [DOCS] .cursor/rules/studio/charts/RULE.md:18 - `apps/design-system/__registry__/default/block/chart-composed-actions.tsx` [DOCS] .cursor/rules/studio/charts/RULE.md:19 - `apps/design-system/__registry__/default/block/chart-composed-table.tsx` [DOCS] .cursor/rules/studio/empty-states/RULE.md:14 - `apps/design-system/registry/default/example/empty-state-presentational-icon.tsx` [DOCS] .cursor/rules/studio/empty-states/RULE.md:15 - `apps/design-system/registry/default/example/empty-state-initial-state-informational.tsx`

Finding

Does the system check phone numbers against the National Do Not Call Registry and maintain an internal do-not-call list before initiating outbound calls or messages, as required under 47 CFR §64.1200(c)?

Remediation

The referenced files, such as `.cursor/rules/studio/charts/RULE.md` and `apps/design-system/__registry__/default/block/chart-composed-demo.tsx`, pertain to UI design system charts and do not indicate outbound communication functionality. Therefore, no changes are required within these specific files to perform National Do Not Call Registry checks, as non-compliance with 47 CFR §64.1200(c) could otherwise lead to significant penalties.

TCPA-004 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of documentation (.md files) related to testing practices and UI component behavior, which contains no information or code relevant to TCPA message frequency disclosure, consent systems, or consumer messaging.

Evidence

[DOCS] .agents/skills/vitest/references/features-snapshots.md:8 Snapshot tests capture output and compare against stored references. [DOCS] .agents/skills/vitest/references/features-snapshots.md:158 escapeString: false, [DOCS] .claude/skills/studio-testing/rules/testing-component-tests-ui-only.md:11 logic that cannot be captured by testing utility functions alone. [DOCS] .claude/skills/studio-testing/rules/testing-component-tests-ui-only.md:64 test('closes on Escape key', async () => { [DOCS] .claude/skills/studio-testing/rules/testing-component-tests-ui-only.md:67 await userEvent.keyboard('{Escape}') [DOCS] .claude/skills/studio-testing/rules/testing-e2e-shared-features.md:15 - Mouse/click interactions AND keyboard shortcuts (Tab, Enter, Escape, Arrow keys) [DOCS] .claude/skills/studio-testing/rules/testing-e2e-shared-features.md:52 test('Escape clears highlight', async ({ page }) => { [DOCS] .claude/skills/studio-testing/rules/testing-e2e-shared-features.md:54 await getFilterBarInput(page).press('Escape')

Finding

Does the system disclose to consumers the expected frequency of messages before obtaining consent, and does it enforce frequency limits consistent with the disclosed rate, as recommended by CTIA guidelines?

Remediation

The documentation found in `.agents/skills/vitest/references/features-snapshots.md` and `.claude/skills/studio-testing/rules/testing-component-tests-ui-only.md` pertains to testing and UI functionality, not message frequency disclosure or consent. No specific changes are required within these documented testing practices to address TCPA-004 message frequency disclosure requirements, as their content is irrelevant to the regulation.

TCPA-005 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited, referring to TypeScript branded types and CSS styling variables for 'brand', is unrelated to TCPA requirements for sender identification in outbound messages.

Evidence

[DOCS] .agents/skills/vitest/references/advanced-type-testing.md:125 ## Branded Types [DOCS] .agents/skills/vitest/references/advanced-type-testing.md:128 type UserId = number & { __brand: 'UserId' } [DOCS] .agents/skills/vitest/references/advanced-type-testing.md:129 type PostId = number & { __brand: 'PostId' } [SOURCE] apps/design-system/__registry__/default/block/chart-composed-basic.tsx:51 color: 'hsl(var(--brand-default))', [SOURCE] apps/design-system/app/(app)/page.tsx:33 <div className="flex items-center justify-start min-h-[24px] gap-3 text-brand"> [SOURCE] apps/design-system/app/(app)/page.tsx:47 <div className="flex items-center justify-start min-h-[24px] text-brand"> [SOURCE] apps/design-system/components/copy-button.tsx:74 {hasCopied ? <Check className="h-3 w-3 text-brand-600" /> : <Copy className="h-3 w-3" />} [SOURCE] apps/design-system/components/mdx-components.tsx:88 'text-foreground underline decoration-1 decoration-foreground-muted underline-offset-4 transition-co

Finding

Does the system include proper sender identification in all outbound messages, including the identity of the entity sending the message and how to contact them, consistent with TCPA and CTIA requirements?

Remediation

The terms 'brand' identified in .agents/skills/vitest/references/advanced-type-testing.md and apps/design-system/app/(app)/page.tsx refer to internal TypeScript type branding for compiler safety and UI styling elements, respectively. These references do not indicate a lack of proper sender identification in outbound messages, therefore no specific remediation is required in these files to comply with TCPA-005.

TCPA-007 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The cited evidence from documentation files (.md) refers to test runner behavior ('stop after n failures' for Vitest's --bail option), which is entirely unrelated to handling consumer consent revocation under TCPA.

Evidence

[DOCS] .agents/skills/vitest/references/core-cli.md:94 --bail <n> # Stop after n failures [DOCS] .agents/skills/vitest/references/core-config.md:115 // Stop after first failure [DOCS] .agents/skills/vitest/references/features-concurrency.md:230 Stop after first failure: [DOCS] .agents/skills/vitest/references/features-concurrency.md:233 vitest --bail 1 # Stop after 1 failure [DOCS] .agents/skills/vitest/references/features-concurrency.md:234 vitest --bail # Stop on first failure (same as --bail 1) [DOCS] .agents/skills/vitest/references/features-coverage.md:129 /* v8 ignore stop -- @preserve */ [DOCS] .claude/skills/studio-testing/SKILL.md:39 - `testing-extract-logic` - Remove logic from components into `.utils.ts` files [DOCS] .claude/skills/studio-testing/rules/testing-extract-logic.md:10 Remove as much logic from components as possible. Put it in co-located

Finding

Does the system honor revocation of consent through any reasonable means indicated by the consumer, not limited to specific keywords, and process revocation within a reasonable timeframe, consistent with FCC guidance?

Remediation

Clarify that the phrases 'stop after n failures' within `.agents/skills/vitest/references/core-cli.md`, `.agents/skills/vitest/references/core-config.md`, and `.agents/skills/vitest/references/features-concurrency.md` pertain exclusively to test execution control and not to the processing of consumer consent revocations, thus mitigating false interpretations regarding TCPA compliance.

TCPA-008 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited, consisting of GitHub Actions workflow schedules, pertains to internal repository automation and does not indicate the sending of outbound calls or messages to external recipients, which is the focus of TCPA time-of-day restrictions.

Evidence

[CONFIG] .github/dependabot.yml:5 schedule: [CONFIG] .github/workflows/ai-tests.yml:12 schedule: [CONFIG] .github/workflows/dashboard-pr-reminder.yml:4 schedule: [CONFIG] .github/workflows/docs-last-changed.yml:4 schedule: [CONFIG] .github/workflows/docs-lint-v2-scheduled.yml:1 name: '[Docs] Lint v2 (scheduled)' [CONFIG] .github/workflows/docs-lint-v2-scheduled.yml:3 schedule: [CONFIG] .github/workflows/docs-mgmt-api-update.yml:4 schedule: [CONFIG] .github/workflows/docs-tests-smoke.yml:7 schedule:

Finding

Does the system enforce time-of-day restrictions for outbound calls and messages, ensuring they are not sent before 8:00 AM or after 9:00 PM in the recipient's local time zone, as required under 47 CFR §64.1200(c)(1)?

Remediation

The `.github/dependabot.yml` and `.github/workflows/*.yml` files control internal CI/CD schedules and are not associated with sending outbound calls or messages to external recipients; therefore, no changes are needed in these specific files to comply with TCPA time-of-day restrictions under 47 CFR §64.1200(c)(1).

What This Analysis Covers

OpenDocket scans source code patterns — specifically whether code handles regulated data in compliance-aware ways. It searches for evidence of encryption, access controls, consent mechanisms, audit logging, and other patterns that regulators look for.

What It Does Not Cover

Only public repository content is analyzed
Files in .gitignore are not scanned
Infrastructure, deployment, and cloud configuration are outside scope
Operational policies and procedures are outside scope
This analysis covers code at time of scan — changes after scan date are not reflected

Legal Limitations

This report is not defensible in court
It does not constitute legal advice
It does not satisfy regulatory audit requirements
To obtain a defensible compliance assessment, engage a licensed compliance attorney and certified auditor
OpenDocket provides directional guidance only

How Findings Are Generated

Primary analysis by Claude Sonnet (Anthropic)
Verification by Gemini 2.5 Flash (Google)
Question libraries are open source and community-maintained
All questions cite regulatory source text
Questions have not been validated by a licensed attorney

Why Two Models?

Claude Sonnet scans broadly — it finds every pattern that could indicate a compliance risk. This produces a comprehensive set of findings but includes noise from documentation files, config references, and test data.

Gemini 2.5 Flash then challenges each finding independently. It asks: is this evidence from actual application code? Would a regulator actually find this concerning? Is the severity appropriate?

The result is a tiered output:

CONFIRMED — Gemini agrees this is a real risk
CONTEXT DEPENDENT — Risk depends on deployment/infrastructure
POSSIBLE FALSE POSITIVE — Likely noise, review before acting

The confirmed count is the number you should act on. The total count shows the full scope of what was examined.

Evidence Tiers

Evidence is classified into three tiers based on file type:

[SOURCE] — Application source code (.ts, .py, .go, .rs, etc.) — strongest evidence
[CONFIG] — Configuration files (.yml, .json, .toml, Dockerfile) — moderate evidence
[DOCS] — Documentation (.md, .txt, .html) — context only, cannot produce High Risk findings

A finding is only classified as High Risk if supported by at least two source code files with matching evidence. Documentation references alone produce Pattern of Concern at most.

How to Use This Report

Share with your engineering lead for remediation planning
Share with your attorney as a starting point for compliance review
Re-scan after remediation to track progress
Do not present this as proof of compliance

Findings based on OpenDocket's open source question libraries. View and contribute