admin/ARTEX-chixuweihu
1
0 Fork 0
mirror of https://github.com/RuoJi6/ARTEX.git synced 2026-11-14 14:13:50 +08:00
Code Issues Packages Projects Releases Wiki Activity
581 Commits 6 Branches 15 Tags
28b40bafc84f3294f98cfaa7e3eee598e7bb1bdf
Commit Graph
12 Commits
Author SHA1 Message Date
RuoJi6 0ecaea2fb2 feat(web): 任务发现 tab 支持严重度筛选与排序 
对齐全局发现页：共用 severity chip、Case 列表 sort=severity，
原始上报列表前端按严重度过滤并排序。
 2026-10-26 09:14:28 +08:00
ji ruo fb8c3cb6f4 fix: wrap intelligence table text and distinguish category colors 2026-10-20 11:43:24 +08:00
luckoneandClaude Code f3fb37f70d feat(notify): 漏洞发现支持推送到钉钉/飞书/企业微信等六种渠道 
新增「系统 → 通知推送」页，把扫描发现的漏洞推送到钉钉、飞书、企业微信、
通用 Webhook、Telegram、邮件。同一类型可配任意多个机器人实例，每个实例独立
设启停、限流与过滤规则（最低级别 / 任务资产范围 / 漏洞类型关键词 / 是否接收
处置状态变更）。推送时机分实时与汇总两种模式，「高危实时、其余汇总」建两个
渠道即可表达，策略不写死在代码里。带投递历史与失败重发。

三个关键设计：

1. 写漏洞的事务只做一次盲 INSERT。notification_events 由 RecordFindingTx
   在同一事务内写入，保证「漏洞落库」与「推送任务存在」原子一致；这条 INSERT
   刻意不读渠道表、不跑用户的过滤规则，否则一条配错的过滤条件就能污染甚至
   中止事务，让高危漏洞存不进库。为把失败隔离在这一条语句上（PostgreSQL 中
   事务内任一语句报错会让整个事务作废、连 COMMIT 都失败），它被 SAVEPOINT
   包住，失败时只记日志。

2. 投递用租约领取而非长事务。FOR UPDATE SKIP LOCKED 领取后把行置为 sending、
   把 next_attempt_at 推到未来作为租约，提交后再做网络投递，因此投递期间不
   持有数据库锁；崩溃留下的 sending 行会被下一轮重新领取，自愈且不会无限重试。

3. 限流不消耗重试预算。先按渠道令牌桶算出本轮还能发几条，再按这个数量领取；
   顺序反过来会让被限流挡下的投递白计一次尝试，三次预算被等待耗光后落入失败。

审计并修复的四个问题：

- 推送凭据经错误信息外泄：http.Client.Do 返回的 *url.Error 会把完整 URL 打进
  错误文本，而钉钉 access_token、企业微信 key、飞书 hook id、Telegram
  /bot<token>/ 都就在 URL 里。该串流入 last_error（明文落库）、投递历史接口
  （绕过渠道掩码）、服务端日志与前端错误提示。现统一脱敏为 scheme://host
  + 底层原因，并拒绝跨主机重定向。
- 最低级别门槛打错字会让过滤器静默失效：未知级别序数为 0，判定退化成
  rank >= 0 恒真，用户以为限制「仅高危」实际全推。现于写入路径校验取值。
- 汇总批次无上限：一次领取把全部待发行读进内存、消息被渠道长度上限截掉大半
  且静默丢失。现单批上限 500 条，超出部分留库成为下一批。
- 邮件渠道把 SMTP 4xx（灰名单等临时失败）判成永久失败，导致这类最该重试的
  场景从不重试。现按应答码首位区分 4xx/5xx。

测试：notify 包 82% 覆盖（含用自建最小 SMTP 服务器驱动的完整邮件协议会话、
两种签名算法对 OpenSSL 基准值的比对、UTF-8 边界截断、以及模板能力边界的
反射断言）；db 与 server 侧共 29 个用例跑真实 PostgreSQL，其中端到端用例
真发 HTTP 到假接收端并断言消息内容与投递状态。

Co-Authored-By: Claude Code <[email protected]>
 2026-09-30 16:25:06 +08:00
Autumn-27 4756bb1c45 feat(intent): 意图删除支持假删除/真删除两种模式 
删除入口区分两种模式(待领/运行中/已暂停的意图均可删除):

- 假删除(默认):意图置 state='deleted'、删除原因记入新字段 delete_reason,
  保留节点与全部产出/血缘,不再在图上另挂 fact。
- 真删除:物理删除意图及「仅由它支撑」的独占子孙(沿 yields/derived_from
  级联到叶子),避免孤立数据;共享节点、目标、任务根事实保留。被删意图先做
  token rollup 并清理 activity/副会话,被删 finding 先删 findings 行。

两种模式都照常用 cancelled 触发通知 planner(带删除前捕获的意图摘要 + 原因),
planner 文案不再声称原因挂为事实。

- DB: 新增 SoftDeleteIntent、重写 CancelIntent 为深度独占级联;schema 加
  delete_reason 列与 intent 的 deleted 状态(含旧库迁移)。
- 前端: 删除对话框加模式切换与动态说明,状态徽章/图标新增「已删除」,
  播报板展开展示删除原因。
 2026-09-17 12:52:57 -04:00
