What the data for this category looks like
Vulnerability scanning service data comes from vulnerability scanners, asset inventories, CVE databases, and patch announcements. Data update frequency is weekly or monthly, aligned with daily operations scanning and rescan cycles. Daily generated documents include scanning plans, vulnerability lists, rectification work orders, and rescan reports. Core fields cover asset scope, vulnerability CVE IDs, risk levels, rectification requirements, rescan results, and associated work order IDs. Non-essential statistical numeric fields are not included.
What constraints these characteristics impose on the "sharing and embedding" workflow
Core data for vulnerability scanning services is split across multiple document types and linked to specific scanning tasks. Therefore, sharing and embedding requires precise binding to the unique identifier of the corresponding task to prevent cross-task data leaks. Data updates occur weekly or monthly, so embedded pages must be set up by external business systems for automatic periodic refreshes to ensure displayed content matches the latest scan results. Since core data involves high-severity vulnerabilities and rectification work orders, sharing links must strictly restrict access scope, allowing only internal operations personnel to access. Additionally, data is linked to asset scope and rectification status. Embedded content must fully retain field association relationships to avoid losing critical context when split.
How to set up configurations
This configuration covers FastGPT sharing link basic settings. External business system association configuration should refer to the corresponding service documentation.
| Configuration Item | Recommended Starting Value | Rationale |
|---|---|---|
Sharing entry shareId | Copy the full sharing link generated by the system; do not manually replace the identifier | Identifies the sharing entry; vulnerability scanning service business records and data permissions must still be handled by external systems |
| Sharing link validity period | Test starting point: 7 days; adjust based on actual testing of vulnerability scanning service collaboration cycles and revocation requirements | Verify availability within the validity period and access behavior after expiration; this value is not an official default or industry average |
| QPM | Test starting point: 20 requests per user per minute; adjust based on actual load | Limits access frequency for a single user; requires validation combined with request logs and actual load |
| Identity verification | When identity permission requirements apply, first verify commercial edition capabilities and the uid returned by the third-party identity service | Holding a sharing link does not equate to having business data permissions; third-party identity and data scope must be verified separately |
| Referenced content display | Select display configurations for referenced fragments, full text, or original text based on the sensitivity of vulnerability scanning service materials | Check displayed content within authorized data ranges; do not use hidden interfaces as a substitute for data permission controls |
| Conversation record verification | Test example: Prepare 10 vulnerability scanning service Q&A samples, check them in the same browser and another device respectively | Anonymous records rely on browser local identity; retention is not guaranteed across devices or after cache clearing |
Three Common Misconfigurations
- Vulnerability scanning service related sharing links fail to open. First verify the full system-generated link and its validity period, then check browser request statuses. Do not manually replace
shareId. - Visibility of vulnerability scanning service data does not match expectations. Verify third-party identity verification results, workflow request parameters, and external system data permissions separately. The sharing entry identifier itself does not provide business authorization.
- The same vulnerability scanning service Q&A is not visible on another device. For anonymous scenarios, first check device, browser, and local identity status. Record retention is not guaranteed across devices or after cache clearing; do not use this phenomenon alone to judge service anomalies.
How to Confirm Configuration is Complete
- Access the configured sharing link, confirm that only the vulnerability list or rectification work order corresponding to the specified scanning task in the external business system loads, with no unrelated other scan data.
- Switch browsers or open incognito windows to access the same sharing link, confirm that operation logs for both sessions comply with isolation rules for external business systems or FastGPT anonymous local identities, and do not interfere with each other.
- Wait for the preset refresh cycle of the external business system, then refresh the page, confirm that the page content updates to the latest rescan report or rectification status data.
- Access the sharing link from a device with a non-internal IP, confirm that no content loads, verifying that the external business system or FastGPT commercial edition identity verification configuration is active.
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.