What data for this category looks like
Data for this category primarily comes from source code repositories, dependency lists, static code scanning tools, and public vulnerability databases. Daily produced documents include code audit reports, vulnerability proof documents, repair recommendation documents, and retest records. Data updates follow project version iterations or individual audit task progress. Updates typically occur after completing one project version or each round of audits. Data fields include code file paths, vulnerability types, risk levels, associated dependencies, and more. There are no unified fixed units; values adjust based on specific audit items.
What constraints these characteristics impose on forms and interactions
This category’s data is multi-source and updates with project iterations. Batch import and association binding of multi-source data must be implemented via external business systems to avoid duplicate data entry. Daily document types are diverse. The formInput node is responsible for collecting input. External business systems can adapt to input requirements for different fields, such as risk level selection and file selection controls for vulnerability paths. The high update frequency requires incremental submission and version association via external business systems. For time-consuming processes such as dangerous function localization and data flow tracking, rapid input and verification rules for configuration fields via external business systems reduce the probability of manual errors. Uncertainty in multi-source data import also requires configuring fault-tolerance mechanisms via external business systems to handle situations such as tool response delays or abnormal file formats.
How to configure
This page’s configuration is based on FastGPT v4.17.0
| Configuration Item | Recommended Approach | Rationale |
|---|---|---|
Form input node formInput | Test example: Select 3 fields from code security audit fields as required inputs; actual fields are determined per task | This node collects user input; missing required items requires checking interaction status to prevent subsequent nodes from receiving incomplete input |
User selection node userSelect | Test example: Set 2 business options, check corresponding branches one by one | This node handles user selection; queries and filtering of code security audit-related records are implemented by subsequent interfaces or external systems |
| Field passing after submission | Test example: Prepare 10 code security audit input samples, covering complete filling, missing required items, and canceled operations | Compare input and node output to verify whether subsequent nodes receive corresponding fields; result thresholds are determined per actual task |
| External implementation item: Data import verification rules (handled by external system) | Must be implemented separately by external system; only allow .zip/.tar.gz format files, verify total file size does not exceed 1000 MB (test example) | Data comes from source code repositories; non-code files must be filtered and single import scale limited |
| External implementation item: Failure retry mechanism (handled by external system) | Must be implemented separately by external system; retry 3 times, 60 seconds interval between each attempt | Multi-source data import may fail due to network fluctuations or SAST tool response delays; appropriate retries ensure data integrity |
| External implementation item: Version association configuration (handled by external system) | Must be implemented separately by external system; bind project version number input field | Data updates follow project version iterations; association with corresponding versions facilitates subsequent retests and traceability |
Three common configuration errors
- Phenomenon: "Unsupported file format" error appears after form submission, and the allowed upload file type list is not displayed. Cause: Data import verification rules are not configured via the external business system, or the verification rules do not cover common archive formats of source code repositories.
- Phenomenon: The
userSelectcontrol cannot customize options according to audit requirements, only preset general categories are displayed. Cause: Custom options for theuserSelectnode are not configured via the external business system, only preset values are used. - Phenomenon: Associated audit data is lost after form submission, and the corresponding project version cannot be traced. Cause: Version association fields are not configured via the external business system, or the fields are not set as required items, resulting in disconnection between data and project versions.
How to verify successful configuration
- Upload an archive in source code repository format, check via the external business system whether the file can be imported and parsed normally.
- Open the risk level selection control, confirm that preset risk level options are included, and support custom new options configured via the external system.
- When submitting the form, check whether a required project version number field prompt appears, ensuring the association configuration takes effect.
- Simulate a network delay scenario, check via the external business system whether the failure retry mechanism is triggered and executed according to the configured interval and number of times (test example).
The values provided are common starting points and should be evaluated against local sample sets.
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.