Why Software Moved Left

Not all software works. Obviously, we all have apps in use that crash too often, stop working the way they used to, get to the point where they can’t adapt to our larger extended needs, or are simply compromised by an upgrade. day or a change that makes them non-functional. .

But before that point, not all software works in its development programming phase. This basic, unfortunate and inconvenient truth has given rise to the term “left shift” of development; also sometimes called test-driven development. It’s about testing software early and often – and this is very commonly discussed in the context of securing software applications against cyberattacks and all forms of malware etc.

What Does Left Shift Really Mean

The official definition of move to the left, with regard to safety, is the process of implementing or using a tool earlier in the software development lifecycle to allow teams to build more secure applications before deployment. Given this context, we can now examine how software creation has changed over the past two decades and what developers are doing today to make our applications more secure and robust.

In his role as a developer advocate at a cloud security company LaceKedasha Kerr says she spent time talking to many engineers who worked throughout the PC revolution segment from the 1980s and 1990s through the 2000s. This process provided invaluable insight into the current state of software.

“I realized that programming [back then] back then it was the wild Wild West,” Kerr said. “Programmers were responsible not only for coding an application, but also for testing, deploying and managing the project. This is where the term full-stack engineer started to be used, which created a different kind of job role silo in teams, compared to what we see today with software engineers. frontend and backend.

Tumbling down the software cascade

Kerr, who tweets wonderfully like @itsthatladydev reminds us that this era of Old West programming was a time when the software waterfall model was widely used, i.e. developers would build all the code they could and then run it into production in a set of essentially linear sequential phases. Or in other words, down in one direction.

Due to the cascading effect, it sometimes took one to two years to deploy projects into production and when that was the case, security was not a priority.

“Since on-premises data centers were widely used and personal data did not live in the cloud or on the internet at the time, there was more emphasis on physical security, ensuring that data warehouses were not were accessible only to authorized persons. If there was a security issue, engineers often didn’t know about it until it was published in a dedicated magazine or they heard their peers talk about it in a meeting,” Kerr said.

All of this meant that when code was deployed to production, there was often no “live production” environment (as we now know with the immediacy and continuous continuity of the cloud) because the “deployment” in production meant physically sending a CD and/or floppy disk to customers so they could update the software on their machine.

“It was a time when software was supposed to run on a single machine – there was no web application. If a company didn’t provide access to Microsoft Visual SourceSafe, version control meant having a folder on a hard drive that was passed between engineers,” Kerr said.

For other engineers at the time, moving to production was painful and nerve-wracking because there was a lot of copy/pasting. The software would be released every six months and then go into production.

Kerr says all of this meant that programmers (and their supporting operations staff in roles like database administrator – DBA and system administrator – sysadmin) had to shut down servers overnight and copy the source code from directory to directory…while crossing their fingers and hoping the whole system wouldn’t be deleted, while hoping they had a reliable copy of the code to restore and stored safely on a floppy disk.

Then… came Agile

“Because there was often no testing environment, developers relied on peer reviews before shipping code and hoped it worked as intended. But in 2001, a group of programmers came together to create the Manifesto for agile software development, changing the way apps were built. The manifesto introduced 12 guiding principles around teamwork, leadership and customer satisfaction. The highly agile Agile process has dramatically shortened software deployment cycles, and companies have quickly adopted the practice to quickly deliver solutions to customers,” said Kerr of Lacework.

Thinking back to what happened throughout the initial adoption period when Agile was popularized and adopted, Kerr points to the change in cadence that happened here. Where code was deployed on a yearly basis (six months if you were lucky), we’ve seen release cycles as short as two weeks. The internet age had arrived, the cloud was forming and things were going well. We hadn’t really stopped worrying enough about data control, cybersecurity and locking down the systems we were building, but that was okay because we would worry later – obviously it wasn’t fine, but let’s continue.

“Today, when we consider how software is released to production, we think of automated processes with continuous integration and deployment (CI/CD) pipelines and built-in test suites. We have more specialized roles with dedicated specialists working in DevSecOps, product management, cloud architecture, frontend development and backend development – and so eventually a single programmer is no longer responsible for all stages of building software. Going into production is as easy as pushing a button, and thanks to version control systems like Git, there’s no need for floppy disks and CD-ROMs to hold source code,” Kerr said. .

While Agile processes make building software faster and more efficient with Scrum, technologies like Jira (a proprietary issue tracking product developed by Atlassian that enables bug tracking and agile project management) and sprints two weeks, Agile methodologies are often seen as neglecting post-deployment. security reviews and cloud configuration error checks.

The specter of technical debt

Keer points out the implications of this and says that if any vulnerabilities or misconfigurations are discovered before going into production, there is little time left to address concerns as another two-week sprint is about to begin – these vulnerabilities would be pushed into “technical debt”. (sections of code that ultimately need to be refactored and fixed because they don’t fully align with the functionality, security, and scalability requirements of the total software system being built). In his view, instead of sprinting to the finish line and continually shipping new features, we need to step back to ensure our code and processes include safeguards against bad actors.

“Software engineering has evolved into a well-organized machine where quality code is the norm and testing is mandatory. However, in today’s environment, data lives in the cloud. This means that when creating software, we need to implement a security mindset – not physical security, but cybersecurity We are no longer in the age of on-premises data warehouses – we live in a world where web applications are the norm and bad actors crave access to data that lives in the cloud,” Kerr added.

Where this whole discussion takes us is to a point where we need to think about how we think. Instead of seeing the move left as a standalone business process, we can embed a security-focused mindset into our daily workflow, just like we do with testing – at every stage of development. .

“Let’s make sure we incorporate the same patterns in application security. Having a security-focused mindset helps us build software that has greater resilience against bad actors and allows us to feel more confident with the code we ship. This shift in mindset will help us identify data access issues earlier in the build process, rather than a side effect of not having the right permissions in place,” Kerr concluded.

Shift-left for businessmen

This is an IT story, a software engineering story, a workflow process story of a tech geek and on many levels it is of course a software security and cyber- strategy… but let’s think a bit more broadly.

Many of the terms used here are now bleeding into business management and process engineering studies. Because we are now talking about post-pandemic Agile agility, workflows that revolve around Scrum-based planning systems, this is (arguably) a perfect theory for tomorrow’s management consultants (God forbid) begin to apply to all aspects of the business.

As we now also embrace change on the left as prototyping precautionary enterprise test theory where we can simulate real-world deployments with virtualized abstract technologies, often using the digital twins we build in the Internet of Things (IoT) to represent not just physical objects, but processes, systems, and entire cities, we can move left to a better place.

Fortunately, the left shift is independent of the international language, which means that people who speak human languages ​​written from right to left such as Arabic, Urdu, Hebrew and Farsi will always fully understand the concepts here because the computer command line starts on the left side of the filter. Whichever side of the page/screen you’re starting from, shift-left is right.