Among the various development models such as waterfall, spiral, etc, the popularity of DevOps, which is based on Agile methodology, has grown drastically in the past few years. The global DevOps market is expected to reach $17.8 Billion by 2026, as per a market study by Global Industry Analysts Inc., (GIA).
DevOps is based on the Agile methodology where teams are dynamic. When requirements come in, they are added as part of the life cycle. Therefore, the changes can be incorporated in a short time frame. The DevOps process requires a shift in the collective mindset of people, process, and approach to deliver better applications in a streamlined approach with in a short timeframe. However, to ensure optimal security in agile development models, a DevSecOps approach is much needed.
DevOps can be Short-sighted on security
In the traditional waterfall model, teams are independent. As part of the process, development teams will deliver to the testing team. The testing team will then test and send the report to the development team. So, while there are several other challenges present in the waterfall model, security is integrated into the process.
DevOps follows a different approach where each phase has its own tool to achieve a particular functionality, and there is some automation to cover any gaps. The development team will develop the code and push it to a code repository such as GitHub or Bitbucket, which stores all the code developed by teams across the globe.They also maintain and manage versions using tools such as Git (versioning system). If other teammates require code, they can pull it from the repository. With Github and Git as part of DevOps, it is simple to see who made changes and what the changes are.
From DevOps to DevSecOps
When security tools are integrated into the DevOps pipeline, it is referred to as DevSecOps. Many DevOps based companies do not have security integrated into their DevOps pipeline. However, if teams are reluctant to incorporate security whether it is due to time or resource constraints, it can lead to gaps in the application. Whether they are using Static Application Security Testing (SAST) or Dynamic Application Security Testing(DAST), there can be gaps in the testing methodology if a standard is not followed. In most cases, in a pure DevOps company, security is the aspect that is overlooked and not up to the mark.
By contrast, in DevSecOps, security becomes a major part of the operations and development phase. Developers adopt tools to ensure that security vulnerabilities are addressed,right from the time they build applications. This simply means that they are thinking about the security too, rather than looking only at the performance and functional aspects.
Whether it is during production or operation, the team must make an effort to ensure that the operating system, servers, ports etc. are all secure.
In a DevSecOps model, a security code reviewer reviews the code and canmake their observations then and there rather than waiting till the application is developed. Any build is pushed to different environments, both production and non-production environments. Things are tested in non-production environments before being put into production.
Tools in DevOps have integrations with each other. Tools such as open source automation server Jenkins can operate across all the development phases and raise alerts to the development teams. If Jenkins is integrated into CI/CD tools, it can provide feedback to the development/testing teams. Though some manual involvement is needed, much of the process is automated.
Development teams can then ensure that the suggested changes are reflected to the client in no time. These changes need to be deployed to all environments through a Continuous delivery (CD) model.
Inbuilt Security, Rather than as an Afterthought
Given the rapid pace of developments in the technology world, building new products and deploying them in a specific time frame becomes very important. Understandably, the focus there is more on the functional aspect, ensuring that the product runs perfectly and delivers on its intended function. Often, organisations underestimate the existing security threat simply because their organisation hasn’t been hacked. But this approach is short-sighted.
It is true that placing emphasis on security can often seem inconvenient. After all, security teams might raise red flags on what seems like a perfectly executed product. Training teams to develop a security mindset requires investments in training, tools, internal alignment, and even consultancy from vendors such as Entersoft. Besides, there might be a fear that putting security in place might slow down the development process. There is also a mindset that ‘hackers are unlikely to target us’.
As a result, the temptation is huge to put security on the backburner during initial stages, and bringing in a security budget only once the product is widely available to customers. However, this approach is not optimal and has a number of pitfalls. Some of the advantages of early intervention through a DevSecOps models are:
· Mitigating Vulnerability: When security is done as an after thought and the company finds security issues at a later stage, they can feel extremely uneasy and vulnerable.
o For example, this opens up the possibility that the system might already have been hacked in the past and the company has no way to trace it.
o The system might already be in stealth mode, waiting to attack at the right time.
· Protecting Reputation: Early adoption of security helps protect the company’s reputation since end users and customers are not exposed to any vulnerabilities.
· Saves time and money: Despite the initial investments, a DevSecOps approach helps save time and money spent on security in the long run. This is especially true for industries such as financial services and healthcare that maintain highly confidential and sensitive data, with compliance deadlines.
The shift from DevOps to DevSecOps might feel complicated, how the benefits of this shift will be apparent in the long run.