01
安全验证
对网站、应用、API、基础设施和外部攻击面进行授权发现与测试。
7
从决策到结项的受控阶段
1
测试前的授权关卡
PDF + SARIF
适用时提供可移植结果
1 次复测
对已报告修复进行明确验证
// 评估流程
一个受控流程。每个阶段职责清晰。
该流程尽早消除歧义，保留可追溯的证据链，并将专家精力集中在真正重要的安全决策上。
01 / 范围决策
decision
确定哪些内容需要安全保证。
我们从业务决策出发，而不是按 endpoint 数量计算。产品发布、客户要求、关键业务流程或合规期限决定最小且可信的评估边界。
// 您提供
- 说明产品、决策目标和期限
- 确定最重要的业务流程
// Kotav + Argus
- 推荐满足需求的最小服务范围
- 指出会改变边界的复杂因素
结果
在确认商业范围前，形成清晰的评估类型、交付目标和初始边界。
示例展示 — 不含客户数据
范围选择器
01
Website
Public surface
€250
02
Web application
App + API
已选择
03
Full application
Roles + logic
扩展
建议边界1 app · 1 role · primary API · 3 workflows
02 / 安全信息收集
scope
将产品转化为明确的评估范围。
引导式信息收集准确记录应用、API、角色、流程、环境和排除项。完整性检查会在访问缺失或边界含糊演变为交付风险之前将其暴露出来。
// 您提供
- 提供资产、测试账户和关键流程
- 确认排除项和敏感操作
// Kotav + Argus
- 标准化资产、角色和访问路径
- 检查完整性并指出歧义
结果
形成可测试的范围，明确包含项、排除项和必要条件，而不是按 endpoint 数量销售。
示例展示 — 不含客户数据
项目 / 范围
2
assets
1
auth role
3
workflows
app.example.testWEB APP范围内
api.example.test/v2PRIMARY API范围内
CustomerAUTH ROLE已提供
Admin consoleSEPARATE APP已排除
Ambiguities resolved before any testing begins.
03 / 授权关卡
authorise
在执行前精确授权工作内容。
在 Rules of Engagement 获批之前，测试始终保持锁定。测试窗口、联系人、停止条件、数据处理方式和允许的技术都会记录在项目中。
// 您提供
- 批准 Rules of Engagement
- 指定技术联系人和紧急联系人
// Kotav + Argus
- 强制执行范围主机和测试限制
- 拒绝执行项目范围外的操作
结果
获得可追溯的授权记录，以及带有约定安全条件的受控测试窗口。
示例展示 — 不含客户数据
Rules of Engagement
授权关卡已通过
范围、测试窗口、联系人、排除项和停止条件均已记录。
Testing window
12–16 Aug · UTC
Emergency contact
Security lead on file
Data handling
EU-hosted evidence
Stop conditions
3 controls defined
04 / Argus 执行
run
映射、测试并保留证据轨迹。
Argus 映射已授权的攻击面，执行已认证流程并运行可重复的安全检查。每个候选信号都与目标、测试路径及产生它的原始证据保持关联。
// 您提供
- 保持授权访问可用
- 在缺少上下文时回答针对性问题
// Kotav + Argus
- 执行有边界的 Web 与 API 验证
- 采集可复现的候选证据
结果
形成结构化的信号、覆盖范围和证据队列，而不是未经筛选的扫描器导出。
示例展示 — 不含客户数据
Argus / 验证执行
CURRENT WORKFLOW
Invoice access controls
01:42:16
Authentication34 / 34
Authorisation19 / 25
Session controls11 / 19
Input handling16 / 38
116
checks
8
signals
2
review queue
05 / 专家审查
review
验证信号并测试业务影响。
专家复现重大候选问题、排除误报，并在需要人工判断时测试相关授权机制或业务逻辑。严重级别依据已验证的影响，而不是工具置信度。
// 您提供
- 必要时澄清预期行为
- 确认重要业务背景
// Kotav + Argus
- 保留可复现的证据链
- 支持聚焦的人工验证
结果
获得已验证问题，包括可信的严重级别、受影响资产、复现步骤、影响和可执行的修复建议。
示例展示 — 不含客户数据
专家审查
HIGHCWE-639 · BOLA
Cross-tenant invoice access
A tenant A session retrieved invoice metadata owned by tenant B after changing only the object identifier.
VERIFIED REQUEST
GET /api/invoices/tenant-b-id Authorization: Bearer [tenant-a-session] → 200 OK · ownerTenant: tenant-b
Reproduced Impact confirmed False positive removed Fix reviewed
06 / 结果交付
deliver
为工程团队和决策者交付结果。
问题通过门户交付，并附有按优先级整理的证据和修复建议。交付包可包含管理层视图、技术细节、已验证证据、SARIF 和适用于审计的报告。
// 您提供
- 分配负责人并更新修复状态
- 在工程和 GRC 流程中使用证据
// Kotav + Argus
- 保持问题与其证据的关联
- 生成经专家审查的可移植结果
结果
获得可直接使用的交付包：专家审查报告、已验证证据、修复优先级，以及适用时的 SARIF。
示例展示 — 不含客户数据
结果 / 问题
1
critical
2
high
4
medium
9
verified
HIGHCross-tenant invoice accessOPEN
HIGHRefresh token remains valid after logoutOPEN
MEDRate limit bypass on exportACCEPTED
专家审查报告
07 / 复测与结项
retest
验证修复并以证据完成结项。
在明确的复测窗口内，已报告修复会按照原始复现路径重新测试。已验证、未解决和已接受的风险保持区分，使最终状态清晰可见。
// 您提供
- 修复就绪后通知 Kotav
- 记录已接受或延期的风险
// Kotav + Argus
- 重新执行相关验证路径
- 更新证据和问题状态
结果
形成结项记录，清楚显示已修复内容、遗留问题及支持每个最终状态的证据。
示例展示 — 不含客户数据
复测 / 结项
之前
7个未解决问题
复测后
6项修复已验证
Object ownership enforced已验证
Logout invalidates refresh tokens已验证
Export throttling风险已接受
// 您将获得
一条证据链，多种实用输出。
同一项已验证问题既可支持工程修复，也可支持管理层风险决策和审计沟通。所有结果都与范围、授权、复现和复测状态保持关联。
交付包 / v1.0
specialist-reviewed-report.pdf
Executive + technical detail
verified-findings.sarif
Portable engineering output
evidence-pack/
Requests, responses and reproduction
remediation-notes.md
Prioritised developer guidance
证据链完整
范围 → 测试 → 审查 → 问题 → 复测
// 每个产品一份记录
三个保障时点，共用一条证据历史。
Runtime 测试已部署系统；AppSec 检查选定的代码变更；当公开威胁信息发生变化时，Sentinel 会重新评估已保留的证据。任何主动测试仍须基于已授权的项目。
02
AppSec
通过不可变 commit 标识和客户控制策略，保障代码仓库与拉取请求。
03
Argus Sentinel
12 个月验证计划，包括计划内 Argus runs 和有限人工复核。不是 SOC、不是 24/7 监控、也不是 incident response。人工时间用于重大 findings、季度 risk review 和每年两次聚焦手工测试窗口。
