la voie vers une application sécurisée

La voie vers une application sécuriséeUne liste de contrôle pour l’analyse de la sécurité du code source

Logiciel IBM

Rational

Décembre 2009

2 La voie vers une application sécurisée

Sommaire

2 I. Introduction

2 II. Les problèmes de coûts poussent les entreprisesvers le développement sécurisé

3 III. La voie vers des pratiques de développement decode sécurisé

4 III. Les étapes vers le code sécurisé

11 IV. Application de la liste de contrôle pour l’analyse dela sécurité du code source

13 V. Annexe : Liste de contrôle pour l’analyse de lasécurité du code source

Il est reconnu qu’en détectant et encorrigeant les vulnérabilités tôt sur le cycle de développement des logiciels, les organisations peuvent réduireconsidérablement leurs risques et leurs coûts.

I. IntroductionL’épidémie continue d’avertissements des brèches en matièrede protection des données due aux lois actuelles sur ladivulgation illégale des données souligne malheureusementl’insécurité de nombreuses applications. Comment lesorganisations peuvent-elles s’assurer que leurs applicationssont sécurisées, éviter les retombées en termes de coûts et demauvaise publicité et empêcher de voir leur cours baisser enbourse à cause de nombreux correctifs de sécurité ? Commentfaire pour ne pas avoir à expliquer aux consommateurs et auxautorités réglementaires que du code défectueux à permis àdes pirates de voler les informations sensibles, et peut-être lesinformations réglementées ?

La voie vers la création d’une application sécurisée commencepar un test rigoureux du code source pour détecter toutes lesvulnérabilités. Il faut également s’assurer que l’utilisation del’application ne compromet ou ne permet à personne decompromettre la confidentialité et l’intégrité des données.

Cependant, pour les entreprises qui utilisent en interne desapplications construites sur-mesure, externalisées ou en opensource, vérifier que l’ensemble du code actuel et hérité estsécurisé ne sera pas chose facile. La détection et l’éradicationdes vulnérabilités en matière de sécurité ont toujours été destâches extrêmement difficiles. De nombreuses organisationsoptaient pour une analyse de code manuelle, un processuscoûteux et mobilisant beaucoup de main-d’œuvre, ainsi quepour l’ethical hacking, qui examine un sous-ensemble desvulnérabilités potentielles d’une application.

Même si ces deux approches ont des effets positifs, lesentreprises peuvent utiliser des outils d’analyse automatiquedes vulnérabilités pour une approche plus systématique,automatisée et efficace au développement de code. Ces outils d’analyse automatique des vulnérabilités améliorentconsidérablement la vitesse et la précision du processusd’analyse de code et peuvent être intégrés sans problème aucycle de développement. En effet, les meilleurs outils peuventidentifier les vulnérabilités à la ligne de code (LOC) près etfournissent des informations détaillées sur le type de faillerencontré, le risque qu’elle présente et la méthode à suivrepour la corriger.

II. Les problèmes de coûts poussent lesentreprises vers le développement decode sécuriséLa nécessité de créer du code sécurisé n’a jamais été aussigrande, compte tenu de l’apparition rapide des nouvellestechnologies, y compris les services Web et les Rich InternetApplications, et de la nécessité de garantir l’intégrité desapplications existantes, héritées et en cours de développementdans un monde axé sur les réseaux. Les entreprises continuentà intégrer leurs systèmes chez leurs partenaires commerciauxpour accélérer le partage des informations. Dans cesconditions, les entreprises doivent s’assurer que leur code est sécurisé pour protéger la confidentialité des données,promouvoir la fidélité des clients, protéger les informationssensibles et maintenir l’intégrité opérationnelle.

Un défaut sur un logiciel peut entraîner une divulgation desdonnées. Une des pires divulgations de données survenuesdans le domaine de l’éducation est l’attaque portée en 2006 àla base de données de UCLA (University of California, LosAngeles), qui contenait les informations personnelles de

3Logiciel IBM

800 000 personnes. Lors d’une conférence de presse, JimDavis, le vice-président associé du département informatiquede UCLA, a révélé que le pirate avait profité d’une simpledéfaillance logicielle pour accéder à la base de données. Deplus, le pirate a très bien su effacer ses traces, car on pense queles défaillances avaient commencé jusqu’à un an avant queUCLA ne les détecte. La divulgation involontaire desinformations sensibles d’une entreprise ou d’informationsprivées et réglementées peut entraîner des amendes, une baissedes cours en bourse sans compter les dégâts engendrés pour laréputation de l’entreprise.

De nombreuses études montrent que la détection et lacorrection des défauts de code tôt sur le cycle dedéveloppement des logiciels coûtent beaucoup moins cher. Sil’on regarde le coût d’un seul bogue qui se retrouve dans ducode publié et entraîne une divulgation de données, oncomprend facilement les conséquences de la non détection decette simple vulnérabilité en termes de coûts. Les études leconfirment. Une enquête menée auprès de 31 entreprisesayant connu des violations de données montre qu’uneviolation de données coûte en moyenne 3 millions GBP, enraison des frais associés au nettoyage informatique, aux fraisjuridiques, aux notifications, aux pertes de clients, aux servicesde surveillance de crédit pour les consommateurs touchés et àla charge de travail supplémentaire pour le service à laclientèle. Cette enquête, réalisée par Ponemon Institute©, aégalement montré que la perte de clients associée à uneviolation des données s’élevait à 2 % en moyenne, maispouvait aller jusqu’à 7 % dans certains cas.1

III. La voie vers des pratiques dedéveloppement de code sécuriséQuel est le meilleur moyen de s’assurer que le code estsécurisé ? La voie vers un développement de logiciels sécuriséet efficace implique que les processus d’analyse de code sourceaccomplissent trois choses :

● Créer une cohérence : Lorsqu’ils développent du code, lesdéveloppeurs doivent créer des processus, des politiques etune culture cohérents pour une sécurité améliorée.

● Offrir une vue d’ensemble des questions de sécurité :en ce qui concerne les vulnérabilités dangereuses, les défautsde conception à grande échelle dépassent généralement leserreurs de code individuelles. Corriger les vulnérabilitésindividuelles aura très peu d’effet si les données ne sont paschiffrées, si le processus d’authentification est faible ou si desportes dérobées existent dans une application.

● Établir des priorités de résolution : lors de l’analyse decode existant, les développeurs doivent identifier toutes lesvulnérabilités du code et résoudre d’abord les risques lesplus importants.

