With today’s fast development speeds, it’s hard to keep up with security practices for some organisations. This is especially true in the last few years, where applications have been under attack more in the previous five years than ever before.
One of the ways many organisations are working to reduce this problem is through better security methodologies. Namely, the shift left approach.
The phrase “shift left” was initially coined by Larry Smith to integrate testing and quality assurance earlier into the software development life cycle (SDLC). Essentially, one would shift the testing phase from the end of the SDLC to an earlier point in the cycle, as if moving it from the right side of a timeline to the left. Even though Smith would introduce this far before DevOps would be widely adopted, his idea has stuck around and become an integral part of DevOps as a whole.
With the original Waterfall method, testing would often occur before an application was released. This often led to significant bugs or design flaws that could require long delays to fix. Adopting a Shift Left approach can provide several benefits to a development team, such as:
As we stated before, the original Waterfall method of development often prioritised testing towards the end of a development cycle. Because of this, testing and quality assurance would often bring development to a halt while they attempted to fix bugs. Due to how late into the SDLC testing was performed, there would often be critical bugs that could require lengthy amounts of time to resolve. If these bugs had been spotted earlier in development, they could turn a significant refactoring into a quick fix.
With a Shift Left approach, developers can build and run tests early in development. With this, tests are run more frequently and thus reduce the chances of bugs and security vulnerabilities between phases of the SDLC. The methodology can also be applied to more than testing, such as security and deployment.
There are several different types of technology that you can use with a shift left mentality to improve application security:
Establishing a CI/CD pipeline can help enact good practices, most notably with integrated automated testing at all development steps. Not only does this improve application security overall, but it also brings several improvements to development speed and better coding practices. However, it can sometimes be challenging to implement and does require prior planning.
This testing method allows your organisation to analyse and test code before running (the “static” part). Developers typically implement SAST during the early stages of the SDLC to find weaknesses in code. This type of testing works from the inside out, alongside a development cycle to detect potential bugs. It also requires access to an application’s source code or binary but doesn’t execute the code.
Similar to SAST, DAST is often found alongside it. However, these tests are performed on code that is actively running. Because it’s testing running code, DAST can find runtime errors and emulate bad actors who may try to attack an application from the outside. DAST testing does not have access to the source code of an application, meaning it acts more like hackers than developers. This type of testing is often found towards the end of the SDLC but can be shifted left to ensure application security.
Of course, no project is entirely devoid of open-source software. Utilising these open-source components can often bring their own challenges regarding security risks, software licence compliance, and lengthy code dependencies. Using SCA tools can scan your codebase, find all of the open-source components used, and return a report known as a bill of materials. This bill of materials will list all open-source details and any potential issues that may require a fix or licence compliance issues.
When trying to apply a shift left methodology into your organisation’s workflow, there are several tools and practices you can implement, such as:
Of course, all great ideas start with a plan. Even a single page dedicated to how your organisation views security and how it should be changed can work wonders. Including items like milestones, metrics, and ownership can help pave the way to a better-structured plan.
You should always know who is creating your software and where it’s going. Establishing a clear idea of your development team and building a relationship between them and security can go a long way. Learning how code moves from development to production and third-party vendors may also be working in the pipeline.
As modern development speeds are now much faster, it’s imperative that security is at the forefront of this development. In 2020, over 79% of developers surveyed stated that their applications in development had an average of 20 or more vulnerabilities. Having a team aware of security best practices can significantly prevent potential exploits.
Automation is key to DevOps and modern development teams. Ensuring that shift left testing is included early into the SDLC can decrease the chance of exploits found in production. With automation, testing can be performed much more frequently. Paired with SAST and DAST testing at both ends of the pipeline, security teams have a greater chance of finding and resolving vulnerabilities before a final product reaches production.
Uleska helps security and development teams manage application security at scale by automating and orchestrating their preferred security tools within CI/CD.
With Uleska, teams can confidently start an AppSec program using open-source, commercial, and custom tools and then quickly change, add or scale tools as the technology and business needs evolve. Uleska also brings speed and scale when integrating into development tools, and reporting of metrics and risk.
By bringing security, DevOps and development teams together, we help reduce manual tasks so application security takes less time, cost and can scale, allowing teams to focus resources on the issues and metrics that matter.
You may unsubscribe at any time using the unsubscribe link in the newsletter.