What the data for this category looks like
Data sources for code security audit include source code repositories, dependency lists, static application security testing (SAST) tools, and public vulnerability databases. Data updates once per version or per project. Daily output includes code audit reports, vulnerability proof documents, repair recommendation documents, and retest records. Individual audit data contains fields such as dangerous function location markers, data flow trace paths, and repair plan review results. This data has no fixed unit, and is stored as structured text and attachments.
Constraints for deployment and upgrade
Multi-source data integration requires configuring access permissions for multiple external services during deployment, including code repositories, SAST tools, and vulnerability databases. Verify network connectivity in advance. Frequently updated data requires reserving sufficient storage and computing resources during deployment to avoid task backlog after upgrade. Diverse audit document formats require configuring a compatible parsing engine during deployment to adapt to audit report structures from different projects. The high time consumption of manual review processes requires optimizing task queue scheduling logic during upgrade to avoid resource preemption.
How to set configurations
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
MONGODB_URI | mongodb://audit_user:secure_pass@db-host:27017/audit_db?authSource=admin | Stores code audit reports, vulnerability records, and retest data. Requires specifying an authenticated user, database name, and authentication source |
REDIS_URL | redis://:redis_pass@cache-host:6379/1 | Caches frequently accessed vulnerability database snapshots and audit task queues. Uses database 1 to isolate business cache from other service cache |
STORAGE_S3_ENDPOINT | https://s3-cn-hongkong.amazonaws.com | Stores raw code files, audit attachments, and vulnerability proof documents. Must match the object storage endpoint of the cloud service provider |
DB_MAX_LINK | 15–25 connections | Controls the number of simultaneous database connections, to avoid exhausting connection pool resources during parallel audits across multiple projects |
FILE_TOKEN_KEY | Randomly generated 32-digit hexadecimal string | Encrypts uploaded audit attachment files to prevent unauthorized file access and tampering |
ROOT_KEY | 64-bit strong key generated based on deployment environment | Permission verification key for the management backend, to prevent unauthorized configuration modifications and system access |
Three common configuration errors
- Symptom: After deployment in a Docker container, access to external vulnerability databases or code repositories fails, returning AxiosError 404 or connection timeout. Cause: The container network has no outbound access rules configured, or the domain name corresponding to
STORAGE_S3_ENDPOINThas not been added to the container's allowed access list. - Symptom: The local development environment can correctly parse uploaded audit documents, but attachments cannot be recognized after image packaging and deployment, with no error prompt. Cause:
FILE_TOKEN_KEYwas not configured correctly during deployment, leading to attachment decryption failure, or the mounted storage volume has insufficient permissions to read attachment files. - Symptom: After upgrading to FastGPT v4.17.0, old-version audit reports fail to load, returning a field missing error. Cause: The field structure of old-version audit reports was not adapted in advance, and no data migration configuration was executed, leading to compatibility issues.
How to verify successful configuration
- Run
docker logs fastgpt-auditto view service startup logs, and confirm there are no error messages forMONGODB_URIandREDIS_URLconnections. - Upload a small test code audit report, and check if attachments can be downloaded and parsed normally in the management backend, to confirm storage configuration is effective.
- Call the built-in audit task query interface, check if the returned vulnerability data matches the configured vulnerability database data source, to verify normal data integration.
- Modify the
DB_MAX_LINKparameter, restart the service, and check the database connection count via monitoring tools to confirm the configuration value takes effect.
The values provided are common starting points, and 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.