Developing a secure application is no different than delivering a high-quality application as long as security is addressed throughout the software development lifecycle.
It seems easy to say, “Let’s assess security at every phase of the development lifecycle”. But, in reality, it is very difficult to integrate traditional security practices into the software development lifecycle for DevOps because there is no time for manual security testing, secure code reviews, dependency assessments, and audits. Also, there is no opportunity to put in control gates and perform extensive security reviews because the review take longer than the commit and deploy cycles.
In DevOps practices, the velocity of change increases due to rapid business changes, growing vulnerabilities, software complexity, and dependencies on third-party libraries (commercial or open source). There are also many questions like:
- Where and how to address security?
- Which method is effective?
- How to link security activities?
- What is the most important security check to perform?
- Who is responsible: development, security, or both?
Most often, security folks do not like frequent constant changes on the delivery pipeline with releasing a new version because they have to reassess, retest, and approve new applications builds even though the new builds many have a small change. As a result, most of the organizations who do not practice DevOps principles bolt on secure testing at the end of the SDLC. These organizations also face some challenges like organization culture, operational silos, and toolset complexity when trying to integrate automated security testing into the development lifecycle.
Culture: Organizations as a whole can make a huge impact on how security is implemented throughout the SDLC. This is more than just a mantra handed down from people at the top of the organizational chart. It is the organizational culture and policies along with the organization’s structure.
There are several opinions about the correct company structure and how to set up a company with security in mind. However, most companies are do not have green field operations. Their operational practices are already established and this introduces obstacles for them in transitioning to a security-focused development strategy.
There isn’t simply one easy way to overhaul your company’s culture, policy, or structure. More importantly, this is not a practical approach. The key to successful transformations lie in how development organizations can leverage the knowledge, experience, and tools from within their security teams to develop secure applications from inception to deployment.
Silos: Silos are often brought up when discussing barriers to new methodologies and technologies in the software community. Unfortunately, security, which is often its own silo, is another stakeholder that needs to be part of a project from its inception. Forcing strict guidelines from a security silo into the development realm can create strong backlash as enforcing those practices slows development and release cycles.
Discrete Toolset: Another major barrier to implementing security is the difference in toolsets between security, operational, and even other development teams. Typically, developers have their favorite tool for each development activity. They also have limited knowledge and desire on using security analysis tools on different phases of SLDC. While many security tools allow for easy integration into development tools, that is not always the case. Tools may integrate with each other, but integration can take a lot of time to manually set-up and may require continued maintenance over time.
To overcome these challenges, security integration into application development lifecycle requires practice with DevOps. DevOps is a set of principles and practices emphasizing collaboration, empathy and communication between software development teams and IT operations staff along with acquirers, suppliers, security teams, and other stakeholders in the life cycle of a software system [1].
At the minimum, security analysis can be performed at Design/Architecture, Development, QA/Test, Staging (Prior to release into production), and active monitoring production phases. And as pointed earlier, security analysis should be done throughout the application lifecycle. The 2018 DevSecOps Community survey data shows an average 15-20% improvement of security analysis on each phase in either mature DevOps organizations or others for this year. (Fig -1)
Figure 1. Automated Security in the SLDC.
Mature DevOps organizations are able to perform automated security analysis on each phase (Design, Develop, Test) more often than non-DevOps organizations. Since DevOps enables strong collaboration, automation of the process and enforces traceability, mature DevOps organizations are 338% more likely to perform automated security analysis (57%) than non DevOps organizations (13%).
Furthermore, when organizations adapt to DevOps processes they will get major benefits with increased team efficiency, traceability, complete visibility, and a quick incident response to cyber incidents.
Implementing security for an application is a difficult problem which is solved easily with a DevOps mindset. In non-DevOps mindsets, integrating security is often avoided because it is seen as an extra effort without getting any new features or improvements. However, this type of thinking is flawed. Security should be seen as a non-functional quality attribute and should carry the same, if not more, importance as the other major functional quality attributes like availability, usability, etc. As such, Security and DevOps can align perfectly with other attributes of application quality assessments and remediation paths. Once a secure SDLC is setup, there are several benefits that arise from inception to operate with constant collaboration.
Finally, I encourage you to read this year’s full set of responses from the 2018 DevSecOps Community Survey here. The results are fascinating.
[1] IEEE P2675 DevOps Standard for Building Reliable and Secure Systems Including Application Build, Package and Deployment
