What DevSecOps? We are the legacy!

One of our clients used to organise a Cloud guild every Friday for the DevOps and Cloud architects to interact and learn about all the wonderful initiatives happening across the organisation. However, despite best intentions, the informal nature of this meetup meant that rants and vents outnumbered tech discussions. In one of these meetups, I came across a cloud architect who seemed quite disengaged during a modern DevOps practices discussion. This intrigued me because “modern DevOps” is such a hot topic that I simply couldn’t believe that a person might not be interested.

I approached him and introduced myself as a Lead DevSecOps consultant from RiverSafe. He replied “I’m a cloud architect for the business solutions team. I look after a couple of on-prem legacy applications. I am the last person you should speak to.”

This intrigued me. “Why is that?” I asked.

“Well, we are a legacy app team. We can’t do DevSecOps or even DevOps! We do a handful of manual deployments and follow a traditional waterfall model. So, we don’t tick any box.”

We both laughed. I asked, “You are joking right?”

I added: “What if I tell you that agile has no direct relationship to DevSecOps and that most of the agile teams are just agilefall teams (waterfall pretending to be agile). And what if I tell you that DevSecOps and the shift-left process can be introduced even for legacy and on-premise application teams to help them become more efficient and secure.”

This conversation inspired me to blog on this topic: 3P framework

Like our architect, most people believe that agile and DevOps are somehow interconnected. The upcoming Scaled Agile Framework (SAFe) uses the word DevOps and agile in an interchangeable manner. If we take a step back from the agile discussions, there are quite a few practical and proven frameworks that determine the success of a team and a product. My favourite is the 3P framework (People, Process and Product).

Agile and waterfall are the process for building software and services. If you have the right team with access to the right products and tools, whether you use agile versus waterfall versus SAFe, this is not going to make much difference. On the other hand, if you have the right team and an agile process like scrum but no funding for tools or products then good luck getting anything done.

What constitutes the right team? I like Tuckman’s famous four stages of team development.

1. Forming – Hiring and forming a team. Agree on a vision
2. Storming – Get to know each other. Build trust. Clashes and conflicts arise here
3. Norming – Clashes and conflicts get resolved one way (collaborate) or the other (can’t bother). Needs leadership to mentor and guide the teams
4. Performing – Work and achieve a common goal. Autonomous mode with support from the leaders

I have heard terms such as “swarming” and “pairing” and so on which are variations of team collaboration. Some leaders are so obsessed with step 1 that they conduct overly complex and difficult interviews and tests in the name of hiring the right person or the consultant. In reality, steps 2 and 3 are considered the key for a successful team and often the inherent organisational barriers and time constraints of the leaders would in fact negatively affect the team during those stages. So, you can hire the best individual that ticks all the boxes and can still end up with a poor team!

DevSecOps and shift-left paradigm bring in useful process improvements and tools to teams, helping them to get better at what they do and offer. Likewise, security also gets an upgrade so everyone wins!

DevSecOps for the legacy and on-prem apps

Every app can be containerised in one way or the other. Kubernetes and the recently announced Google Anthos platform makes it very easy to containerise, secure and manage both on-premise, and cloud applications (hybrid-cloud ftw!). Even the most difficult and old Windows-only application can be virtualised and deployed onto the cloud nowadays.

Once containerised we found that the order in which the tools and process changes can be introduced is different for greenfield and legacy teams/apps. The animation below suggests an idea for the rollout.

For Greenfield and young teams that are new to DevSecOps you can start bottom up with introducing credentials scanning tools, SAST, Container scanning and so on.

However, for legacy apps and projects with just a handful of releases, it makes sense to start top down with the network security tools and IAST followed by container scanning tools and so on.

If you are a fan of my driving tips analogy IAST is like a driving instructor carefully evaluating your driving style for safety but ready to jump in and help when you are about to derail (due to security risk). IAST is different from performance and telemetry tools which are like those driving examiners who will evaluate and find major and minor faults but offer no further help.

Container scanning tools such as Aqua, TwistLock or the Anthos vulnerability scanning will keep an eye on the container images, which is even more important for legacy apps using an old and outdated version of libraries. If you are a small and medium enterprise with a smaller budget GitLab is an attractive proposition with built-in SAST and container scanning. Claire and Anchore is free if you know how to set it up.

It will be awesome if you can reach all the way to static analysis and linting but feel free to be pragmatic.

So, as you can see, DevSecOps really is for everyone.