What this category of data looks like
Core data for vulnerability scanning services comes from vulnerability scanners, asset inventories, CVE databases, and patch bulletins. Four types of documents are generated daily: scan plans, vulnerability lists, remediation tickets, and rescan reports. Data update frequency is weekly or monthly. The most time-consuming steps focus on asset scope confirmation, false positive filtering, and rescan result verification. A single vulnerability data entry includes fields such as CVE ID, risk level, affected assets, and remediation suggestions. Remediation tickets are linked to corresponding scan tasks and rescan results. Overall data flows through the full vulnerability lifecycle. This page applies to FastGPT v4.17.0 deployment configurations.
What constraints do these characteristics impose on the permission and data isolation link
Vulnerability scanning service data involves high-severity vulnerability information and internal operational tickets. Improper isolation may lead to high-severity vulnerability exposure or audit deductions. In multi-team sharing scenarios, unique identifiers are required to distinguish scan data and tickets of different operational teams, preventing cross-team permission overreach. Historical version data has potential field missing issues. All versions must have complete associated fields. For intranet deployment and multi-account on-duty scenarios, permission isolation must adapt to existing authentication systems and multi-person collaborative on-duty workflows, while ensuring compliance of data flow.
How to set the configurations
| Configuration Item | Recommended Setting | Rationale for This Setting |
|---|---|---|
teamId | Globally unique team identification string | Used to distinguish scan data and tickets of different operational teams, enabling cross-team permission isolation |
tmbId | Bound to a single remediation ticket or scan plan | Links to specific business data, ensuring permission verification accurately matches individual tasks or tickets |
| Multi-account team sharing configuration | Enable team-level multi-account reuse, configure the allowed number of logged-in accounts in the range of 2-20 | Adapts to collaborative scenarios with multiple personnel on duty for operations |
| SSO authentication integration | Configure enterprise unified identity authentication protocols such as SAML 2.0 | Meets the requirement of quickly connecting to existing authentication systems in intranet environments |
| Historical version field completion | Batch supplement the tmbId field for the MongoAppVersion table | Fixes the issue of missing associated fields in historical version data |
| Data isolation scope configuration | Divide isolation boundaries by asset groups, each group corresponds to one teamId | Matches the business logic of vulnerability scanning services that manage data by asset dimension |
Three common mistakes
- Failure to create multiple accounts and inability for the same team to share data, caused by incorrect configuration of the
teamIdteam binding logic, or failure to enable the multi-account team sharing switch. - Permission verification fails for historical version data in the MongoAppVersion table, caused by earlier historical version documents missing the
tmbIdfield, leading to missing association relationships. - OneAPI reports MySQL connection refusal during intranet deployment, caused by failing to configure MySQL service access permissions to allow the local Docker container network segment, or failing to match database connection parameters to the intranet deployment environment.
How to confirm the configuration is complete
- Log in to two different team accounts, verify that each can only view scan plans, vulnerability lists, and remediation tickets associated with their own
teamId. - View historical version data in the MongoAppVersion table, confirm that each record includes the
tmbIdfield. - Initiate an SSO authentication process, verify that login can be completed via enterprise unified identity without creating additional local accounts.
- Execute a database connection test within the Docker container where OneAPI is deployed, verify that the MySQL service can be accessed normally.
The values provided here 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.