Some FAQ about DevSecOps

How long has the DevSecOps methodology been around?

It is difficult to determine with any certainty when DevSecOps emerged, as the methodology has no identifiable author. From 2009 to 2010, the DevOps movement emerged—a methodology of interaction between the teams developing and operating software products. At the same time, the trend toward application security was developing, since the number of hacker attacks successfully launched through application vulnerabilities was growing by the year. And gradually, it came to be understood that security must be included in the DevOps cycle. Before the DevSecOps methodology arose, security was not incorporated in the design, code writing, and testing phases of software development. As such, it was not uncommon for serious vulnerabilities to be discovered in applications just before they went live. The launch had to be postponed, and development had to backtrack to patch all the vulnerabilities, which took time and was very costly. With the rise of DevSecOps, security checks began to be implemented at the earliest stages of the software life cycle, allowing you to have a secure product by the time it goes into production.

Are there alternative technologies for secure application development? What are the advantages of DevSecOps over the alternatives? What are the disadvantages?

DevSecOps is not a technology, but a model or approach that allows security to be built into software development and operation. In fact, you can apply any technology that allows you to improve the security of the product under development. You can build models of how development, safety, and operators interact. The main advantage of DevSecOps is that it is based on the “Shift Left” principle: finding defects as early as possible by all possible means.

What results can be expected from implementing DevSecOps? How justified is it economically?

Since it’s not a compliance standard or a “launch and forget” technology, if a company has deployed at least some elements of DevSecOps—processes in which security checks the code for vulnerabilities and interacts with developers—we can say that DevSecOps is implemented at a basic level. True, there is no fully mature system that automatically tests the code, but there is a basis on which such a system can be implemented. And there is no limit to perfection—you can increase the maturity of the process and its automation. But the most important thing you should avoid is abruptly starting your life on Monday from scratch: it is important to develop existing DevSecOps processes and implement new technologies progressively, gradually increasing the level of development security.

When a company’s security is fully integrated into the development process and code review is automated, you can expect at least a two-fold reduction in the time it takes to fix vulnerabilities and bugs in the software code.

How time-consuming and expensive is it to implement DevSecOps?

This largely depends on what the development team already has, what components are being used—what CI/CD servers are used, what languages the code is written in, what specialists are on the team, the scale of development—and much more. It may turn out that all the necessary people and tools for DevSecOps implementation exist within the company, and it will be easy and inexpensive to buy a few more things and fine-tune the processes. But it may turn out to be the opposite: the development is weak, and the security process is entirely absent—then it will be both time-consuming and expensive. In this case, it will be necessary first off to invest in building the process. And only then apply technology on top of it. Thus, the costs of implementing DevSecOps can be spread out so that they do not place a heavy financial burden on the company.

What tools are used to automate the processes?

Different tools are used at different stages of software development. At the stage when the source code is checked, the technologies that work with the source code are applied. These include static application security testing (SAST), software composition analysis (SCA), etc. As for the stage at which the finished application is awaiting operation, here we apply a binary analysis, dynamic analysis (DAST). These are all components of application security. In general, there are no strict requirements for the use of one tool or another. For example, if an application has already been developed and needs to be launched but a vulnerability has been found in it, you can protect it with WAF while the vulnerability is being fixed by the developers. DevSecOps is a model, so all application security technologies apply here.

As surveys show, DevSecOps adoption varies around the world. Why do some companies take their time?

Some companies take their time because DevSecOps is not a cash-and-carry solution. It takes a lot of work to improve the maturity of software development, operation, and security. It is important that the entire internal process is run intelligently. However, there are times when a company lacks the resources to increase maturity. Alternatively, there is a lack of knowledge: the team simply does not have any person with the necessary expertise to move the entire project forward. The latter problem is particularly difficult to solve because hiring specialists with such knowledge—ready-to-go security managers—is very difficult; there are almost none on the market. So the process is ongoing, but slowly. It also depends on the scale of development and operation: if the development is not large-scale, then, in general, the company can do with occasional checks of the software for vulnerabilities, without establishing a serious process.

The situation worldwide is very different. In the United States, for example, business processes in companies are generally more mature: they are used to competently build processes, develop methodologies, and strictly follow them in practice. Constantly improve the level of security. Generally speaking, all the quality standards of business processes worldwide come from the United States. At the decision-making level, the DevSecOps methodology is a must.

If we consider Southeast Asia, there are countries in the region where the level of maturity in DevSecOps issues is average. And there are lagging regions that are little aware of code security; thus far, only antiviruses, firewalls, and other superimposed means of protection are mastered.