Dude, agile up

“We need to really shift things to the left!” announced a leader as they entered the meeting room. “We need to agile up and do DevOps in a modern way”. There was silence in the room as the  lecture went on for more than 30 minutes and included reference to Infrastructure as Code (IaC), Platform as Code (PaC), Infrastructure as a Service (IaaS), Platform as a Service (PaaS), ServiceNow, Slack, more ServiceNow, more slack, and some waterfall here and there.

As we left the meeting, I was pulled aside by the tech lead who naively asked, “Prabhu, what is shift left? Is it the same as “Lift and Shift”?

As a premier cloud security and data analytics company, RiverSafe, has a strong track record helping clients (large and small) implement secure Dev and DevOps practices including shift left!

Levels of DevOps maturity

Clients engage RiverSafe to help implement DevSecOps practices tailored for their business and cloud strategy. One of the activities my team undertakes is to understand and evaluate the maturity level of the DevOps teams within the client organisation. What is the level of expertise in terms of technology, processes and ability to deliver complex changes? Is the team ready and are they in favour of a process change to their dev, build, deployment, security or support processes?

Every time we ask this question we find huge variations in the maturity level across clients. We have come across teams who just maintain a single Jenkins pipeline, teams that use AWS but do not know the difference between on-demand and reserved instances and teams that are cloud-native and ready to race but are blocked because the rest of organisation is not there yet.

Shift left is a radical idea to implement security processes on the left side of the software development lifecycle – during requirements planning and development instead of at the end of the process.

In my view shift left is an ideal state, an aspiration however, most teams are simply not ready for this. So how hard can it be to do security on the left of the software development lifecycle?

Below is a secure dev process we have developed and are implementing for a large client.

I will write a separate blog to explain this framework, but as you can see there are a number of steps, automation requirements, integration with tools, and upskilling of people involved to undertake security as a process from the left. So my advice is don’t try it alone.

Should I shift-left?

This is the same as asking should I become efficient and productive. Undertaking security at the end of the development is never fully secure. Pen-testers follow a checklist and strict guidelines and hence cannot identify all the issues all the time. Worse vulnerabilities can arise an hour or a day after the pen-test is complete so you need an automated and continuously integrated process with your CI/CD pipelines and IDEs.

There could be security vulnerabilities in software and services due to:

• Plain-text keys and credentials hiding in the git commit diffs or inside complex base64 encoded config maps. So you need credential scanning tools such as TruffleHog, gittyleaks here.  Having said that TruffleHog was found to detect keys only 30% of the time!
• Genuine defects in the code. There are static analysis tools such as SonarQube, CheckMarx that can detect issues and present remediation advice in a format that developers can understand
• Defects in the open source libraries (Hi npm!) – OWASP dependency check, CheckMarx OSA, BlackDuck can help you here
• Defects in the containers – Claire, TwistLock, Anchore, Quay.io does the job
• Defects in the infrastructure configuration – Redlock, tenable.io will cover you

Below are some of the tools we used for implementing shift left for another large client below:

I’m sold. How do I shift left?

I can talk about the 8 step process involved in implementing this as shown in the framework below:

But as this is my blog let me use another framework that helped me turn left safely while learning to drive. It is called MSPSL. (Image courtesy of drivingtesttips.biz)

Mirror – Look in the rear-view mirror and identify what development process worked and didn’t work for your company and teams in the past. What were the key learnings? Is there anything useful if you look sideways to the side mirrors? Map out the current state and to-be state.

Signal – Signal your intention to shift left and work with the stakeholders involved. You cannot shift left silently and win the race! Be prepared to face the challenges. Some people might say that you will become slow when you turn left. Others might report weird possibly fake roadblocks. There might be legitimate concerns such as process or a toolchain that is difficult to implement or adapt.

Position – Position your team by aligning everyone involved in the correct lane. This might involve a series of workshops, sessions, training and lobbying. Do we have the right tools ready and in place to help with the automation? What about the pipelines and artefacts? Can they be upgraded and made verifiable and repeatable? (Hello Huawei!)

Speed – Now carefully choose the speed. Take all the time you need since one crash can prevent all your followers from turning left. Re-adjust your position depending on the speed changes. Don’t hesitate and give up at this stage!

Look – As you turn to left keep looking and monitoring. Is productivity improving or dropping drastically beyond a certain threshold? Are the people getting burnt out in the process? What can you learn from the change no matter if it is a success or failure?

Congratulations! Like me, you have now successfully learned to shift left.

Btw, “Lift and Shift” is a legitimate approach that allows you “lift” legacy (monoliths) applications and operating system images and “shift” them to the cloud. You get operational benefits and some performance benefits from this migration which is definitely better than nothing.