DevSecOps — DevOps With Security

DecSecOps – why

The business goal always comes first.

Digital companies, which means virtually all enterprises, suffer from data loss, personal data leaks (GDPR!), and PR scandals which damage their reputation, causing significant money loss directly (lawsuits, damages paid) and indirectly (losing the trust of the consumers and business partners resulting in lower sales).

One of the reasons it happens is that very often so called security teams have been disconnected from the rest of the software development, delivery and operations teams. They are used for reviewing architecture documents, penetration testing and code security analysis, and what they are most famous for is creating and enforcing IT security policies (from time to time).

Is that a problem? It’s not a problem per se, but apparently this kind of approach is not good enough. Some argue it was never good enough, while less argue that it’s enough now and for the future.

DevOps revolution meets security

We are in the middle of the DevOps revolution. The DevOps roles are extensively sought out on the market and we are experiencing an explosion of cloud native infrastructures, Kubernetes, and the hybrid cloud, which are needed for faster deployments and a better automated software development life cycle.

Security as a shared focus

First of all, DevSecOps is about reminding everyone about security. Don’t forget about security and make this aspect as important as the actual software production and operations. Security, which always was supposed to be an integral part of the software development and continuous delivery lifecycle, is even more inside the process than an external remote process.

It also is inline with the meta trend of Full Cycle Development and Full Cycle developers.

Roles blend, responsibilities are not assigned to one team, and the security team is not separated. And most importantly, nobody is allowed to say ‘not my problem, ask the security team’. Of course there are people more specialized in security aspects and it’s their primary focus and responsibility, but everyone is invited and included in the constant never ending security process.

From the start

The second important message from DevSecOps is to start with the security aspects from the beginning, as too often ‘later’ becomes ‘never’ or ‘too late’. It’s much cheaper to address the security requirements and design from the start than at the end, before production deployments.

Security culture – break the silos

Building the proper mindset is critical and more important than any tools or processes. Without it, security becomes just an annoyance, which should be checked off as complete in order to focus on ‘more important things’ like application functionality.

Neglecting security, also by disconnecting it from the process, was a very common mistake that many organizations made in the past, now it is high time to change that.

Automation – security as code

With our strong metatrend of everything as code, security can’t be an exception.

Automated code security rules are built into IDEs and on commit leves, configuration checking, open source libraries’ vulnerability scanning, container security scanners and much more. It should be an integral part of your DevOps pipeline.

Security gateways, which allow an application to go to another test stage and production, are also a very good practice.

With frequent releases of smaller functionalities, they also help with accidental security regressions. They will be detected before reaching production or test environments.

Visibility problem

There are no visible rewards, no direct increase in sales, and no fancy UIs to showcase to the customers.  The problem with security is that it should be virtually invisible to the customer. It becomes visible only when their data is accessed by adversaries, for example, someone makes an illegal transaction on their behalf. But then the damage is done already, it’s too late.

→ Read more why Essentially, Data is good. It’s the use cases that can be problematic

This can be remedied with DevSecOps. Instead of planning the next big security review (too little, too late), it’s embedded in the process, as part of the everyday work of the team. The chance for a security mishap is much lower because of the increased frequency and closed feedback loops;  mitigation replaces reaction.

Feedback from operations

Despite all the efforts, security will never be perfect so it’s important to include monitoring of suspicious activities as a regular part of the general application monitoring.

Hackers may, and will, discover attack scenarios and data which nobody has thought of before, despite their best efforts. Of course the primary goal is to make it as hard as possible.

The second goal is early detection and fast reaction. Security fixes should be deployed ASAP as part of a well working Continuous Delivery and Deployment pipeline. Exposing the users for days or weeks is not acceptable and never was, but fortunately now with DevSecOps, the reaction times can be much faster which minimize the exposure time.

→ Explore more about What happened to NoOps?

Cloud tools

All the public cloud providers improved their security tools for their respective cloud platforms to help DevSecOps achieve the security goals easier and cheaper.

From DevOps to DevSecOps

The importance of security has grown recently with the rapid spike of digital sales of goods and services.

Those who rushed and skipped security aspects have experienced massive data leaks and lost many of their customers.

It’s hard to advertise security other than to promise your customers that you have taken steps to ensure your security is solid. Which everybody does, so nobody really listens anymore.

The real success in DevSecOps is that nobody is aware of the security. The secure and convenient authentication and authorization mechanisms and lack of security holes plus fast reaction times for security issues is something that we all as digital consumers expect, and nothing less.

And according to many experts, and I agree, no matter if you call it ‘just’ DevOps, actually it was, and is, and always should be DevSecOps.

Avenga is happy to help you achieve that with its DevSecOps and security services.