ANNEXE L'ENTENTE DE

DVELOPPEMENT DE LOGICIEL SCURIS

AVERTISSEMENT : CE DOCUMENT NE DEVRAIT TRE CONSIDR QUE

COMME GUIDE SEULEMENT. OWASP SUGGRE FORTEMENT QUE VOUS
CONSULTIEZ UN AVOCAT SPCIALIS POUR VOUS AIDER NGOCIER UNE
ENTENTE DE LOGICIEL.

Annexe de l'entente de dveloppement de logiciel scuris OWASP

TABLE DES MATIRES

ANNEXE L'ENTENTE DE DVELOPPEMENT DE LOGICIEL SCURIS....1
TABLE DES MATIRES....................................................................................................2
INTRODUCTION...............................................................................................................3
PROPOS DU PROJET....................................................................................................3
OBJECTIONS.....................................................................................................................4
1. MAIS TOUS LES TERMES NE SONT PAS ADQUATS POUR NOUS.............4
2. MAIS QUI DEVRAIT PAYER POUR CES ACTIVITS.......................................4
3. MAIS LE NIVEAU DE RIGUEUR EST MAUVAIS..............................................5
4. MAIS NOUS NE POUVONS PRENDRE AUTANT DE RISQUE........................5
5. MAIS COMMENT POUVONS-NOUS ASSURER LE CODE DE TIERCE
PARTIE............................................................................................................................6
6. MAIS POURQUOI DEVRAIS-JE AVOIR TOUS CES PROBLMES..................6
7. MAIS IL EST TROP DIFFICILE DE PRODUIRE TOUTE CETTE
DOCUMENTATION.......................................................................................................7
ANNEXE DE L'ENTENTE................................................................................................8
8. PHILOSOPHIE.........................................................................................................8
9. ACTIVITS DU CYCLE DE VIE...........................................................................9
10. ZONES D'EXIGENCES DE SCURIT...........................................................10
11. PERSONNEL ET ORGANISATION.................................................................11
12. ENVIRONNEMENT DE DVELOPPEMENT.................................................12
13. BIBLIOTHQUES, CADRES DE TRAVAIL ET PRODUITS.........................12
14. RVISIONS DE SCURIT.............................................................................12
15. ASSURANCE.....................................................................................................13
16. GESTION DES PROBLMES DE SCURIT ET ACCEPTATION..............13

Page 2

Annexe de l'entente de dveloppement de logiciel scuris OWASP

INTRODUCTION
Cette Annexe au contrat est prvue pour aider les dveloppeurs de logiciels et leurs
clients, ngocier et saisir des termes contractuels et des modalits importantes, relies
la scurit du logiciel dvelopper ou livrer. La raison pour ce projet est que la plupart
des ententes ne parlent pas de ces problmes et que les parties ont des opinions
normment diffrentes sur ce qui a t convenu. Nous croyons qu'noncer clairement
ces termes est la meilleure faon d'assurer que les deux parties puissent prendre des
dcisions informes sur la faon de procder.
Comme l'a indiqu John Pescatore, un directeur de recherche :
La scurit d'un logiciel commercial s'amliorera lorsque le march
exigera une meilleure scurit. Au minimum, chaque demande de
soumission pour un logiciel devrait demander au fournisseur de dtailler la
faon dont il teste leurs produits pour les vulnrabilits de scurit. Cette
tape commencera convaincre les fournisseurs de logiciels prts
l'emploi et les dveloppeurs impartis que les socits estiment la
scurit.
Nous demandons avec instance aux Clients et Dveloppeurs d'utiliser ce document
comme cadre de travail pour discuter des attentes et ngocier les responsabilits. Cette
Annexe est prvue pour tre jointe une entente de dveloppement de logiciel. Ces
dispositions sont ngociables, signifiant qu'elles peuvent et devraient tre discutes par le
Client et le Dveloppeur. Pour plus d'information gnrale sur les ententes concernant les
logiciels, veuillez vous reporter http://www.nolo.com.

OWASP reconnat avec reconnaissance la contribution spciale d Aspect Security

pour leur rle dans la recherche et la prparation de ce document.
http://www.aspectsecurity.com

La traduction franaise de ce document est