A. La voie vers un développement sécurisé : commentrechercher les vulnérabilités Pour s’assurer que le code est sécurisé, il faut examiner tousles endroits où des vulnérabilités peuvent exister. Mêmelorsqu’ils utilisent des outils automatisés, les développeursdoivent comprendre que pour créer une application sécurisée,il faut peut-être revoir les pratiques d’implémentation et deconception, notamment les pratiques en matière de codeexterne et de réutilisation de code, même s’ils ne lesconsidèrent pas comme vulnérables au premier abord. Parconséquent, les entreprises doivent être exigeantes en matièrede développement de code sécurisé et s’assurer que tous lesendroits pouvant présenter des vulnérabilités sont analysés.

Pour mesurer efficacement le risque posé par une application,les analystes de sécurité ou les développeurs doiventrechercher deux types d’erreurs :

● Les erreurs d’implémentation :Ces défauts de code qualitatifs sont plutôt atomiques et sont généralement isolés lorsqu’ils sont identifiés etrésolus. Les erreurs d’implémentation sont causées par demauvaises pratiques de programmation. Les dépassementsde la mémoire tampon sont des exemples d’erreursd’implémentation. Ils sont dus à une mauvaise gestion de lamémoire et de la concurrence critique, qui entraîne desécarts en termes de durée de communication.

● Les erreurs de conception :Ces erreurs comprennent une mauvaise utilisation ou uneimplémentation inadéquate des fonctions de sécurité. Parexemple, l’authentification, le chiffrement, l’utilisation detypes de code externe non sécurisés et la validation d’entréesde données et de sorties d’application.

Alors que les erreurs d’implémentation sont les plus courantes,ce sont en fait les défauts de conception qui entraîne le plus derisques pour les applications Web modernes. Existe-t-il uncontrôle d’accès ? Existe-t-il un chiffrement et est-il suffisant ?L’accès à la base de données est-il sécurisé et conforme à lapolitique ? Ces problèmes de sécurité liés à la conceptiondoivent être analysés et corrigés pendant le développementd’application sécurisé.


B. La voie vers un développement sécurisé : commentrechercher les vulnérabilitésLe processus destiné à détecter les erreurs ne consiste passeulement à définir le besoin de sécurité au cours du processusde développement, mais aussi à examiner tous les endroits ducode où des défauts de conception existent ou peuvent exister.Ces emplacements sont généralement beaucoup plus étendusque les développeurs, même les meilleurs, ne le pensent.Effectuer une analyse poussée du code source peut entraînerles testeurs dans des endroits inattendus.

S’assurer que le code existant et le nouveau code sontdéveloppés de manière sécurisée implique des processus et desprocédures de recherche des vulnérabilités ainsi que des outilspour aider cette recherche. Quels sont les outils les plusefficaces pour développer des logiciels sécurisés ?

L’analyse de code manuelle et l’ethical hacking sont desapproches couramment utilisées. Même si ces deux approchessont utiles, aucune n’est suffisante pour traiter l’étendue deserreurs de conception existantes et potentielles et donc pours’assurer que le code est sécurisé. L’analyse de code manuelle,par exemple, est longue et coûteuse. Repérer les lignes de codequi contiennent des défauts ou qui peuvent donner lieu à deserreurs opérationnelles est extrêmement difficile. L’ethicalhacking ne peut identifier qu’un petit sous-ensemble deserreurs qu’une application peut contenir. Même si cetteapproche est utile pour mettre ces erreurs en évidence, ellen’offre qu’une vision incomplète de la sécurité globale del’application.

Compte tenu de l’étendue des erreurs de conception existantesou potentielles, selon les experts, les entreprises doiventutiliser des outils de détection des vulnérabilités de logicielautomatisés pour repérer tous les défauts potentiels. Ilss’accordent sur le fait que l’approche la plus efficace pour les entreprises qui développent leurs propres logiciels estd’intégrer des analyseurs de vulnérabilité du code source dansles processus de développement, d’intégration et de test desapplications. Seuls des outils de test de vulnérabilité du codesource de pointe et les pratiques de cycle de développement de logiciel associées peuvent garantir efficacement que le codeest sécurisé.

III. Les étapes vers le code sécurisé :ce qu’il faut examiner La technique la plus efficiente et efficace pour créer du codesource sécurisé est d’évaluer les applications existantes ainsique le code en cours de développement à l’aide de cinqcatégories de vulnérabilités de code :

1. Fonctions liées à la sécurité2. Erreurs d’encodage et de validation des entrées/sorties3. Traitement des erreurs et journalisation des vulnérabilités4. Composants non sécurisés5. Erreurs de codage.

Suivre les problèmes de sécurité par le biais du code sourced’une application réduit considérablement la vulnérabilité del’application et des données critiques qu’elle traite et protège.

Voici de plus amples informations sur chaque catégoried’erreurs :

1. Fonctions liées à la sécuritéLes applications sont la somme de nombreuses fonctionsdiscrètes, qui semblent souvent inoffensives. Pourtant, unecombinaison imprudente de ces fonctions, ou un manque dedocumentation concernant l’implémentation de ces fonctions,peut facilement créer un risque de sécurité et entraîner desdivulgations de données personnelles, confidentielles, ou del’intégrité du système.

Ce risque est accentué par l’utilisation répandue de langagesde programmation de haut niveau et de modules préconçus etde bibliothèques précompilées en particulier. Avec ces outils,les développeurs peuvent rapidement déployer des applicationscomplètes ayant accès à de nombreux services et sources dedonnées. Ces outils aident également à éviter de nombreuxproblèmes de sécurité, par exemple en retirant la gestion de lamémoire et les questions de contrôle des ressources auxdéveloppeurs qui utilisent des interfaces de haut niveau.

Ces outils n’exigent pas une compréhension plus détaillée del’utilisation des services et des données de manière sécurisée,ni des conflits éventuels d’une telle utilisation avec lesprocessus métier existants ou la sécurité des infrastructuresd’une entreprise. En conséquence, l’implémentation nonsécurisée de ces bibliothèques ou modules est en fait la cause

5Logiciel IBM

de la majorité des problèmes de sécurité concernant lesapplications actuelles. En outre, ces types d’erreurs deconception de sécurité sont souvent plus dangereux que lestypes précédents de problèmes de codage, car les applicationsd’aujourd’hui s’interfacent à la fois avec le back office desentreprises et avec Internet, créant ainsi un conduit potentielpour la perte de données sensibles.

Une identification complète de l’état de la sécurité d’uneapplication doit comprendre une analyse des défauts deconception critiques suivants :

