不用精通，但得读得懂：安全这行为什么绕不开编程

原创

Sink
Sink

船山信安

2026年9月20日 17:17
湖南

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

工程观察 · ENGINEERING

不用精通，但得读得懂：安全这行为什么绕不开编程

开发视角 · 写给学安全的人

这个问题我被问过很多次，答案一直没变：不用精通，但得读得懂。不是让你去写几万行的系统，是让你在工具跑不出结果、在报告需要说清\"改哪里\"的时候，不至于只能点头。先把数据摆出来，比讲道理有说服力。

01招聘在考什么：Python 41%，渗透测试 14%

先看一份 2026 年针对 Cybersecurity Engineer 岗位的 JD 统计。它把技能按出现频率分了三档，其中\"常见要求\"这一档是这样排的：

同一份统计里还写着一句话，我觉得比排名更值得琢磨：没有任何一项技能出现在超过一半的岗位里。作为对比，软件工程岗位里 Python 出现在 70% 以上、SQL 在 71% 以上。

安全岗位的要求是分散的，但\"自动化 + Python\"是最稳定的一对：两者的共现提升度是 1.49，意思是要求\"自动化\"的岗位，比随机概率高出 49% 会同时要求 Python。这两者其实是一个信号。

再说一个更底层的事实。NIST 的《网络安全人才框架》（NICE Framework，SP 800-181 Rev 1）里，\"安全供给\"大类下专门设了一个 软件开发（DEV） 特殊领域，下面挂着 Software Developer（SP-DEV-001）和 Secure Software Assessor（SP-DEV-002）两个岗位角色。也就是说，在这个沿用最广的人才标准里，写代码本身就是网络安全人才的一个正式类目，不是加分项。

口径提醒：不同机构的统计差异很大。另有基于 2025–2026 年招聘的统计给出 Python 58%、渗透测试 45%；SpecOps 对 Indeed 上 843 条职位的统计则显示\"编码经验\"仅占 11%、渗透测试 14%。差异来自岗位层级与统计方法。趋势是一致的：越往中高级、越靠近甲方建设类岗位，编程权重越高。

02第一堵墙：工具跑不出结果的那天

有位从渗透转安全开发的人，把自己的经历写成文章发出来了。第一个任务是做内部漏洞扫描插件，他的做法很典型：找开源的 POC，改一改，能跑通就行。

两个月后交付——支持 20 多种漏洞检测、并发 500、输出漂亮的 HTML 报告。他自认为很牛。

测试团队第一天就打回来了。原因很朴素：扫一个目标要 15 分钟，人家有 100 个目标，跑完要 25 个小时。根本没法用。

除了慢，还有两条更致命：扫出来的漏洞没有做利用验证，全是误报，测试人员一个个手工确认，比不扫还累；报告字段花里胡哨，唯独没有修复建议，运维拿到不知道该改哪里。

这三个问题——性能、误报、不可执行——没有一个是安全知识能解决的。它们是软件工程问题：并发控制、结果验证、输出设计。

他后来总结了一句我认为很对的话：安全工具首先是\"工具\"，其次才是\"安全的\"。

03第二堵墙：读不懂别人的代码

黑盒测试的天花板，是你只能猜后端长什么样。猜对了是运气，猜错了就是漏。白盒不一样，你能看见\"它为什么会写成这样\"。

这一点上，写过程序和没写过程序的人，读代码的方式是两套：

举个最常见的例子。一个查询接口，前面把身份校验做得很规范：token 校验、过期判断、失效重登，一样不少。然后拿着这个身份直接去数据库取数据了。中间没有任何一行问过：这条数据是这个人的吗。

这是典型的越权。它没有任何危险函数，没有任何可疑关键字，扫描器扫不出来。你要看出来，唯一的办法是读懂那三四十行代码在干什么——而\"读懂\"这件事，前提是你自己写过。

同样，做白盒审计时你要跟踪用户输入从入口到敏感函数的整条数据流，判断中间有没有过滤、转义、预编译。这要求你知道框架的参数绑定是怎么做的、ORM 的查询是怎么拼出来的、中间件的执行顺序是什么。这些没有一样是工具能替你看的。

ONE LINE
       精通是给开发岗位的要求。熟悉，是给你自己留的退路。

04第三堵墙：你说不出\"改哪里\"

这份工作里，最容易被忽略、也最见功力的一环，是报告的最后一米。

差别不在措辞，在于你能不能落到一处 diff 上。你说\"建议修复\"，开发听到的任务是模糊的；你说\"147 行，改成 132 行那个写法\"，他的任务是确定的。

而能给出这种建议的前提，是你知道 132 行的写法叫什么、为什么好。这又是编程。

05要熟到什么程度：四个\"能\"

先把心理负担卸掉：你不需要写几万行的系统。公开分享里有人给过一组经验值（不是精确统计，但和我的体感一致）：

域名爬虫的核心逻辑：20 行
     一个能用的内网扫描脚本：50 行
     单个漏洞的验证脚本：30–80 行

这些代码不需要你懂装饰器、元类、异步 IO。requests 加标准库，够解决八成的自动化需求。

具体要熟到什么程度，我的标准是四个\"能\"：

1能读

拿到一份陌生语言的代码，能找到入口，能把数据流跟到终点。

2能改

开源 POC 跑不通，你能自己把它改通——改编码、改协议、改适配，而不是换一个脚本重试。

3能写

用三五十行，把一件之前手动做的事自动化掉。

4能说清

告诉开发改哪一行、改成什么、旁边有没有现成的正确写法。

06一段能直接改的骨架

单个漏洞的验证脚本，拆开就是四段：目标输入、构造请求、发送、判断结果。下面这个骨架不到四十行，四个部分都在，换个 payload 和判断条件就能复用：

import requests, argparse from concurrent.futures

import ThreadPoolExecutor

def check(target, timeout=8):

# 1. 构造：payload 单独放，改漏洞时只动这一处

 url = f\"{target.rstrip('/')}/api/export\"

payload = {\"filename\": \"../../etc/passwd\"}

try:

# 2. 发送：一定带超时，别让一个死连接拖垮整批

r = requests.post(url, json=payload, timeout=timeout, verify=False)

 except requests.RequestException as e:

return target, \"ERROR\", str(e)[:60]

# 3. 判断：不要只看状态码，要看响应内容特征

if r.status_code == 200 and \"root:\" in r.text:

return target, \"VULN\", f\"{len(r.text)} bytes\"

return target, \"SAFE\", f\"HTTP {r.status_code}\"

def main():

ap = argparse.ArgumentParser()

ap.add_argument(\"file\", help=\"每行一个目标\")

ap.add_argument(\"-w\", \"--workers\", type=int, default=10)

args = ap.parse_args()

targets = [l.strip() for l in open(args.file) if l.strip()]

 # 4. 并发：先 10 个，别上来就开 500

with ThreadPoolExecutor(max_workers=args.workers) as pool:

for t, verdict, detail in pool.map(check, targets):

print(f\"[{verdict:5}] {t}  {detail}\")

if __name__ == \"__main__\":

main()

这段代码里真正值钱的不是语法，是四个细节：超时、异常兜底、并发收敛、判断看内容不看状态码。缺任何一条，它跑一百个目标就会出一次洋相——而这正是上一节那位同行的第一课。

07三个月怎么走

公开分享里有一条路径，我按自己的经验微调过。前提不是每天看两小时视频，而是每天至少写五十行：

两个必须避开的坑。

别等\"学完了\"再写。看两天语法就开始抄例子、改例子。边写边查的效率，比干看高得多。

别只盯着漏洞，忘了可观测性。那位同行后来做的 WAF 规则引擎上线后 CPU 动不动飙到 100%，却没有任何日志——他最后是靠在关键函数里加 print(time.time()) 一行行定位的。安全工具多半是 7×24 跑的底座组件，日志、指标、告警是必修课，不是附加题。

这行里，工具会替你跑，但不会替你判断。工具说\"这里有漏洞\"，你得知道依据是什么；工具说\"这里没问题\"，你得知道它漏掉了什么。

而判断这件事，只对读得懂代码的人开放。