This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
OWASP Secure Software Development Lifecycle Project
- Main
- FAQs
- Acknowledgements
- Road Map and Getting Involved
- Related stuffs
- Sub-Projects
- Top 10 Practices
- Recent Updates
|
OWASP Secure Software Development Lifecycle Project(S-SDLC)
OWASP Secure Software Development Life Cycle Project(S-SDLC) is an overall security software methodology for Web and APP developers.
Software security has now become a wider concept other than network security. There is a developing common sense that creating secured enough software is not just about individual skills but also or even more on work flows-- Software Development Life Cycle. To achieve security requires to be involved in every phase of a Secure Software Development Life Cycle.
The project’s final goal is to help users to reduce security issues, and raise the overall security level from every stage by using the methodology. Description
OWASP Secure Software Development Life Cycle Project(S-SDLC) defines security software development process as well as guides, tools, checklists and templates of activities in each phase.
The delivery will contain(not final): • Introduction: S-SDLC frame • Training guideline: Providing Security Training System • Requirements Phase: Risk Evaluation Guideline, and Requirements Criteria Doc. • Design Phase: Security Design Review Guideline and Threat Modeling Guideline. • Implement Phase: Security Coding Guide(C/C++、JAVA、PHP，C#) • Validation Phase: Actives level, Security Testing Guideline • Release/maintenance Phase: Vulnerability Management and Incident Response Guideline Detail information is in below table of content:
Licensing
Creative Commons Attribution ShareAlike 3.0 License
The OWASP Secure Software Development Lifecycle Project materials are free to use. In fact it is encouraged!!! Additionally, I also encourage you to contribute back to the project. I have no monopoly on this knowledge; however, we all have pieces of this knowledge from our experience. Let's begin by putting our individual pieces together to make something great. Great things happen when people work together. The OWASP Secure Software Development Lifecycle Project materials are licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one. |
What is OWASP Security Principles Project?
OWASP Secure Software Development Life Cycle Project is an overall security software methodology for Web and APP developers. The project’s goal is to help users to reduce security issues, and raise the overall security level from every stage by using the methodology. Presentation
Project Leader
The OWASP Secure Software Development Lifecycle Project is developed by a worldwide team of volunteers. A live update of project contributors is found here. The first contributors to the project were: Related Projects
To be updated... Openhub |
Quick Download
News and Events
To be updated... In Print
Classifications
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
How can I participate in your project?
All you have to do is make the Project Leader's aware of your available time to contribute to the project. It is also important to let the Leader's know how you would like to contribute and pitch in to help the project meet it's goals and milestones. There are many different ways you can contribute to an OWASP Project, but communication with the leads is key.
If I am not a programmer can I participate in your project?
Yes, you can certainly participate in the project if you are not a programmer or technical. The project needs different skills and expertise and different times during its development. Currently, we are looking for researchers, writers, graphic designers, and a project administrator.
Contributors
The OWASP Secure Software Development Lifecycle Project is developed by a worldwide team of volunteers. A live update of project contributors is found here.
The first contributors to the project were:
- RIP (Sub-project Owner)
- Silver Zhang(Sub-project Owner)
- Kevin (Sub-project Owner)
- Xia Tianze (Sub-project Owner)
- Yu Kan(Sub-project Owner)
- Lance Li (Sub-project Owner)
- Wang Jie (Sub-project Owner)
- Bao Yuezhong (Participant)
- Ricky Xu (Participant)
Base on the current estimation, the roadmap of the OWASP Secure Software Development Life Cycle Project is below:
| Sub-Project Name | Purpose | RoadMap | Sub-Porject Owner and Participant | Output and Delivery | Ref |
|---|---|---|---|---|---|
| OWASP S-SDLC Project | OWASP Secure Software Development Life Cycle Project defines security software development process. This part of the project is an overview of the life cycle. | 2017Q3 | Project Owner：
RIP Kevin Yuezhong Bao Tianze Xia Project Manager： XuFei |
OWASP S-SDLC Project Introduction Doc and Slides | |
| OWASP S-SDLC Overall Flow | This part of the OWASP S-SDLC Project defines phases of the life cycle and give suggestions and best practices of adoption. | 2017Q2-Q4 | Kevin
Peter Xiao |
Best Practices of S-SDLC in Enterprises | |
| OWASP S-SDLC Security Awareness Training | This part provides guidelines of security awareness trainings. These trainings are to enhance the sensitivity of security of software developers. | 2017Q2-Q4 | Jie Wang | (1)Training slides
(2)Training Videos (3)Examples of examination questions |
(1)OWASP TOP 10
(2)OWASP MOBILE TOP 10 (3)OWASP IoT TOP 10 |
| OWASP S-SDLC Security Requirement | This part of OWASP S-SDLC aims to acquire security requirements by identifying the functional implementation, position in industry or general security requirements (eg, compliance requirements). | 2017Q2-Q4 | Tianze Xia | (1)Best Practices of S-SDLC Security Requirement
(2)Security Requirement Checklist |
OWASP Cheat Sheet Series |
| OWASP S-SDLC Security Design | This part of S-SDLC will guide to deliver a doable security design to the implementation team by considering potential technical security risks. So that by avoiding the early detections of security risks, the cost to build secure products is in control. | 2017Q2-Q4 | Lance Li | (1)Best Practices of S-SDLC Security Design
(2)Benchmark of OWASP security baseline (3)Threat Modeling Guide (4)Security Guideline for Common Components |
(1)Application Threat Modeling
(2)OWASP ESAPI |
| OWASP S-SDLC Security Implementation | The goal of this sub-project of OWASP S-SDLC are to:
(1) Let implementation teams do secure coding. The key is to let team understand security features of the language and framework they use, and obey the output of the S-SDLC security design (2) Let implementation teams identify and fix defects in legacy codes. The key is to adopt automated, efficient tech (eg. IAST) by providing guidelines and best practices. |
2017Q2-Q4 |
Kan Yu Ricky |
(1)Best Practices of S-SDLC Security Implementation
(2)Security Sriteria Checking Tool Sets for Coding (3)Guideline for OWASP Code Review |
(1)OWASP Code Review Guide Project
(2)OWASP Cheat Sheet Series |
| OWASP S-SDLC Security Test | Security testing is a process intended to reveal flaws in the security mechanisms of an information system that protect data and maintain functionality as intended
Typical security requirements may include specific elements of confidentiality, integrity, authentication, availability, authorization and non-repudiation. Actual security requirements tested depend on the security requirements implemented by the system. Due to the logical limitations of security testing, passing security testing is not an indication that no flaws exist or that the system adequately satisfies the security requirements. This part of the OWASP S-SDLC project will provide some best practice and useful tips of security testing to help a.) Beginners can start security test easily; b.) Professionals can use for reference. |
2017Q2-Q4 | Tianze Xia | (1)Best Practice of S-SDLC security testing
(2)Best Practice of OWASP Cheat sheet (3) Best Practice of OWASP ASVS |
(1)OWASP testing Guide
(2)OWASP Cheat sheet (3)OWASP Application Security Verification Standard Project (ASVS) |
| OWASP S-SDLC Security Deployment & SecDevOps | In this phase of the S-SDLC focus on security auditing before deployment and security monitoring. The sub-project will research on
(1) develop a appropriate security baseline for deployment and devops (2) the process of incident response and related tech. (3)SecDevOps |
2017Q2-Q4 | RIP | (1)Best Practice of S-SDLC security Deployment
(2)Best Practice of S-SDLC SecDevOps (3)Security Baseline for deployment and devops (4)OpenRASP |
OWASP AppSensor
OpenRASP |
Involvement in the development and promotion of the OWASP Secure Software Development Lifecycle Project is actively encouraged! You do not have to be a security expert in order to contribute. Some of the ways you can help:
- Helping find references to some of the principles.
- Project administration support.
- Wiki editing support.
- Writing support for the book.
This Page includes S-SDLC releated stuffs. Categorized as a.)Tools b.) Libraries c.)Technical Docs
Tools
- OpenRASP
OpenRASP is an open-source, free and self-adapting security tool made for OWASP S-SDLC Security Deployment & SecDevOps phase.
It can provide functions like threat detection, data stream monitor, quick-response to production by the deep integration of its protection engine.
Unlike other perimeter control solutions like WAF, OpenRASP directly integrates its protection engine into the application server by instrumentation. It can monitor various events including database queries, file operations and network requests etc.
When an attack happens, WAF matches the malicious request with its signatures and blocks it. OpenRASP takes a different approach by hooking sensitive functions and examines/blocks the inputs fed into them. As a result, this examination is context-aware and in-place. It brings in the following benefits:
1. Only successful attacks can trigger alarms, resulting in lower false positive and higher detection rate;
2. Detailed stack trace is logged, which makes the forensic analysis easier;
3. Insusceptible to malformed protocol.
OpenRASP FAQ
1. List of supported web applicationBelow table shows the recent updates of the project.Below tables shows recent updateBelow table shows recent updates.s. servers
Only Java based web application servers are supported for now. The support of other web application servers will also be soon included in the coming releases.
OpenRASP on the following application servers for both Linux and Windows platforms has been tested.
- Tomcat 6-8
- JBoss 4.X
- WebLogic 11/12
2. Performance impact on application servers
Multiple intense and long-lasting stress tests has been taken. Even in the worst-case scenario (where the hook point got continuously triggered) the server’s performance was only reduced by 10%
3. Integration with existing SIEM or SOC
OpenRASP logs alarms in JSON format, which can be easily picked up by LogStash, rsyslog or Flume.
4. How to develop a new plugin?
A plugin receives a callback when an event occurs. It then determines if the current behavior is malicious or not and blocks the associated request if necessary.
Detailed documents available on github.
- "INSIGHT" Platform
"INSIGHT" is a management platform developed by the Security Department of CreditEase which integrates Application system asset, Vulnerability lifecycle, and Security knowledge base.
- Application System Asset Management: managing assets of application system in the company, including system name, domain, senior level, department, and owner.
- Vulnerability Lifecycle Management: proceeding online submission, notification, verification, retesting, classification, risk calculation, repair deadline calculation, email reminder, and vulnerability data analysis for the security vulnerability found from application system in the company.
- Security Knowledge Management: implementing centralized storage, online learning, security training, and knowledge inherited of security knowledge and standard specification.
"INSIGHT" was developed by Python language and form of Flask framework & MySQL & Docker container.
Detailed documents available on github.
The concept of design
Application security activities begin with the risk assessment of the application assets. When the company accumulates more assets, it shall encounter increasing problems, such as unclear assets resource, miss of asset owner, the high cost of continuous of vulnerability tracking and difficulty of security knowledge penetrating, no data support for high-frequency risks, and failure of solving core problems, In addition, risk quantification is also a problem.
In the design of application security management framework, the general process of risk governance is as follows:
Based on the demands of the above risk governance, “INSIGHT" came into being.
Highlights
After the implement of "INSIGHT" system, we achieved the following goals. Please see the following picture:
Vulnerability history at a glance
Vulnerability tracking is methodical
Learning Cases can be found easily
Safety requirements are precisely controlled
Threats and risks are well-founded
Quantitative figures are known in real time
Libraries
To be added.
Technical Docs
To be added.
InfoSec Awareness Top 10 2018 Released
The InfoSec Awareness Top 10 2018 is now available. 《安全意识Top 10-2018》文档现已正式发布。
Top 10 Awareness for Most Critical Public Information Security Threats
This project is one of sub-projects for OWASP S-SDLC Project, aimed at the hot spot of the social public information security problems. By analyzing and proving the collected problems, we are endeavoring to arouse the basic information security awareness for public, and encouraging the general people could learn, understand and apply the foundamental information security controls by learning this Top 10 document. Ultimately, everyone is responsible for the infosec risk-free guarantee in the online society .
本项目为OWASP S-SDLC子项目， 旨在针对社会公众关注的热点安全问题，通过对安全问题的分析、案例演示，唤起公众对安全的关注，提升人民群众网络安全意识，了解和掌握网络安全防范方法，营造网络安全人人有责、人人参与的良好氛围。
Final Release
The Top 10 Awareness against Most Critical Public Information Security Threats shows as below.
| 1 | 利用漏洞攻击 |
| 2 | 信息泄漏事件 |
| 3 | 计算机病毒事件 |
| 4 | 木马事件 |
| 5 | 钓鱼事件 |
| 6 | 电信诈骗 |
| 7 | 网络设备监视及窃听事件 |
| 8 | 网页内嵌恶意代码事件 |
| 9 | 信息篡改事件 |
| 10 | 信息丢失事件 |
Project Team
- Project Leader: Jack Ding (Email:[email protected])
- Team Members:
- SecZone: Chuanyong Cao, Xiangxi Chen, Fei Xu, Jie Wang, Tianzhe Xia, Qingmign Zou
- Qingyuan Polytechnic College, Mentors: Hua Huang, Xiquan Guo, Bin Wang, Xianghui Chen, Zhicheng Liu
- Qingyuan Polytechnic College, Students: Kaitao Zhen, Junpeng Zou, Ronghua Chen, Haoliang Chen, Zijian Liu, Qiping Huang, Yuanhong Yu, Guanxiong Liang, Shaomo Huang, Junming Ma, Junjie Zou, Huixin Kong, Yaoguang He
- 项目牵头人：丁子桓（Email:[email protected]）
- 项目参与者：
- SecZone互联网安全研究中心：曹传勇、陈香锡、许飞、王颉、夏天泽、邹庆明
- 清远职业技术学院—指导教师： 黄华、郭锡泉、王斌、陈湘辉、刘志成
- 清远职业技术学院—学生团队：郑楷涛、邹俊鹏、陈榕华、陈浩亮、刘梓健、黄绮萍、余远宏、王春前、梁冠雄、黄邵模、马俊明、邹俊杰、孔慧欣、何尧光
Project Roadmap
| Phase | Date |
|---|---|
| Web site technology solutions
网站技术方案 |
June 13- June 23, 2018
2018年6月13日-6月23日 |
| Data Classification Standard
数据分类标准 |
May25- June1, 2018
2018年5月25日-6月1日 |
| Data collection 1
手动收集整理分类数据阶段1 |
June 2- June10, 2018
2018年6月2日-6月10日 |
| Data collection 2
手动收集整理分类数据阶段2 |
June 11- June15, 2018
2018年6月11日-6月15日 |
| Review categories and Website debugging
评审类别和网站调试 |
June 11- June20, 2018
2018年6月11日-6月24日 |
| Output-Secure Awareness TOP 10 Document
安全意识TOP 10文档 |
August 20, 2018
2018年8月20日 |
| Web Site on line
网站上线 |
August 23, 2018
2018年8月23日 |
Licensing
InfoSec Awareness Top 10 2018 is free to use. It is licensed under the Creative Commons Attribution-ShareAlike 4.0 license.
Attachment: Data Classification Standard
(Will provide English Version Later)
Please note that the following contents are currently in Chinese only.
1．企业必须自上而下推行S-SDLC实施，且有相应的组织结构支撑
企业要实施S-SDLC，单靠传统的信息安全部门或几个网络安全人员是不行的，必须由公司领导层至上而下去推行。之所以必须是至上而下推行，一个重要的原因就是S-SDLC的实施并不是只有信息安全部门投入就可以了。S-SDLC会与研发部门的各个环境深度结合，需要研发部门的积极支持和全体参与。另外，安全对于大部分企业而言，能直接看到的是成本投入增加，而产出收益却是隐性的，并不会因为做了S-SDLC就能看到产品的直接销售收益。
因此，不管是对于研发部门还是其他部门，都很难有主动实施S-SDLC的动力。微软在推行时，是由比尔.盖茨亲自发邮件要求员工停下手上所有的工作后才开始实施；而华为则是由CEO担任全球网络安全委员会主任来推行实施。也就是说，如果没有高层领导至上而下的要求，安全部门推行S-SDLC只会是一厢情愿。相信很多安全部门在推行S-SDLC时，都会遇到研发团队不配合而导致无法推行或推行效果不理想的情况。
有了至上而下的要求，企业还要有相应的组织结构支撑，而合理的组织结构是保障S-SDLC实施效果的基础。因为S-SDLC在实施过程中会产生大量新的工作内容和新的工作流程，而这部分工作内容和工作职责混乱不清，将直接影响S-SDLC的执行效率和实施效果。
2．S-SDLC要与企业的质量管理体系相结合
不少企业实施S-SDLC时，将S-SDLC作为一个独立的流程来操作。这使得企业需要投入大量额外资源来支撑S-SDLC整个流程的运转，且实施的质量得不到保障。因此，S-SDLC的实施效果往往达不到预期。 安全本质上是产品的一种质量属性。在质量管理领域，业界已有成熟的方法和流程，比如：ISO9001、CMM等级，这些都用来保障产品的质量。大部分企业都设置有质量部门，并设置有质量管理人员角色。但安全往往因为专业性强，缺乏成熟的管理方法和流程，再加上安全部门的存在，因此产品质量部门通常不关心产品的安全问题。
在S-SDLC落地的过程中，将安全工程活动标准化，并纳入产品的质量体系，是保障S-SDLC实施效果的基础。举个例子来说，当产品的某项安全指标没有达到要求时，质量部门有权否决产品的上市发布或上线运营。
3．建立合适的人员培训体系
在S-SDLC实施的过程中，安全不仅仅是软件安全专家的事，而是实施企业所有人的事。仅靠几个安全专家很难保证企业所有产品的安全质量，而信息安全部门或网络安全部门面对软件开发往往也力不从心。 S-SDLC虽然整体涉及软件产品的安全开发生命周期，偏重于方法和流程，但人的因素同样至关重要。对于同样的方法、同样的流程和同样的工具，如果实施人员的安全开发思想意识和技术能力不同，其产生的实施效果差异也会非常大。比如：某公司的安全部门要求所有口令都在hash后再存储，而开发人员就将口令设计成hash之后的结果，让人看了哭笑不得。
如何让所有研发人员都了解并关注软件安全开发？建立一套合适的培训体系是较好的业界实践。这里的培训强调的是体系化的软件安全开发培训，而不是安全部门内部组织的信息安全知识培训或攻防渗透技术培训，因为对于不同的部门、不同的岗位、不同的人员，其安全的认知意识和技术能力也是不一样的。 简单来说，建议将安全培训分成不同的等级，且不同等级面向不同类型的人员群体。比如：软件安全开发意识培训可以面向所有人、软件安全编码培训可只面向开发和测试人员，而网络攻击技术培训可只面向安全专业人员。另外，需要让所有研发人员宏观的理解S-SDLC方法与流程，有助于让每个研发人员认知其与S-SDLC流程中上、下游角色的互动关系，也有助于让每个研发人员理解每一个S-SDLC的工作环节对整体产品安全的重要性。
4．用度量体系将S-SDLC实施效果可视化
对于企业的研发高层领导来说，最关注的还是S-SDLC实施效果。如何让S-SDLC实施效果可视化，是S-SDLC实施过程中需要注意的重要问题。如果研发高层领导看不到S-SDLC的实施效果，那就意味着可能失去研发高层领导对S-SDLC实施的持续支持和资源投入，从而导致S-SDLC实施失败。 S-SDLC实施的效果本身就是隐性的。微软在这个问题上也没法给出立竿见影的效果，但今天Windows操作系统的安全性要比在S-SDLC实施前的Windows XP好多了，尽管今天的Windows操作系统还是有很多安全漏洞，但安全性的增强并不是简单地从漏洞数量上进行对比，而是漏洞发现的难度、漏洞利用的难度和漏洞被利用的影响都比之前有了明显的改善。
因此，作为S-SDLC实施人员，需要在实施S-SDLC前给研发部门高层领导一个相对合理的预期：世界上没有100%的安全，不能保证S-SDLC实施后就不会再有漏洞了；也不是实施了S-SDLC后安全就可以高枕无忧了。但这也并不意味着就完全看不到效果。 如何让S-SDLC实施的效果可视化，比较好的做法是建立一套度量体系，通过度量的方法让S-SDLC实施的效果可视化出来。度量体系本身也是一套复杂的工程，比如说业界的OWASP SAMM和BSIMM就是复杂的评估度量体系。实施人员可以选取一些比较直观且容易实施的工程活动，体现工程能力的成熟度提升，这个和软件成熟度CMM类似。另外，也要有结果性的数据，比如：可以对测试发现的安全问题进行分级，建立一个S-SDLC实施前的基线，再看S-SDLC实施后每一年的问题发展趋势。
5．产品的安全目标决定S-SDLC的过程
完整的S-SDLC包含众多的活动，而同样的活动在不同企业的投入弹性空间也非常大，以威胁建模为例，有的产品可能只花半天时间，而有的产品可能需要花一个月甚至更长时间。 在S-SDLC实施的过程中遇到过很多类似问题：这个活动需不需要做？这个活动需要做到什么程度？这个活动需求投入多少人？对于这些问题，并没有统一的答案。因为不同的产品所处的环境不一样，面临的风险也不一样。但我们可以给出基本的判断原则。 这些原则的基本出发点就是产品的安全目标是什么？安全目标说起来容易，但要说清楚，就不是一件容易的事了。很多专业的安全人员往往更多的考虑安全技术，而忽略了安全目标。技术应该是用来支撑目标的达成，所以当目标不清楚的情况下，很难判断一项技术的使用是否合理？这些技术是否足够？这就导致了很多企业当前的一个现象：安全的投入好像是一个无底洞，不知道什么时候才能做完。这显然不是企业领导者所要的结果。
因此，在实施S-SDLC的过程中，定义一个清晰的安全目标，才能使S-SDLC的实施过程更加科学合理。
6．威胁模型可以使产品避免大的设计风险
如果问S-SDLC实施过程中有什么过程是特别难的，OWASP S-SDLC项目组相信很多真正实施过的企业或专家都会将这一票投给威胁建模。因为威胁建模做得太浅则感觉没什么效果；而做的太深则导致实施难度和投入成本的增加。如何取得深浅之度的平衡是威胁建模的难点所在。 要解决这个问题，还得从威胁建模的本质说起。威胁建模的本质是建立产品的威胁模型。而需要通过威胁建模达到什么样的目的，不少安全人员的理解也不太一样。
根据OWASP S-SDLC项目组的实践经验，一方面希望专业的安全人员通过威胁建模发现更多、更深入的产品设计漏洞，以呈现威胁建模的效果；另一方面又希望这一过程能工具化，使普通的研发人员也能发现同样的问题。但通常实际的效果是：经验丰富的安全人员不通过威胁建模的方法就能发现该问题；而普通的研发人员即使用了威胁建模的方法，也发现不了该问题。
对于这一现象，并不是威胁建模本身出了问题，而是企业对威胁建模的使用以及目标预期出了问题，威胁模型的核心作用是通过模型化的方式来管理威胁、风险和对应的缓解措施。威胁、风险、缓解措施这三者相辅相成，S-SDLC中STRIDE威胁建模方法可以将大颗粒度的威胁结构化，从而避免了产品威胁模型遗漏了大颗粒度的威胁，保证了威胁的完整性；有了威胁就会有风险，有风险就需要根据风险来设计相应的缓解措施；这就是威胁建模的核心价值。而发现设计漏洞，实际上就是发现某个威胁没有相应的缓解措施或是缓解措施的设计BUG可以被绕过。
这里还有一点值得注意，就是所有的缓解措施都不能100%的缓解风险，缓解措施的目的是通过合适的成本将风险降低到一个可接受的范围内。
7．安全特性组件化可尽量避免编码漏洞
代码漏洞对于软件来说几乎是不可避免的，据数据统计，代码量与漏洞成正比。即便最早提出和实施方法论的微软，也不能保证代码百分之百没有漏洞。
漏洞问题对产品来说是最直观的（可直接利用），也是最头痛的（消灭不了）；代码漏洞也是S-SDLC需要重点解决的问题。目前多数也认识到这一问题，并选择使用代码扫描工具，例如SAST和DAST等，但这类工具存在致命的缺陷：误报和漏报。误报过多造成大量研发资源的浪费，而漏报过多又会使得工具的应用效果大打折扣。代码扫描工具的漏报和误报是必然存在的，S-SDLC中也有如何降低漏洞和误报的实践，但这更多需要依赖于新型的安全检测工具去解决。
从S-SDLC的整体视角上看，扫描工具只能发现部分已存在的代码漏洞，并不能减少代码漏洞的产生，属于“后端被动式”的解决思路。S-SDLC更关注如何减少代码漏洞的产生，也就是如何从“前端”主动解决问题。一个比较好的实践就是将产品中的安全特性组件化，比如：密码算法模块、认证授权模块，这些模块都是重要的缓解措施实现，一旦出问题就导致缓解措施被绕过的漏洞。因此，将这些模块组件化，让不同的产品在这些领域都使用公共组件，而不用自己开发，自然也就不会引入漏洞；而这些公共的组件则由安全专业团队重点保障。在微软，为了避免参数校验问题导致和缓冲区溢出问题，由专业的安全团队重写了经常导致漏洞的函数（如：memcpy、strcpy）,并由一系列自身带有安全校验的函数来代替。这一措施使得产品在很大程度上解决了缓冲区溢出的问题（虽不能全部解决，但效果显而易而，且投入成本不高）。
8．管理第三方软件的风险
不论是传统的软件企业还是新型的互联网企业，在软件开发的过程中都免不了要使用第三方组件。第三方组件既包含开源软件，也包含商业软件。而且随着软件越复杂，第三方软件的使用数量也越来越多。从安全的角度看，第三方软件也是一个重要的风险源（比如，前两年OpenSSL的漏洞集中暴发）。第三方软件不仅是产品集成的组件，开发环境中所用到的工具也要作为第三方软件来对待（XcodeGhost事件大家应该都还记得）。
第三方软件与自主研发的软件不一样。S-SDLC的方法和流程没法覆盖开源社区和第三方厂商。那么如何管理第三方软件的风险，也是S-SDLC实施过程中面临的一个主要的问题。具体来说，有以下实践供大家参考： （1）企业要有清单列表记录哪些产品使用了哪些第三方软件。一旦某个第三方软件出现漏洞，可以通过清单列表迅速排查。 （2）企业要有清单列表记录禁用的第三方软件。对于那些安全问题比较多、风险较大的第三软件，应加入到这个禁用清单列表中禁止使用。 （3）对于使用较多且开源的第三方组件，建议进行代码扫描，对于发现的漏洞，提交开源社区，并促使开源社区修复。 （4）对于第三方软件的使用要有安全性指导（主要是规避一些因配置不当引入的安全问题）。 （5）慎用对安全问题处理态度消极的厂商所开发的第三方软件。
9．安全服务化和自动化是实施DevSecOps的基础
近年来，DevOps的开发模式已被广泛应用。DevOps的核心思想是将开发和运维一体化，开发能快速推出产品进行AB测试，通过数个版本的迭代，使产品变得成熟稳定，同时也使产品功能变得丰富。 在DevOps开发模式下，传统的S-SDLC流程在DevOps模式下显得过于厚重，那么就需要有适用于DevOps流程的S-SDLC，这就是DevSecOps的由来。由于运维流程也一体化了，因此在传统S-SDLC的安全成本模型也就发生了变化。举个例子来说，在传统S-SDLC的测试过程中，我们要尽可能的发现所有的安全漏洞，因为产品一旦发布，漏洞的修复成本会很高；但在互联网企业自己开发、自己测试、自己运维的DevOps模式下，产品发布后，漏洞修复的成本并不一定有增加很多。因为运维一体化后，漏洞一旦发现，响应的时间可控制在一个很短的时间内。 但这并不是说DevOps之后开发过程中的安全活动就不需要做了，只是做的方式会有差异。这个差异主要来自于安全功能的服务化、自动化工具。安全功能服务化本身符合SOA架构和微服务架构的演进方向。安全功能服务化后，就能将产品的一些安全风险转移到安全服务上。以IAM服务为例，采用成熟的IAM服务能在很大程度上降低产品在认证和授权方面的问题。AWS提供的移动应用账号服务可以让移动应用直接集成，而不用担心账号的安全问题；或是采用OAuth认证方式，采用安全性很强的Google、QQ、微信等知名厂商的安全认证对接。这样自然就减少了产品研发过程中的安全投入，使S-SDLC可以变得快起来。另一方面，采用工具实现自动化，也在很大程度上能减少S-SDLC过程的投入。
10．S-SDLC工具链
无论在普通开发、敏捷开发还是DevSecOps模式下，S-SDLC落地的关键都离不开流程体系和高度自动化工具链的融合。根据OWASP S-SDLC项目团队的实践积累，若有一个一体化的平台能准确、完整地记录、管理和追踪软件产品在S-SDLC实施过程中的实际情况，实现软件产品开发信息在S-SDLC流程中跨活动、跨角色流动，才能真正确保软件产品的安全需求和安全威胁在开发、测试和部署运维过程中落地。而无论是需求阶段的需求库、开发与测试的安全测试工具，还是其他安全工具，都将成为S-SDLC工具链中的一环。
| Main Section | Chapter | Status |
|---|---|---|
| Preface | Purpose of S-SDLC | Done. Waiting for approve |
| Coverage of S-SDLC | Done. Waiting for approve | |
| Security Strategy | Security Strategy | Done. Waiting for approve |
| Security Goal | Done. Waiting for approve | |
| The infrastructure of security engineering capability | A Brief Overview of the Infrastructure | Done. Waiting for approve |
| Organization Structures | Done. Waiting for approve | |
| The Flow Framework | Done. Waiting for approve | |
| The Security Tech Framework | Done. Waiting for approve | |
| The Chain of Tools | Done. Waiting for approve | |
| The Training System | Done. Waiting for approve | |
| The Measurement System | Done. Waiting for approve | |
| Security Requirements | To Understand Security Requirements | Done. Waiting for approve |
| How to build Security Requirements | Done. Waiting for approve | |
| The interpretation of OWASP Top10 Project for training purpose | Detailed explanations of the top 10(e.g. Demo) | Calling for volunteers |
| TBD... | TBD... |
