In the modern world, software is everywhere. Software houses and programming enthusiasts produce millions of lines of code that other specialists use transparently. Maintaining a high level of security for such software snippets is essential, but unfortunately, this level of security is not largely met.

Nowadays, whether an application consists of just a few lines of code or is a big and complex program, it most likely relies on additional libraries. Those dependencies facilitate the developer’s work, speed up the creation of a product, and significantly enlarge the code base… as well as the number of bugs. Also, considering that code is written by people – and no one is infallible – it’s impossible to have an entirely bug-free piece of software. The code review process helps to eliminate software bugs, but the outcome is also prone to human error.

Pourquoi l'audit du code à la recherche de vulnérabilités est-il important ?

Le test d'intrusion is a time-limited operation, so finding all the security issues during the process is almost impossible. Due to limited budgets, companies often take the black box approach, auditing software without prior knowledge about how the system works. Black box testing further limits the likelihood of finding security bugs. 

Même une équipe de spécialistes en cybersécurité sera incapable de détecter chaque problème. Le temps disponible pour réaliser des tests en boîte blanche est limité, de sorte que certains bugs peuvent rester non détectés.

Malheureusement, les cybercriminels ne sont pas limités par le temps ni par l'argent. Ils disposent de ressources illimitées pour analyser le logiciel et trouver les failles de sécurité qu'ils peuvent exploiter.

Pour prévenir une cyberattaque réussie, il convient de réaliser une revue de sécurité du code. Il s'agit du processus d'inspection du code source visant à détecter et à éliminer les vulnérabilités et les failles de sécurité.

L'évaluation peut être réalisée comme suit :

  • manuellement par une personne,
  • de manière automatisée, à l'aide d'outils de revue de code de sécurité,
  • ou en combinant ces deux approches.

Revue de code de sécurité vs revue de code

Alors que les revues de code classiques se concentrent sur la qualité du code, les revues de code de sécurité se concentrent sur ses aspects sécuritaires, comme la concaténation de chaînes dans les opérations de base de données ou la configuration de l'authentification.

A security bug is a specific type of software flaw that allows an action, that the application’s author didn’t intend, to take place. For instance, the wrong application parameter handling can lead to an attacker injecting additional SQL queries and retrieving sensitive data, like passwords, from the database.

Comment réaliser une revue de code de sécurité

Il n'existe pas de méthode structurée pour réaliser une revue de code de sécurité, bien qu'elle puisse être effectuée à l'aide de normes reconnues telles que :

  • OWASP TOP 10,
  • Mitre Top 25 des faiblesses logicielles les plus dangereuses,
  • PCI-DSS,
  • ou HIPPA.

Tout programmeur devrait connaître les normes et consulter au minimum la fiche pratique OWASP TOP 10. Bien entendu, il doit également respecter les normes de sécurité internes de son organisation.

Si elles sont appliquées, ces connaissances peuvent augmenter le niveau de sécurité du code dès la phase de développement.

Revue automatisée du code de sécurité

Outre l'analyse manuelle du code, l'audit peut être réalisé à l'aide d'outils automatisés de revue de sécurité du code. Ils peuvent être divisés en deux groupes :

  • SAST – Tests de sécurité statique des applications,
  • DAST – Tests de sécurité dynamiques des applications.

Test de sécurité des applications statiques (SAST)

SASTtools are simple scanners with rules that aim to find the code’s patterns. The effectiveness of this approach depends on the quality of the set rules. SASTtools are language-dependent, so if the software is written in a rare programming language, in some cases the automated analysis cannot be performed. Regarding the Cycle de vie de développement logiciel sécurisé (S-SDLC) framework, l'analyse SAST doit être déclenchée pendant le processus de build de l'application afin de détecter les problèmes de sécurité le plus tôt possible.

Tests de sécurité dynamique des applications (DAST)

DAST tools are independent of the technology stack. They test and exploit the application during its runtime. The DASTtools don’t need to access the source code, which is a significant advantage in some situations. Their main drawback is that they can’t find all the security flaws; what’s more, to interpret the results, technical security knowledge is required.

Outils d'analyse automatisée de la sécurité du code

Tools can also help to find “low-hanging fruit” when dealing with large amounts of code. Most of them are grep-like tools which look for a predefined sets of rules, keywords, or technology-specific functions. For instance, (Java Spring framework case): find the following piece of code: “csrf().disable()”; if this code is found, report this situation as a security issue as the anty Cross-Site Request Forgery mechanism is disabled.

SonarQube or semgrepen sont des exemples ; les deux sont des plateformes open-source pour analyser le code statique afin de trouver des bugs et détecter les vulnérabilités dans les dépendances.

There are also tools that offer a more advanced approach enabling the use of internal language, writing advanced rules and querying the code. They can even handle queries such as “find all the methods” (while in object-oriented programming, “a method” is another term for a function), where code responsible for authorisation is not present. 

A greater range of possibilities also requires greater domain skills. To write such queries, one should have a certain degree of security knowledge, that may be regulated by the code writing style. For external auditors this approach is prone to false positives and false negatives. However, it can be an excellent solution for engineers that are part of an internal development team.

