Article Preview
Top1. Introduction
In the past, software security focused on anticipating where and how attacks would be leveraged on an application and putting up barriers to prevent those attacks. However, most attacks, especially sophisticated attacks, can't be anticipated, which means that fixes are bolted on as new vulnerabilities are discovered. The inability to anticipate attacks and lack of implementing security early in a project lifecycle is why there are often patches in response to 0-day vulnerabilities (Kongsli, 2006). This paper discusses ways to reverse this reactive nature of secure development and help teams to respond more quickly and more effectively to cyber incidents.
Developing a secure lifecycle requires the development team to focus on continuous integration, infrastructure as code, eliminating denial of service (DOS), and limiting the attack surface. These include adding automated security testing techniques such as fuzz testing, software penetration testing to the software development cycle or the system integration cycle. Other techniques include standardizing the integration cycle in order to reduce the possibility of faults and security concerns by implementing good security practices from the inception of the project, or “pushing security left” (Tomhave & Kenefick, 2014).
This paper focuses on how implementing security from the inception of a project greatly improves the overall security of the software being produced. It also discusses how implementing these pieces of security on a DevOps platform allows for rapid release cycles as well as secure software. These techniques provide developers, and other team members, a deeper understanding of what makes a truly secure application.
1.1 Problem Statement
It is very difficult to integrate security into the software development lifecycle because there is no time for manual penetration testing and audits. There is also no opportunity to put in control gates and perform extensive security reviews. These problems arise due to the velocity of change in the software lifecycle. The velocity of change increases due to rapid business changes (Liu, Y., L. Chengbo, and L. Wei), growing vulnerabilities, software complexity and dependencies on third-party libraries (i.e. open source modules). Organizations like Facebook and Etsy are delivering changes into production environment 50 or more times each day. Amazon has thousands of small engineering teams working independently and continuously deploying changes into various production environments. In 2014, Amazon deployed 50 million changes which equates to more than one deployment per second (Brigham & Liguori, 2015). This paper discusses how a development team can take measures early in the DevOps software development lifecycle to ensure the security of their piece of software.
3. Barriers To Incorporating Security Into The Sdlc
There are several barriers that face companies, development teams, etc. which make incorporating security into the SDLC difficult. The following sections discuss the most common barriers, which means that this list is not exhaustive.