SD Elements | 
Research
Upcoming Events
Resources
The DevOps lifecycle varies from organization to organization, but it’s best known as a methodology for providing continuous integration and delivery using a pipeline of phases like Requirements, Design, Development, Deployment, and Testing. Where and when does security fit into this pipeline? The timing of a security phase can also vary and is largely dependent on how an organization defines its security policies. There are divergent views of security as either an afterthought or as a default: security performed as an afterthought leaves security to the final stages of the release cycle, whereas security as a default integrates security into the design of the release cycle. So how do organizations prioritize security, and why is it so often deprioritized? It could be due to budget, staff, executive decision — but whatever the reason, the conception that security is a disruption to the development lifecycle is simply the result of immature security policies.
How do we begin to define mature security policies? We will address common security myths, introduce security facts, and explain the outcomes related to each. Based on this information, you can start to develop some idea of how to create and develop mature security policies in your organization.
Security Myths
The traditional waterfall development approach started with software requirements, transitioned to design, development, quality analysis, and then ended in production. The new Agile development approach starts with user stories, moves to development, and then into continuous integration and continuous deployment.
Given the iterative, faster workflow associated with Agile development, treating security as the last step doesn’t work in the same way as it did in the unidirectional waterfall workflow. In fact, security’s placement as the last step in an Agile workflow resigns it to a lower priority. This is partially a result of being limited to a certain set of low-precision security tools and partially a result of facing greater time restrictions. Addressing security only after coding restricts you to using only after-coding security tools and resources, like code scanners and penetration testing. While many organizations rely solely on these after-coding tools to manage application security, they can only capture a percentage of the total security vulnerabilities in the time given.
The results of horizontal security:
Immature security policies
Reliance on code scanners and ad hoc security solutions
De-prioritization of security activities
Potential for breaches, penalties, and loss of reputation
Security facts
In order to have an application security program that facilitates, and doesn’t slow business, it’s essential to shift left. This means that it’s important to address security requirements at the very beginning of the software development lifecycle, in the requirements stage of pre-production, rather than as the last step before a software release.
Many organizations consider application security to be an important part of their business success. Yet, they’re limited in the tools and resources needed to carry out the necessary security activities. The classic approach of using code scanners and penetration testing isn’t working. Organizations commonly leverage code scanners to identify security defects and rely solely on these tools as their whole application security program. Code scanners, however, only catch 46% of vulnerabilities on average, and they’re notorious for creating high numbers of false positives and negatives. Furthermore, 24% of critical software vulnerabilities that are found by scanners are never fixed, likely due to a lack of time and resources. That 30 % of critical vulnerabilities that are found and fixed take an average of 113 days to remediate (Security Compass Scanner Gap Report). Penetration testing is a valuable security activity, but since it takes place after coding, it has strong potential to negatively impact development timelines. Research has shown that the later security vulnerabilities are found in the software development lifecycle, the greater the cost and time for their remediation. At this point, we are left to consider only those security activities that take place before coding.
The results of shifting left:
Fewer undetected security vulnerabilities
Significantly lower remediation costs
Lowered risk of a security breach
Consider that organizations are typically defined by a vertical business architecture where business-level decisions determine programs and departments, which then determine projects — the development of a final product begins with those business-level decisions. When it comes to securing this process, the pitfall of some organizations is that they inject application security at the project level. If security activities are forcibly introduced into a previously effective development pipeline, that pipeline will be disrupted because it was not designed to work with security. The alternative is to implement security vertically at the business-level so that it can unify the security of its programs and projects. Business-level security policies trickle down to form a bedrock of risk management and compliance — this is how the traditional DevOps pipeline becomes designed for security, and the so-called slowdown of development caused by security becomes an acceleration of development.
The results of vertical security:
Security by design
Mature security policies
Security automation and security champions
Fewer code scanner findings and false positives
Separating myth from fact is necessary for building mature security policies that work with your business instead of against it. Security is often seen as an inhibitor to contemporary development methods designed to release more frequently, but slow down and disruption is a result of forcing security into an organization’s policies that were not designed with security at the forefront; when those policies are created with security in mind, slow down and disruption become acceleration and efficiency.