In 2019, for the first time ever, the amount of companies that were affected by at least one cyberattack has exceeded 80%. This ridiculous figure is particularly alarming as the goal of these attacks is in many cases to gather information. While many companies are expending lots of effort on optimizing continuous integration/continuous delivery (CI/CD) processes, security often still plays a subordinate role, making it very easy for hackers to find vulnerabilities within applications and exploit them.
Since traditional security approaches cannot keep up with the increasing complexity of cyber-threats, it is crucial to assign a new role to application security. A modern-day software development method that does this best is DevSecOps. DevSecOps extends the outdated approaches of DevOps and Agile by adding suitable security testing methods alongside every single phase of the software development lifecycle (SDLC), creating a dynamic and continuous testing process.
This article will give you a better understanding of DevSecOps by answering the following questions:
Software Development: a variety of computer science activities aimed at conceiving, deploying, designing and supporting software. The main focus lies on writing and improving the source code.
IT Security: a set of measures that can be implemented to reduce the risk of malicious software attacks by identifying potential vulnerabilities within an application. Find out more about different security approaches in the AST Report 2020.
Software Development + IT-Security + IT-Operations = DevSecOps
DevSecOps embodies all of these practices of former models with the goal of making security a priority for everyone involved in the software development process. While DevOps and Agile were very innovative and disruptive at the time, they are unable to cope with the security demands of the shorter modern-day SDLCs.
DevSecOps should not be seen as a replacement for these models, but more of an add-on, which extends these existing approaches, by placing more value on security. While testing was done in a very centralized way, based on the classic V-Model, in DevSecOps testing is done by executing appropriate security controls directly within the various delivery teams.
Depending on the phase at which the testing is done, a mix of static, dynamic, interactive and feedback-based testing approaches (fuzzing) are used in DevSecOps.
Integrating DevSecOps into the CI/CD pipeline is not something that can be done within a day. Let’s have a look at the tools and practices required for a successful transition:
If you want to drive change towards implementing DevSecOps in your company, the first step needs to be cultural acceptance. If this is not already the case, it is crucial to build up a security culture and to create a consensus, that everyone is responsible for security.
Since testing will no longer be done only by security experts, but also by “normal” developers, the usability of the testing tools will play a big role. Traditional security approaches are insufficient for security testing during the many phases of a DevSecOps cycle.
Implementing too many tools can be tricky, as this makes it difficult to supply the CISO with conclusive analytics and reports. Versatile testing tools, that are multi-operational among the different stages of the CI/CD pipeline can be very helpful, to maintain an overview and draw conclusive KPIs.
A solution that meets the usability needs of developers, as well as the analytical needs of management is CI Fuzz. The testing platform is very popular among DevSecOps professionals since it offers a very effective but simple testing solution, based on modern fuzzing.
As mentioned before, the main challenge of introducing DevSecOps is in most cases the culture. In many companies, software development and application security are divided into different teams, that sometimes work together and sometimes work against each other.
This “dev vs sec” mentality can be problematic when the roles of the team members are rearranged. Making everyone responsible for security inevitably means that developers will have to get the hang of security practices.
This can very well lead to some resistance and obstacles, especially right after introducing DevSecOps. However, security professionals will certainly not become obsolete, since manual testing will still be required, especially when it comes to logic and design flaws. Another challenge arises from the so-called “Clash of Tools”, which describes the necessity of introducing new tools, in order to be able to conduct tests throughout the whole CI/CD pipeline.
Because the start is often rocky, the biggest challenge when integrating DevSecOps is “not giving up”. DevSecOps will improve your application security, but it will not eliminate 100% of bugs and it will probably come with some difficulties in the beginning. So set yourself realistic goals and don’t go chasing after perfection!
Although it may not sound like much, adding the three letters “Sec” to a DevOps cycle is a big change for everyone involved. Creating a security culture takes time and patience, but no later than when it is established, everyone on the team will understand its value.
In modern software development, there is no way around security. The earlier you catch on to it, the better. DevSecOps offers an approach that elevates the importance of application security to a higher level, leaving little to no room for hacker attacks. It is no question that integrating this security benchmark comes with some challenges, but overlooking security issues will leave you with much more devastating problems in the future.
Get our free Application Security Report 2020 to stay on top of the latest developments in AppSec: