SDL一些思考

SDL简述

SDL主要是起防御的作用，SDL是一种方法论。

项目生命周期设计的各个阶段，都可以实施SDL。

挑战

周期比较长的项目。

项目周期越来越短，比如敏捷开发。

随着公司业务发展，产品线越来越多，需要越来越多的人力，效率，以及工程化的东西来支撑。

安全团队也要考虑工具化、自动化的措施来解决效率问题。

可能需要重构来解决业务发展带来的问题。

不是所有项目都适合SDL，项目周期长的项目，产品线少的公司，在实施和落地SDL的时候，相对轻松。

推动SDL的困难

• 项目周期越来越短

• 业务体量：覆盖面、工程化

• 开发技术栈比较多，需要适配多个环境，需要去考虑。

  • C++
  • python
  • go
  • react

做安全可以一拱一卒，去做就好了，每天去做，到时间就会有一定的成功，需要有实践的精神在

SDL误区：

急于求成，看到其他公司在做SDL，其他场景别人做得比较好，我也想去做，也想达到同样的效果，但是对预期的时间和投入可能会估计不足，再一个SDL是跟企业的场景、环境紧密相关的，不同的环境，不同的场景，不同的困难，有不同的坑需要填平，那么想把其他公司或其他场景照搬过来，是不现实的。其他人成功的案例，或者解决问题的方法和思路是可以借鉴的，千万不能照搬，否则不但不会成功，反而会引进来更多的坑。

总结来说就是企业的基因和状态不太一样，所以不一定能走得通，所以还是要根据自身的情况，来借鉴别人的这一种方式。

SDL与业务共舞

安全是为业务赋能的，SDL又如何与业务实现共舞呢？

安全是为业务保驾护航的，要将安全做成业务的一种属性。与业务和谐共舞，安全肯定不是给业务找麻烦的，是为业务良性发展做安全保障。这个过程中确实会给业务带来麻烦或问题，这也是没有办法避免的，因为如果业务不存在这些风险，那么安全也没有必要去做了。安全就是要将业务中的风险规避掉，纠正掉，正因为如此，才会要去做一些安全的事情。

两点建议：

公司内部可能是需要有一个良好的安全氛围，氛围的建立，需要一些安全规范，或一些安全活动来建立。有对安全的一个认知，那么大家对安全都是有义务，有责任的，形成一个安全共建，共建安全，让大家合力的这样一个氛围。

安全人员就是跟业务线的同学，沟通工作的时候，要本着一个对业务负责，然后有时候换位思考，在业务线同学的角度考虑问题，尽量避免一些没有必要的负面情绪和冲突，做好和业务线同学的沟通工作。

以上这两点是相辅相成的。

中小企业SDL的落地方案

小企业业务线少，场景单一，这是比较好入手的一点。整个安全行业来说，中小企业的话，经常存在一个人的安全部，一个人的SDL这种情况，从SDL建设的角度，优先做一些投入产出高的东西，大家都安全的印象和感觉是比较好的，能让公司和同事看到安全部门是能够给公司带来收益的，看到你做了什么事情。

落地的时候，无论大还是小公司，需要有卡点（抓手），这样在落地的安全的要求，能够比较好实现。小企业的业务线少，需要应对的量也比较小，那么研发场景，比如CI/CD，需求系统都是比较单一，那么就可以用开源或者免费的半自动化，或者自动化的工具去做，因为小企业不光安全部门，包括运维部门，开发部门，都会去考虑一些开源的工具，这些工具在社区的时候，本身也会去考虑或关心一些安全的东西进去，比如devsecops，安全的开源工具会慢慢的多出来，小企业慢慢的都可以从零到一实现安全的相关需求。

SDL推动落地经验和总结

推动落地差不多就是上面说的这些，其实SDL不光是技术问题。在做SDL的过程中，也有一段时间了，需要解决的一些技术问题，场景或者工具、阶段大家都比较清楚，除了这些技术问题，比如说公司内部人员，文员都要去满足，解决一些挑战。

1. 沟通认可，就是上面说的，将SDL落地到某条业务线，一定要让该业务线的同事对SDL有一定的概念，认知和认可，他们才能配合你来做这些事情。
2. 一定要明确我们安全部门或SDL要做什么，需要业务或对方人员做什么，需要配合我们怎么怎么做，这些都要梳理清楚，明确的给到对方，这样对方才能知道怎么配合我们。需要对方去做的事情，一定要简单明了，不要给对方带来负担。
3. 自动化，devops都是在讲这件事情，提高我们安全的效率，要跟上公司当前CI/CD的节奏，或者跟上公司大型项目的节奏，比如是敏捷开发，就要跟上敏捷开发的节奏。要跟上这些事情，单靠敏捷开发是不可能实现的，一定要通过一些自动化才能实现。

总结就是：沟通的话，通过工具化，工程化，来解决效率方面的问题。

总结

安全不仅仅是一个事后的防御，仅仅是在业务上线后，部署一些设备，出台一些防御策略，更是一个事前和事中就将安全融合进去，做到真正的同业务结合起来，做到未雨绸缪。