Qu'est-ce que Trojan Source et comment s'introduit-il dans votre code source ?
Début novembre, l'université de Cambridge a publié ses recherches intitulées « Trojan-Source ». Ces recherches se concentraient sur la manière dont les portes dérobées peuvent être dissimulées à l'aide de caractères de formatage directionnels dans le code source et les commentaires. Ceux-ci peuvent être utilisés pour créer du code dont la logique est interprétée différemment par le compilateur et par un réviseur de code humain.
Cette faille de sécurité est nouvelle, bien que l'Unicode ait déjà été utilisé de manière abusive par le passé, par exemple en dissimulant l'extension réelle d'un fichier en inversant la direction de la dernière partie du nom du fichier. Des recherches récentes ont montré que de nombreux compilateurs ignorent les caractères Unicode dans le code source sans avertissement, tandis que les éditeurs de texte, y compris les éditeurs de code, peuvent contourner les lignes contenant des commentaires et le code qui en dépend. Il peut donc arriver que l'éditeur affiche le code et les commentaires différemment et dans un ordre différent de celui dans lequel le compilateur les analyse, voire que le code et les commentaires soient intervertis.
Veuillez continuer votre lecture pour en savoir plus. Si vous souhaitez vous impliquer et essayer le piratage simulé de Trojan Source, nous vous invitons à consulter notre mission publique et gratuite afin de l'expérimenter par vous-même.
Texte bidirectionnel
L'une de ces attaques de type « Trojan Source » utilise l'algorithme Unicode Bidi (bidirectionnel), qui traite la composition de texte avec un ordre d'affichage différent, comme l'anglais (de gauche à droite) et l'arabe (de droite à gauche). Les caractères de formatage directionnel peuvent être utilisés pour réorganiser le regroupement et afficher l'ordre des caractères.
Le tableau ci-dessus contient certains des caractères de remplacement bidirectionnels pertinents pour l'attaque. Prenons par exemple
RLI e d o c PDI
L'abréviation RLI signifie « isoler de droite à gauche ». Elle isole le texte de son contexte (délimité par PDI, Pop-Directional-Isolieren) et le lit de droite à gauche. Le résultat est le suivant :
c o d e
Cependant, les compilateurs et les interpréteurs ne traitent généralement pas les caractères de contrôle de formatage, y compris les remplacements bidirectionnels, avant d'analyser le code source. S'ils ignorent simplement les caractères de formatage directionnels, ils analysent :
e d o c
Du vin nouveau dans des bouteilles neuves ?
Bien entendu, ce n'est pas une nouveauté. Par le passé, des caractères de formatage directionnel étaient insérés dans les noms de fichiers afin de dissimuler leur nature malveillante. Une pièce jointe à un e-mail affichée sous le nom « myspecialexe.doc » pourrait sembler tout à fait innocente s'il n'y avait pas le caractère RLO (remplacement de droite à gauche) indiquant le nom réel « myspecialcod.exe ».
L'attaque par code source troyen insère des caractères de formatage directionnels dans les commentaires et les chaînes de caractères du code source, car ceux-ci ne génèrent pas d'erreurs de syntaxe ou de compilation. Ces caractères de contrôle modifient l'ordre d'affichage de la logique du code, de sorte que le compilateur lit quelque chose de complètement différent de ce qu'un être humain lit.
Par exemple, un fichier contenant les octets suivants dans cet ordre :
sera réorganisé comme suit selon les caractères de formatage directionnels
Le code est ainsi rendu comme suit lorsque les caractères de formatage directionnel ne sont pas explicitement appelés :
Le RLO transforme la parenthèse fermante en parenthèse ouvrante et inversement dans la dernière ligne. Le résultat de l'exécution de ce code serait : « Vous êtes un administrateur ». La vérification administrative a été commentée, mais les caractères de contrôle donnent l'impression qu'elle était toujours présente.
(Source : https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Quel impact cela pourrait-il avoir sur vous ?
De nombreux langages sont vulnérables à cette attaque : C, C++, C#, JavaScript, Java, Rust, Go et Python, et on suppose qu'il en existe d'autres. Il est possible que le développeur moyen désapprouve la présence de caractères de formatage directionnel dans le code source, mais un débutant pourrait tout aussi bien hausser les épaules et ne pas s'en préoccuper. De plus, la visualisation de ces caractères dépend fortement de l'IDE, de sorte qu'il n'est jamais garanti qu'ils seront reconnus.
Cependant, comment cette faille de sécurité a-t-elle pu s'introduire dans le code source ? Tout d'abord, cela peut se produire lorsque du code source provenant de sources non fiables est utilisé, dans lequel des contributions de code malveillantes sont passées inaperçues. Deuxièmement, cela peut se produire par simple copier-coller de code provenant d'Internet, ce que la plupart d'entre nous, développeurs, avons déjà fait. La plupart des entreprises s'appuient sur des composants logiciels provenant de plusieurs fournisseurs. Cela soulève la question suivante : dans quelle mesure pouvons-nous faire pleinement confiance à ce code et nous y fier ? Comment pouvons-nous rechercher du code source contenant des portes dérobées cachées ?
À qui appartient ce problème ?
D'une part, les compilateurs et les pipelines de compilation devraient interdire les lignes de code source comportant plus d'une direction, sauf si une direction est strictement limitée aux chaînes de caractères et aux commentaires. Veuillez noter qu'un caractère de formatage directionnel dans une chaîne de caractères ou un commentaire peut prolonger un changement de direction jusqu'à la fin de la ligne s'il n'est pas affiché. En général, les éditeurs de code devraient explicitement afficher et mettre en évidence les caractères Unicode suspects tels que les homoglyphes et les caractères de formatage directionnel. Depuis novembre, GitHub ajoute un symbole d'avertissement et un message à chaque ligne de code contenant du texte Unicode bidirectionnel, bien qu'il ne mette pas en évidence l'emplacement de ces caractères dans la ligne. Cela peut toujours permettre à des changements de direction malveillants de se glisser parmi des changements de direction inoffensifs.
Il est impératif de sensibiliser les développeurs et les réviseurs de code à cette question. C'est pourquoi nous avons créé une solution complète qui illustre cette vulnérabilité. Actuellement, cette solution complète est disponible pour Java, C#, Python, GO et PHP.
Si vous souhaitez en savoir plus, nous vous invitons à essayer notre simulation (missions publiques) de Trojan Source et à consulter la recherche sur les sources troyennes.
Secure Code Warrior là pour aider votre entreprise à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre entreprise à réduire les risques liés à un code non sécurisé.
Réserver une démonstration
Laura Verheyde est développeuse de logiciels à l'adresse Secure Code Warrior . Elle se consacre à la recherche de vulnérabilités et à la création de contenu pour Missions et Coding labs.
Début novembre, l'université de Cambridge a publié ses recherches intitulées « Trojan-Source ». Ces recherches se concentraient sur la manière dont les portes dérobées peuvent être dissimulées à l'aide de caractères de formatage directionnels dans le code source et les commentaires. Ceux-ci peuvent être utilisés pour créer du code dont la logique est interprétée différemment par le compilateur et par un réviseur de code humain.
Cette faille de sécurité est nouvelle, bien que l'Unicode ait déjà été utilisé de manière abusive par le passé, par exemple en dissimulant l'extension réelle d'un fichier en inversant la direction de la dernière partie du nom du fichier. Des recherches récentes ont montré que de nombreux compilateurs ignorent les caractères Unicode dans le code source sans avertissement, tandis que les éditeurs de texte, y compris les éditeurs de code, peuvent contourner les lignes contenant des commentaires et le code qui en dépend. Il peut donc arriver que l'éditeur affiche le code et les commentaires différemment et dans un ordre différent de celui dans lequel le compilateur les analyse, voire que le code et les commentaires soient intervertis.
Veuillez continuer votre lecture pour en savoir plus. Si vous souhaitez vous impliquer et essayer le piratage simulé de Trojan Source, nous vous invitons à consulter notre mission publique et gratuite afin de l'expérimenter par vous-même.
Texte bidirectionnel
L'une de ces attaques de type « Trojan Source » utilise l'algorithme Unicode Bidi (bidirectionnel), qui traite la composition de texte avec un ordre d'affichage différent, comme l'anglais (de gauche à droite) et l'arabe (de droite à gauche). Les caractères de formatage directionnel peuvent être utilisés pour réorganiser le regroupement et afficher l'ordre des caractères.
Le tableau ci-dessus contient certains des caractères de remplacement bidirectionnels pertinents pour l'attaque. Prenons par exemple
RLI e d o c PDI
L'abréviation RLI signifie « isoler de droite à gauche ». Elle isole le texte de son contexte (délimité par PDI, Pop-Directional-Isolieren) et le lit de droite à gauche. Le résultat est le suivant :
c o d e
Cependant, les compilateurs et les interpréteurs ne traitent généralement pas les caractères de contrôle de formatage, y compris les remplacements bidirectionnels, avant d'analyser le code source. S'ils ignorent simplement les caractères de formatage directionnels, ils analysent :
e d o c
Du vin nouveau dans des bouteilles neuves ?
Bien entendu, ce n'est pas une nouveauté. Par le passé, des caractères de formatage directionnel étaient insérés dans les noms de fichiers afin de dissimuler leur nature malveillante. Une pièce jointe à un e-mail affichée sous le nom « myspecialexe.doc » pourrait sembler tout à fait innocente s'il n'y avait pas le caractère RLO (remplacement de droite à gauche) indiquant le nom réel « myspecialcod.exe ».
L'attaque par code source troyen insère des caractères de formatage directionnels dans les commentaires et les chaînes de caractères du code source, car ceux-ci ne génèrent pas d'erreurs de syntaxe ou de compilation. Ces caractères de contrôle modifient l'ordre d'affichage de la logique du code, de sorte que le compilateur lit quelque chose de complètement différent de ce qu'un être humain lit.
Par exemple, un fichier contenant les octets suivants dans cet ordre :
sera réorganisé comme suit selon les caractères de formatage directionnels
Le code est ainsi rendu comme suit lorsque les caractères de formatage directionnel ne sont pas explicitement appelés :
Le RLO transforme la parenthèse fermante en parenthèse ouvrante et inversement dans la dernière ligne. Le résultat de l'exécution de ce code serait : « Vous êtes un administrateur ». La vérification administrative a été commentée, mais les caractères de contrôle donnent l'impression qu'elle était toujours présente.
(Source : https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Quel impact cela pourrait-il avoir sur vous ?
De nombreux langages sont vulnérables à cette attaque : C, C++, C#, JavaScript, Java, Rust, Go et Python, et on suppose qu'il en existe d'autres. Il est possible que le développeur moyen désapprouve la présence de caractères de formatage directionnel dans le code source, mais un débutant pourrait tout aussi bien hausser les épaules et ne pas s'en préoccuper. De plus, la visualisation de ces caractères dépend fortement de l'IDE, de sorte qu'il n'est jamais garanti qu'ils seront reconnus.
Cependant, comment cette faille de sécurité a-t-elle pu s'introduire dans le code source ? Tout d'abord, cela peut se produire lorsque du code source provenant de sources non fiables est utilisé, dans lequel des contributions de code malveillantes sont passées inaperçues. Deuxièmement, cela peut se produire par simple copier-coller de code provenant d'Internet, ce que la plupart d'entre nous, développeurs, avons déjà fait. La plupart des entreprises s'appuient sur des composants logiciels provenant de plusieurs fournisseurs. Cela soulève la question suivante : dans quelle mesure pouvons-nous faire pleinement confiance à ce code et nous y fier ? Comment pouvons-nous rechercher du code source contenant des portes dérobées cachées ?
À qui appartient ce problème ?
D'une part, les compilateurs et les pipelines de compilation devraient interdire les lignes de code source comportant plus d'une direction, sauf si une direction est strictement limitée aux chaînes de caractères et aux commentaires. Veuillez noter qu'un caractère de formatage directionnel dans une chaîne de caractères ou un commentaire peut prolonger un changement de direction jusqu'à la fin de la ligne s'il n'est pas affiché. En général, les éditeurs de code devraient explicitement afficher et mettre en évidence les caractères Unicode suspects tels que les homoglyphes et les caractères de formatage directionnel. Depuis novembre, GitHub ajoute un symbole d'avertissement et un message à chaque ligne de code contenant du texte Unicode bidirectionnel, bien qu'il ne mette pas en évidence l'emplacement de ces caractères dans la ligne. Cela peut toujours permettre à des changements de direction malveillants de se glisser parmi des changements de direction inoffensifs.
Il est impératif de sensibiliser les développeurs et les réviseurs de code à cette question. C'est pourquoi nous avons créé une solution complète qui illustre cette vulnérabilité. Actuellement, cette solution complète est disponible pour Java, C#, Python, GO et PHP.
Si vous souhaitez en savoir plus, nous vous invitons à essayer notre simulation (missions publiques) de Trojan Source et à consulter la recherche sur les sources troyennes.
Début novembre, l'université de Cambridge a publié ses recherches intitulées « Trojan-Source ». Ces recherches se concentraient sur la manière dont les portes dérobées peuvent être dissimulées à l'aide de caractères de formatage directionnels dans le code source et les commentaires. Ceux-ci peuvent être utilisés pour créer du code dont la logique est interprétée différemment par le compilateur et par un réviseur de code humain.
Cette faille de sécurité est nouvelle, bien que l'Unicode ait déjà été utilisé de manière abusive par le passé, par exemple en dissimulant l'extension réelle d'un fichier en inversant la direction de la dernière partie du nom du fichier. Des recherches récentes ont montré que de nombreux compilateurs ignorent les caractères Unicode dans le code source sans avertissement, tandis que les éditeurs de texte, y compris les éditeurs de code, peuvent contourner les lignes contenant des commentaires et le code qui en dépend. Il peut donc arriver que l'éditeur affiche le code et les commentaires différemment et dans un ordre différent de celui dans lequel le compilateur les analyse, voire que le code et les commentaires soient intervertis.
Veuillez continuer votre lecture pour en savoir plus. Si vous souhaitez vous impliquer et essayer le piratage simulé de Trojan Source, nous vous invitons à consulter notre mission publique et gratuite afin de l'expérimenter par vous-même.
Texte bidirectionnel
L'une de ces attaques de type « Trojan Source » utilise l'algorithme Unicode Bidi (bidirectionnel), qui traite la composition de texte avec un ordre d'affichage différent, comme l'anglais (de gauche à droite) et l'arabe (de droite à gauche). Les caractères de formatage directionnel peuvent être utilisés pour réorganiser le regroupement et afficher l'ordre des caractères.
Le tableau ci-dessus contient certains des caractères de remplacement bidirectionnels pertinents pour l'attaque. Prenons par exemple
RLI e d o c PDI
L'abréviation RLI signifie « isoler de droite à gauche ». Elle isole le texte de son contexte (délimité par PDI, Pop-Directional-Isolieren) et le lit de droite à gauche. Le résultat est le suivant :
c o d e
Cependant, les compilateurs et les interpréteurs ne traitent généralement pas les caractères de contrôle de formatage, y compris les remplacements bidirectionnels, avant d'analyser le code source. S'ils ignorent simplement les caractères de formatage directionnels, ils analysent :
e d o c
Du vin nouveau dans des bouteilles neuves ?
Bien entendu, ce n'est pas une nouveauté. Par le passé, des caractères de formatage directionnel étaient insérés dans les noms de fichiers afin de dissimuler leur nature malveillante. Une pièce jointe à un e-mail affichée sous le nom « myspecialexe.doc » pourrait sembler tout à fait innocente s'il n'y avait pas le caractère RLO (remplacement de droite à gauche) indiquant le nom réel « myspecialcod.exe ».
L'attaque par code source troyen insère des caractères de formatage directionnels dans les commentaires et les chaînes de caractères du code source, car ceux-ci ne génèrent pas d'erreurs de syntaxe ou de compilation. Ces caractères de contrôle modifient l'ordre d'affichage de la logique du code, de sorte que le compilateur lit quelque chose de complètement différent de ce qu'un être humain lit.
Par exemple, un fichier contenant les octets suivants dans cet ordre :
sera réorganisé comme suit selon les caractères de formatage directionnels
Le code est ainsi rendu comme suit lorsque les caractères de formatage directionnel ne sont pas explicitement appelés :
Le RLO transforme la parenthèse fermante en parenthèse ouvrante et inversement dans la dernière ligne. Le résultat de l'exécution de ce code serait : « Vous êtes un administrateur ». La vérification administrative a été commentée, mais les caractères de contrôle donnent l'impression qu'elle était toujours présente.
(Source : https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Quel impact cela pourrait-il avoir sur vous ?
De nombreux langages sont vulnérables à cette attaque : C, C++, C#, JavaScript, Java, Rust, Go et Python, et on suppose qu'il en existe d'autres. Il est possible que le développeur moyen désapprouve la présence de caractères de formatage directionnel dans le code source, mais un débutant pourrait tout aussi bien hausser les épaules et ne pas s'en préoccuper. De plus, la visualisation de ces caractères dépend fortement de l'IDE, de sorte qu'il n'est jamais garanti qu'ils seront reconnus.
Cependant, comment cette faille de sécurité a-t-elle pu s'introduire dans le code source ? Tout d'abord, cela peut se produire lorsque du code source provenant de sources non fiables est utilisé, dans lequel des contributions de code malveillantes sont passées inaperçues. Deuxièmement, cela peut se produire par simple copier-coller de code provenant d'Internet, ce que la plupart d'entre nous, développeurs, avons déjà fait. La plupart des entreprises s'appuient sur des composants logiciels provenant de plusieurs fournisseurs. Cela soulève la question suivante : dans quelle mesure pouvons-nous faire pleinement confiance à ce code et nous y fier ? Comment pouvons-nous rechercher du code source contenant des portes dérobées cachées ?
À qui appartient ce problème ?
D'une part, les compilateurs et les pipelines de compilation devraient interdire les lignes de code source comportant plus d'une direction, sauf si une direction est strictement limitée aux chaînes de caractères et aux commentaires. Veuillez noter qu'un caractère de formatage directionnel dans une chaîne de caractères ou un commentaire peut prolonger un changement de direction jusqu'à la fin de la ligne s'il n'est pas affiché. En général, les éditeurs de code devraient explicitement afficher et mettre en évidence les caractères Unicode suspects tels que les homoglyphes et les caractères de formatage directionnel. Depuis novembre, GitHub ajoute un symbole d'avertissement et un message à chaque ligne de code contenant du texte Unicode bidirectionnel, bien qu'il ne mette pas en évidence l'emplacement de ces caractères dans la ligne. Cela peut toujours permettre à des changements de direction malveillants de se glisser parmi des changements de direction inoffensifs.
Il est impératif de sensibiliser les développeurs et les réviseurs de code à cette question. C'est pourquoi nous avons créé une solution complète qui illustre cette vulnérabilité. Actuellement, cette solution complète est disponible pour Java, C#, Python, GO et PHP.
Si vous souhaitez en savoir plus, nous vous invitons à essayer notre simulation (missions publiques) de Trojan Source et à consulter la recherche sur les sources troyennes.
Veuillez cliquer sur le lien ci-dessous et télécharger le PDF de cette ressource.
Secure Code Warrior là pour aider votre entreprise à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre entreprise à réduire les risques liés à un code non sécurisé.
Consulter le rapportRéserver une démonstration
Laura Verheyde est développeuse de logiciels à l'adresse Secure Code Warrior . Elle se consacre à la recherche de vulnérabilités et à la création de contenu pour Missions et Coding labs.
Début novembre, l'université de Cambridge a publié ses recherches intitulées « Trojan-Source ». Ces recherches se concentraient sur la manière dont les portes dérobées peuvent être dissimulées à l'aide de caractères de formatage directionnels dans le code source et les commentaires. Ceux-ci peuvent être utilisés pour créer du code dont la logique est interprétée différemment par le compilateur et par un réviseur de code humain.
Cette faille de sécurité est nouvelle, bien que l'Unicode ait déjà été utilisé de manière abusive par le passé, par exemple en dissimulant l'extension réelle d'un fichier en inversant la direction de la dernière partie du nom du fichier. Des recherches récentes ont montré que de nombreux compilateurs ignorent les caractères Unicode dans le code source sans avertissement, tandis que les éditeurs de texte, y compris les éditeurs de code, peuvent contourner les lignes contenant des commentaires et le code qui en dépend. Il peut donc arriver que l'éditeur affiche le code et les commentaires différemment et dans un ordre différent de celui dans lequel le compilateur les analyse, voire que le code et les commentaires soient intervertis.
Veuillez continuer votre lecture pour en savoir plus. Si vous souhaitez vous impliquer et essayer le piratage simulé de Trojan Source, nous vous invitons à consulter notre mission publique et gratuite afin de l'expérimenter par vous-même.
Texte bidirectionnel
L'une de ces attaques de type « Trojan Source » utilise l'algorithme Unicode Bidi (bidirectionnel), qui traite la composition de texte avec un ordre d'affichage différent, comme l'anglais (de gauche à droite) et l'arabe (de droite à gauche). Les caractères de formatage directionnel peuvent être utilisés pour réorganiser le regroupement et afficher l'ordre des caractères.
Le tableau ci-dessus contient certains des caractères de remplacement bidirectionnels pertinents pour l'attaque. Prenons par exemple
RLI e d o c PDI
L'abréviation RLI signifie « isoler de droite à gauche ». Elle isole le texte de son contexte (délimité par PDI, Pop-Directional-Isolieren) et le lit de droite à gauche. Le résultat est le suivant :
c o d e
Cependant, les compilateurs et les interpréteurs ne traitent généralement pas les caractères de contrôle de formatage, y compris les remplacements bidirectionnels, avant d'analyser le code source. S'ils ignorent simplement les caractères de formatage directionnels, ils analysent :
e d o c
Du vin nouveau dans des bouteilles neuves ?
Bien entendu, ce n'est pas une nouveauté. Par le passé, des caractères de formatage directionnel étaient insérés dans les noms de fichiers afin de dissimuler leur nature malveillante. Une pièce jointe à un e-mail affichée sous le nom « myspecialexe.doc » pourrait sembler tout à fait innocente s'il n'y avait pas le caractère RLO (remplacement de droite à gauche) indiquant le nom réel « myspecialcod.exe ».
L'attaque par code source troyen insère des caractères de formatage directionnels dans les commentaires et les chaînes de caractères du code source, car ceux-ci ne génèrent pas d'erreurs de syntaxe ou de compilation. Ces caractères de contrôle modifient l'ordre d'affichage de la logique du code, de sorte que le compilateur lit quelque chose de complètement différent de ce qu'un être humain lit.
Par exemple, un fichier contenant les octets suivants dans cet ordre :
sera réorganisé comme suit selon les caractères de formatage directionnels
Le code est ainsi rendu comme suit lorsque les caractères de formatage directionnel ne sont pas explicitement appelés :
Le RLO transforme la parenthèse fermante en parenthèse ouvrante et inversement dans la dernière ligne. Le résultat de l'exécution de ce code serait : « Vous êtes un administrateur ». La vérification administrative a été commentée, mais les caractères de contrôle donnent l'impression qu'elle était toujours présente.
(Source : https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Quel impact cela pourrait-il avoir sur vous ?
De nombreux langages sont vulnérables à cette attaque : C, C++, C#, JavaScript, Java, Rust, Go et Python, et on suppose qu'il en existe d'autres. Il est possible que le développeur moyen désapprouve la présence de caractères de formatage directionnel dans le code source, mais un débutant pourrait tout aussi bien hausser les épaules et ne pas s'en préoccuper. De plus, la visualisation de ces caractères dépend fortement de l'IDE, de sorte qu'il n'est jamais garanti qu'ils seront reconnus.
Cependant, comment cette faille de sécurité a-t-elle pu s'introduire dans le code source ? Tout d'abord, cela peut se produire lorsque du code source provenant de sources non fiables est utilisé, dans lequel des contributions de code malveillantes sont passées inaperçues. Deuxièmement, cela peut se produire par simple copier-coller de code provenant d'Internet, ce que la plupart d'entre nous, développeurs, avons déjà fait. La plupart des entreprises s'appuient sur des composants logiciels provenant de plusieurs fournisseurs. Cela soulève la question suivante : dans quelle mesure pouvons-nous faire pleinement confiance à ce code et nous y fier ? Comment pouvons-nous rechercher du code source contenant des portes dérobées cachées ?
À qui appartient ce problème ?
D'une part, les compilateurs et les pipelines de compilation devraient interdire les lignes de code source comportant plus d'une direction, sauf si une direction est strictement limitée aux chaînes de caractères et aux commentaires. Veuillez noter qu'un caractère de formatage directionnel dans une chaîne de caractères ou un commentaire peut prolonger un changement de direction jusqu'à la fin de la ligne s'il n'est pas affiché. En général, les éditeurs de code devraient explicitement afficher et mettre en évidence les caractères Unicode suspects tels que les homoglyphes et les caractères de formatage directionnel. Depuis novembre, GitHub ajoute un symbole d'avertissement et un message à chaque ligne de code contenant du texte Unicode bidirectionnel, bien qu'il ne mette pas en évidence l'emplacement de ces caractères dans la ligne. Cela peut toujours permettre à des changements de direction malveillants de se glisser parmi des changements de direction inoffensifs.
Il est impératif de sensibiliser les développeurs et les réviseurs de code à cette question. C'est pourquoi nous avons créé une solution complète qui illustre cette vulnérabilité. Actuellement, cette solution complète est disponible pour Java, C#, Python, GO et PHP.
Si vous souhaitez en savoir plus, nous vous invitons à essayer notre simulation (missions publiques) de Trojan Source et à consulter la recherche sur les sources troyennes.
Table des matières
Secure Code Warrior là pour aider votre entreprise à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre entreprise à réduire les risques liés à un code non sécurisé.
Réserver une démonstrationTéléchargerRessources pour débuter
Thèmes et contenus de la formation Securecode
Nos contenus de pointe sont constamment développés afin de s'adapter à l'évolution constante du paysage du développement logiciel, en tenant compte de votre rôle. Les thèmes abordés couvrent tous les domaines, de l'IA à l'injection XQuery, et sont proposés pour une multitude de rôles, des architectes et ingénieurs aux chefs de produit et responsables assurance qualité. Nous vous invitons à découvrir un aperçu de notre catalogue de contenus classés par thème et par rôle.
La Chambre de commerce établit la norme en matière de sécurité à grande échelle axée sur les développeurs
La Chambre de commerce néerlandaise explique comment elle a intégré le codage sécurisé dans le développement quotidien grâce à des certifications basées sur les rôles, à l'évaluation comparative du Trust Score et à une culture de responsabilité partagée en matière de sécurité.
%20(1).avif)
.avif)
Modélisation des menaces avec l'IA : transformer chaque développeur en modélisateur de menaces
Vous repartirez mieux équipé pour aider les développeurs à combiner les idées et les techniques de modélisation des menaces avec les outils d'IA qu'ils utilisent déjà pour renforcer la sécurité, améliorer la collaboration et créer des logiciels plus résilients dès le départ.
Ressources pour débuter
Cybermon est de retour : les missions KI « Beat the Boss » sont désormais disponibles sur demande.
Cybermon 2025 Beat the Boss est désormais disponible toute l'année dans SCW. Il utilise des exigences de sécurité IA/LLM avancées pour renforcer le développement sécurisé de l'IA à grande échelle.
Explication de la loi sur la cyber-résilience : implications pour le développement de logiciels sécurisés dès la conception
Découvrez les exigences de la loi européenne sur la cyber-résilience (CRA), à qui elle s'applique et comment les équipes de développement peuvent s'y préparer en adoptant des méthodes sécurisées, en prévenant les failles de sécurité et en renforçant les compétences des développeurs.
Facteur 1 : Critères de réussite définis et mesurables
Le catalyseur n° 1 inaugure notre série en dix parties intitulée « Les catalyseurs de la réussite » et démontre comment un codage sécurisé peut être associé à des résultats commerciaux tels que la réduction des risques et la rapidité afin d'atteindre une maturité programmatique à long terme.
