Companies today are under enormous pressure to bring robust software to market quickly and affordably. Yet the majority of organizations are struggling to do so. According to one study, 75% of software projects fail while 80% of business and IT executives say they spend at least half of their time on rework.
To streamline software development, a growing number of teams are choosing to implement continuous integration and continuous development (CI/CD) pipelines and integrate testing directly into them. This is called shift-left testing. Shift-left testing is a strategy that involves integrating testing throughout the entire development cycle, instead of waiting until the end. Chances are likely that you’ve heard the expression test early and test often. This is the essence of shifting left.
Shift-left testing is not a new or cutting-edge concept. The term was originally coined by Larry Smith in 2001 and has recently been rising in popularity.
“Shift-left testing is how I refer to a better way of integrating the quality assurance (QA) and development parts of a software project,” Smith says. “By linking these two functions at lower levels of management, you can expand your testing program while reducing manpower and equipment needs — sometimes by as much as an order of magnitude.”
Here are some of the top reasons to shift left.
Back in 2015, an issue appeared in Airbus’s engine software, resulting in a fatal crash and requiring all A400M aircraft to be grounded and inspected. Issues need to be detected as soon as possible and patched. Had it been discovered sooner, the company could have avoided catastrophe. Shifting left and testing earlier can help identify critical issues before they become buried and more complicated to fix.
Detecting an issue late in the dev process and having to backtrack and rework can be very expensive — especially after products go to market.
Just recently, VMware had to patch a vulnerability in VMware Cloud Director that could be exploited to take over private clouds. The vulnerability was discovered during a customer security audit. VMware was informed of the issue on April 1, and a patch was quickly developed by April 30. However, the resolution process took time and effort.
When developers are asked to move products along quickly, they will sometimes sacrifice quality over speed in order to meet deadlines or accommodate feature requests.
However, this leads to technical debt or hidden issues that must be fixed before the product is released. By shifting left, teams can reduce technology debt before it compiles and creates larger problems down the line.
Security is one of the most important parts of the development process, especially right now. According to the FBI, cybercrime has quadrupled during the COVID-19 pandemic, meaning dev teams need to be extra cautious about vetting software for vulnerabilities.
Despite the heightened need for protection in today’s volatile climate, security is still largely treated as an afterthought. Security is usually tacked on at the end of the development cycle, right before a product goes to market — instead of getting baked into the framework early on. For this reason, security issues often go completely overlooked, resulting in an endless cycle of vulnerability discovery and software patching.
Unfortunately, security and audit teams are usually the first to receive criticism when software issues are detected, despite the fact that they are oftentimes siloed from the development process and unable to leverage their input at key times. This can be very frustrating for security teams, having to clean up after developers’ mistakes — especially when they can be prevented.
The good news is that security and audit teams can shift left, too, and integrate testing earlier in the development process. This can result in a program that is inherently more secure while preventing embarrassing and costly mishaps down the line. Security and audit teams can shift left by working with developers to implement security “guardrails” and training development teams to create secure coding. One of the best ways that security and audit teams can shift left is to leverage automation. For example, Sonrai Dig offers prevention and remediation bots that can identify and fix security issues throughout all stages of development. Bots can act as automated security checkpoints, ensuring that workloads only move to production after adhering to the company’s security policies. It’s an easy way to ensure your software is secure, your users are happy, and your bottom line is healthy.
How do security teams make the shift left to embed security early in the process? There are a lot of different ways to incorporate security, but one of the most critical steps to take to eliminate vulnerabilities is to remove hardcoded credentials, secrets and access keys from application code. These are the powerful credentials used by applications to access databases, cloud platforms and other sensitive resources.
We’ve all heard how a common mistake of a developer embedding credentials in code and using a code repository for version control without realizing that the repository they thought was private was actually public. Instead of hard coding these privileged credentials in the application, they should instead be secured, managed and monitored by a secrets management platform and only accessed by applications when needed. Code repositories are very widely used, but with secrets management, even when code is inadvertently made public, there are no credentials to be exposed.
One challenge when removing hard-coded credentials is that developers have to code their applications to fetch the passwords and credentials needed to securely access the resource. While it is relatively easy to replace the hard-coded credential with a simple API call early in the development process, it will require considerable rework if you wait until after credentials are hardcoded into the application. A huge potential hassle for developers – but something which can be easily solved by having security teams engaged with developers early in the development lifecycle.
Developers too often view security as a roadblock, especially if they jump into the process too late. Developers also may not fully understand the specific security needs and approaches and may think they can handle it themselves. If you want to get security and DevOps teams to work together smoothly, here are a few practical steps to consider:
1. Transform your security team into a DevOps partner, by first developing some of the basic skills to understand the development process, so that you can communicate to the development team in their language.
2. Work with your DevOps counterparts to establish enterprise requirements for securing secrets and credentials.
3. Help developers understand the security vulnerabilities and the challenges that come with addressing them. Train the developers to be “security-minded."
4. Communicate the vulnerabilities in terms that developers can more easily relate to, such as the recent Kubernetes vulnerabilities. Once they fully understand what it means to be responsible for security, handling compliance and audit requests, securing the person (and non-person) credentials for the DevOps tools, maintaining the secrets management platform or the SIEM and so on – they’ll be more likely to hand off those responsibilities to the right team.
Want to learn more about how to incorporate security earlier in the development process? Check out our webinar, “Pillars of Cloud Security: How “Shift-Left” Enhances a Secure SDLC”, which is packed with guidance from cloud security experts.