a. Cryptographie faible ou non conformeUn des composants fondamentaux de la sécurité d’uneapplication est le chiffrement des données. Les donnéespersonnelles ou sensibles sont embrouillées à des fins deprotection. Si les pirates parviennent à casser les algorithmesde chiffrement, ils peuvent voler des données sensibles.L’utilisation de générateurs de chiffres aléatoires faibles etd’algorithmes cryptographiques non conformes est deuxvulnérabilités de chiffrement répandues qui permettent auxpirates de voler des données sensibles.

Pour que le chiffrement soit efficace, le caractère aléatoire dela cryptographie sous-jacente doit être suffisamment fort pourempêcher les pirates de deviner ou de reproduire facilementles clés utilisées pour autoriser le partage des données. Leschiffres aléatoires faibles ne sont pas assez aléatoires. Lorsqueles chiffres moins aléatoires ainsi obtenus sont utilisés pourformer des clés, cet algorithme de chiffrement expose lesdonnées chiffrées à la prédiction de nombres séquentiels et àla mystification de session. Les développeurs doivent éviter lesgénérateurs de chiffres aléatoires faibles.

Attention aux algorithmes cryptographiques non conformes.Les algorithmes cryptographiques embrouillent les données etseule une poignée d’algorithmes réellement sécurisés existe.Ces derniers ont été évalués de manière approfondie par desexperts en cryptographie. Même pour ces experts, produire unalgorithme vraiment sécurisé et acceptable est extrêmementdifficile. D’où l’utilisation continue de triple DES, Blowfish etautres algorithmes usés. Il arrive même qu’on parvientultérieurement à casser ces algorithmes. Quoi qu’il en soit,suivez les recommandations des experts. D’autres algorithmessont ou peuvent être suffisamment résistants pour empêcherun pirate de décrypter des données chiffrées.

b. Communications réseau non sécuriséesUtiliser des méthodes légales pour envoyer ou recevoir desdonnées sans documenter ni protéger ces processus peutexposer des données critiques lors du transit, permettant ainsi aux pirates de les intercepter et de les lire facilement. Les développeurs doivent employer des protocoles decommunication réseau sécurisés, comme Secure Sockets Layer(SSL), autant que possible et documenter soigneusement cesprocessus.

c. Vulnérabilités liées à la configuration de l’applicationLes développeurs doivent s’assurer que les fichiers deconfiguration ou les options qui commandent leursapplications sont également sécurisés. Autrement, un piraterisque d’accéder à ces fichiers ou options non protégés, de lesmanipuler et d’ajuster les propriétés ou les contrôles d’accèsdu logiciel pour accéder à des données sensibles.

Un chiffrement inexistant

Lors de l’évaluation de la sécurité du code, faitesparticulièrement attention à la présence et àl’implémentation d’un chiffrement correct. Détectez toutcode manquant. Le non chiffrement des informationssensibles a entraîné de nombreuses brèches de données.Prenons par exemple l’incident qui a eu lieu aux EtatsUnis, au Department of Veterans Affairs (le ministèreaméricain des anciens combattants) signalé en mai 2006.Une des applications du ministère a stockée les numérosde sécurité sociale et les adresses personnelles de tousles anciens combattants retraités L’ordinateur portabled’un employé qui contenait ces informations a été volé,mettant ainsi en danger les données de 38,6 millionsd’anciens combattants.L’analyse du code peut aider à retrouver toutes lesinformations sensibles stockées de manière nonsécurisée. La question que l’on peut se poser estpourquoi ces données étaient disponibles sur unordinateur portable ? Pourquoi ne pas passer des appelssécurisés à une base de données centralisée, protégéepar des contrôles d’accès et un système de surveillancerigoureux ? La réponse probable est qu’il était plus simplede créer une application sur ordinateur portable stockantles informations dans un format non sécurisé.


d. Vulnérabilités liées aux contrôles d’accèsSans contrôles d’accès, les pirates ayant accès au réseau,notamment les éléments internes malicieux, peut accéderfacilement aux données et ressources confidentielles. Lesorganisations doivent mettre en place une technique efficacepour identifier les utilisateurs, mapper les utilisateurs identifiésen fonction des données et s’assurer que les utilisateurs ontaccès aux données appropriées.

La vulnérabilité associée survient lorsqu’une applicationoctroie des droits d’accès supérieurs aux droits nécessaires à unutilisateur ou une application. Selon le niveau d’accès octroyé,un utilisateur peut accéder à des informations confidentiellesou même prendre le contrôle du système. Par conséquent,pour toute application traitant des données sensibles, assurez-vous d’appliquer le principe du privilège le plusfaible : n’octroyez que le niveau d’accès minimum nécessaire àun utilisateur ou à une application pour fonctionner. Cetteapproche implique d’identifier les différentes autorisationsdont une application ou un utilisateur de cette application abesoin pour exécuter les actions requises. Elle impliqueégalement de restreindre tous les modules et objets appropriésà ces privilèges.

Lors de l’évaluation des contrôles d’accès, recherchezégalement ces autres vulnérabilités en termes de sécurité :

● Utilisation non protégée de la base de données et dusystème de fichiers : vous devez vous assurer que les outilsde sécurité de l’application analysent soigneusement lesappels aux bases de données et aux systèmes de fichiers dansle code source de l’application. Autrement, des piratespourraient manipuler ces appels pour exposer des donnéessensibles.

● Vulnérabilités du code dynamique : l’applicationcharge-t-elle du code dynamique ? Les pirates peuventinsérer des commandes malicieuses dans les applications qui chargent du code dynamique. Vous devez vous assurerd’examiner les applications en premier pour vérifier si cerisque existe.

● Chargement du code externe : les pirates peuventmodifier, exposer ou détruire les données en manipulant de manière incorrecte les appels système validés.

● Vulnérabilités liées au stockage des données : pourquoiattaquer une application si les données ne sont pas sécurisées ? Les pirates risquent d’accéder aux serveurs pourvoler des données sensibles si elles ne sont pas stockées demanière sécurisée.

● Erreurs d’authentification : en utilisant les informationsd’authentification d’utilisateurs légitimes, ou en trompant un système de sorte qu’il pense que les informationsd’authentification légitimes sont utilisées, un pirate peutvoler ou manipuler des données. Lors de l’incident depiratage survenu chez ChoicePoint, Inc© par exemple, les pirates ont pu acquérir les véritables informationsd’authentification des utilisateurs, ce qui les a aidés àdissimuler leurs activités malicieuses.

