If you know the term “nightly build”, chances are you’ve used it at least once. A nighlty build is a code compiled overnight from another automated code and previously verified. This is a formidable means of identifying vulnerabilities that arise as a result of changes made during lengthy compilation processes. However, although it is an essential part of DevOps, nightly builds Also have drawbacks: if new bugs are discovered the next morning after a night of compilation, everything slows down. Worse, this practice perfectly embodies the partition between development and security, since it compartmentalizes the tasks that developers and security professionals must undertake every day (or, in this case, every night).
The history of the divide between security and development is not based solely on the nightly builds, on the contrary. It has its origins in a set of misunderstandings, through which developers often see security officials as systematic blockers to production, whenever a vulnerability is highlighted. In this context, security officials do not have the knowledge to understand the lingo, processes, or goals of the developers. Historically, the two parties have always worked in their own compartmentalized departments, without any desire for rapprochement.
How to unify security and development?
Establishing an effective bridge between the two teams would, however, allow a more secure code to be developed without sacrificing the speed necessary to meet deadlines. But this is a cultural problem. The development and security teams must therefore find common ground in order to work together, understand exactly how each works and interact effectively.
On the developer side, that means better appreciating the value of security and sharpening the skills they need to design more robust code. On the security side, it means understanding the deadlines, tools and processes of the developers, then working with the hierarchy to find out how to integrate the security tools.
According to a recent Securosis report, this pooling must bring together members of all the necessary teams. DevOps is not enough for this purpose, as it only deals with infrastructure, security testing, and code issues. It must take into account that development (Dev) and operational (Ops) offer a plethora of possible resolutions to most vulnerabilities, when they integrate security teams early enough in the software lifecycle. So once these team members get together and openly chat about current vulnerabilities and business goals, they can put in place processes and tools that will improve the security state of their applications, without compromising the deployment speed.
Know where to start to address vulnerabilities
Security debt is a pitfall that accumulates over time and should be dealt with with an action plan to reduce it and prevent risks. But not all vulnerabilities are critical, whether they are in a security debt or have been discovered in a lot of new vulnerabilities as a result of a recent scan. However, only a developer cannot prioritize these threats properly.
Deciding which vulnerabilities should be addressed as a priority is a common issue for development teams. Many security professionals claim that all
vulnerabilities tend to appear as priorities for developers, when it is actually very difficult to differentiate one flaw having an impact on the entire IT ecosystem from another more anecdotal.
Establishing priorities can therefore speed up the whole development process. While helping to prioritize, security teams can help developers understand which vulnerabilities need to be addressed immediately during the development phase, and which possible threats are linked to unmonitored vulnerabilities. The bottom line is that developers have a better understanding of how to prioritize possible flaws.
IT development companies must therefore be both agile and secure. From this perspective, DevOps is no longer sufficient. That’s why security and development teams have to work in unison to produce code that is more robust, less costly, and compliant with regulations. It is an essential internal communication that does not sacrifice innovation or speed of deployment, on the contrary.
By Nabil Bousselham, Principal Solutions Architect at Veracode