What Data for This Category Looks Like
Data for this category primarily comes from source code repositories, dependency lists, static application security testing (SAST) tools, and public vulnerability databases. Data updates follow each version or project iteration. Daily deliverable documents include code audit reports, vulnerability proofs, repair suggestions, and retest records. Core fields include vulnerability severity, associated code line numbers, affected business scope, and repair verification status. There are no unified mandatory units. Specific field units adjust based on the audit item.
What Constraints These Characteristics Impose on Workflow Orchestration
Data sources are scattered and rely on external tools. Workflows must support cross-node calls to different data sources. Update frequency shifts with project versions. Configurable execution nodes must support on-demand triggering. Multiple linked daily deliverable documents require sequential processing. Workflows must support multiple input and output nodes to fit different audit stages. Core fields are non-standardized. Configurable variable mapping nodes are required to adapt to field format differences across audit items. Retest records must link back to original audit results. Workflows must retain context association capabilities between nodes.
Configuration Settings
The following configurations apply to FastGPT v4.17.0. Adjustments can be made based on actual audit scenarios.
| Configuration Item | Recommended Approach | Rationale |
|---|---|---|
| Form input node | Bind the audit project identifier in the global variable variables | Adapt to code repository paths and audit scopes for different projects |
| Tool call split rule | Match knowledge base or MCP call nodes by nodeId | Distinguish between static scan result calls and knowledge base retrieval for manual review stages |
| Form default value | Use the project update time from the current workflow context | Automatically populate the generation time field of audit reports |
| Supported document upload formats | Use code-specific formats identified through actual testing (.py, .java, .tar.gz) | Match common input file types for code security auditing |
| Single recall limit | Top 5 entries | Adapt to the typical number of return results from vulnerability databases |
| Node timeout setting | 600 seconds | Adapt to typical time consumption for SAST tool scans and vulnerability database queries |
Three Common Mistakes
- Phenomenon: The default value of the form input node returns an empty string after referencing a variable. Cause: The target variable is not bound to the
variablesglobal variable pool of the current workflow. The variable name is only written directly in the local form configuration. - Phenomenon: Tool calls have no split logic during workflow execution, and all trigger the same node. Cause: No split rule based on
nodeIdis configured, or the node ID does not match the target node. - Phenomenon: The workflow reports an error and fails to parse after uploading a code file. Cause: No file format exclusive to code security auditing is configured, and a document of an unspecified type is uploaded.
How to Verify Correct Configuration
- Trigger the workflow, then check the output log of the form input node. Confirm that the default value has automatically populated the project update time.
- Switch between different audit projects. Verify that the
variablesof the workflow adjust along with the project. - Upload different types of code files. Confirm that only supported formats can be uploaded normally and proceed to subsequent nodes.
- Check the tool call log. Confirm that the split rule correctly matches the knowledge base or MCP node based on
nodeId.
The values provided are common starting points. They should be evaluated against local 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.