une gracieuset de Gestion medscure et
dHorizon-Cumulus.
http://medsecure.ca

Page 3

http://horizon-cumulus.ca

Annexe de l'entente de dveloppement de logiciel scuris OWASP

Page 4

Annexe de l'entente de dveloppement de logiciel scuris OWASP

PROPOS DU PROJET
Ce document a t cr par la Fondation de lOpen Web Application Security Project, un
organisme sans but lucratif, dvou la cration d'outils et de documentation gratuits et
libres relis aux logiciels scuriss. Pour faciliter une utilisation dans l'entente prive, ce
document est plac dans le domaine public. Vous pouvez trouver des dtails
supplmentaires

propos
de
ce
projet
au
http://www.owasp.com/documentation/legal.html. Nous accueillons les commentaires
tant des producteurs que des consommateurs de logiciels, ainsi que de la communaut
juridique.
OBJECTIONS
Les quelques pages suivantes couvrent certaines des objections frquemment entendues
utiliser cette langue dans les ententes de dveloppement de logiciel :
1.

MAIS TOUS LES TERMES NE SONT PAS ADQUATS POUR NOUS...

Ce document devrait tre considr comme point de dpart pour votre entente. Vous
pouvez ne pas aimer toutes les activits ou pourriez vouloir en suggrer plus. Vous
pourriez vouloir assigner les responsabilits diffremment. Ce document n'est pas prvu
pour saisir exactement les besoins de tous les Clients et Dveloppeurs de logiciels. Il est
prvu pour fournir un cadre de travail, pour discuter des principaux sujets qui sont
importants, pour assurer que le logiciel est finalement scuris. Aprs avoir eu une
discussion de scurit et avoir conclu une entente, vous devriez personnaliser cette
entente en consquence.
2.

MAIS QUI DEVRAIT PAYER POUR CES ACTIVITS...

Cette entente n'est PAS une faon de placer un plus gros fardeau sur le dveloppeur du
logiciel. La question n'est pas de savoir sil y a des cots associs la scurit, c'est
vident qu'il y en a. La bonne question est plutt de savoir quelles activits devraient tre
ralises par les deux parties, pour minimiser ces cots et lorsqu'elles devraient survenir.
Cette annexe est intentionnellement silencieuse sur la question de la partie qui devrait
payer pour les activits dcrites aux prsentes. Tandis que plusieurs de ces activits
devraient dj tre en cours, et sont attendues par plusieurs Clients, elles ne sont pas
habituellement pratiques dans l'industrie du logiciel. La question de la partie qui paie (et
combien) devrait faire partie de la ngociation.

Page 5

Annexe de l'entente de dveloppement de logiciel scuris OWASP

Calculer les cots de la scurit est trs difficile. Tandis qu'il y a des cots associs la
ralisation d'activits de scurit, il y a galement des cots importants associs avec le
fait de les ignorer. Nous sommes convaincus que la faon la plus rentable de dvelopper
un logiciel est de rduire la possibilit que des failles de scurit soient prsentes et de
minimiser le temps entre la prsentation d'une faille et sa correction.
Une distinction importante faire en calculant les cots est entre l'tablissement de
mcanismes de scurit et les activits d'assurance qui s'assurent que ces mcanismes
sont adquats et efficaces. Tenter d'ajouter des mcanismes la fin d'un cycle de vie peut
provoquer de srieux problmes de conception et augmentera normment les cots.
Cette entente encourage les dcisions htives sur les mcanismes, pour minimiser ces
cots. De faon similaire, attendre juste avant le dploiement pour raliser des activits
d'assurance, comme la rvision de code et les essais de pntration, augmentera aussi
normment les cots. Nous croyons que la faon la plus rentable de gagner l'assurance
est de placer un niveau d'effort constant dans l'assurance, travers tout le cycle de vie.

3.

MAIS LE NIVEAU DE RIGUEUR EST MAUVAIS...

