Long confined behind perimeter security, applications within an information system were protected with network equipment filtering the inputs and outputs of a homogeneous technical environment. However, this stronghold logic had a structural weakness. If the attacker managed to break into the secure perimeter, the compromise of the systems was greatly facilitated.
In the early 2000s, the advent of web applications and smartphones forced engineers to rethink their software designs. This multiplication of application entry points and associated data flows requires rethinking cybersecurity architectures.
From a paradigm where the user was known to the company, the application opened up to populations of users that were unknown and therefore less controllable. This change notably impacted equipment dedicated to security, such as firewalls. Initially designed to secure the incoming flows of the information system, the latter evolved towards the securing of outgoing flows but above all the analysis of traffic.
Rather than securing ever-increasing data flows and knowing that network bypass techniques were multiplying (as evidenced by the generalization of VPNs), applications have been secured from their conception. Connection methods have become more complex by lengthening passwords and then multiplying authentication factors with the use of smartphones. Payment forms and methods have become standardized. Users are now made aware of basic security rules.
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.
DevSecOps: 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 continuous improvement model. Teams develop small features delivered quickly. Then they identify potential design weaknesses by continually 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 law of 20 – 80. 20% of the main measures of security will make it possible to ward off 80% of the attacks suffered. It remains to be hoped that the remaining 20% of attacks are not too impactful…
The second criterion is scalability because application security is above all a process, which continues to evolve 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 is better to develop a culture of application resilience that promotes regular testing and deployment of patches for users.
This automated process between developers and operations is called “DevOps”. The consideration of security has enriched the term in an unoriginal way as “DevSecOps”.
DevSecOps or Secure Software Development Lifecycle?
While DevSecOps is the buzzword, it only reflects part of application security. Indeed, it designates more a collection of tools than a methodology serving a business need. Secure Software Development Lifecycle (SDLC) thus responds to this methodological need, making it possible to decorrelate the security of the tools alone in order to adapt it to the stages of a project. It thus completes the DevSecOps by bringing it the organizational side that it lacked.
This methodology brings together a set of measures and good practices, which depend on the application landscape, the methodologies used and of course the human skills in order in particular to model the threats and implement their remediation. As such, tools such as the OWASP Threat Dragon facilitate the implementation of this approach, particularly with regard to:
- Planning attack scenarios (1st stage of design)
- Writing the resulting security tests
- Updating applications based on threats encountered in production.
In response to this organizational component, DevSecOps enables the process to be equipped with solutions that have become specialized over time. What they have in common is their ability to automate various tasks.
Let us first mention the analysis of the security of the code through SAST tools – Static application security testing or DAST for more Dynamic scenarios .
A SAST solution thus allows developers to detect application vulnerabilities in their 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, error handling etc. The two solutions are regularly used in tandem.
Vulnerability scanners often take over during the testing and production phases to consolidate a more global security vision.
These solutions are of course not exhaustive. They are examples of a rich and polymorphic universe, which constantly adapts to external threats as well as to the uses of developers.
On the other hand , it is important to mention that if these tools make it possible to identify vulnerabilities individually, it remains complex to establish with these tools attack scenarios successively combining several vulnerabilities.
DevSecOps evolution perspectives
While there are many development prospects, a third type of tool testifies to the impact that artificial intelligence could have within application security. These are the RASP – Runtime application self-protection, which constitute a small revolution in terms of application security. Monitoring user usage in real time, the objective of these solutions is to detect and block attacks by taking advantage of information from the running software via 2 methods:
- An environmental diagnosis to collect attacks and events in order to enrich the antiviral databases and thus allow companies to have in-depth knowledge of their threat environment.
- Protection of application uses by intercepting a priori the instructions that could compromise the application behavior defined as standard.
These solutions remain expensive to implement and generate false positives. They are therefore aimed at large companies but nevertheless remain an exciting playground in which ethics and the monitoring of user behavior are at the center of attention.
Far from a fixed and sclerosing image for users, application security is a constantly changing environment. It is available through its methodological side, Secure Software Development Lifecycle , implemented by a rich and varied tooling structured around DevSecOps. This booming field sees solutions specializing to respond to an ever more specialized technological context. The challenge is to guarantee user confidence in their use of the solutions.