What data looks like for this category
Data for this category primarily comes from vulnerability scanners, asset inventories, CVE databases, and patch bulletins. Daily produced documents include scan plans, vulnerability lists, rectification work orders, and rescan reports. Data update frequency is weekly or monthly. Core fields include scan task ID, asset IP address, CVE ID, vulnerability severity, rectification status, and rescan time. All fields align with standardized security operations workflows. No additional non-standard statistical fields are included.
Constraints on workflow orchestration
Data sources for this category are scattered. Workflow orchestration must use multiple nodes to pull asset inventory, CVE database, and scan result data separately. Since data updates occur weekly or monthly, workflows must include scheduled trigger nodes that match these cycles. Multiple daily produced documents require nodes to perform format validation and field mapping, to meet the field requirements of different operation documents. Asset range confirmation, false positive exclusion, and rescan result verification are the most time-consuming steps. Workflows must add manual review nodes to connect automated steps, to prevent high-severity vulnerabilities from being exposed due to process oversights.
How to set configurations
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
variables | Bind to the asset IP range of the scan task, maximum 500 asset IPs | Aligns with the asset range confirmation step of vulnerability scanning services, reduces manual input costs |
nodeId | Bind to the text content extraction node | Accurately locates the link where vulnerability information needs to be extracted, avoids confusion in workflow node calls |
| Scheduled trigger cycle | 7 days / 30 days | Matches the weekly or monthly data update frequency, aligns with the execution rhythm of scan plans |
| Text extraction fields | Extract vulnerability severity, CVE ID, and rescan status | Meets the standardized field requirements of vulnerability lists and rectification work orders |
| Global variable validation | Only take effect in the current workflow | Prevents variable conflicts across workflows, adapts to scenarios where multiple apps are switched |
| Abnormal alert trigger | Triggered when high-severity vulnerabilities are detected | Notifies operation teams in a timely manner, avoids exposure risks of high-severity vulnerabilities |
Three common configuration errors
- A "required global variable not configured" error appears during workflow runtime. The symptom is that validation is still triggered after switching from an app with required global variables to an app without global variables. The cause is that the workflow caches the global variable configuration of the previous app, and does not automatically clear old validation rules.
- Text content extraction returns empty results. The symptom is that no vulnerability information is obtained from the knowledge base or scan results even though extraction rules are configured. The cause is that
variablesis not bound to the correct data source node, so the extraction node has no available input data. - A "node ID does not exist" error appears during workflow debugging. The symptom is that the
nodeIdconfiguration is not updated after modifying a node in FastGPT v4.8.10 or earlier versions. The cause is that the node ID changes when modified via the interface, and the bound parameter in the workflow is not synchronized. This issue was fixed in FastGPT v4.17.0 with optimized automatic node ID synchronization logic.
How to confirm the configuration is correct
- Trigger a test run, check whether the input and output of workflow nodes correctly pull fields such as asset IP addresses and CVE IDs.
- Verify that the global variable configuration only takes effect in the current workflow, and no residual validation prompts appear after switching to other workflows.
- Confirm that the scheduled trigger node automatically starts the scan process at the set 7-day or 30-day cycle.
- Simulate a high-severity vulnerability detection scenario, and confirm that the abnormal alert node normally triggers notifications.
The values listed here are common starting points. They should be evaluated against sample data from the respective deployment contexts.
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.