Cette entente prsume que le logiciel tant dvelopp est raisonnablement important pour
une grande entreprise ou une agence gouvernementale. Nous avons slectionn un
niveau de rigueur , pour l'entente qui est atteignable par la majorit des organisations
de dveloppement de logiciels et identifieront et greront la plupart des risques communs.
Cependant, pour un logiciel qui sera utilis dans des applications vitales, comme les
logiciels mdicaux, financiers ou relis la dfense, vous pourriez vouloir augmenter le
niveau de rigueur. Vous pourriez vouloir ajouter des activits supplmentaires de rvision,
de documentation et d'essais. Vous pourriez vouloir amliorer les processus pour trouver,
diagnostiquer et remdier aux vulnrabilits. Pour les applications moins sensibles, vous
pourriez vouloir rduire ou retirer des activits.

4.

MAIS NOUS NE POUVONS PRENDRE AUTANT DE RISQUES...

Cette entente est prvue pour faciliter les discussions propos de la partie qui prendra le
risque pour les vulnrabilits de scurit dans le logiciel. une extrmit du spectre, le
Client pourrait prendre tout le risque et le Dveloppeur pourrait livrer un code avec
beaucoup de vulnrabilits. l'autre extrmit, le Dveloppeur pourrait prendre tous les

Page 6

Annexe de l'entente de dveloppement de logiciel scuris OWASP

risques et assumer la responsabilit pour livrer un code parfait. Ces deux extrmes sont
irralisables.
Actuellement, dans cette entente, le Dveloppeur prend le risque pour les problmes qui
ont t couverts dans les exigences ou devraient tre couverts par des efforts raisonnables
de tests. Mais les mesures correctrices de nouveaux problmes de scurit doivent
tre payes par le Client. Nous croyons que ceci est un quilibre utile, puisque le
Dveloppeur peut limiter son risque et encourage le Client faire corriger les exigences
de scurit ds le dpart. Mais il y a plusieurs autres solutions possibles ce problme.
Veuillez nous laisser savoir si vous avez des suggestions de remplacement et que nous
pouvons inclure dans les versions futures de ce document.
Notez que la discussion ici ne couvre que le risque associ la correction des
vulnrabilits de scurit dans le code et n'inclut pas les cots associs la rcupration
des incidents de scurit, selon toute exploitation de ces vulnrabilits. Nous sommes
intresss dans les pratiques exemplaires dans ce domaine.
5.

MAIS COMMENT POUVONS-NOUS ASSURER LE CODE DE TIERCE

PARTIE...

Presque tous les projets de logiciels utilisent une quantit importante de code de tierce
partie, comme les bibliothques, les cadres de travail et les produits. Ce code est tout
aussi important d'un point de vue de scurit, que le code personnalis dvelopp
prcisment pour votre projet.
Nous croyons que la responsabilit d'assurer la scurit de ce code est mieux d'tre
assume par le Dveloppeur, bien qu'il puisse ne pas avoir la pleine capacit lui-mme de
garantir cette scurit. Cependant, la scurit doit faire partie de la dcision dvelopper
ou acheter et ceci semble la meilleure faon de l'encourager.
Le Dveloppeur, bien sr, a l'option de transfrer cette responsabilit aux fournisseurs de
logiciel de tierce partie. Le Dveloppeur peut galement analyser le code de tierce partie
lui-mme ou embaucher des experts de scurit pour l'analyser pour lui.

6.

MAIS POURQUOI DEVRAIS-JE AVOIR TOUS CES PROBLMES...

Finalement, nous croyons qu'il n'y a pas de solution de remplacement pour intgrer la
scurit dans le processus de contrat du logiciel. Actuellement, nous croyons qu'il y a des
msententes srieuses propos de la livraison de la scurit du code, en vertu de
Page 7

Annexe de l'entente de dveloppement de logiciel scuris OWASP

plusieurs ententes de dveloppement de logiciels. Ceci peut seulement mener des

contentieux coteux et une dcision prise par des individus avec peu
d'exprience
ou
de
comprhension
des
logiciels.
Reportez-vous

http://www.owasp.org/columns/jwilliams/jwilliams4.html pour une discussion complte

de ce problme.
Il y a plusieurs avantages travailler compltement sur cette entente. Le principal est
qu'il rendra les attentes claires entre les parties impliques. Dans certains cas, elle aidera
empcher les poursuites judiciaires, lorsque de difficiles problmes de scurit surgissent
dans le logiciel. galement, celles-ci sont les mmes activits qui sont requises de
plusieurs raisons de conformits juridiques et rglementaires.

