What the data for this category looks like
Data for this category primarily comes from source code repositories, third-party dependency lists, static application security testing (SAST) tools, and public vulnerability databases. Daily produced documents include code audit reports, vulnerability proof documents, repair suggestion lists, and retest records. Data updates trigger when project version iterations complete or individual audit tasks finish, with no fixed cycle. A single audit data entry includes fields such as project identifier, vulnerability type, risk level, associated code line numbers, and repair solutions. No unified standardized unit exists, and data is only archived by project.
What constraints these characteristics impose on the "permission and data isolation" link
Code security audit data includes sensitive source code fragments, undisclosed vulnerability details, and repair solutions, and is archived independently by project. Audit data from different projects must be strictly isolated to prevent cross-project permission leaks. Since data sources include association information from third-party dependencies and public vulnerability databases, permission configurations must distinguish between tool access permissions and audit result viewing permissions. Audit task execution records and retest data must be bound to the team permissions of the corresponding project to prevent unauthorized personnel from accessing incomplete or confidential audit materials. Team permission configurations for local deployment scenarios must adapt to the isolation needs of multiple development teams to avoid cross-team data confusion.
How to set the configurations
| Configuration Item | Recommended Approach | Rationale |
|---|---|---|
teamId | Bound to the unique identifier of the corresponding project | Achieve precise isolation of project-level audit data, matching the project-based data archiving feature |
teamId | Associated with the project field of the audit task | Ensure that audit reports are only visible to team members bound to the current teamId |
tmbId | Assign unique identifiers by team role | Distinguish three roles: security R&D, regular audit, and read-only view, limiting the scope of operational permissions |
| Permission Expiration Time | 30 days | Periodically reclaim audit data access permissions for personnel who have left or changed roles, complying with data retention standards |
| Single Audit Task Timeout Threshold | 600 seconds | Avoid occupying server resources for extended periods, matching the execution rhythm of code audits |
| Local Deployment Team Grouping | Divided by department | Adapt to the multi-department isolation requirements in local deployment scenarios, matching the organizational structure of development teams |
Three common configuration mistakes
- Phenomenon: An error indicating insufficient permissions is prompted when attempting to create a regular user, and account allocation cannot be completed. Cause: The team version permission configuration switch was not enabled in FastGPT v4.17.0, and only the root account retains highest permissions.
- Phenomenon: Cross-project audit data leakage still occurs after configuring
teamId. Cause:teamIdwas not correctly bound to the corresponding project's audit report, or permission group configurations were not associated with thetmbIdidentifier. - Phenomenon: Audit data for the current department cannot be viewed in a local deployment scenario. Cause:
tmbIdwas not configured by department grouping, leading to incorrect permission mapping that fails to match the isolation rules of the corresponding project.
How to confirm the configuration is active
- Log in with a non-root account, attempt to access an audit report not bound to the current
teamId, and confirm that viewing is not possible or an insufficient permissions prompt is displayed. - Switch to role accounts corresponding to different
tmbIdvalues, and confirm that only audit data and tasks for the corresponding team can be accessed. - In a local deployment scenario, switch to a department grouping account, and verify that only code audit-related documents for the current department can be viewed.
- Check the permission configuration page in FastGPT v4.17.0, and confirm that the binding relationship between
teamIdandtmbIdhas taken effect.
The values provided are common starting points and should be measured against the reader's own samples.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-10-19.