Après il ne faut pas confondre la sécurité (lutte contre un risque aléatoire non-intentionnel) qui est ultra important dans les systèmes critiques et la sûreté (risque lié à une attaque intentionnelle) qui est le souci principal du législateur pour les logiciels de caisse.
Le principe de base de "on ne s'audite pas soi-même" est une règle d'or dans les systèmes critiques dont la défaillance peut causer de graves blessures ou la mort. L'effort de documentation est énorme car il faut prouver qu'on respecte l'état de l'art car par essence, on ne maîtrise pas les aléas. Sinon on gagnerait toujours au loto :-). On ne peut pas s'engager sur le risque 0.
Dans une approche où c'est la sûreté qui compte, c'est l'inverse. Si le coffre fort résiste à une bombe atomique, qui se soucie de savoir que l'entreprise qui l'a fabriqué est incapable de justifier qu'elle fabrique l'acier dans les règles de l'art : le résultat parle de lui-même. Donc a l'extrême on s'en fout que la doc soit lacunaire tant que tous les tests de corruption / intrusion possibles et imaginables montrent que le système est inviolable.
Donc je comprends que pour un logiciel de caisse, les petits acteurs sont pour l'auto-certification.
Mais ceci étant dit, la confiance dans les mesures techniques auto-vérifiables ignore un biais fondamental : les défaillances subtiles (bugs rares, interactions) passent souvent inaperçues sans regard externe. Ok, dans un logiciel libre tout le monde peut auditer le code. Mais dans les faits, vous connaissez beaucoup de petit projets (libres ou pas) qui ont des red teams bénévoles indépendante des développeurs ?
[^] # Re: Bravo
Posté par vpo . En réponse à la dépêche Rétablissement de l'« auto-attestation » pour les logiciels de caisse, l'aboutissement d'une année de mobilisation. Évalué à 2.
Après il ne faut pas confondre la sécurité (lutte contre un risque aléatoire non-intentionnel) qui est ultra important dans les systèmes critiques et la sûreté (risque lié à une attaque intentionnelle) qui est le souci principal du législateur pour les logiciels de caisse.
Le principe de base de "on ne s'audite pas soi-même" est une règle d'or dans les systèmes critiques dont la défaillance peut causer de graves blessures ou la mort. L'effort de documentation est énorme car il faut prouver qu'on respecte l'état de l'art car par essence, on ne maîtrise pas les aléas. Sinon on gagnerait toujours au loto :-). On ne peut pas s'engager sur le risque 0.
Dans une approche où c'est la sûreté qui compte, c'est l'inverse. Si le coffre fort résiste à une bombe atomique, qui se soucie de savoir que l'entreprise qui l'a fabriqué est incapable de justifier qu'elle fabrique l'acier dans les règles de l'art : le résultat parle de lui-même. Donc a l'extrême on s'en fout que la doc soit lacunaire tant que tous les tests de corruption / intrusion possibles et imaginables montrent que le système est inviolable.
Donc je comprends que pour un logiciel de caisse, les petits acteurs sont pour l'auto-certification.
Mais ceci étant dit, la confiance dans les mesures techniques auto-vérifiables ignore un biais fondamental : les défaillances subtiles (bugs rares, interactions) passent souvent inaperçues sans regard externe. Ok, dans un logiciel libre tout le monde peut auditer le code. Mais dans les faits, vous connaissez beaucoup de petit projets (libres ou pas) qui ont des red teams bénévoles indépendante des développeurs ?