What the data for this category looks like
Data sources for code security auditing include project source code repositories, third-party dependency lists, static application security testing (SAST) tool outputs, and public vulnerability databases. Data updates occur with project version iterations or when individual audit tasks complete, and dedicated documents are typically generated per project or per version. Daily produced documents fall into four categories: code audit reports, vulnerability proofs, repair suggestions, and retest records. Structured fields include vulnerability ID, affected code path, dependency package version, repair status, traceability chain, and others. There is no unified fixed unit, and field content adjusts based on document type and audit scope.
What constraints these characteristics impose on the "citation sources and traceability" link
Mixed access to multi-source data requires traceability configuration to accurately bind unique identifiers for each source, preventing confusion between scan results from different tools or audit documents from different projects. High update frequency requires configuration to support real-time association with the latest audit versions, ensuring traceability information matches the current project’s latest status. Complex document structures require configuration to split traceability fields by document type, to match the content formats of different documents such as audit reports and vulnerability proofs. Additionally, security audit scenarios have high traceability accuracy requirements, needing traceability information to be precise to specific code lines or dependency package versions, and cannot rely on generalized source descriptions.
How to set the configuration
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
| Maximum Reference Token Count | 8000–12000 token | Code audit reports typically contain long-text vulnerability analysis and attack path descriptions, requiring complete retention of traceability information |
| Return Data Format | Structured JSON | Fields such as vulnerability ID, code path, and dependency version must be extracted for precise traceability, facilitating subsequent verification and audit |
| Detail Toggle | Enabled | Specific content of original documents must be displayed to meet the detailed traceability information requirements of security audits |
| Single Recall Limit | Top 10 | Covers the main vulnerability items in a single audit, avoiding missing key traceability association information |
| Result Rearrangement | Enabled | Sort by vulnerability risk level, prioritizing traceability content for high-risk vulnerabilities, aligning with security audit priority requirements |
| Maximum Context Length | 6000 characters | Adapts to long-text display of code snippets, retaining complete attack path and repair suggestion content |
This configuration applies to FastGPT v4.17.0.
Three common misconfiguration issues
- Phenomenon: Citation results only return a single document, unable to associate traceability information across multiple audit reports. Cause: Result rearrangement configuration is not enabled, leading to traceability information for high-risk vulnerabilities being overwritten by low-priority content.
- Phenomenon: Empty traceability fields are returned after invocation, making it impossible to view specific content of original documents. Cause: Return data format is not correctly configured as structured mode, resulting in exclusive fields of original documents not being extracted.
- Phenomenon: After consecutively initiating audit-related questions, traceability information is lost, and subsequent questions are off-topic. Cause: Unique ID of a single audit task is not bound, and context association identifiers are not retained, causing the traceability context of each question to be reset.
How to verify correct configuration
- A code audit report is uploaded, retrieval is triggered, and the source field of returned results is checked to confirm inclusion of identifiers such as repository address, scanning tool name, and vulnerability ID.
- The maximum reference token count configuration is adjusted, a long-text vulnerability proof document is uploaded, and returned content is verified to not be truncated, displaying complete vulnerability analysis details.
- After the detail toggle is enabled, high-risk vulnerability keywords are searched, and returned results are confirmed to include specific code snippets or dependency version information from the original document.
- Two consecutive audit-related questions are initiated, and the second question is verified to still associate the traceability context of the first question, with no context loss occurring.
The configuration values provided are common starting points and should be evaluated against your 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.