7.

MAIS IL EST TROP DIFFICILE DE PRODUIRE TOUTE CETTE

DOCUMENTATION...

OWASP n'encourage pas la documentation pour l'amour de la documentation... Cette

entente se concentre sur l'encouragement de la qualit, pas la quantit. Nous croyons qu'il
serait possible (dans certains projets) de satisfaire cette entente avec une courte
valuation de risque, quelques pages d'exigences, un court document de conception
logicielle, un plan de tests et certains rsultats de tests.
L'objectif de cette documentation est simplement d'assurer, chaque tape du cycle de
vie, que l'attention adquate a t porte la scurit. Un avantage supplmentaire est que
cette documentation peut tre recueillie sous la forme d'un ensemble de certification ,
qui tablit essentiellement l'argument, de la raison pour laquelle on devrait faire
confiance ce logiciel pour faire ce qu'il prtend faire.

Page 8

Annexe de l'entente de dveloppement de logiciel scuris OWASP

ANNEXE L'ENTENTE
Cette Annexe est faite pour _____________________ ( Entente ) entre le Client et le
Dveloppeur. Le Client et le Dveloppeur conviennent de maximiser la scurit du
logiciel, conformment aux dispositions suivantes.
8.

PHILOSOPHIE
Cette Annexe est prvue pour clarifier les droits et obligations relis la scurit
de toutes les parties d'une relation de dveloppement de logiciel. Au plus haut
niveau, les parties conviennent que :

(a)

Les dcisions de scurit seront bases sur le risque. Les dcisions propos de
la scurit seront prises conjointement avec le Client et le Dveloppeur, selon une
comprhension arrte des risques impliqus.

(b)

Les activits de scurit seront quilibres. Un effort de scurit sera peu prs
galement distribu travers tout le cycle de vie du dveloppement du logiciel.

(c)

Les activits de scurit seront intgres. Toutes les activits et la

documentation discutes aux prsentes peuvent et devraient tre intgres dans le
cycle de vie du dveloppement du logiciel du Dveloppeur et ne devraient pas
tre gardes spares du reste du projet. Rien dans cette Annexe n'implique aucun
processus particulier de dveloppement de logiciel.

(d)

Les vulnrabilits sont attendues. Tous les logiciels comportent des anomalies
et certaines de celles-ci creront des problmes de scurit. Le Client et le
Dveloppeur s'efforceront d'identifier les vulnrabilits aussi tt que possible dans
le cycle de vie.

(e)

L'information de scurit sera compltement divulgue. Toute l'information

portant sur la scurit sera partage entre le Client et le Dveloppeur,
immdiatement et entirement.

(f)

Seule la documentation de scurit utile est ncessaire. La documentation de

scurit n'a pas besoin d'tre exhaustive, afin de dcrire clairement la conception,
l'analyse de risque ou les problmes de scurit.

9.
(a)

ACTIVITS DU CYCLE DE VIE

Comprhension du risque. Le Dveloppeur et le Client conviennent de travailler
ensemble comprendre et documenter les risques auxquels l'application est
confronte. Cet effort devrait identifier les principaux risques aux biens et
fonctions importantes, fournis par l'application. Chacun des sujets numrs dans
la section des exigences devrait tre considr.
Page 9

Annexe de l'entente de dveloppement de logiciel scuris OWASP

(b)

Exigences. Selon les risques, le Dveloppeur et le Client conviennent de travailler

ensemble pour crer des exigences dtailles de scurit, en tant que partie
intgrante des spcifications du logiciel dvelopper. Chacun des sujets numrs
dans la section des exigences de cette Annexe devrait tre discut et valu par le
Dveloppeur et le Client. Ces exigences peuvent tre satisfaites par un logiciel
personnalis, un logiciel de tierce partie ou la plateforme.

(c)

Conception. Le Dveloppeur accepte de fournir de la documentation qui explique

clairement la conception pour atteindre chacune des exigences de scurit. Dans
la majorit des cas, cette documentation dcrira les mcanismes de scurit, o les
mcanismes s'adaptent dans l'architecture et tous les modles pertinents de
conception, pour assurer leur utilisation propre. La conception devrait clairement
prciser si le support provient du logiciel personnalis, du logiciel de tierce partie
ou de la plateforme.

(d)

Implantation. Le Dveloppeur convient de fournir et de suivre un ensemble de

lignes directrices de codage de scurit et d'utiliser un ensemble d'interfaces
communes de programmation de contrle de la scurit (comme lOWASP
ESAPI). Les lignes directrices indiqueront comment le code devrait tre format,
structur et comment. Les interfaces communes de programmation de contrle
de la scurit dfiniront comment les contrles de scurit doivent tre nomms et
comment les contrles de scurit doivent fonctionner. Tout le code portant sur la
scurit sera soigneusement comment. Une orientation prcise sur l'vitement
des vulnrabilits de scurit sera incluse. Tout le code sera galement rvis au
moins par un autre Dveloppeur, contre les exigences de scurit et les lignes
directrices de codage, avant qu'il ne soit considr comme tant prt pour les
modules d'essai.

(e)

Analyse de scurit et essais. Le Dveloppeur effectuera une analyse de scurit

et les essais de l'application (galement appele vrification ) conformment
aux exigences de vrification d'une norme convenue (comme OWASP ASVS). Le
Dveloppeur documentera les constatations de vrification, conformment aux
exigences de rapport de la norme. Le Dveloppeur fournira les constatations de
vrification au Client.

(f)

Dploiement scuris. Le Dveloppeur convient de fournir des lignes directrices

de configuration scurise qui dcrivent entirement les options pertinentes de
configuration et leurs implications pour la scurit globale du logiciel. Cette ligne
directrice devra inclure une description complte des dpendances de la
plateforme de support, y compris le systme d'exploitation, le serveur Web et le
serveur d'application, et la faon dont ils devraient tre configurs pour la
scurit. La configuration par dfaut du logiciel devra tre scurise.

Page 10

Annexe de l'entente de dveloppement de logiciel scuris OWASP

10.

ZONES D'EXIGENCES DE SCURIT

Les zones de sujets suivantes doivent tre considres pendant les activits de
comprhension du risque et de dfinition des exigences. Cet effort devrait
produire un ensemble d'exigences prcises, personnalises et vrifiables. Tant le
Dveloppeur que le Client devraient tre impliqus dans ce processus et doivent
convenir d'un ensemble d'exigences finales.

(a)

Validation et codage. Les exigences doivent prciser les rgles pour canoniser,
valider et coder chaque entre l'application, que ce soit des utilisateurs, des
systmes de fichiers, des bases de donnes, des rpertoires ou des systmes
externes. La rgle par dfaut doit tre que toutes les entres sont invalides,
moins qu'elles ne correspondent une spcification dtaille de ce qui est permis.
De plus, les exigences doivent prciser l'action prendre, lorsqu'une entre
invalide est reue. Prcisment, l'application ne doit pas tre susceptible aux
injections, aux dbordements, aux violations, ou d'autres attaques d'entre
corrompue.

(b)

Authentification et gestion de session. Les exigences doivent prciser comment

les authentifiants et les identifiants de session seront protgs travers leur cycle
de vie. Les exigences pour toutes les fonctions relies, y compris les mots de
passe oublis, les mots de passe changeants, le rappel des mots de passe, la
dconnexion et les connexions multiples doivent tre incluses.

(c)

Contrle d'accs. Les exigences doivent inclure une description dtaille de tous
les rles (groupes, privilges, autorisations) utiliss dans l'application. Les
exigences doivent galement inclure tous les biens et fonctions fournis par
l'application. Les exigences doivent compltement prciser les droits d'accs
exacts de chaque bien et fonction pour chaque rle. Une matrice de contrle
d'accs est le format suggr pour ces rgles.

(d)

Gestion d'erreur. Les exigences doivent dtailler la faon dont les erreurs
survenant pendant le traitement seront gres. Certaines applications devraient
fournir des rsultats selon le meilleur effort, dans l'ventualit d'une erreur, tandis
que d'autres devraient mettre fin au traitement immdiatement.

(e)

