Published: Sep 27, 2021

if anyone can inspire digital trust, it’s us – developers

But with everyone in DevOps talking about being agile, and failing fast and learning fast today, where does quality stand? How can we strike a balance between speed and quality? Or what measures can we put in place to harmonise them?

Typically, two approaches are most commonly applied in ensuring software quality – do quality checks after the design and development cycle, or continuously throughout the development phase. While the former is a common practice traditionally, the latter typically offers fewer problems and surprises at the end.

By starting small, chewing little, validating, testing and then progressing a little more, it fits the ideology of fail fast and learn fast. And even when nothing fails, insights gained can help optimise long term goals, and move the development along. In a nutshell, this is shift left security.

Contrast this method with waterfall monolith applications where testing is only conducted at the end. Not only is it likely that we will end up with a long list of issues that need fixing, we may also have to redesign modules or patch in complex workarounds to resolve issues that could have been circumvented totally if checks were conducted earlier.

That’s not a great way to design – obviously.

You’ll ask – what then is a better approach for DevOps? Well, take a Jenkins build pipeline that churns out software sub modules. We’ll want to embed quality checks into every pipeline processing each software sub module and deal with arising issues incrementally instead of having a surprise when codes are assembled and run.

Try imposing this concept into a manufacturing line setup that runs from left to right. Quality checks should be implemented as much left as possible and practical before the final code assembly comes – in other words, shift left the quality checks. If issues can be detected early, they can be fixed early. Importantly, costs of rolling back major design decisions and architecture rebuild can be avoided.

Shift left security sounds great in concept. But, how well the development team embraces it will depend on the pipeline design. Do we design code build, scan, test and deploy into a single pipeline? Definitely not – else every build will take hours if not days to run.

Developers are keen to find out if the code they build integrates well with the rest, and that needs to be done as often as possible – preferably once a day based on a trunk approach. Therefore, breaking up build, scan, test and deploy into respective pipelines is the best way to allow developers flexibility to increase the velocity and efficiency of the DevOps process. Depending on how long scans or automated testing runs are, weekly or even longer batch jobs can be scheduled to accommodate that. Other determining factors include how fast codes are generated and how large the development is.

By now, it should be clear why adopting shift left security in code development is preferred – from more efficient software rollout to alleviating security domain issues. Moreover, commercial and open-source tools are readily available in the market to help us with its implementation. For your easy reference, I’ve listed examples in various categories in the box.

Source: SCS magazine, Singapore Computer Society