The need for modern applications to support continuous integration, delivery and deployment spawned the need for DevOps. Increasingly, as cyberthreats evolve and grow and application development methods and time frames change, security now needs to be an integral part of today’s application life cycle. As a result, businesses should move from DevOps to DevSecOps.
DevSecOps is needed to address security implications introduced by changes in the way applications are now developed, deployed and updated. Some of the main drivers for moving to DevSecOps include:
The speed and frequency of new apps creation and updates: It is no secret that developers are under great pressure to create new applications and features in faster time frames than ever before. Some industries such as banking and financial services are being challenged by nimbler FinTech organizations offering innovative services and better customer engagement. The same is true in retail versus online competitors. And most other businesses are in the midst of a digital transformation. All of this necessitates the development of more apps in shorter time frames.
As the industry knows from DevOps, app development is just one part of the more extensive application lifecycle work that needs to be done. Here again, there is a change from tradition. Beyond the customary needs to update, patch and maintain applications, today’s users are accustomed to quick actions on their demands. They have an app store mentality. When they point out a flaw or suggest an enhancement, they expect these things to be addressed immediately.
They want the same responsiveness in their business applications. It is no longer enough to put items in a Jira or some other project tracking solution for later consideration; actions must be taken immediately.
In both the building and enhancing of the apps, the need for speed can overlook security issues.
Cloud-native architectures: Many modern apps are built using cloud-native architectures based on loosely coupled microservices and containers. The architecture lets developers quickly build and update applications. The approach typically makes use of third-party and open source code to build a larger application. For instance, a loan processing application might include an open source decision engine, an outside financial institution’s credit rating service and a commonly used mobile app user interface.
Another advantage of using a cloud-native architecture is that changes can be made quickly. Rather than writing a monolithic app from scratch or recoding an entire app when small changes need to be made, changes only need to be made to impacted elements. If a new feature needs to be added to a front-end mobile user interface, that’s the only element of the app that must be changed.
These conveniences that make cloud-native so well-liked in the development community, again, can mean that security issues are overlooked.
Low-code/no-code and composable applications: New technology such as low-code and no-code platforms abstract details about the code from developers. And they enable citizen developers, who certainly do not have an eye for security, to build their own apps. Composable techniques further simplify application development via the reuse of components.
Bringing Security Into DevOps
The implication of these industry changes is that security needs to be entrenched in the process throughout an application’s life cycle. It is no longer enough to test for vulnerabilities after the fact.
Specifically, security operations must be integrated at every step of application development, modification, and deployment. It must be real-time instead of reactive. Security can no longer wait for a breach or attack; it must constantly examine the elements of an application as they operate and are modified.
Additionally, DevSecOps is increasingly needed to find weaknesses and vulnerabilities due to hidden dependencies in today’s cobbled-together applications. The bottom line is that implementing cybercrime protection at the code-level and secure coding practices are lower cost, more efficient and more effective than trying to patch security holes in a finished application.