2. Erreurs de validation des entrées/sorties (E/S) etd’encodagePour la plupart des applications, l’entrée doit être dynamique.Les réponses et les sélections des utilisateurs dans uneapplication déterminent et personnalisent leur expérience del’application. Chaque entrée peut introduire une vulnérabilitéet doit être validée pour s’assurer que sa forme ou sa taillen’entraîne pas de comportement imprévisible de l’application.Tous les sources d’entrées et en particulier celles issues desinteractions avec les utilisateurs doivent être contrôlées à unmoment donné après leur entrée dans le système et avantqu’elles n’atteignent leur lieu d’utilisation. Les développeursdoivent vérifier que toutes les entrées sont validées et qu’ellessont conformes aux attentes. Sinon, une application doitempêcher les entrées mal formées de pénétrer dansl’application.

Une faille des contrôles d’accès : la navigation forcée

Lors de l’analyse du code, faites très attention à lanavigation forcée (ou « forced browsing »). Voici commentelle fonctionne : Les pirates émettent une requêtedirectement vers une page Web à laquelle ils ne sontpeut-être pas autorisés à accéder. Si des contrôlesd’accès insuffisants sont en place, il se peut que lespirates parviennent à accéder à la page Web ou auxressources dorsales. Ils peuvent alors voler ou corrompreces ressources.Pour empêcher de telles attaques, les développeursdoivent s’assurer qu’aucune page Web contenant desinformations sensibles n’est mise en antémémoire sur lesserveurs ou sur les ordinateurs personnels locaux desutilisateurs. Toutes ces données ne sont accessibles quepar des requêtes accompagnées d’un jeton de sessionactif et authentifié et associées à un utilisateur quipossède les droits d’accès requis pour accéder à unepage ou à des informations données.

7Logiciel IBM

Pour mieux comprendre quand et où utiliser la validation desE/S et pour savoir où elle est particulièrement nécessaire, ilfaut comprendre certaines des principales attaques et commentles arrêter :

a. Vulnérabilités liées à l’injection de Structured QueryLanguage (SQL)Une vulnérabilité très courante liée à la validation des entréesest l’injection de langage SQL. Les pirates utilisent cettetechnique pour voler de grandes quantités d’informations de cartes de crédit dans les bases de données. Comme le nomde cette attaque l’indique, les pirates envoient des requêtesSQL inappropriées à une base de données afin d’accéderillégalement aux données ou de déstabiliser le comportementde la base de données. La méthode la plus efficace pourstopper les attaques par injection de langage SQL est d’utiliseruniquement les procédures mémorisées ou les appels à la basede données paramétrés qui n’autorisent pas l’injection de code.Cette technique simple permet d’arrêter les attaques parinjection de langage SQL.

b. Vulnérabilités liées au scripting intersites (XSS)Les attaques XSS profitent de mécanismes de sortie malprotégés dans les applications. Les pirates peuvent utiliser ces mécanismes pour pousser les utilisateurs peu méfiants àexécuter ou à accéder à du code malicieux.

Les attaques XSS peuvent généralement être divisées en deuxcatégories :

● Attaques mémorisées : le code injecté est mémorisé defaçon permanente sur la base de données du serveur, leforum de messagerie ou le journal de visiteurs ciblé.

● Attaques réfléchies : le code injecté atteint une victime, parle biais d’un e-mail par exemple, ou en vivant sur un autreserveur. Après que l’utilisateur a cliqué sur un lien ou asoumis un formulaire, le code injecté est transféré au serveurWeb vulnérable, qui renvoie l’attaque au navigateur del’utilisateur. Le navigateur exécute alors le code car le codeprovient d’un serveur digne de confiance.

Les attaques XSS les plus graves entraînent la divulgation descookies de la session de l’utilisateur, ce qui permet au pirate deprendre le contrôle de la session de l’utilisateur et de soncompte. D’autres attaques graves incluent la divulgation desfichiers d’utilisateurs finaux, l’installation d’applications detype cheval de Troie, la redirection d’un utilisateur vers uneautre page ou un autre site qui contient une attaque de typehameçonnage et la modification du contenu. Pour vous

défendre contre les attaques par scripting, protégez toutes lessorties fournies par les utilisateurs aux fichiers clients etjournaux avec HTML Entity Encoding. Ce codage organisetous les caractères non alphanumériques dans une séquence decaractères spéciale qui ne peut pas être interprétée par lesvisualiseurs compatibles HTML.

c. Vulnérabilités liées à une injection dans le systèmed’exploitation (OS)Les applications nécessitent parfois un accès aux commandesde niveau système d’exploitation. Soyez vigilant lorsque cetype d’accès implique aussi des entrées des utilisateurs carcomme pour les injections de langage SQL, les pirates peuvent utiliser les entrées mal formées pour modifier lecomportement du système d’exploitation, entraînant ainsi desviolations de données potentielles ou compromettantl’ensemble du système.

d. Manipulation des cookies personnalisés ou deschamps masquésLes cookies sont un moyen utile et populaire d’assurer lamaintenance des informations de l’utilisateur pendant lessessions et d’une session à l’autre. La création de cookiespersonnalisés avec des noms et des valeurs personnalisés estune pratique dangereuse, qui incite souvent les développeurs àse reposer trop lourdement sur ces cookies non sécurisés, carles pirates peuvent facilement modifier les cookies. Si lesdéveloppeurs ne valident pas les cookies, ils donnent auxpirates l’occasion de créer des injections de langage SQL et delancer des attaques XSS efficaces.

Utilisation du scripting inter-sites (XSS) pour lancer desattaques sur d’autres sites

Les attaques par scripting intersites (XSS) concernentparticulièrement les sites destinés aux consommateurs etles sites des réseaux sociaux, où la communication estfortement orientée vers des supports multimédia depointe au détriment de la sécurité.Prenons par exemple le ver (worm) qui a cibléMySpace.com© en 2006. Qualifié d’extrêmement virulent par un analyste de sécurité, cette attaque XSS aprofité d’une vulnérabilité d’Apple© QuickTime (même siApple ne l’a pas reconnue comme telle au départ) pourinjecter du JavaScript depuis une source externe et sansavertissement dans le profil d’un utilisateur, dans le but devoler les données de connexion MySpace d’un utilisateuret de lancer des attaques de spam à travers MySpace. Lavulnérabilité d’un lecteur multimédia a permis aux piratesde lancer une attaque étendue.


3.Traitement des erreurs et journalisation desvulnérabilitésVotre application présente-t-elle une défaillance progressive ?La gestion et la journalisation des erreurs sont des tâchesparticulièrement difficiles pour les développeurs : qui peutprévoir toutes les défaillances potentielles d’une application etleurs répercussions ?

