Ce que j'ai dit, c'est ressource ou pas, bénévolat ou salariat, rien n'empêche une porte dérobée d'être insérée.
Sauf que dans une boîte qui a les ressources pour respecter l'état de l'art, c'est toute de même bien plus compliqué.
Je bosse dans une équipe développant une lib qui doit respecter pléthore de standards ISO en termes de cybersécurité et de sureté.
Et bien il faut un paquet de +1 dans les revues de codes pour que le boss qui chapeaute fasse sa propre revue de code et fasse son +2 dans gerrit. Et il est du genre très chiant pour donner son +2, et les autres qui font le +1 sont eux aussi tatillons.
En plus, si le commit ne passe pas les analyses de code statiques (MISRA, etc), pareil, faut justifier pourquoi ça ne passe pas. Et il faut une bonne raison en documentant et en ayant une exemption acceptée par le comité qui va bien. Sinon tu corriges.
Ensuite, on a des tests unitaires de partout et des tests d'intégration où on doit prouver que 100% du code est testé.
Ca part après sur des fermes de serveur pour faire du test système et de performance tout isolé dans des machines virtuelles.
Ah et aussi, on doit prouver que pour toute ligne de code testée, on a les fragments d'architecture et les interfaces spécifiées qui correspondent.
Et chaque équipe qui bosse sur une brique différente du soft doit se plier au même process.
Bien sûr les gens qui testent, qui développent les tests, ceux qui codent, ceux qui définissent l'architecture ne sont pas les mêmes, et pareil pour ceux qui revoient toutes les docs et qui les approuvent. Plus ensuite des auditeurs internes et à la fin, on a des auditeurs externes qui revérifient tout.
Donc oui, même avec un tel process qui implique des dizaines de personnes plus tous les employés qui assurent les fonction support pour l'IT de la boîte, il doit y avoir moyen de mettre du code malicieux. Mais sauf à corrompre pas mal de gens pour qu'ils soient tous dans le complot, cela me semble extrêmement difficile d'y arriver tellement il y a d'étapes à franchir.
Déjà que cela nous prend un temps fou pour livrer ce code certifié et validé alors que nous bossons à plein temps dessus en étant très nombreux, je ne vois pas comment des bénévoles pourraient faire pareil. Sauf à être milliardaires et ne pas avoir besoin de bosser pour manger. Mais si mes collègues et moi étions milliardaires, nous ne nous embêterions pas à bosser sur des trucs aussi pénibles à gérer au quotidien, sauf à aimer le masochisme puissance 1000.
[^] # Re: Le HS de la conclusion
Posté par vpo . En réponse au journal Xz (liblzma) compromis. Évalué à 8.
Sauf que dans une boîte qui a les ressources pour respecter l'état de l'art, c'est toute de même bien plus compliqué.
Je bosse dans une équipe développant une lib qui doit respecter pléthore de standards ISO en termes de cybersécurité et de sureté.
Et bien il faut un paquet de +1 dans les revues de codes pour que le boss qui chapeaute fasse sa propre revue de code et fasse son +2 dans gerrit. Et il est du genre très chiant pour donner son +2, et les autres qui font le +1 sont eux aussi tatillons.
En plus, si le commit ne passe pas les analyses de code statiques (MISRA, etc), pareil, faut justifier pourquoi ça ne passe pas. Et il faut une bonne raison en documentant et en ayant une exemption acceptée par le comité qui va bien. Sinon tu corriges.
Ensuite, on a des tests unitaires de partout et des tests d'intégration où on doit prouver que 100% du code est testé.
Ca part après sur des fermes de serveur pour faire du test système et de performance tout isolé dans des machines virtuelles.
Ah et aussi, on doit prouver que pour toute ligne de code testée, on a les fragments d'architecture et les interfaces spécifiées qui correspondent.
Et chaque équipe qui bosse sur une brique différente du soft doit se plier au même process.
Bien sûr les gens qui testent, qui développent les tests, ceux qui codent, ceux qui définissent l'architecture ne sont pas les mêmes, et pareil pour ceux qui revoient toutes les docs et qui les approuvent. Plus ensuite des auditeurs internes et à la fin, on a des auditeurs externes qui revérifient tout.
Donc oui, même avec un tel process qui implique des dizaines de personnes plus tous les employés qui assurent les fonction support pour l'IT de la boîte, il doit y avoir moyen de mettre du code malicieux. Mais sauf à corrompre pas mal de gens pour qu'ils soient tous dans le complot, cela me semble extrêmement difficile d'y arriver tellement il y a d'étapes à franchir.
Déjà que cela nous prend un temps fou pour livrer ce code certifié et validé alors que nous bossons à plein temps dessus en étant très nombreux, je ne vois pas comment des bénévoles pourraient faire pareil. Sauf à être milliardaires et ne pas avoir besoin de bosser pour manger. Mais si mes collègues et moi étions milliardaires, nous ne nous embêterions pas à bosser sur des trucs aussi pénibles à gérer au quotidien, sauf à aimer le masochisme puissance 1000.