互联网与软件技术
├── 业务研发主线（前端／后端／客户端）
├── 质量与稳定主线（测试开发／SRE）
└── 平台与治理方向
├── 安全工程师 ← 本篇
├── 架构师
└── 技术项目经理（TPM）
定位一句话：安全工程师的工作是"假设一定会有人来攻"，在系统上线前尽量把漏洞找出来堵上，在上线后持续监测是否已经被攻进来——它的产出不是功能，而是"没有出事"。
在平台与治理方向中的位置：与架构师、技术项目经理同属"横向治理"类角色——不直接交付业务功能，而是为所有业务线提供约束与保障。这决定了这份工作的一个天然难点：它的价值很难被看见。功能上线了大家看得见，漏洞没出事没人记得；只有当事故真的发生，安全的重要性才被瞬间放大。理解这一点，是理解这份职业节奏与心态要求的前提。
一句话定义：安全工程师负责在研发与运行体系中建设并运营安全能力，包括漏洞的发现与修复推动、攻击面的收敛、权限与身份体系的加固、安全事件的监测与响应，以及把安全要求嵌入研发流程，使业务在可控风险下持续迭代。
职责边界（五类日常）
一、漏洞发现与治理
这是外界最熟悉的一块，也是新人最容易产生误解的一块：以为发现漏洞就是全部。真实的闭环是五步，发现只占第一步。
- 发现：对 Web、App、接口、内网系统做安全测试与代码审计；此外还有依赖与开源组件的漏洞扫描、配置与基线核查、外部漏洞情报的跟踪。渠道是多元的，单靠人工测试覆盖不了全部攻击面。
- 定级：同一个漏洞在不同业务上的严重程度完全不同——一个能读到别人订单信息的缺陷，在演示环境里是小事，在有真实交易与用户数据的系统里是最高优先级。定级要综合"能否被利用、利用难度、影响面、是否已有公开利用方式"，而不是照搬漏洞扫描器给的分数。
- 推动修复：这是整条链上最需要软技能的一步。业务团队有排期、有上线窗口，安全提出的修复会占用资源。能不能把技术风险翻译成业务能听懂的语言，直接影响修复是否被排上——"这个接口可以越权读取其他用户数据"比"存在水平越权漏洞"有效得多。
- 回归验证：修复后要复测确认真的堵上了，且没有引入新问题。
- 台账闭环：形成漏洞台账，记录状态、责任方与时限，定期复盘"哪一类问题反复出现"——反复出现的类型，说明流程或规范有缺口，而不是开发者不小心。
二、研发流程内嵌
安全如果只在上线前设一道关，结果一定是"上线前一周批量卡壳"。成熟做法是把要求拆散，嵌到流程的各个环节：
百科资料数据截止：2019-05