Shift Left Security — An Approach in Application Security
Since the beginning of modern computing, security has largely been separated from software development. The latest vulnerability research confirms that over the past five years, out of all published vulnerabilities, 76% were from applications. Given this radical shift in attacker focus, it’s time to implant security with development. The best approach to get this done is to implement a shift-left security strategy.
“Only 20% of organizations following DevOps practices consistently integrate security into the development process” Source:HPE /True State of Application Security & DevOps
“Only 15% of organizations can remediate security vulnerabilities or address compliance violations as they arise” Source: Chef| 2017 Community Survey
What is shift-left security?
Moving security practices left into the software development lifecycle with the goal of shifting from a reactive to a proactive security posture.
In the simple definition, “shift left” security is moving security to the earliest possible point in the development process. Modern CI/CD typically involves an eight-step process as shown in the figure below. Many security teams only become involved in the concluding steps of operations and monitoring. Consider that shift-left security is good for reducing not only security risk but also cost. Addressing security issues in design was six times cheaper than during implementation but the same security issues addressed during testing could be 10 times costlier.
Step 1: Define your shift-left security strategy
The first step of any journey is to define where you plan to go. It is important to define what shift-left means in your organization. This is about painting the most evocative picture possible for your teams so they know what success looks like. Key items to include in this document plan are vision, ownership/responsibility, milestones, and metrics. Expect the strategy document to mature over time and don’t spend too much time trying to perfect it. Iteration over time is essential.
Step 2: Understand where & how software is created in your organization
Perhaps one of the most challenging aspects of shifting security left is first getting a hold on how and where software is created in your organization. Depending on the size of your company, this could run the gamut from straightforward to extremely challenging. This step is critical because the end result is what allows the security team to understand where they can actually move security closer to development. In many instances, development is outsourced to multiple vendors, which will require additional work. Small and medium-sized companies will find this step relatively straightforward but equally rewarding.
The objective of this step is to first look organization-wide and document the overall flow of software in your company. Medium to large organizations will want to start at large-scale level and then drill into individual business units. It is certain that each business unit will have its own software development process and tools. Key items to identify in this process include who is developing code (people), how it flows from the development environment to production (process), and which systems they are using to enable the process (technology). This may also be referred to as the CI/CD toolchain. Undoubtedly, much of your software development is being done in the public cloud.
Step 3: Identify and implement security quality guardrails
Quality assurance and quality control has always been part of the software development lifecycle. However, software quality has not historically included security. Every step of the software development process is an opportunity to give feedback and look for security issues. The most effective security teams start small and automate at every stage of SDLC.
Step 4: Assess and continuously train development teams in secure coding
Developers undoubtedly know how to code, but do they know how to do it securely? Most of the time-shifting security left is to ensure that those who do the majority of your coding create secure code in the first place. This is problematic to do if you have no objective measure of where their skills stand today and no plan to improve them continually over time. Given that in one survey, 19% of developers said they were unfamiliar with the OWASP Top 10, this is an area that should not be overlooked. As per a recent survey published by DevOps service provider GitLab, which found that 70% of programmers are expected to write secure code, but only 25% think their organization’s security practices are “good.” If only 25% of developers feel this way, security teams have a lot of work to do in this area.
What shift-left security looks like
Let’s look at these two scenarios below where we have simplified development into build, deploy, and run phases.
In Scenario 1, development starts without security. Software quality is only checked during runtime. This frequently results in an uneasy conversation between security and development when vulnerabilities are found.
Scenario 1
In Scenario 2, however, security teams have invested the time to understand the development process in their organization. They have also taken the time to merge security processes and tools in the CI/CD pipeline, resulting in automated security quality guardrails.
Scenario 2
Conclusion
Utilizing these four steps above will put your organization on a solid path towards not only shifting security left but making security equal with development. As your organization moves towards shift left as part of its cloud journey, it’s critical that security controls be automated at every stage of the software development life cycle. Neova Solutions empowers security teams to do exactly that by securing DevOps and your CI/CD pipeline.
Originally published at https://www.neovasolutions.com on April 21, 2020.
Connect with us:
