Connecter la sécurité et la gestion des changements de logiciels

Quand on crée des logiciels qui doivent être super sûrs, comme ceux qui contrôlent des avions ou des dispositifs médicaux, faut faire gaffe. Si ces systèmes lâchent, ça peut blesser des gens ou abîmer l'environnement. Donc, on doit toujours vérifier qu'ils sont sûrs.

Un moyen de prouver qu'on a pensé à la sécurité, c'est ce qu'on appelle un Dossier d'Assurance Sécurité (DAS). Un DAS, c'est en gros un ensemble de raisons et de preuves qui dit que le système est sûr à utiliser. Ça décompose les revendications de sécurité en plus petits morceaux, soutenus par des preuves comme des tests et des simulations. Ça aide tout le monde à comprendre comment on a pris les décisions concernant la sécurité.

Créer et maintenir ces dossiers à jour, c'est pas simple, surtout quand le logiciel change. Parfois, y'a un écart entre ce qui se fait sur la sécurité et ce qui se fait sur le logiciel. Les gens qui s'occupent de la sécurité peuvent pas toujours connaître le logiciel, et vice versa. À cause de cette déconnexion, c'est compliqué de garder les arguments de sécurité à jour quand le logiciel change.

Dans beaucoup de cas, les experts en sécurité ont dit qu'il n'y avait pas de bonnes méthodes pour gérer efficacement les changements des DAS. Donc, quand quelque chose change dans le logiciel, c'est galère pour les experts de comprendre comment ça impacte la sécurité.

Ils veulent savoir quelques trucs quand le logiciel change :

1. Pourquoi le logiciel a-t-il changé ?
2. Quel risque ce changement essaie-t-il de corriger ?
3. Comment ce changement pourrait affecter la sécurité ?

Pour simplifier, on peut relier les arguments de sécurité directement aux changements du logiciel. Ça veut dire qu'on doit lier les parties importantes du logiciel aux raisons de sécurité et suivre tous les changements. Comme ça, les gens qui travaillent sur la sécurité sauront si quelque chose change dans le logiciel et comment ça peut impacter la sécurité.

#Relier Logiciel et Sécurité

Pour résoudre ce problème, on propose une méthode pour relier les changements de logiciel avec les arguments de sécurité de façon organisée. En utilisant une technique appelée Analyse de la Forêt des Artéfacts de Sécurité (AFAS), on peut automatiquement repérer des changements dans le logiciel. Ça compare deux versions du logiciel et crée une représentation visuelle de ce qui a changé. Grâce à cette représentation, les équipes de sécurité peuvent voir exactement ce qui a été ajouté, retiré ou modifié, et comment ça affecte leurs arguments de sécurité.

Quand le logiciel change, notre méthode aide aussi à capturer les raisons de ces changements. Les gens qui bossent sur le logiciel, comme les développeurs, peuvent donner leurs raisons et d'autres détails importants pour chaque changement. Ça aide les équipes de sécurité à comprendre si les changements sont bons ou mauvais pour la sécurité.

Par exemple, quand on conçoit un système pour des drones utilisés en urgence comme les missions de recherche et de sauvetage, un besoin important est que le drone sache où il peut et ne peut pas voler. C'est crucial parce que si un drone pénètre un espace aérien interdit, ça peut provoquer des accidents.

Un besoin pour les drones était qu'ils devaient continuer à vérifier les informations sur l'espace aérien pendant qu'ils volaient. Dans une version plus récente du logiciel, ça a été changé pour vérifier l'espace aérien seulement lors de la planification de nouveaux itinéraires de vol. Notre système peut montrer ce changement clairement et aider les experts en sécurité à évaluer si c'est toujours sûr.

#Lier Tous les Éléments

Quand on développe des systèmes sûrs, on commence par identifier les dangers potentiels. Ça s'appelle une analyse préliminaire des dangers (APD). Ensuite, on crée des Arbres de défaillance (AD) ou une Analyse Critique des Modes de Défaillance et Effets (ACMDE) pour mieux comprendre ces risques. Même si notre focus est principalement sur les Arbres de Défaillance, les mêmes idées peuvent s'appliquer à l'ACMDE.

Les Arbres de Défaillance nous aident à décomposer les risques en plus petits morceaux, montrant comment différents événements pourraient causer des problèmes de sécurité. C'est une question de compréhension et de gestion des risques.

Dans notre méthode, on s'assure qu'il y a un lien direct entre un Arbre de Défaillance et ses parties pertinentes dans le Dossier d'Assurance Sécurité. Ce lien nous aide à relier les arguments de sécurité et la conception du système.

En gardant ces connexions claires et à jour, tout changement dans le système enverra des alertes à travers les arguments de sécurité liés. Comme ça, si quelque chose change dans le logiciel, on peut rapidement évaluer comment ça affecte la sécurité.

#Importance de Capturer les Raisons

Pour vraiment comprendre comment les changements impactent la sécurité, on doit capturer les raisons derrière eux. Quand un développeur change quelque chose dans le code, il doit donner des détails sur pourquoi il a fait ce changement. Ça peut inclure les alternatives qu'il a considérées et ce qui l'a amené à sa décision finale.

Par exemple, si un besoin de sécurité pour un drone dit qu'il doit récupérer des données en temps réel sur l'espace aérien, les changements sur la façon dont ça se fait pourraient impacter la sécurité. Maintenir un enregistrement clair de pourquoi et comment ces besoins changent est essentiel. Ça donne le contexte dont les analystes de sécurité ont besoin pour évaluer si le nouveau design est toujours sûr ou si plus de précautions sont nécessaires.

#Défis à Venir

Il y a encore plein de défis à relever quand il s'agit de relier sécurité et développement logiciel. Un domaine clé est la gestion des connaissances. Qu'est-ce que les analystes de sécurité doivent savoir ? Comment peut-on collecter ces infos efficacement ? Ce sont des questions cruciales qu'il faut répondre.

Un autre défi est d'analyser les changements intelligemment. Les changements logiciels peuvent se faire à différents niveaux. On veut faire la différence entre les changements inoffensifs et ceux qui pourraient être risqués. Pour les approches futures, on espère utiliser des systèmes plus intelligents pour analyser les changements et suggérer des étapes concrètes quand la sécurité pourrait être en danger.

Enfin, il faut améliorer les outils utilisés dans ce processus. Les systèmes actuels manquent souvent de soutien pour gérer la connexion entre les revendications de sécurité et les changements logiciels. Développer des outils faciles à utiliser qui aident à maintenir cette connexion, tout en facilitant le travail des analystes et des développeurs, est vital.

#Conclusion

En résumé, maintenir la sécurité dans le développement logiciel est crucial, surtout pour des systèmes où des vies pourraient être en jeu. Relier les points entre les Exigences de sécurité et les changements logiciels est essentiel pour s'assurer que la sécurité reste une priorité tout au long du processus de développement.

En créant des liens clairs entre les changements dans le logiciel et les arguments de sécurité, et en capturant les raisons de ces changements, on peut améliorer la gestion de la sécurité dans le développement logiciel. En avançant, s'attaquer aux défis auxquels on est confronté sera essentiel pour créer des systèmes plus sûrs qui peuvent s'adapter à de nouveaux changements tout en gardant tout le monde en sécurité.