敲完《苍穹外卖》，我更加确信：网络安全人员必须熟悉开发
在近期赶项目进度、持续进行功能开发的过程中，我对“安全与开发之间的关系”产生了更加深刻、也更加笃定的认识：
安全的基础，是开发。
如果在不了解开发的前提下学习安全，就如同尚未学会行走便尝试奔跑。短期内或许可以模仿一些动作，但一旦进入复杂场景，问题便会立刻暴露。
不理解开发，安全往往会走很多弯路
不少人在学习安全时，习惯从“漏洞类型”入手：
SQL 注入、XSS、SSRF、反序列化、逻辑漏洞……
但当真正开始挖掘漏洞时，往往会遇到一个现实问题：
你知道漏洞的名称，却不知道它为什么会出现在这里。
而这个“为什么”，恰恰隐藏在开发者的设计思路之中。
当真正参与过功能开发之后，思考视角会发生明显变化。你会开始站在开发者的立场，重新审视系统本身：
- 这个功能是如何一步步被设计出来的？
- 哪些参数处理是为了赶进度而被简化的？
- 哪些逻辑在“理论上安全”，但在实现时被弱化了？
- 哪些细节在测试阶段几乎不会被认真关注？
这些地方，正是漏洞最容易滋生的土壤。
漏洞，往往诞生于开发者的“妥协”
这一点在实际开发中尤为明显。
大多数主流框架，本身都提供了相对规范、完善且安全的实现方式。然而问题并不在于“没有安全方案”，而在于——
安全的写法，往往更复杂、更繁琐，也更耗时。
一个极为常见的现实场景是：
- 官方文档建议使用规范方式进行参数校验、权限控制或数据绑定；
- 实际开发中，为了效率，选择“自己简单判断一下”。
功能可以正常运行，需求也如期上线，但安全性往往正是在这一刻被“省略”了。
而攻击者所做的事情，其实并不复杂：
将你在开发过程中省略的那一步，反向利用。
因此，许多漏洞并非源于开发者完全不懂安全，而是——
他们了解安全，却在现实压力下选择了妥协。
理解开发之后，漏洞会变得“显而易见”
当具备扎实的开发经验后，挖漏洞的方式会发生本质变化。
你不再只是机械地问：
“这个站点有没有 SQL 注入？”
而是会自然地思考：
“如果我是开发者，这个功能我可能会在哪一步偷懒？”
例如：
- 表单校验是否只存在于前端？
- 权限校验是通过统一中间件完成，还是在某些接口中单独实现？
- 文件上传功能是严格限制，还是为了快速交付而简化？
- 某些内部接口，是否默认“只有内部人员才会调用”？
这些问题，往往只有真正写过业务代码的人，才会下意识地提出。
为什么很多安全从业者同时也是优秀的开发者
安全领域中有一个并不总被新手接受的事实：
真正成熟的安全从业者，往往具备很强的开发能力。
甚至，许多人本身就是从开发岗位转型而来。
原因并不复杂：
- 熟悉开发，才能读懂源码；
- 理解开发，才能看清业务逻辑；
- 了解开发过程，才能明白漏洞是如何被“写出来”的。
从某种意义上说，安全的本质正是：
站在开发者的对立面，完整而深入地理解开发者。
写代码，是安全成长绕不开的一步
这对我而言，是一个非常重要的提醒。
在未来的学习过程中：
- 不应只停留在漏洞 payload 层面；
- 不应只依赖工具与现成 PoC；
- 更应主动编写真实的业务代码。
哪怕只是实现一个简单的 Web 项目，也足以让人产生新的认知：
“原来，漏洞是这样产生的。”
当有一天，你在写代码的同时，会下意识地思考：
“这个地方如果被人盯上，可能会出问题。”
那意味着，你已经不再只是“学习安全”，
而是真正开始在理解安全，实践安全。