DevSecOps - In the thick of things instead of just being there

We remember: in 2009, Flickr kicked off a major rethink of development processes with its "10+ Deploys per Day: Dev and Ops Cooperation" talk.

At that time, development and operations were strictly separated and the operations teams were handed a "finished" product for operation at the end of the development process. Errors that only manifested themselves in operations were reported to the development team, which then fixed them - outside the operations environment.

This time-consuming methodology has proven to be a bottleneck and innovation killer, especially in the area of web application development. With DevOps, developers and operations are now supposed to be in the same boat and take over updates in smaller units and much, much shorter cycles into the productive environment ("deploy").

To this end, many tasks are automated as far as possible and executed continuously in the background. Errors are thus detected and addressed earlier. The entire process from development to operation should literally become more "agile" and thus faster.

According to the "DevOps 2017 Trend Study", only slightly more than half of the companies in Germany are using DevOps, and in many cases they are still at the first stage, the actual implementation of DevOps.

In the SAP environment, which is traditionally much more segmented (OS/datacenter, DB, Basis, application), this figure is probably much lower. After all, the "never touch a running system" adage applies much more strongly to mission-critical applications than to other web applications.

Also, many of the concepts of DevOps, such as continuous integration and automated unit tests, are difficult to integrate into traditional SAP development processes. As a result, DevOps - even before it has really arrived in the SAP environment - has already become obsolete again, or rather has been supplemented.

Because if security becomes a criterion for the operation of applications and, just as functional defects before, has the potential to send the results of the agile DevOps process back to the drawing board, then security should also be integrated into the development process early on.

This is precisely the approach taken by DevSecOps. Security experts should not be entrusted with securing the finished product "from the outside", so to speak, but should identify the gaps that could become security problems during operation "upstream", i.e. early in the software development lifecycle, and prevent them - ideally through better, more secure code.

Even if some DevOps concepts cannot be transferred one-to-one to SAP development, the fact remains that many of the "critical" or even "hot news" security notes of recent years could have been avoided by consistently integrating security into the development process. The same applies, of course, to the average of two million lines of custom code that exist in productive SAP systems.

Tools that make many of the agile DevSecOps approaches possible in the first place are numerous in the SAP area: from excellently integrated tools for static code analysis, static code security testing (SAST) to test automation of packaged solutions.

Such tools and the continuous cooperation and combined brainpower of SAP developers, security experts and operations teams inevitably lead to the avoidance of many obvious security blunders in custom code. Security is built into the code instead of being imposed from the outside.

Given the average cost of an SAP security incident, which according to a study by the Ponemon Institute is $4.5 million, companies should be highly motivated to apply DevSecOps concepts to SAP application development as well.

But maybe there is just a lack of the right buzzword? In that case, I'd like to throw DevSecSAPOps into the ring.