Le traçage de la gestion et de la journalisation des erreurs d’une application est cependant capital. En effet,aujourd’hui, de nombreuses attaques réussissent en injectant des données erronées dans une application et enprofitant du comportement incorrect qu’elles provoquent dans l’application.

Lorsque vous notez une application en fonction de sa gestiondes erreurs, évaluez d’abord ces deux aspects :

a. Traitement des erreurs non sécuriséeUne mauvaise gestion des erreurs peut fournir aux pirates des informations cruciales pour lancer leurs attaques. Parexemple, de mauvaises habitudes de gestion des erreurspeuvent fournir des informations utiles concernant la manièredont une application traite les entrées, surtout si la gestion des erreurs consiste en une écriture personnalisée en fonctiond’erreurs et d’éléments de données aux détails spécifiques. Les développeurs doivent limiter la quantité de détails qu’ils

révèlent aux utilisateurs de l’application. Évitez les applicationsqui s’intègrent à un serveur Web en affichant les erreurs sur leserveur. Un pirate extérieur peut se servir des informationsainsi divulguées pour accéder aux systèmes.

b. Journalisation non sécurisée ou inadaptéeLes fichiers journaux sont essentiels pour surveiller lecomportement d’une application, mais ils constituentégalement de précieuses ressources pour les pirates. Ne rendezpas les fichiers journaux accessibles. Envisagez la journalisationdu comportement de l’application pour les applications quitraitent des données sensibles, afin de vous assurer que lespirates ne puissent pas couvrir leurs traces.

4. Composants non sécurisésDu code vulnérable peut se retrouver dans une application,par un acte malicieux, par inadvertance ou à cause demauvaises pratiques d’écriture de code. Par exemple, un pirate peut insérer du code malicieux dans une applicationpour contourner les mesures de sécurité existantes.Malheureusement, le code malicieux est souvent d’aspectidentique au code non malicieux. Ces deux types de codepeuvent permettre d’accéder à des réseaux et à des données etils fonctionnent tous les deux généralement comme les autresparties d’une application.

Par conséquent, il est extrêmement difficile d’identifier le code malicieux si l’évaluation des développeurs ne porte que sur la fonctionnalité. Au lieu de cela, les développeursdoivent se concentrer sur les emplacements. Commencez paridentifier les types de fonctionnalités spécifiques (commecommunication réseau, événements programmés etmodifications des privilèges) puis mappez chaque type avec lemodule d’application dans lequel il fonctionne. Recherchez lesinadéquations, comme une bibliothèque graphique exécutantdes opérations réseau sortantes ou des événementsprogrammés figés dans le code dans une applicationmajoritairement en temps réel. Ces inadéquations sont lessignes avant-coureurs d’intentions malicieuse.

Aujourd’hui, les pratiques en matière de développementd’applications impliquent une multitude de composants.Même si ce nombre élevé de composants aide à créer des

Web 2.0 : exposer l’insécurité sur le Web

La nature axée sur le Web du commerce moderne permet d’accéder via le Web à plus de données quejamais auparavant. Les technologies comme AJAXpermettent aux développeurs de logiciels d’accéder plusfacilement aux informations et contribuent à améliorerconsidérablement l’expérience des utilisateurs finaux.Mais ces technologies ne font pas grand chose pourrégler les problèmes de sécurité. Les organisationsdoivent se montrer particulièrement vigilantes quant à leurqualité de code et à leurs vulnérabilités en termes desécurité à mesure qu’elles adoptent de nouveaux outils et de nouvelles techniques de développement.Une innovation du Web 2.0, par exemple, est le mashupqui combine du contenu provenant d’un serveur hébergéà des flux publiquement disponibles. Cependant, cesnouvelles capacités ouvrent de nouvelles possibilitésd’attaque inter-sites. Lorsque les mashups Web 2.0 nesont pas réalisés de manière sécurisée, ils ouvrent la voieà de nouvelles formes de phishing (ou hameçonnage) etautres attaques.

9Logiciel IBM

applications sécurisées plus rapidement, deux typesd’utilisation de composants entraînent d’importants risques de vulnérabilité :

a. Méthodes Java Native Interface non sécuriséesSi les développeurs emploient des méthodes Java NativeInterface (JNI) non sécurisées dans leur code, les piratespeuvent accéder facilement aux ressources critiques, comme lamémoire système ou environnement.

En quoi consistent les méthodes JNI ? Il s’agit de langages deplus haut niveau qui fournissent des interfaces pour vérifierl’accès aux ressources. Par contraste, la méthode JNI est unmoyen plus basique d’accéder à ces ressources, car elle évite cetype d’interfaces pour obtenir de meilleures performances.Comme le code est écrit sans contrôles au niveau del’interface, le risque d’erreur de mauvais codage estextrêmement élevé. De manière générale, évitez d’utiliser desméthodes JNI, sauf dans certains cas exceptionnels où lesperformances sont prioritaires. Localisez et testez toujours demanière approfondie les méthodes JNI utilisées. En outre,vous devez prendre en compte le fait que les bibliothèques JNIpeuvent contenir des erreurs intégrées, en particulier lorsd’une programmation en C ou C++, qui sont plus vulnérablesaux problèmes de dépassement de la mémoire tampon et deconcurrence critique.

b. Méthodes non prises en chargeLes développeurs prennent parfois des raccourcis et utilisentdes méthodes ou des appels non pris en charge au cours dudéveloppement des applications. Utiliser des fonctions ou desroutines non documentés peut produire des insécuritéscachées, qui permettent aux pirates d’attaquer une application.

Pour tout projet de logiciel, assurez-vous que tous les contratsstipulent l’utilisation exclusive de méthodes prises en charge.Pour les applications existent, trouvez les méthodes non prisesen charge, supprimez-les et remplacez-les par des méthodesprises en charge.

5. Erreurs de codageLes erreurs de codage, également connues sous le nomd’erreurs d’implémentation, peuvent être causées par uneformation insuffisante des développeurs, par des délais tropserrés, par un manque de priorités en ce qui concerne lesexigences liées au projet ou par la réutilisation de code dequalité inconnue ou médiocre.

Lorsque des erreurs de codage existent dans les applications,elles peuvent provoquer des comportements inattendus,comme donner le contrôle d’un système ou d’un processus àun pirate ou même arrêter une application. En raison desrisques de sécurité inhérents aux erreurs de codage, ces erreursdoivent être supprimées du code, qu’il soit en cours dedéveloppement ou déjà en production.

Lorsque vous évaluez le code, recherchez ces vulnérabilitésliées au codage :

a. Vulnérabilités liées au dépassement de la mémoiretamponUn dépassement de la mémoire tampon se produit lorsque laquantité de données copiées dans une mémoire tampon estsupérieure à la capacité de cette mémoire. Même si l’oncomprend parfaitement les dépassements de mémoire tampondepuis plus de 20 ans, ils restent un problème courant etentraînent un risque extrêmement élevé. Les pirates peuventprofiter de ce type de mauvaise gestion de la mémoire pourcharger et exécuter du code défaillant dans la mémoire del’ordinateur, ce qui permet aux pirates de prendre le contrôlede tout le système;

Dans les langages structurés, comme C et C++, il existelittéralement des centaines d’appels et de combinaisonsd’appels qui peuvent donner lieu à des erreurs d’allocation de mémoire et à une mauvaise compréhension descomportements de l’application. Cette complexité crée desconditions idéales pour les attaques par dépassement de lamémoire tampon.

Comportement suspect

Signes indiquant qu’une application peut contenir du codemalicieux

Signe

Raw socket access

Minuterie ou fonctiond’obtention de l’heure

Modifications des privilèges

Indique

Portes dérobées possibles

Déclencheur

Niveaux d’accès nonautorisés


Dans les langages de plus haut niveau, comme Java, JavaServerPages (JSP), C#, .Net, les vulnérabilités sont beaucoup moinsnombreuses, car le langage et l’interprétation du moteurd’exécution traitent toute la gestion de la mémoire au niveauinférieur, qui est donc protégée de toute influence par leprogrammeur. Même dans ces langages de plus haut niveau, ilse peut que des appels parfois non documentés créent unevulnérabilité de dépassement de la mémoire tampon à l’insudu programmeur. Soyez très vigilant en matière dedépassement de la mémoire tampon pour les langages de plus haut niveau.

b. Vulnérabilités liées à la chaîne de formatLes vulnérabilités liées à la chaîne de format illustrent larelation entre les erreurs d’implémentation et la qualitéglobale d’une base de code. Les vulnérabilités liées à la chaînede format sont souvent considérées comme un type dedépassement de la mémoire tampon, mais cette comparaisonn’est pas entièrement correcte. Même si une vulnérabilité dechaîne de format peut produire un dépassement de la mémoiretampon, elle peut aussi entraîner l’exposition d’informations,sans dépassement.

Lors du développement de code, une utilisation incomplète decertains appels peut entraîner des vulnérabilités de la chaîne de format. Les bonnes pratiques en matière de codageimpliquent l’utilisation cohérente de certains arguments,comme les spécificateurs de champs. Si au lieu de cela, lesdéveloppeurs élaborent du code à l’aide d’appels incomplets,ces appels ne sont pas suffisamment liés, ce qui permet auxpirates d’insérer des données, des arguments ou des requêtesd’informations supplémentaires dans ces appels. Analysez toutle code à la recherche d’appels incomplets et corrigez cesappels.

c. Erreurs DoSToute application qui donne accès à des données ou desservices critiques ne peut remplir que cette fonction lorsqu’elleest exécutée. Les attaques DoS compromettent les applicationset affectent la livraison de données ou de services critiques.

Une vulnérabilité DoS est due à des erreurs d’implémentationqui provoquent la consommation de ressources rares, limitéesou non renouvelables ou la destruction ou l’altération desinformations de configuration. Pour éviter ces conditionsd’échec, les développeurs doivent concevoir leurs applicationspour fonctionner même dans les pires scénarios.

d. Vulnérabilités liées à l’augmentation des privilègesDans de nombreux cas, le but ultime d’une attaque estl’augmentation des privilèges. Un utilisateur ayant desinformations d’authentification insuffisantes obtient un accèsprivilégié, ce qui permet au pirate d’accéder à ces données etdes ressources confidentielles, et même de prendre le contrôlede tout le système ou de le détruire, tout en restant classécomme utilisateur de confiance.

Un pirate élève généralement ses privilèges en exploitant lessections des programmes dans lesquelles une applicationdélivre ou reçoit des privilèges de niveau supérieur. Parfois, lesapplications doivent créer des processus sous des utilisateursdifférents ou avec des niveaux d’accès différents. La charge dela preuve incombe aux développeurs afin de s’assurer que leprocessus d’augmentation des privilèges ne peut pas êtreexploité par des programmes malicieux. De même, leprocessus de désaugmentation doit aussi être testé enprofondeur.

Par exemple, lorsqu’un processus de priorité inférieureredonne le contrôle à un autre programme doté de privilègesplus élevés, l’application doit toujours vérifier la validité descodes de retour, les conditions d’erreur et les opérations dediminution des privilèges déclenchées par les erreurs. Si unede ces opérations échoue, les programmes peuvent continuer àfonctionner à des niveaux ou des privilèges différents de ceuxqui sont requis.

11Logiciel IBM

e. Concurrence critiqueDeux processus peuvent partager le contrôle ou les données. La concurrence critique désigne la compromissionde ce partage, qui découle généralement d’erreurs desynchronisation, lorsqu’il existe un risque de conflits entre lesprocessus et donc une vulnérabilité. Une faille classiqueinterrompt une paire d’appels séquentiels qui doivent êtreexécutés automatiquement sans interruption par un autre filou processus sur la machine avec un troisième processus.

Un exemple est la vérification combinée des droits d’accès àun fichier, suivie par un appel ultérieur visant à écrire ou à lirece fichier. En interrompant le processus entre les deux appels,un pirate peut réécrire ou modifier le fichier car cecomportement est prévisible. Le pirate peut placer desinformations inappropriées dans un fichier ou accéder à unfichier inapproprié.

IV. Application de la liste de contrôle pourl’analyse du code sourceA. Des applications coupables jusqu’à ce qu’elles soientprouvées innocentesLes cinq grands types de vulnérabilités de code décritsprécédemment représentent tous les risques les plus probables et les plus dangereux contenus dans le code existant et hérité. Les clients professionnels, les chefs de projet de développement de logiciels et les développeursdoivent s’assurer que tout le code est analysé afin d’identifierces cinq catégories de vulnérabilités.

Compte tenu de la multitude de risques posée par cesvulnérabilités et par leur présence probable dans denombreuses applications, les équipes de projet doivent traitertoutes les applications qu’elles mettent en service, qu’ellescréent ou qu’elles réévaluent avec beaucoup de scepticisme enmatière de sécurité. Cette attitude marque un changementimportant par rapport à l’approche de développementtraditionnelle, qui consiste à analyser une application en sebasant sur sa vitesse, ses fonctionnalités et sa convivialité.

