What the data for this category looks like
This category's data primarily comes from target system logs, public vulnerability databases, automated scanner results, and manual verification records from red team engineers. Daily associated documents include project test authorization letters, official penetration test reports, vulnerability reproduction process records, and rectification priority recommendations. Data updates follow the rhythm of individual projects or major system version iterations, with no fixed cycle. Individual project data includes fields such as authorization scope, vulnerability ID, exploitation path, and repair status. There is no unified quantitative statistical unit, and data is only archived and stored by project.
What constraints do these characteristics impose on the database and operations link
The data characteristics of this category impose multiple constraints on the database and operations link. Multi-source mixed data sources include structured vulnerability rating data and unstructured manual verification text. The database must support multi-format storage and flexible mixed query capabilities. Data updates have no fixed cycle. On-demand writing must be supported to avoid idle resource occupation caused by scheduled batch synchronization. Associated test authorization letters are sensitive legal documents. Fine-grained permission control must be configured to prevent unauthorized access to data. Project data volume grows with the number of vulnerabilities. The number of concurrent connections per database must be limited to avoid performance bottlenecks at the operations level. This ensures the response speed of tool calls.
How to set configurations
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
PG_URL | postgresql://pentest_user:secure_pass@db-host:5432/pentest_db?sslmode=require | Stores structured test authorization letters and vulnerability rating data, complies with FastGPT v4.17.0 structured data storage specifications, and requires SSL encryption to ensure the security of sensitive information |
MONGODB_URI | mongodb://pentest_user:secure_pass@mongo-host:27017/pentest_data?authSource=admin | Stores unstructured vulnerability reproduction records and manual verification text, supports flexible document-based queries, and meets the mixed retrieval needs of multi-source data |
DB_MAX_LINK | 20–30 | Matches single-project data volume and concurrent verification requests, prevents service interruptions caused by exhausted database connection pools, and aligns with the daily operation rhythm of red team engineers |
REDIS_URL | redis://:cache_pass@redis-host:6379/0 | Caches frequently queried vulnerability database data and authorization status, reduces repeated database access pressure, and improves the response speed of tool calls |
Three Common Mistakes
- Phenomenon: After enabling problem optimization and result rearrangement, tool calls return timeouts, with duration exceeding 30 seconds. Cause: No reasonable value for
DB_MAX_LINKis configured, leading to exhausted database connection pools and failure to respond to multi-source data query requests in a timely manner. - Phenomenon: Concurrent calls occur during the tool selection phase, with the same vulnerability verification request triggering multiple scanner calls. Cause: No temporary lock for tool call results is configured via Redis, leading to repeated task triggers and increased load on databases and scanners.
- Phenomenon: Unable to create a project database after local deployment. Cause: Database permissions for
PG_URLare not correctly configured, and the current user lacks the necessary permissions for CREATE SCHEMA or CREATE TABLE, preventing database initialization.
How to confirm the configuration is complete
- Run the built-in database connection test script included with FastGPT v4.17.0 to verify the connectivity of
PG_URLandMONGODB_URI, and confirm that permission configurations meet the security requirements for document storage. - Submit a single test authorization letter data entry, check the response speed of database writing and associated queries, and align with the time consumption requirements of the target business scenario.
- View Redis connection logs, confirm that the expiration time configuration of cache keys matches the update rhythm of vulnerability database data, and avoid repeated queries caused by expired cached data.
- Simulate concurrent submission of vulnerability verification requests from multiple users, check the usage status of the database connection pool, and confirm that the value of
DB_MAX_LINKadapts to concurrent loads.
The values provided here are common starting points and should be measured against deployment-specific 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.