Journalisation. Les exigences doivent prciser que les vnements portant sur la
scurit et doivent tre journalises, comme les attaques dtectes, les tentatives
choues d'ouverture de session, et les tentatives de dpasser les autorisations. Les
exigences doivent galement prciser l'information saisir avec chaque
vnement, y compris l'heure et la date, la description de l'vnement, les dtails
de l'application et autre information utile dans les efforts d'investigation
informatique.

Page 11

Annexe de l'entente de dveloppement de logiciel scuris OWASP

(f)

Connexions aux systmes externes. Les exigences doivent prciser comment

l'authentification et le chiffrement seront grs pour tous les systmes externes,
comme les bases de donnes, les rpertoires et les services Web. Tous les
authentifiants ncessaires pour la communication avec les systmes externes
seront stocks l'extrieur du code dans un fichier de configuration, sous forme
chiffre.

(g)

Chiffrement. Les exigences devront prciser quelles donnes doivent tre

chiffres, comment elles doivent tre chiffres et comment tous les certificats et
autres authentifiants doivent tre grs. L'application devra utiliser un algorithme
standard implant dans une bibliothque de chiffrement largement utilise et
teste.

(h)

Disponibilit. Les exigences doivent prciser comment elles protgeront contre

les attaques de refus de service. Toutes les attaques possibles sur l'application
devraient tre considres, y compris le verrouillage de l'authentification,
l'puisement de la connexion et d'autres attaques d'puisement des ressources.

(i)

Configuration scurise. Les exigences doivent prciser que les valeurs par
dfaut pour toutes les options de configuration pertinentes de scurit doivent tre
scurises. Aux fins de vrification, le logiciel devrait pouvoir produire un rapport
facilement lisible, montrant tous les dtails pertinents de configuration de scurit.

(j)

Vulnrabilits spcifiques. Les exigences devront inclure un ensemble de