Aujourd’hui, les équipes de développement traitent chaqueapplication existante ou en cours de développement comme unrisque de sécurité avant que son innocuité puisse être prouvée.Les équipes doivent réagir de la sorte à cause des risques quereprésentent ces vulnérabilités pour l’entreprise. En effet,comme indiqué par un groupe de travail de l’Institute ofElectrical and Electronics Engineers (IEEE) étudiant lenouveau rôle de la sécurité dans le cycle de développement deslogiciels, les applications ont aujourd’hui un effet beaucoupplus important sur l’approbation des clients, sur la stabilité etsur la rentabilité des entreprises à long terme.2

Par conséquent, le groupe de l’IEEE recommande aux équipes de projet traditionnellement concentrées uniquementsur la satisfaction des demandes des clients d’apprendre àcommuniquer le risque de sécurité aux sponsors en amont,afin de justifier les exigences appropriées en matière de budget et de projet. Même si ces changements sont peupopulaires, aujourd’hui, les menaces de sécurité et l’obligationde protéger les informations sensibles et personnelles exigentune concentration dédiée à la sécurité de la part de tous lesmembres des équipes de projet.

Erreurs courantes liées au déni de service (DoS)

DoS d’arrêt de l’application : Comment l’applications’arrête-t-elle ? Certains auteurs d’applications, lorsqu’ilsimplémentent la fonctionnalité de fermeture pour uneapplication le font de manière trop générale. Par exemple,si une application se ferme automatiquement en raisond’erreurs d’entrée au moyen d’une fonction système desortie, un pirate peut provoquer une suite d’événementssimilaire qui entraîne l’arrêt artificiel et intempestif del’application.DoS des connexions à la base de données non fermées :L’application se connecte-t-elle sans problème aux basesde données ? Pour autoriser l’accès d’un processus auxdonnées, l’application et la source de données doiventd’abord établir une connexion. Si ce processus est codéincorrectement, la queue des requêtes de récupérationpeut devenir embouteillée et surchargée en raison destentatives de connexion échouées aux bases de données.


B. Tests de vulnérabilité du code sourceLes outils de test de vulnérabilité du code source à eux seuls ne suffisent pas à sécuriser un logiciel. Ces outils aident les développeurs et les analyseurs de code à évaluer les applications, même celles qui contiennent des millions de lignes de code, pour identifier les vulnérabilités potentiellesles plus dangereuses. Avec ces outils de test, les équipes dedéveloppement et de résolution peuvent classer leurs effortspar ordre de priorité et adopter une approche axée sur lesrisques pour améliorer la base de code, en commençant par lesproblèmes les plus critiques.

La création d’applications sécurisées nécessite que lesorganisations développent du code sécurisé et prévoient destests de vulnérabilité en continu. Pour toute application, lasécurité du code doit être une condition requise préalable à lapublication du code. L’explosion du nombre de menacesciblées doit faire des tests de vulnérabilité de la sécurité desapplications un passage obligé dans toutes les entreprises.

Ce travail est pénible et compliqué car les applicationscomplexes peuvent contenir des erreurs de codage et desvulnérabilités extrêmement complexes et difficiles à identifier.Les équipes d’analyse du code ont besoin d’outils d’analyse decode sophistiqués. En effet, la nature technique et les causesreconnues des erreurs d’implémentation et de codage poussentde nombreuses entreprises à faire de l’analyse du code le pointde départ logique de l’amélioration de la sécurité globale del’application.

C. Choisir le bon outilLorsqu’il s’agit de choisir un outil automatisé de test devulnérabilité du code source à utiliser tout au long du cycle de développement d’un logiciel, les organisations doiventd’abord évaluer leurs ressources de développement de codeexistantes. Ces ressources comprennent l’expertise en sécuritéinterne, les technologies et les partenaires de service ainsi queleurs objectifs d’amélioration du cycle de développement delogiciels. Ces objectifs peuvent impliquer la diminution dunombre de correctifs de sécurité publiés, la réduction des

risques de violations de données coûteuses, la réduction des coûts liés au cycle de développement des logiciels, laconformité à des normes plus strictes et l’obtention d’unavantage concurrentiel. Les entreprises doivent choisir l’outilqui fonctionne le mieux avec leurs ressources de codeexistantes et qui aide l’organisation à atteindre ses objectifs entermes de cycle de développement de logiciels. Elles doiventégalement s’assurer que l’outil choisi couvre toutes les erreursde codage et tous les défauts de conception qui doivent êtreidentifiés et éliminés pour créer une application sécurisée.

Les nombreuses violations de données exposées par les média à ce jour, qui sont souvent dues à des défauts de code, soulignent la nécessité d’éradiquer les vulnérabilitéspour empêcher la divulgation d’informations sensibles ouréglementées par négligence ou par malveillance. Même pourles organisations qui ne sont pas encore soumises à cesréglementations, la croissance rapide en matière d’outils, de technologies et de langages de programmation plusconnectés, y compris les applications Web 2.0, rend toutes les organisations qui utilisent ces technologies vulnérables.Compte tenu des coûts considérables aussi bien financiersqu’en termes de réputation résultant des violations dedonnées, les entreprises cherchent de plus en plus à trouver lemoyen le plus efficient et efficace pour garantir la sécurité deleur code source, pour développer des applications sécuriséeset pour éliminer les bogues le plus tôt possible dans leprocessus de développement, bien avant la livraison du code.

Les entreprises qui parviennent à intégrer efficacement les tests de vulnérabilité du code source à leurs pratiques de cycle de développement de logiciels peuvent éviter lesimpacts négatifs des défauts de sécurité. Ces pratiquesaméliorées débouchent sur des économies considérables pourles entreprises et pour les clients, les partenaires et les autresacteurs qui utilisent leurs logiciels. Ces économies sont lapreuve de l’efficacité d’un programme de sécurité de codesource.

13Logiciel IBM

V. ANNEXE : Liste de contrôle pour l’analyse de la sécurité du code sourceVérifier que les applications sont sécurisées commence par la recherche des vulnérabilités afin d’atténuer les risques qu’ellesposent pour l’application et l’intégrité des données :

Catégorie Vulnérabilité Risque

Fonctions liées à la sécurité Cryptographie faible ou non conforme Les pirates peuvent casser les algorithmes pour volerdes données sensibles

Communications réseau non sécurisées Les méthodes légitimes utilisées pour envoyer lesinformations ne sont pas documentées ni protégées,ce qui expose des données critiques

