Nicolas Engel

Idea(ls) on cybersecurity

DevSecOps – A bird in the hand is worth two in the bush.

Defensive security has always been less popular than offensive security. Its reactive function against attackers taking the initiative is simply less attractive. The fiction is also not mistaken in showing little hooded geniuses play complex systems with ease while ignoring the players of the opposing team. For there to be a match, there must be an opposition, but that is not the question. This Manichaean vision being reduced to an “attack – defense” hides the ability to anticipate and prepare for threats. We too often forget that defensive security does not only consist in parrying attacks in real time but also in securing information systems (and the people who go with them) upstream.

“Security by design”, quesaco?

Long confined to perimeter security, applications in an information system were protected by firewalls, the use of a VPN and network segmentation. This bastion logic gave a false impression of security for the applications within the information system, in particular because the fraudulent uses of the company’s collaborators persisted. However, internal threats remained less numerous than external ones because users were and remain more easily identifiable.

In the early 2010s, the advent of mobile devices (smartphones, connected objects) and applications communicating via the web forced engineers to rethink their software designs by securing application entry points and data flows.

From a paradigm where the user was known to the company, the application opens up to populations of users that are unknown and therefore less controllable. This change has a strong impact on all equipment dedicated to security, such as firewalls, which originally secured incoming flows. They experienced a double evolution with the securing of outgoing flows – by limiting the opening of ports in particular – but also by analyzing the traffic and the packets exchanged (via deep packet inspection techniques and the introduction of IDS – Intrusion Detection System) .

Rather than securing ever-increasing flows and knowing that techniques for circumventing network monitoring tools have multiplied (as evidenced by the massive use of VPNs), applications have been secured from their conception. Connection methods have become more complex by lengthening passwords and then multiplying authentication factors – a password supplemented by a fingerprint, for example. Payment forms and methods have become standardized. Users are now made aware of basic security rules. And despite everything, attacks on software and web applications have continued to increase.

Faced with this growing threat, a set of methods and tools have emerged to standardize the security of software developments and thus respond to the professionalization of attacks.

Automation at the service of security

Rather than pretending to secure an application against all potential threats, a method that turns out to be costly and inefficient, engineers favor pragmatism and scalability.

Pragmatism because modern development methods favor short iterations according to the model of continuous learning. Develop small features to deliver quickly. Then, identify any design weaknesses by continuously testing and deploying to users. What is valid for application development is just as valid for security. Once the basic rules have been implemented – it is still necessary to agree on them – realism prevails by identifying the major risks that one wishes to cover according to the famous Pareto principle of 20 – 80. 20% of the main measures of security will make it possible to prevent 80% of the attacks suffered. Let’s hope that the remaining 20% of attacks won’t be too painful…

The second criterion is scalability because application security is above all a process, which is constantly evolving to adapt to the application scope but also to techniques and attacks that diversify over time. There is no point in having comprehensive countermeasures if they quickly become obsolete. It makes more sense to develop a culture of application resilience that promotes automated testing and regular application deployments that are as transparent as possible for users.

This automated process involving developers and operations is called “DevOps”. The consideration of security has enriched the term in an unoriginal way as “DevSecOps”.

DevSecOps and Secure Software Development Lifecycle?

If DevSecOps is the buzzword, in my opinion it only reflects part of application security. Indeed, it designates a collection of tools and not a methodology serving a business need such as the Secure Software Development Lifecycle (SDLC). This methodology makes it possible to decorrelate the security of the tools to adapt it to the stages of a project. It thus completes the DevSecOps by bringing it the organizational side that it lacked.

It brings together a set of measures and best practices, which depend on the application landscape, the used methodologies and of course the human skills in order to model the threats and implement theirs remediations. Tools such as the OWASP Threat Dragon facilitate the implementation of this approach, particularly with regard to the following steps:

In response to this organizational aspect of application security, DevSecOps provides the approach with increasingly sophisticated solutions over time. Their common point is their ability to automate various tasks such as:

Code security analysis through more or less complex scenarios (SAST tools – Static application security testing or DAST for more dynamic scenarios) such as Klocwork for example. A diagram being worth more than a long speech, the added values of such a solution are as follows:


A SAST solution allows developers to detect common flaws in their application codes, whereas a DAST solution is more aimed at testers to assess the security of a solution through a complete functional scenario including configuration problems, processing errors etc. The two solutions are regularly used in tandem. These solutions are mostly used in the development and application test phase.

Vulnerability scanning such as OpenVas often takes over during the testing and production phases to comprehensively test the application via vulnerability databases available online such as CVE (Common Vulnerability Exposure) analyses.

These solutions belong to a rich and polymorphic universe to which I will probably return in another article. In summary, it is worth mentioning that if these scanners make it possible to update their vulnerability database easily, it remains complex to establish with these tools scenarios that successively exploit several vulnerabilities in chain.

Finally, the third type of tool is made up of RASPs – Runtime application self-protection, which constitute a sort of Holy Grail in terms of application security. Monitoring application instructions in real time, the objective of these solutions is to detect and block computer attacks by taking advantage of information from the running software via 2 methods:

These solutions remain expensive to implement and generate many false positives. It is therefore aimed at large companies but nevertheless remains an exciting playground in which ethics and the monitoring of user behavior are at the center of attention.

Application security is divided into two parts via its methodological side, the Secure Software Development Lifecycle, and its tooling side, consisting of DevSecOps. A booming field, the tools are multiplying and specializing to respond to an ever more specialized technological context. From a monolithic approach to security where applications were secured in a perimeter manner, the current evolution advocates a component-based approach allowing multiple layers of defenses.

“The elephant dies, but its tusks remain.”

African proverb

Leave a Reply

Your email address will not be published.