vulnrabilits prcises qui ne doivent pas tre retrouves dans le logiciel. Si non
autrement spcifi, alors le logiciel ne doit pas inclure aucune des dfaillances
dcrites dans la liste OWASP Top Ten Most Critical Web Application
Vulnerabilities. (Dix plus cruciales vulnrabilits d'application Web de
l'OWASP).

11.

PERSONNEL ET ORGANISATION.

(a)

Architecte de scurit. Le Dveloppeur assignera la responsabilit pour la

scurit une unique ressource technique principale, tant connu comme
l'Architecte de scurit du projet. L'architecte de scurit certifiera la scurit de
chaque livrable.

(b)

Formation de scurit. Le Dveloppeur sera responsable de vrifier que tous les

membres de l'quipe du dveloppeur ont t forms dans les techniques scuriss
de programmation.

(c)

Dveloppeurs de confiance. Le Dveloppeur accepte d'effectuer les enqutes sur

les antcdents adquats pour tous les membres d'quipe de dveloppement.

Page 12

Annexe de l'entente de dveloppement de logiciel scuris OWASP

12.

ENVIRONNEMENT DE DVELOPPEMENT

(a)

Gestion de configuration. Le Dveloppeur devra utiliser un systme de contrle

du code source qui authentifie et journalise les membres d'quipe associs avec
tous les changements au produit de base du logiciel et toute la configuration et
tous les fichiers de conceptions relis.

(b)

Distribution. Le Dveloppeur devra utiliser un processus de conception qui

conoit de faon fiable une distribution complte de la source. Ce processus devra
inclure une mthode pour vrifier l'intgrit du logiciel livr au Client.

13.

BIBLIOTHQUES, CADRES DE TRAVAIL ET PRODUITS

(a)

Divulgation. Le Dveloppeur devra divulguer tout logiciel de tierce partie utilis

dans le logiciel, y compris toutes les bibliothques, les cadres du travail, les
composantes et autres produits, qu'ils soient commerciaux, libres, de source
ouverte ou de source ferme.

(b)

valuation. Le Dveloppeur devra faire des efforts raisonnables pour s'assurer

que le logiciel de tierce partie satisfait tous les termes de cette entente et est
aussi scuris qu'un code personnalis dvelopp en vertu de cette entente.

14.

RVISIONS DE SCURIT.

(a)

Droit de rvision. Le Client a le droit de faire rviser le logiciel pour des

dfaillantes de scurit ses frais, tout moment l'intrieur d'une priode de 60
jours de la livraison. Le Dveloppeur accepte de fournir un support raisonnable
l'quipe de rvision, en fournissant le code source et l'accs aux environnements
de test.

(b)

Couverture de rvision. Les rvisions de scurit devront couvrir tous les

aspects du logiciel livr, y compris le code personnalis, les composantes, les
produits et la configuration du systme.

(c)

Porte de la rvision. Au minimum, la rvision devra couvrir toutes les exigences

de scurit et devrait rechercher d'autres vulnrabilits communes. La rvision
peut inclure une combinaison du balayage de vulnrabilit, les essais de
pntration, l'analyse statique du code source et la rvision du code expert.

(d)

Problmes dcouverts. Les problmes de scurit dcouverts seront rapports au

Client et au Dveloppeur. Tous les problmes seront surveills et remdis, tel que
prcis dans la section de Surveillance de problmes de scurit de cette Annexe.

Page 13

Annexe de l'entente de dveloppement de logiciel scuris OWASP

15.

ASSURANCE

(a)

Ensemble de certification. Le Dveloppeur fournira un ensemble de

certification constitu de la documentation de scurit cre travers le
processus de dveloppement. L'ensemble devrait tablir que les exigences, la
conception, l'implantation et les rsultats de tests de scurit ont t adquatement
complts et que tous les problmes de scurit ont t rsolus adquatement.

(b)

Autocertification. L'architecte de scurit certifiera que le logiciel satisfait aux

exigences de scurit, que toutes les activits de scurit ont t effectues et que
tous les problmes de scurit identifis ont t documents et rsolus. Toute
exception l'tat de certification sera entirement documente avec la livraison.

(c)

Aucun code malveillant. Le Dveloppeur garantit que le logiciel ne devra

contenir aucun code qui ne supporte pas les exigences du logiciel et affaiblit la
scurit de l'application, y compris les virus informatiques, les vers, les bombes
retardement, les trappes, les chevaux de Troie, les ufs de Pques et toutes autres
formes de code malveillant.

16.

GESTION DES PROBLMES DE SCURIT ET ACCEPTATION

(a)

Enqute des problmes de scurit. Si des problmes de scurit sont

dcouverts ou raisonnablement souponns, le Dveloppeur devra aider le Client
effectuer une enqute pour dterminer la nature du problme. Le problme devra
tre considr comme tant nouveau , s'il n'est pas couvert par les exigences de
scurit et est l'extrieur de la porte raisonnable des essais de scurit.

(b)

Surveillance. Le Dveloppeur surveillera tous les problmes de scurit

dcouverts pendant tout le cycle de vie, que ce soit un problme d'exigences, de
conception, d'implantation, d'essais, de dploiement ou fonctionnel. Le risque
associ avec chaque problme de scurit sera valu, document et rapport au
Client aussitt que possible aprs la dcouverte.

(c)

Protection. Le Dveloppeur protgera adquatement l'information concernant les

problmes de scurit et la documentation associe, pour aider limiter la
possibilit que des vulnrabilits dans le logiciel fonctionnel du Client soient
exposes.

(d)

Nouveaux problmes de scurit. Le Dveloppeur et le Client acceptent de

dlimiter l'effort ncessaire pour rsoudre les nouveaux problmes de scurit et
ngocier, en bonne foi, pour atteindre une entente pour effectuer le travail
ncessaire pour les aborder.

Page 14

Annexe de l'entente de dveloppement de logiciel scuris OWASP

(e)

Autres problmes de scurit. Le Dveloppeur devra utiliser tous les efforts

commerciaux raisonnables cohrents avec des pratiques exemplaires de
dveloppement de logiciel, en considrant la svrit du risque, pour rsoudre
tous les problmes de scurit, qui ne sont pas considrs comme tant nouveaux,
aussi tt que possible.

(f)

Acceptation. Le logiciel ne devra pas tre considr comme accept, jusqu' ce

que l'ensemble de certification soit complt et que tous les problmes de scurit
aient t rsolus.

Page 15