What data belongs to this category
The core data of this category includes four document types: SBOM manifests, dependency risk reports, license lists, and repair work orders. Data sources include package managers, code repositories, vulnerability databases, and license databases. The update frequency is daily or when a new version is released. SBOM manifests contain fields such as third-party component name, version identifier, associated license information, and known vulnerability IDs. Dependency risk reports include entries such as risk level, repair suggestions, and impact scope. Repair work orders include information such as pending tasks, associated components, and responsible teams.
Constraints Imposed on Permissions and Data Isolation
Multi-source, heterogeneous data sources require data isolation by owning entity to prevent cross-team supply chain information leaks. Different update rhythms require matching permission real-time capabilities. This ensures that daily updated dependency risk data is only visible to authorized teams. Structural differences across document types require permission rules to be refined by document type. For example, SBOM manifests are only accessible to R&D teams, and risk reports are only accessible to security teams. Consequences of misconfiguration include high-risk dependency deployments and license violations. Strict restrictions must be placed on cross-team access to sensitive data to prevent unauthorized operations.
Configuration Guidelines
This configuration guide applies to FastGPT v4.17.0.
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
| Team permission scope | Bind corresponding supply chain data by teamId | Supply chain data is attributed to projects or teams. Binding team IDs enables precise isolation of SBOMs and risk reports across different teams |
| Data isolation granularity | Divide individual governance tasks by tmbId | Each individual governance task corresponds to an independent dependency scanning process. Binding template IDs isolates runtime data across different tasks |
| Global variable scope | Bind to current team context | Global variables with identical names across different teams must be stored independently, matching the team attribution rules for supply chain data |
| Data synchronization frequency | Daily or when a version is released | Matches the native update rhythm of supply chain data to ensure data timeliness |
| Single scan timeout | 600 seconds | Avoids long-term occupation of governance resources and prevents task blocking |
| Conversation record permission | Only allow team members to view their team's governance logs | Prevents sensitive dependency repair work order information from leaking, and meets compliance requirements |
Three Common Configuration Errors
- Symptom: Data cross-contamination occurs when different users call global variables with identical names. Cause: The scope of global variables is not limited by
teamId, resulting in unisolated variable data across different teams. - Symptom: The SBOM manifest for the current team fails to load after switching teams. Cause: The data source configuration after team switching is not synchronized to the current session, and data from the old team is still loaded.
- Symptom: A "no permission to operate this conversation record" prompt appears when viewing repair work orders. Cause: No binding rule is configured between conversation records and team permissions, resulting in blocked cross-team access.
How to Confirm Proper Configuration
- Log in to test accounts for two different teams, and view the SBOM manifests for each team respectively. Confirm that only supply chain data belonging to the current team can be accessed.
- After switching teams, confirm that the dependency scanning task configuration matches the current team's data source, with no cross-team data loading.
- Submit a test request for global variables with identical names. Confirm that variable values across different teams do not interfere with each other, and no data cross-contamination occurs.
- View the permission prompt for repair work orders. Confirm that only members of the current team can access the corresponding work orders, and no cross-team access prompts appear.
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.