Vulnérabilités liées à la configuration de l’application L’accès aux fichiers ou options de configuration nonprotégés permet de manipuler les propriétés ou lesdonnées du logiciel

Vulnérabilités de contrôle d’accès Accès non autorisé aux données et aux ressourcesconfidentielles

Utilisation non protégée de la base de données et dusystème de fichiers

Le piratage et la manipulation des appels aux basesde données et aux systèmes de fichiers exposent lesdonnées

Vulnérabilités de code dynamique Insertion réussie de commandes malicieuse dans lesapplications qui chargent du code dynamique sansvalidation appropriée

Chargement de code local La manipulation de ces appels au niveau du systèmepermet la manipulation, l’exposition et la destructiondes données

Vulnérabilité liée au stockage des données Les données stockées de manière non sécuriséepeuvent être volées facilement

Erreurs d’authentification Les pirates utilisent les informations d’authentificationd’utilisateurs légitimes pour voler ou pour manipulerdes données

Erreurs de validation des E/Set les erreurs d’encodage

Vulnérabilités liées à l’injection de langage SQL Envoi de commandes SQL directement aux bases dedonnées pour voler ou manipuler des données

Vulnérabilités liées aux attaques XSS Les utilisateurs se font pirater leurs sessions à leurinsu, téléchargent des chevaux de Troie à leur insu ousont victimes d’arnaques par hameçonnage

Vulnérabilités liées à une injection dans le systèmed’exploitation (OS)

Les pirates modifient ou abusent des commandes dusystème d’exploitation pour contrôler les données etles ressources

Manipulation des cookies personnalisés ou deschamps masqués

Crée un niveau de confiance dont les pirates seservent pour lancer des attaques, comme une injectionde SQL ou une attaque XSS


Traitement des erreurs etjournalisation des vulnérabilités

Traitement des erreurs non sécurisée Fournit aux pirates des informations utiles pour leursattaques

Journalisation non sécurisée ou inadaptée Les fichiers journaux accessibles divulguent desinformations utiles pour les attaques, tandis qu’unejournalisation inappropriée permet aux pirates d’effacerleurs traces

Composants non sécurisés Code malicieux Du code d’apparence légitime inséré dans le logicielpeut permettre aux pirates de contourner les mesuresde sécurité

Méthodes locales non sécurisées L’utilisation non contrôlée de méthodes locales permetaux pirates d’accéder à des ressources critiquescomme la mémoire système ou environnement

Méthodes non prises en charge Les fonctions ou routines non documentées sont unesource d’insécurité cachée qui peut être exploitée

Erreurs de codage Vulnérabilités liées au dépassement de la mémoiretampon

Les pirates peuvent prendre en otage les ressourcesdu système

Vulnérabilités liées à la chaîne de format Entraîne des dépassements de la mémoire tampon oul’exposition des données

Erreurs DoS Empêche le logiciel de fonctionner

Vulnérabilités liées à l’augmentation des privilèges Les pirates peuvent accéder aux données et auxressources confidentielles

Concurrence critique Contourner un processus d’application pour manipulerdes opérations

Utilisation de méthodes locales non sécurisées Peut sacrifier la sécurité au profit des performances,donnant ainsi un accès non sécurisé à la mémoiresystème ou environnement

Méthode non prise en charge Des opérations légitimes peuvent lancer des appels àdu code vulnérable à l’insu de l’utilisateur

Catégorie Vulnérabilité Risque

Pour en savoir plusPour en savoir plus sur IBM Rational AppScan SourceEdition, contactez votre représentant commercial IBM, votrepartenaire commercial IBM ou rendez-vous à l’adresse :ibm.com/software/rational/products/appscan/source/

À propos des auteursRyan Berg est Senior Security Architect chez IBM. Ryan estun orateur, un formateur et un auteur populaire dans lesdomaines de la sécurité, de la gestion des risques et desprocessus de développement sécurisés. Il détient des brevets etdes brevets en instance dans les secteurs de l’évaluation de lasécurité multilingue, de la sécurité au niveau du noyau, dulangage d’évaluation de sécurité intermédiaire et desprotocoles de communication à distance sécurisés

IBM France17, avenue de l’Europe92275 Bois-Colombes Cedex

La page d’accueil d’IBM se trouve à l’adresse ibm.com

IBM, le logo IBM, ibm.com, AppScan et Rational sont des marques oumarques déposées d’International Business Machines Corporation auxÉtats-Unis et/ou dans d’autres pays. Si ces marques et les autres termesdéposés d’IBM comportent, sur la première occurrence dans ce document,un symbole de marque de commerce (® ou ™), ces symboles indiquent desmarques de commerce enregistrées aux États-Unis ou de common lawappartenant à IBM au moment de la publication de ce document. Cesmarques de commerce peuvent être enregistrées ou de common law dansd’autres pays.

Une liste à jour des marques d’IBM est disponible sur Internet, sous larubrique « Copyright and trademark information » (Informations sur lesdroits d’auteur et les marques), sur le site ibm.com/legal/copytrade.shtml

Java ainsi que tous les logos et toutes les marques mentionnant Java sontdes marques de Sun Microsystems, Inc. aux États-Unis et/ou dans d’autrespays.

1 Ponemon Institute, « 2006 Annual Study: Cost of a Data Breach, »octobre 2006.

2 Biscick-Lockwood, Bar, « The Benefits of Adopting IEEE P1074-2005, »2 avril 2006.

Le présent document peut contenir des informations ou des référencesconcernant certains produits, logiciels ou services IBM non annoncés dansce pays. Cela ne signifie pas qu’IBM ait l’intention de les y annoncer.

Toute référence à un produit logiciel ou service IBM n’implique pas queseul ce produit, logiciel ou service puisse être utilisé. Tout élémentfonctionnellement équivalent peut être utilisé s’il n’enfreint aucun droit d’IBM.

Le présent document est publié uniquement à titre indicatif.Les informations qu’il contient sont soumises à modification sans préavis.Veuillez prendre contact avec votre revendeur IBM local pour obtenir lesdernières informations sur les produits et les services IBM.

IBM ne donne aucun avis juridique, comptable ou d’audit financier et ne garantit pas que ses produits ou services sont conformes aux loisapplicables. Les utilisateurs sont seuls responsables du respect des lois etréglementations de sécurité en vigueur, en particulier les lois etréglementations nationales.

© Copyright IBM Corporation 2009Tous droits réservés.

RAW14198-FRFR-00

http://www.ibm.com/software/rational/products/appscan/source/

http://www.ibm.com/legal/copytrade.shtml

http://ibm.com/software/rational

la voie vers une application sécurisée

Documents