从软件生命周期看应用安全（网络安全）

历史车轮滚滚向前，时代潮流浩浩荡荡，社会不断地发展、演进，积累的人类宝藏（知识储备）越来越多，随着知识量的增加，人们越来越不能做到全知全能，逐步的开始根据能力、爱好、特长等等，进行职责的划分，各行各业，各式各样的生活方式不断涌现。

软件发展也是如此，随着科技的不断发展，软件与硬件的相辅相成互相促进，从最初的机器码“大佬”，到汇编语言“大牛”，从面向过程到面向对象的范式演进，从基础的 OO 到 DDD 的发展，从单体应用到微服务，随着业务规模的急剧膨胀，人机交互诉求越来越复杂，软件代码规模指数级增长。

代码量的提高让我们最终产品的可能暴露出的安全隐患越来越多，让我们从应用的生命周期来看一看，软件一生中的每一步可能会涉及到的安全问题。

（个人理解，非安全领域的小猿，若有不当、不到位之处欢迎指出）

Predefine

从本文标题来看有三个关键词，应用、安全、软件生命周期

何谓应用

我想说软件安全，也想说网络安全，还想说产品安全，但我感觉可能应用更合适一些，因为总感觉生活中用到的软件、网络、产品这些词都像是再说我们作为“产品受众”来说所直接接触到的东西，当然也许我用应用也并不合适。

我认为的应用是：一切独立的可提供功能的被独立编译出来的文件。

无论是动态链接库、可执行文件、藏在容器里不知道自己还有兄弟姐妹的软件、虚拟机里以为这就是整个世界的程序、手机的一个 APP、浏览器看到的那个页面、嵌入式设备里容易被忽视的那些不间断运行的代码、设计出来的专用芯片中深入骨子里固化的逻辑……

无论他们是何种形态，都在独立的默默付出，或者协作着搞事情，但从软件的世界来看，就算独立的软件他们也在以“社会”这个中间媒介间接地交流着

为什么括号里再写个网络安全？可能现在不写网络，受众会很小吧

何谓安全

安全，我认为不止局限于是否能够抵御非正当的入侵手段，还应该能够做到在大量的正当行为同时发生时能够争取的有条不紊的处理（高并发情景）。

除此以外，在突发情况下（设备故障等），能够将手头正在做的事情适当的正确处理，以便于转交他人或事后完成（分布式事务）。

再除此以外，对于事实，无论何时我们都不应撒谎（幂等，最终一致性）

还可以再……

总之，作为一个应用，理应提供持续、稳定、正确、精准的价值输出。

何谓软件生命周期

哦，写到这我才发现写错了，准确来说按照我的定义要讲的是应用生命周期，nevermind……我相信认真读到这里的你并不介意，我要说的生命周期就是一个应用的

一个软件或者说产品的开发过程，可能会随着业务的膨胀逐渐的分割成多个微服务，或者多个 lib，以控制每个应用开发者需要掌控、理解的代码规模，但是这个复杂过程我讲不出来呀……让我们只看一个应用吧^.

一个生命从出生到死亡，他经历了孕育、诞生、生长、成熟、衰亡。从没有意识的“任人摆布”，到一脸懵逼的看到新世界；从对社会充满好奇心的探索，到看破红尘的淡然；在时代浪潮中拼命前进，从一个弄潮儿逐渐变得力不从心，最后挥一挥衣袖不带走一片云彩。

软件生命周期也是如此，当有一个新的 idea 后，我们决定搞起来；当自我感觉良好的时候，让他跑起来……

让我们来一起养成一棵树，树种-树苗-大树-树林-森林，来看看树生何其艰难险阻！

孕育 - 请给“树”一个好的基础

OK，我们要找一个树种了，为了让树种有很大的几率破壳而出，直达云霄，我们需要找一个好种子，并勤奋的浇水施肥，为新生命的到来做好充足准备。

如同生命成长需要能量一样，一切应用都是由代码组成的，一个“茁壮”的应用一定要有良好的代码基础。

单人种树-艰辛也省心

版本管理系统(VCS)：单人开发的时候，也需要记录我们开发的经历，就如同我们对树种孕育的各个阶段都有所研究一样，我们必须要记录代码的成长 / 扩张过程，否则无法回顾 / 审查历史代码，这时候就需要用，比如Git 、SVN 等。(link: https://en.wikipedia.org/wiki/Version_control)

历史不可磨灭：版本管理系统一般以有向无环图(DAG)等手段，保证代码的历史不可被篡改(link: https://en.wikipedia.org/wiki/Directed_acyclic_graph)

GPG秘钥：树到底属于谁？自己的树只能自己浇水。那么就需要证明浇水的人是自己了，可以通过一系列 token 手段，告知 VCS 我是谁。(link: https://en.wikipedia.org/wiki/GNU_Privacy_Guard)

多人种树-众人拾柴火焰高

代码审查：健康茁壮的成长，我们要保证代码的质量，这时候就需要进行 code review，除此以外，当多人开发的时候，任何人都能轻易地改变代码，此时可以考虑使用类似于 Github pull request 的确认流程，使“浇水”的过程互相认证，以降低隐藏很深的漏洞。

站在巨人的肩膀：在无特殊要求的情况下，尽可能的使用已有的轮子，依赖成熟、主流、正确的库 / 框架，可以极大地减少项目代码规模，少写点 bug。(写着写着就收到了这么贴切的事件：https://www.zdnet.com/article/two-malicious-python-libraries-removed-from-pypi/)

一定要注意“正确的”库 / 框架，也许我们信任某个主流的库，但是引用错了，那真的会是一个隐藏在无限深处的坑。(link: )

包完整性校验：好不容易找到个喜欢的东西，我相信谁也不希望半路被掉包。一般认为是 HTTPS 的远程仓库，但实际上不一定靠谱，若使用 https，请先人工确认我们使用的远程库是可靠的（或者说是知名的吧），毕竟 CA 证书只能保证链路中的安全性，无法保证源头。(link: https://www.gnupg.org/gph/en/manual/x135.html)

There are over 400 “Certificate Authorities” who may issue certificates for any domain. Many have poor security records and some are even explicitly controlled by governments. (link: https://whydoesaptnotusehttps.com/)#

团队种树-持续成长

当团队足够大，我们需要保证小树苗持续的成长。

CI/CD：持续集成、持续部署/交付，先让我们看看下面的过程(link1: https://en.wikipedia.org/wiki/Continuous_integr