TLC Community Soapbox | DevSecOps (or, how to become the best plumber in the world)

DevSecOps (or, how to become the best plumber in the world) by Jeroen Mulder

DevSecOps (or, how to become the best plumber in the world)

The general problem with IT architects is that they are constantly trying to shape the world of their enterprise. This typically involves a wide range of new tools and technologies, which is understandable: a lot them simply love technology! Unfortunately, technology hardly ever solves the issue or addresses the real challenge, it just enables business functions.

In a worst-case scenario, technology can become one of the biggest enemies of an enterprise. For example, you might have the best plumber in the world, but if they start plumbing without knowing what problem needs fixing, you’ll still end up with a leak. The same is true for businesses. You can implement all the technology in the world, but if you don’t know why you’re doing it, you’ll find yourself vulnerable. From this point onwards, we need to start thinking security first.

So, this is an article about plumbing? Nope, it isn’t. It’s about DevSecOps and the best way to think about DevSecOps is to start thinking from the perspective of a potential leakage. But first, why should enterprises be implementing it and what pitfalls are they bound to encounter? In short: how can we be cutting-edge “plumbers”?

Providing guardrails

Security isn’t a menu. You can’t simply pick stuff you like and leave behind the rest. Here’s the deal: you have to do it all, from bottom to top and back again throughout your entire solution stack. That’s what we mean with intrinsic security.

Forget about ‘security by design’, that’s a marketing term. Security by design means nothing more than having to apply security measures on all levels, from the infrastructure to the customer access layer. This also includes your development pipelines and thus CI/CD (continuous integration and continuous development). There’s no such thing as doing development in an unsecured environment ‘since it’s not production’. You’re bound for disaster. Or better said, a huge leak. You have to do the plumbing right from the start – DevSecOps.

Unfortunately, there’s not a single accepted definition of DevSecOps. That National Institute of Standards and Technology (NIST) recently published a document titled “Implementation of DevSecOps for a Microservices-based Application with Service Mesh” by Ramaswamy Chandramouli. It states:

“It should be noted that there is no community-wide consensus on the term DevSecOps. As already stated, the term was primarily coined to emphasize the fact that security must be tested and incorporated in all stages of the software development life cycle.”

In an ideal world, DevSecOps would be an obsolete term since security is perceived as integral part of any software development and operations process. However, security in DevOps is often overlooked or underestimated. After all, DevOps is about autonomous teams that build and run the environments. They are end-to-end responsible, but that doesn’t mean that there shouldn’t be some strict guardrails. That’s what DevSecOps is about: providing guardrails.

In an ideal world, DevSecOps would be an obsolete term

Dev, Sec and Ops

As with DevOps, DevSecOps is not about tools. It’s about mindset and culture. When we want security to be implemented in every layer of our technology stack, we need to make sure that security is top of mind of architects and engineers. It’s not just the domain of the security specialists. It’s likely the biggest pitfall in implementing DevSecOps: not having everyone on board, including senior leadership.

In DevSecOps we are trying to bring together the three disparate worlds of Dev, Sec, and Ops that have been separate for a long time. You need senior leadership to bring these worlds together. Don’t think that it will happen automatically, or simply by implementing tools – magic isn’t real after all.

Developers are busy with developing new products, new features. They work on innovation and maybe even disruption. The problem with that is that it creates instability almost by default. Ops get paid to keep the lights on: they only want one thing and that’s stability. Stable environments will cause the least disruptions and, truthfully, the least amount of work. Finally, we have security who’s only task is to minimize risks. With every change in development, security needs to check what the effect will be on the ‘attack surface’. What new vulnerabilities might be introduced with the change? This is exactly the reason why DevSecOps is important.

By integrating security with DevOps processes, we make sure that security is involved from the moment the code is pulled from the repository up until the final release to production and the feedback loop. Making sure that security is also part of the continuous feedback loop is vital so that products and services are improved in security as well. Security must be part of the entire workflow. A vulnerability doesn’t just show up once a product is released in production.

Tip: have a look at the Mitre Att&ck framework and discover how many vulnerabilities you may have in the stacks and how attackers could exploit these vulnerabilities. Include that into your workflows, your CI/CD pipelines and the enterprise mindset as a whole.

No room for mistakes

One challenge remains, how can enterprises do DevSecOps the right way? First of all, include everyone from the leadership to the developers. It needs to be a cultural shift. Secondly, apply security to every component in the stack and have security policies, guardrails, and mitigating actions in place from development to production, including the feedback loop. Automating the security checks into the pipeline without considering the feedback loop is as good as doing nothing at all! Have policies and guardrails for container orchestration, CI/CD pipelines, service mesh components such as sidecars, Infrastructure as Code and Configuration as Code. Static and dynamic scanning must be mandatory. Penetration testing in every single release is a must.

Ultimately you need to do it all and automate it to the bone, counterfeiting for manual failures, or worse, shortcuts. There’s no room for leaving potential holes open. Finally, select the proper tools. Understand what they really do and if they suit the needs of the business.

That’s how you become the best plumber in the world.

There’s no room for leaving potential holes open

Jeroen Mulder, Principal Cloud Solutions Architect, Philips Precision Diagnosis

Jeroen is a certified enterprise/business architect with over 22 years of experience in architecture and consultancy in various tech domains such as cloud, DevOps and security. After a long career within AtoS and Fujitsu, he joined Philips in 2021. Next to his job, he’s the author of two Pack-titles 'Multi-Cloud Architecture and Governance’ and ‘Enterprise DevOps for Architects’.

Not content with just 2 books, Jeroen also has in the works: ‘Transformation into Sustainable Healthcare with DevOps4Care’ (Packt, planned Q3 2022) and ‘The Change to Modern Enterprise Architecture’ (Apress, planned Q1, 2023).

If you want to get in touch then give us a shout