What the data for this category looks like
Business data for vulnerability scanning services comes from vulnerability scanners, asset inventories, CVE databases, and patch bulletins, with update frequencies of weekly or monthly. Daily generated documents include scanning plans, vulnerability lists, remediation tickets, and rescan reports. Core fields for document structure are task nodes, vulnerability IDs, remediation status, and rescan results. Data is maintained by security operations teams, security service providers, and system administrators. The most time-consuming steps are asset scope confirmation, false positive elimination, and rescan result verification. Operational errors may lead to high-risk vulnerability exposure, missing patches, or audit score deductions. This service focuses on tool-based discovery and rescan closed-loop processes, and differs from penetration testing services.
What constraints these characteristics impose on the deployment and upgrade phase
Because data sources are multiple and update frequencies are fixed, multiple data source connection parameters must be configured during deployment to ensure synchronized updates of asset inventories and CVE databases. Storage requirements for business documents grow with weekly or monthly data volume, so configurations for high-capacity databases and object storage must be adapted. Operational security requirements for on-call maintenance and ticket Q&A are high, so permission verification parameters must be strictly configured. During upgrades, core business data must be backed up in advance to prevent loss of scanning plans and vulnerability lists during version migration. Interface compatibility with local models and third-party scanners must also be maintained to ensure stability of rescan workflows.
How to set the configurations
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
MONGODB_URI | mongodb://scan_user:secure_pass@mongodb-host:27017/fastgpt_scan | Stores core business data including vulnerability lists, remediation tickets, and scanning plans; matches the address of a locally deployed MongoDB instance |
DB_MAX_LINK | 20–30 connections | Adapts to weekly or monthly data volume growth for vulnerability scanning services; supports concurrent access for operation ticket queries and rescan report generation |
REDIS_URL | redis://:redis_pass@redis-host:6379/0 | Caches scanning task status and asset scope data; ensures real-time query response for on-call maintenance |
STORAGE_S3_ENDPOINT | http://local-minio:9000 | Stores files including rescan reports and scanning logs; matches a locally deployed object storage service |
ROOT_KEY | Random string of at least 32 characters | Configures background management permissions for the vulnerability scanning service; ensures operational security for internal tickets |
FE_DOMAIN | http://fastgpt-scan.internal.com | Configures the access domain for the on-call maintenance interface; matches the access path of internal services |
Three common mistakes
- When two separate FastGPT instances are deployed during setup, internal ticket interfaces return 401 unauthorized. The cause is incorrect configuration of
FILE_TOKEN_KEYorROOT_KEY, leading to failed permission verification for cross-instance API requests. - After upgrading to FastGPT v4.17.0, existing scanning plans cannot be synchronized. The cause is failure to back up the business database associated with
MONGODB_URIin advance, leading to data migration errors during the upgrade. - After deploying the bge-rerank-base image, rescan report generation times out. The cause is an excessively low
DB_MAX_LINKsetting, which depletes the database connection pool and prevents timely reading of vulnerability data for report generation.
How to confirm proper configuration
- Run the
docker compose pscommand to confirm that all associated services including MongoDB, Redis, and FastGPT instances are running. - Log in to the FastGPT background management page, enter the
ROOT_KEYto verify administrator permissions, and confirm that scanning plans and internal ticket configurations can be edited normally. - Upload a standard-format asset inventory file, and confirm that it can be imported normally to generate a scanning task.
- Trigger a manual rescan, wait for the task to complete, and confirm that the rescan report is generated normally and stored in the specified object storage path.
The values listed above are common starting points, and should be evaluated against the reader’s own deployment 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.