ji ruo 82c1ed9cbb feat: 支持会话级漏洞复测与运行状态展示 2026-09-10 16:06:08 +08:00
Autumn-27 377ccc7e5a fix(web): 修正意图状态标签 exhausted/blocked 语义错误 
- exhausted「已穷尽」→「预算耗尽」：实为达步数/时间预算被中途掐断、只写回部分结果，
  并非该方向已探尽（易被误读为无需再探）。
- blocked「被拦截」→「执行出错」：实为模型/API/网络故障重试用尽、意图基本没真正探成，
  并非目标/WAF 拦截。
- 补上缺失的 stopped「已停止」（用户手动停止的 work）。
 2026-09-09 12:59:48 -04:00
pphua 9793b522d9 feat(tasks): add inherited context and resilient LLM execution 
Add read-only task context inheritance, ordered task-level LLM failover, live Worker controls, cascading task cleanup, FIFO task concurrency, cancellation diagnostics, UI updates, tests, build script, and changelog.
 2026-08-20 18:34:24 +08:00
Autumn-27 8047bb7aca feat(tasks): 任务并发上限(可选,超限排队自动补位) 
任务页新建任务左侧加「并发设置」齿轮:开关(默认关) + 并发数量(开启默认5)。
开启后新建任务若「运行中」数已达上限,进入「排队中」不启动;有空位时后台
每 5s 自动把最早排队的任务补位启动。

- db: tasks 加持久化 queued 列(schema + ALTER 补旧库);Task.Queued/SetQueued。
- manager: ConcurrencyLimit/SetConcurrency(settings KV);SetTaskQueued(落库+同步内存)。
- 准入与促进器(goals.go):launchTask 统一准入,满则挂起排队;抽出 startTaskEngine
  复用;occupiesSlot/runningTaskCount/queueIfAtCapacity;reconcileConcurrency 每
  scheduler tick 补位(关闭则放行全部排队),concMu 串行化防超发;启动重载/setActive/
  reviveTask 三处'排队则不启动'门。
- settings: /api/settings 增 task_concurrency_enabled/limit;PUT 后立即协调一次。
- web: 齿轮 Dialog(Switch+数量);新增 queued/「排队中」状态(类型/状态色/筛选)。
- 超限只排队新任务,不打断在跑的;排队任务不消耗 LLM(目标拆解推迟到出队)。

go build/vet、tsc 通过;DB queued 往返测试通过。
 2026-08-19 10:05:01 -04:00
Autumn-27 ff3d41ea35 feat: 漏洞新增 severity=critical(严重) 与 name(漏洞名称)字段 
severity 严重级:
- report_finding 工具 severity 说明改为 critical|high|medium|low
- DB 排序 CASE、report 报告 sevRank、FindingStats 增加 critical
- 前端 Severity 类型、status.ts 新增 rose 色调(实心高强调,视觉高于高危)、
  发现页严重度筛选/统计卡、任务发现 Tab 排序、dashboard 汇总均加入严重

name 漏洞名称:
- findings 表加 name 列(schema + ALTER TABLE ADD COLUMN IF NOT EXISTS 补旧库)
- report_finding 工具新增 name 入参(非必填),写入 node payload 与独立 findings 行
- DBFinding/AddFinding/AddStandaloneFinding、FindingDTO、findingPayload、report 全链路透传
- 发现列表页与任务发现 Tab 展示 name,为空时回退 vulnclass;vulnclass 移到展开详情「类型」
- report 报告标题优先 name,回退 vulnclass

无 CHECK 约束,旧库仅需补 name 列;critical/name 均向后兼容。
db 测试补充 critical 排序/统计与 name 往返断言。
 2026-08-18 11:21:08 -04:00
Autumn-27 7b3eec2166 feat: 发现处置状态扩展为 8 个 
在 待处理/误报/忽略/已处理 基础上新增:
- in_progress 处理中(已受理、修复/验证中)
- confirmed 已确认(真实漏洞未修复)
- duplicate 重复
- risk_accepted 风险接受(确认存在但业务接受)

改动:db 常量 + ValidFindingStatus 白名单、schema 注释、status.ts 色板/文案、
types.ts 联合类型、两处下拉的 FINDING_STATUSES(下拉与状态筛选自动带出)。
状态无 CHECK 约束,旧库无需迁移。
 2026-08-18 10:37:13 -04:00
Autumn-27 05f0b69469 feat: finding 增加处置状态(待处理/误报/忽略/已处理)+ 发现列表页改版 
- findings 表新增 status 列(默认 pending),schema.sql 同步 ALTER TABLE 补旧库
- 新增 PATCH /api/exploration/findings/{id} 更新处置状态,server 侧白名单校验
- FindingDTO 增加 status/finding_id/assets(后端预渲染资产 label)
- 任务内发现节点通过 node_id 关联独立 findings 行,复用同一处置状态
- 发现列表页:漏洞名称(类型主 + 摘要小字)、新增资产列与状态列(可下拉修改)、状态筛选与待处理统计
- 任务详情发现 Tab 同步展示/编辑处置状态与绑定资产
 2026-08-18 09:46:46 -04:00
Autumn-27andClaude Opus 4.8 0ef8561411 chore: ARTEX 初始化 
ARTEX — AI 自主渗透测试系统（Go 后端 + Next.js 前端，单二进制内嵌）。

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
 2026-07-26 04:27:45 -04:00