What Data for This Category Looks Like
Core data for vulnerability scanning services originates from vulnerability scanners, asset inventories, CVE databases, and patch announcements. Updates occur weekly or monthly. Daily generated documents include scan plans, vulnerability lists, remediation tickets, and rescan reports. Scan plans include task ID, asset scope, and scan cycle fields. Vulnerability lists include CVE numbers, risk levels, and affected assets. Remediation tickets include ticket numbers, associated vulnerabilities, and remediation status fields. Rescan reports include rescan time and remediation results. Data structure is tightly linked to business processes. Permission requirements differ across document types.
Constraints Imposed by These Characteristics on Permission and Data Isolation
Data sources are scattered, covering public vulnerability libraries and internal scan results. Strict ownership separation is required when sharing across teams. Weekly or monthly update cycles result in long data retention periods. Without proper isolation, expired or sensitive vulnerability information may be leaked. The layered structure of documents requires distinct operating permissions for different roles. For example, security administrators can edit scan plans, while regular operations staff can only view remediation tickets. Cross-team API calls that lack permissions stem from failure to isolate data by team dimension. This allows unauthorized teams to access scan data that does not belong to them. Potential error consequences include high-risk vulnerability exposure, missed patches, and audit penalties. Permission configuration must therefore cover access control across the full data lifecycle.
Configuration Guidelines
| Configuration Item | Recommended Approach | Rationale |
|---|---|---|
teamId | Bound one-to-one with business team IDs | Matches asset ownership and team permission scope of vulnerability scanning services, resolves permission issues in cross-team API calls |
tmbId | Bound to the exclusive template ID of the scan task | Isolates scan configurations and results under different templates, avoids data confusion across templates |
| API Call Permissions | Only exclusive keys with a validity period of no more than 30 days are open | Restricts unauthorized teams from calling interfaces, meets cross-team access control requirements |
| Role Permission Settings | Assign three levels of permissions: view, edit, manage | Matches different operating permission requirements for scan plans, vulnerability lists, and remediation tickets |
| Data Storage Retention Period | Divide corresponding retention periods based on weekly or monthly update frequency | Matches the update rhythm of the category, avoids leakage risks caused by long-term retention of expired data |
| FastGPT Version | Use FastGPT v4.17.0 | Ensures compatibility and functional completeness of configuration items |
Common Misconfiguration Scenarios
- Calls to the vulnerability scanning service API return a 403 Forbidden status code. The cause is failure to configure the caller's
teamIdto match the owning team of the target scan task. This leads to permission verification failure. - Cross-team security operations personnel can view vulnerability lists that do not belong to their own team. The cause is failure to configure data isolation scope by
teamId, and the permission verification logic is not bound to team ownership. - Regular operations personnel can modify the remediation status of high-risk vulnerabilities. The cause is failure to configure the three-level division of role permissions. Overly broad permission scope leads to unauthorized operations.
How to Confirm Successful Configuration
- Log in to the FastGPT v4.17.0 backend, switch between different
teamIds, and verify that only scan plans and vulnerability lists corresponding to the current team can be viewed. - Use an API key from an unauthorized team to call the scan result interface, and confirm that a permission denied error message is returned.
- Check user permissions for different roles, and verify that regular operations personnel can only view remediation tickets and cannot modify scan plans.
- Confirm that the
tmbIdof the scan task matches the associated template, preventing unauthorized access to scan data across templates.
The values provided here are common starting points. They should be evaluated 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.