网络安全众测平台全栈开发

最近把一个面向安全众测、攻防演练和漏洞审核场景的平台整理并开源了。

项目地址：https://github.com/benbenbendang/wangluoanquan-zhongce-pingtai

这个项目不是一个简单的“漏洞提交页面”，而是把从选手注册、授权资产查看、漏洞提交、风险申报、申诉处理，到管理员审核、评分、公告发布、模板下载、承诺书归档、积分排行和后台导出的一整套流程做成了线上系统。对我来说，这个项目最大的价值，不只是把页面和接口写出来，而是把真实业务流程完整跑通。

一、项目背景

在众测和攻防演练场景里，最麻烦的往往不是“发现漏洞”本身，而是后续的流程管理。

如果还是靠 Excel、Word、微信群、邮件和人工汇总去处理选手提交的漏洞、风险和申诉，整个过程会非常割裂：

资产授权范围不好统一维护
漏洞附件和补充材料容易散落
审核进度、驳回原因、评分标准不透明
风险申报和漏洞审核之间缺少关联
管理员需要重复统计、重复导出、重复沟通

所以我做这个平台时，目标很明确：把“众测平台”真正做成一个完整的业务系统，而不是单点功能页面。

二、整体架构

平台采用前后端分离，并且按角色拆成两套入口：

选手端：负责注册、登录、看授权资产、提交漏洞、发起风险申报、查看公告、上传承诺书等。
管理端：负责审核用户、维护资产、审核漏洞和风险、处理申诉、发布公告、导出资料等。

整体结构如下：

.
├── backend/           # 选手端 API
├── admin-backend/     # 管理端 API
├── frontend/          # 选手端前端
├── admin-frontend/    # 管理端前端
└── docker-compose.yml # 一键部署

这种拆分方式的好处很直接：

选手端和管理端权限边界更清晰
前端页面职责更单一，开发和维护更容易
后端接口可以按角色拆分，避免一个服务里权限逻辑过于混乱
后续无论做本地开发还是 Docker 部署，结构都比较规整

三、技术选型

这个项目的技术栈没有刻意追求花哨，而是优先选择成熟、稳定、我自己能快速推进业务的方案。

前端

模块	技术
选手端前端	Vue 3、Vite、Vue Router、Pinia、Element Plus、Axios
管理端前端	Vue 3、Vite、Vue Router、Pinia、Element Plus、Axios
静态托管	Nginx

后端

模块	技术
API 框架	FastAPI
服务运行	Uvicorn
ORM	SQLAlchemy 2
数据库驱动	PyMySQL
身份认证	JWT、python-jose
密码哈希	Passlib + bcrypt
配置管理	Pydantic Settings
文件上传	python-multipart

数据层

模块	技术
数据库	MySQL 8.0
附件存储	本地目录挂载
部署方式	Docker Compose

前端用 Vue 3 + Element Plus，是因为业务后台本身更强调表单、表格、审核流和管理操作，组件生态成熟会省很多时间。后端选 FastAPI，则是看重它在接口定义、数据校验、文档生成和开发效率上的平衡。

四、核心业务模块

这个项目的重点其实不在“页面数量”，而在于业务链条是否完整。

1. 选手端

选手端主要覆盖以下流程：

用户注册、登录与资料维护
授权资产查看与搜索
漏洞提交、附件上传、审核状态跟踪
基于漏洞发起风险申报
针对漏洞、风险、资产等对象发起申诉
查看公告、下载模板、上传承诺书
公司维度排行榜展示

也就是说，选手从进入平台开始，到最后完成漏洞提报、补充材料、查看审核结果，整个过程都可以在线上闭环完成。

2. 管理端

管理端主要负责流程管控：

审核新注册用户
管理授权资产，支持新增、导入、禁用、恢复、导出
审核漏洞，设置严重等级、奖励分值和驳回原因
审核风险申报，设置风险类型和风险加分
处理申诉
发布公告、上传模板、管理承诺书
修改管理员账号信息

这一侧更像一个标准的运营后台，但业务对象不是商品和订单，而是资产、漏洞、风险、申诉和资料归档。

五、我在这个项目里做的重点

如果只把它理解成“Vue + FastAPI 的 CRUD 项目”，其实低估了它的难点。这个平台真正花时间的地方，主要有三块。

1. 业务建模

平台里最核心的数据对象包括：

User
Asset
Vulnerability
Risk
Appeal
Attachment
Announcement
VulnerabilityTemplate

这些对象之间不是简单平铺关系。比如风险申报需要关联漏洞，申诉又可能针对漏洞、风险或资产发起，附件既可能服务于漏洞证明，也可能用于承诺书归档。把这些关系理顺，后面的接口和前端页面才不会越写越乱。

2. 双端分离

我把选手端和管理端拆成了两套前端、两套后端接口入口。这样做虽然文件更多，但换来的是边界更清晰：

选手端只处理用户侧操作
管理端只处理审核和配置
后续权限扩展时不需要在一个前端里硬塞大量角色分支

这种方案在真实业务里比“一个后台写完所有页面”更稳，也更容易继续迭代。

3. 部署与运维友好

项目根目录直接提供了 docker-compose.yml，可以一键拉起：

MySQL
选手端 API
管理端 API
选手端前端
管理端前端

同时我把文档也补齐了，包括：

PROJECT_INTRODUCTION.md
DOCKER_DEPLOY.md
CLOUD_DOCKER_DEPLOY.md
MIGRATION_GUIDE.md

这部分看起来不像“代码量”，但其实很关键。很多项目卡死不是因为写不出页面，而是没有把部署、迁移、备份和排障文档梳理出来。

六、开发和部署体验

本地开发环境大致如下：

# 选手端后端
cd backend
pip install -r requirements.txt
uvicorn app.main:app --reload --host 0.0.0.0 --port 8001

# 管理端后端
cd admin-backend
pip install -r requirements.txt
uvicorn app.main:app --reload --host 0.0.0.0 --port 8012

# 选手端前端
cd frontend
npm install
npm run dev

# 管理端前端
cd admin-frontend
npm install
npm run dev