Can Security issues be reduced with DevSecOps

Author- Arindam Bhattacharya

DevSecOps merely cannot improve security unless there is a cultural shift. Security incidents/ issues could have been come down long before if there was proper attention given to the security processes. When we talk about any processes it is driven by both manual and automated processes. 

While automation works best when the processes are made straight forward and desired outcome is known in advance but if this is not the case, intervention of manual process is what all needed. All gaps, incompleteness of the processes.are.because of such manual dependencies.

DevOps pipelines helps to achive automation across the development and operational lifecycle but when security needs to be embedded, this require the same pipeline extended to security lifecycle as well. There are some practicality that works against this idea as because not all security processes can be invoked automatically. 

For example - post a development module is set to form production, it needs not only a static and dynamic security testing of the module but also to extract the risks. The security tools are capable to objectivise the risk but it's not always useful in business context without proper assessment and analysis. So, the security processes are time consuming and thinking to achieve these steps in a automated.way.would be ending up to incomplete/ low quality information. 

So, how do we trigger a sub security process? The Devops tools must have an integration with the required security tools through scripts or any other technologies. Once all security testing is done, risk is extracted, findings are mitigated and go ahead is received from the security team, devops must return to its original pipeline state to invoke next steps (for example code check-in and deployment in the cloud)

So, it's clear that the process needs a bigger wait time even though readiness of development and operations team is right there. This is the major challange of the success of DevSecOps. By name it's perfect but by output not so perfect.

Perhaps we need to have some answers that even after so many good processes, required solutions in place, why applications are still vulnerable? - it's evident that the above processes not sincerely followed and implemented in a hurry. There are some more issues that contribute in this list:

1) Lack of attention on security during development

2) Abruptness in adoption of technologies  during integration without proper Risk assessment.

3) Core vulnerabilities associated with IDEs/ Platforms ignored.

4) Not having used security enabled IDEs during development that can atleast point out code lebel flaws so that many issues can be sorted out during development itself.

5) Insufficient time reserved for Security Checks. Mostly no time to perform a full security UAT.

6) Insufficient time reserved for vulnerability fixation that may also required code level changes.

7) Risks in underlying systems/ platforms/ abstraction layers

8) Lack of modernization initiatives before transformation.

When the code is multidimensional, the complexities are going to be more due to full access/ visibility.issues  of code repositories of all inhabitants of the application. 

It's a time taking process that may need coordination and so automation here is just conceptually possible. The risk is where, we are adding more stages, more plugins, automated scripts to do the job and the inherent risks introduced by those stages are entirely forgotten. 

Security challanges of today is not a feature extended by a tool that promise to sort out some challenges but the tool itself is another reason. The fact that is overlooked, is the privilege that such tools are running and the possibilities of risk starts right there. There are chances that persistent threats are hiding behind, carried by a natural trust. 

While machine learning, AI, touch free, Stateless protocols etc. try solving great problems but leveraging them to solve basic security issues  can add some relief. 

Let process take its own time but too much emphasize on automation will make the security more difficult.