Surveillance des dépendances

As mentioned, dependencies are an integral part of the software. Usually, libraries are more extensive than the software itself, and using them expands the threat surface as well. Reviewing the code to ensure the security of third-party dependencies is barely possible, as the time for delivering the product is always strictly limited. Fortunately, tools like OWASP Dependency Check or npm audit peut répondre à la contrainte de temps. Grâce aux nombreux chercheurs qui signalent les vulnérabilités, ces outils disposent toujours d'une liste à jour des problèmes de sécurité les plus populaires et les plus récents.

Revue manuelle du code de sécurité

The main advantage of a manual security code review is that it’s carried out by an auditor who understands the business logic and validation, and can find vulnerabilities in it. This kind of code review is performed with the use of an IDE tool (integrated development environment). Depending on which language the audited application is written in, usually VS Code or IntelliJsont suffisants.

Par où commencer la revue manuelle de sécurité du code ?

Pour réaliser une revue manuelle de sécurité du code, l'approche la plus simple et la plus efficace consiste à lire le code depuis le début. Mais dans la plupart des cas, il n'existe pas de point unique où le programme commence.

For instance, applications designed in the MVC principle can consist of tens of controllers with hundreds of actions, each of which can be treated as “the beginning”. In that case, the code can be read from the action (controller level) through the service layer into the model layer, where database operations are stored. That approach makes sure that every API method is checked. 

Une autre stratégie consiste à lire le code du bas (couche base de données) vers le haut (couche contrôleur). Dans le cas d'une vulnérabilité d'injection SQL, il sera plus facile d'identifier les points de terminaison ou les méthodes concernés.

Vous pouvez également rechercher des fonctions spécifiques à une technologie qui peuvent conduire à des vulnérabilités – commesystème() oushell_exec() en PHP, ouéval(), setInterval() en JavaScript – et analyser le chemin ou le flux au sein du code pour déterminer s'il est possible d'injecter du code malveillant dans les fonctions.

La stratégie dépend de plusieurs facteurs, comme le nombre de lignes de code (LoC), le temps accordé pour la revue ou la pile technologique.

Fichiers de configuration et données sensibles

Another critical step of a code security review is checking the configuration files. In many cases – especially in non-public code repositories – configuration files contain sensitive data like passwords, API keys, or other types of secrets. Sensitive data stored in the code repository is treated as compromised; thus, secrets, passwords, or API keys should be re-generated and stored in secure places, like vaults. Configuration files must contain only placeholders for values, not values themselves.

In case of vulnerability identification, confirming the finding and exploiting the issue in the application runtime is a good practice. There are cases where, through reading the code, an auditor identifies a security issue, but the framework’s security mechanisms apply a protection layer so, as a result, the flaw can’t be exploited.

Gardez votre application sécurisée

L'analyse du code logiciel est une tâche difficile. Néanmoins, en la réalisant méthodiquement avec le soutien d'outils automatisés, il est possible de couvrir davantage de surfaces de menace, avec au final un impact plus important que dans tout autre type d'audit de sécurité.

Si vous souhaitez garantir un haut niveau de sécurité dans votre application, contactez-nous. Ensemble, nous discuterons des besoins et de la portée de l'audit de sécurité. Vous trouverez ici plus d'informations sur la manière dont nous pouvons vous aider.

A security code review is a systematic examination of source code specifically designed to identify security vulnerabilities and flaws. It differs from a standard code review, which focuses on quality, architecture, and correctness. Security reviews look for exploitable weaknesses including authentication issues, injection vulnerabilities, hardcoded secrets, and insecure use of dangerous functions.

Penetration tests operate under time and budget constraints, which means they cannot cover all possible vulnerabilities in a system. Attackers, by contrast, have unlimited time to analyse software. Regular security code review provides a systematic, ongoing layer of defence that complements the point-in-time findings of a penetration test.

Manual review involves security auditors examining code using IDE tools, tracing logic flows, and understanding business context to identify vulnerabilities that automated tools miss. Automated approaches include SAST (Static Application Security Testing), which uses pattern matching on source code, and DAST (Dynamic Analysis Security Testing), which tests running applications. The most effective programmes combine both.

High-priority areas include configuration files that may contain hardcoded passwords or API keys, technology-specific dangerous functions (such as PHP’s system() or JavaScript’s eval()), SQL query construction, authentication and session management logic, and third-party dependency versions. Dependencies are a frequently overlooked vector; known vulnerabilities in outdated libraries are a common source of exploitable weaknesses.

The primary reference frameworks are OWASP TOP 10 (the most critical web application security risks), MITRE Top 25 (the most dangerous software weaknesses), and industry-specific standards like PCI-DSS for payment systems and HIPAA for healthcare applications. These frameworks provide a consistent, recognised baseline for what a security review should cover.

arrow_circle_right Table des matières

Piotr Izak Senior Cybersecurity Pentester

Piotr Izak

Pentester senior en cybersécurité

Articles connexes