Some thoughts about “Shift Left” security in DevSecOps
A popular term in DevOps context is “shift left”: it refers to the effort by a DevOps team to implement measures to guarantee application quality at the most early point in the software development life cycle.
In a application security context, this refers to the measures implemented to ensure thart security concerns are taken into consideration during the whole application development, rather than at the end of the process.
So we can say that the goal of shift-left security is to identify and resolve potential vulnerabilities earlier in the development life cycle, when these issues are less expensive to fix.
Traditional security testing approach
In a traditional software development lifecycle, most of application’s security testing are performed at the end of the development process, swhen an application is nearing deployment to the production environment.
Usually, a third-party security expert tests the application and provides a report about discovered vulnerabilities. Then any flaws identified during the test are addressed, and the application is deployed.
However, too often major security vulnerabilities are discovered when the application is really near the deploy into production, with the needs to meet the deadlines and deliver the product as soon as possible.
In this case, if a serious issues is found, the possible ways are to decide whether they delay the deploy, apply a hotfix or go live with the plan to fix shortly after: obviously none of these options is a good outcome.
DevSecOps and “Shift left” approach
The philosophy behind DevSecOps is to begin security testing earlier in the software development lifecycle, shifting testing to the left by add security testing into each phase of the DevOps pipeline, rather than rely only on security testing performed when the application is released into production.
Indeed, DevSecOps does not replace traditional security testing or secure software development practices, but complements them: a security testing prior to production release is still important, but it shall be considered as a “final check” before release.
This approach assure that every change to the codebase be checked with a series of security tests before it is accepted into a build that is ready to be released into production: any failure of a security test will be notify the developer immediately, who can begin to address it while it is fresh in their mind about the latest changes of the code.
This is in contrast to finding the flaw during a penetration test (weeks or months later), in which time the issue may have compounded and become much more difficult to resolve.
Some useful resources
A useful webinar
Four practical steps
Step 1: Define your shift-left security strategy
The first step of any journey is to define where you intend to go. Do not underestimate the power of a concisely (ideally one-page) written strategy document. It is critical to define what shift-left means in your organization.
Step 2: Understand where and how software is created in your organization
Perhaps one of the most challenging aspects of shifting security left is first getting a handle 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.
Step 3: Identify and implement security quality guardrails
Quality assurance has always been part of the software development lifecycle. However, software quality has not historically included security. This must change, and the work done in the previous steps will arm you to do this.
Step 4: Assess and continuously train development teams in secure coding
Developers clearly know how to code, but do they know how to do it securely? Part of your journey to shifting security left is to ensure that those who do the majority of your coding create secure code in the first place. This is difficult to do if you have no objective measure of where their skills stand today and no plan to improve them continually over time.
Five suggestions for a successful implementation
1) Culture of Collaboration
Understanding security feedback is critical towards reducing software attack surface and for continually tuning workloads to be resilient to attack. An internal security team is not an adversary.
2) Translate Paper into Code
Security is an enabling concern for most software development projects. Commonly, it also represents a set of features that must exist for customers to feel comfortable using an application. We’ve alluded to this earlier, but more explicitly stated: where developers build value for an organization; security builds trust.
3) Fanatical Testing and Instrumentation
The art of developing zero day exploits is alive and well. It is not something that will disappear in the future but will likely evolve to take advantage of Continuous Delivery, the Public Cloud and the DevOps era. Attackers are continuing to discover and exploit even the smallest mistakes and re-introduction of once solved security defects.
4) Provide Intuitive Security Measurement
Gene Kim does a great job of defining what successful value creation requires at speed and scale. One of the critical elements is a trust based environment whereby DevOps can achieve the mission without blame. The value of blameless environments is fast learning and adaption, or rather inspired innovation.
5) Continuous Science
We’ve briefly touched on measurement for reducing blame but there is more to the picture. People who develop amazing technology also need to sleep. Attackers have always used the art of being stealth to advance their efforts but when that fails to work, they turn to techniques to create and exploit apathy.
Dispelling a few misconceptions
Finally, in a post on Plutora Blog , the author discuss some common misconceptions about DevSecOps:
Myth 1: We Need “Super Developers” for DevSecOps!
Not really. If you think you need to recruit certain people with magical coding skills for DevSecOps, then you’re mistaken. Unless you can’t train your existing people effectively or your developers aren’t interested in making the DevSecOps shift, you don’t have to put on your hiring cap just yet.
Myth 2: DevSecOps Can Replace Agile
It can’t. DevSecOps complements agile, but it’s not a substitute for it. They must co-exist in order for organizations to maximize their business benefits.
Myth 3: You Can Buy DevSecOps
Not exactly. You can only buy tools to use for the process, such as release management and CI/CD tools. You can’t buy the entire DevSecOps process because it’s a philosophy or a methodology.