What data does this category contain
Data for this category comes primarily from source code repositories, dependency lists, static application security testing (SAST) tools, and public vulnerability databases. Updates follow project version iterations or completion of individual audit tasks. Daily deliverables include code audit reports, vulnerability proof documents, remediation recommendation documents, and retest records. Common data fields include audit object identifiers, vulnerability severity levels, trigger paths, remediation statuses, associated dependencies, and more. There are no standardized fixed units; values change dynamically based on the code size and number of vulnerabilities in the audit project.
What constraints do these characteristics impose on the conversation logs and auditing workflow
Because data sources include multiple types of tools and code repositories, conversation logs must bind to individual project audit sessions via chatId to prevent logs from different projects from being mixed, and ensure independent audit traceability. The update rhythm tied to project version iterations requires setting storage limits and automatic cleanup rules for single-session logs, to prevent storage space overflow from affecting subsequent audits. The production of multiple types of audit documents requires log fields to cover dimensions such as audit objects, vulnerability severity levels, and remediation statuses, to facilitate subsequent compliance reviews and issue retrospectives. The potential impact of errors from high-severity vulnerabilities requires conversation logs to retain tamper-proof operation records, to meet security and compliance traceability requirements.
How to configure settings
This configuration is implemented for FastGPT v4.17.0.
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
chatId | Bind to the unique identifier of the audit project | Distinguish session logs for different code security audit projects, prevent cross-project data mixing |
responseChatItemId | Associate reply content for a single vulnerability audit | Precisely locate review conversations and processing records for individual vulnerabilities |
detail | Enable full-field logging | Cover all audit information including vulnerability severity levels, remediation recommendations, retest results, etc., to meet compliance review requirements |
| Log storage limit | Store the first 200 conversation records per project | Match the length of individual task sessions for code security audits, avoid redundant storage |
| Log cleanup cycle | Automatically clean up 30 days after project completion | Meet compliance retention requirements for security audits, and free up storage space |
| Session isolation switch | Enable user-level session isolation | Prevent audit logs from different R&D teams from interfering with each other, and meet permission control requirements |
Three common configuration mistakes
- Conversation logs for different code security audit projects are displayed mixed together. Cause: The project unique identifier is not bound via
chatId, causing session isolation to fail. - Log storage overflow causes service errors. Cause: No single-session log storage limit is set, and expired logs are not cleaned up according to the project iteration rhythm.
- Audit conversations for individual vulnerabilities cannot be associated with corresponding remediation records. Cause:
responseChatItemIdis not enabled to associate reply content, causing conversations to be disconnected from business data.
How to verify successful configuration
- Create two different code security audit projects, initiate sessions, and check the log panel. Confirm that only conversations for the current project are displayed, to verify that the session isolation configuration is effective.
- Initiate an audit session with more than 200 conversation records. Check the log storage count, confirm that new records stop being added after the limit is reached, to verify that the storage limit configuration is effective.
- Complete an audit project and wait 30 days, check whether the corresponding logs are automatically cleaned up, to verify that the cleanup cycle configuration is effective.
- After enabling the
detailconfiguration, view a single conversation log. Confirm that all fields including vulnerability severity levels and remediation statuses are included, to verify that the full-field logging configuration is effective.
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.