Project access

Project assignments restrict non-management users within a tenant. Owners, admins and platform administrators retain their existing access. Role checks still apply: assignment does not let a viewer launch scans or administer a project.

An empty assignment list means unrestricted access to the tenant, preserving the existing product behavior. To revoke tenant access entirely, remove the user's membership. Clearing assignments is not a way to deny all projects.

#Available to assigned users

• Project lists and project details, filtered by assignments.
• Dashboard statistics, overview and analytics; scan history and pagination; aggregated findings; global search and accepted-risk lists.
• Individual scan results and JSON, CSV, PDF, CycloneDX, SPDX and UBOM exports.
• Scan-linked license reports, remediation plans, AI risk, reachability, attack graphs and regulatory evidence.
• SAST and secrets runs/findings linked explicitly to an accessible scan, including SAST exports.
• Project scan launches for analysts through New scan or Projects → Actions → Scan now, with progress and completed/failed jobs under Scans. Jobs and saved results carry the same trusted project ownership from creation.
• Job lists, counts and direct job reads filtered to assigned projects. Global queue position and capacity are omitted for restricted users.

The API filters before pagination and aggregation, checks direct scan/run IDs, and bypasses shared tenant caches for restricted requests. The UI server does not cache authenticated API responses across requests, so a subsequent request uses current permissions even when the user's session cookie has not changed. Already delivered pages or downloaded files cannot be recalled.

#Ownership and upgrades

scans.project_id is the authorization link. It is supplied by trusted server workflows, validated against the scan tenant, and cannot be replaced with another project by the monitoring worker. A package name, repository path or projectId embedded in a result payload does not grant access.

scan_jobs.project_id is assigned before queuing. Deduplication cannot cross project boundaries, and a project job cannot attach another project's result. Legacy jobs without ownership remain hidden from assigned users. Immediately before execution, queued project jobs recheck membership, role, grants and source configuration. Revoked users cannot read jobs or results; already-running analysis may still finish.

POST /api/monitoring/projects/:id/scan/async uses only the project's configured repository or source folder. It returns HTTP 202 with jobId and pollUrl; poll the job for completion and scanId. The older /scan endpoint is now an asynchronous alias with the same 202 response, so clients expecting a completed scan must migrate to polling. /api/analyzeProject/async and /api/scanRepo/async also accept { "projectId": "..." }. Source, credential and scan-option overrides are rejected for project submissions. These launches run SCA with configured tenant Maven settings; they do not enable all analysis engines.

On first migration, a legacy scan is linked only if exactly one monitored project in the same tenant explicitly names it as its latest scan. Ambiguous links, older scans with no surviving explicit link, and ad hoc scans remain unassigned. These stay visible to unrestricted users but are hidden from assigned users. Existing legacy copies may also lack authoritative links to their original SAST/secrets runs. New monitoring scans retain the original scan ID instead of copying results.

#Remaining boundaries

Tenant-wide operations without authoritative project ownership remain blocked: arbitrary-source scan submission (including ZIP uploads), runtime-agent data, firewall/pipeline data and tenant-wide administration. Restricted users must select a configured, assigned project to submit a job.

Runtime correlations are unavailable to restricted scan readers until agent runs have project ownership. Attack-graph enrichment for assigned scans uses explicitly linked SAST runs, not similarly named repositories. SAST/secrets dashboard charts cover the accessible assignments; their counts do not follow the dashboard's optional display-name/time filters.

New API routes remain denied to restricted accounts until their data reads and side effects have been reviewed and explicitly enabled.

#Regression coverage

• tests/integration-project-scope-results.test.js: distinct project assignments, another tenant, unassigned scans, role boundaries, direct IDs, exports, pagination, totals, search, linked evidence, warmed caches, grant changes and denied unscoped submission.
• tests/integration-project-scan-jobs.test.js: project job authorization, roles, source binding, queue filtering/counts, deduplication, result integrity and queued permission revocation.
• tests/integration-async-scan-jobs.test.js: real scanner execution and project ownership through persistence and retrieval.
• tests/unit-project-scan-migration.test.js: upgrade from the old schema, ambiguous and foreign-tenant references, retained history, immutable assignment and restart.
• tests/unit-monitoring-worker.test.js: original scan ID retained by monitoring.
• web-v2/e2e/project-scope.spec.ts: actual login, desktop/mobile navigation, scoped pages, proxy downloads, project submission, job polling and grant changes with the same browser session. The browser fixture substitutes a deterministic scanner; the backend integration test exercises real analysis.