Et on en a d’ailleurs eu l’exemple récemment avec la backdoor ajoutée dans la librairie XZ, qui est arrivée dans les versions publiées, sans que personne ne s’en soit rendu compte, jusqu’au moment où un mec faisant des tests de perfs sur son produit s’est rendu compte d’un ralentissement anormal…
Absolument personne n’avait repéré le truc en analysant le code avant que ça parte dans des releases.
Analysez tout ce que fait l’OS est effectivement impossible, surtout quand on n’a pas les sources, c’est vrai.
En revanche (et si on a du temps à perdre), on peut mettre un FW entre sa machine et internet et alors analysez tout le trafic (pour le peu qu’il soit en clair et s’il est chiffré au connait au moins la destination) ça donne déjà une bonne idée des données qui peuvent transiter, leur type et leur volume.
Ca c’est sûr! 
deja avec WinE ça retire la moitié des problemes
le cas de la library XZ est assez isolé (pour moi).
mais je préfère pouvoir un pc ou il peut avec des trojans plutôt qu’un pc ou il peut avec des trojans ET dont je n’ai pas accès au code source (M$)
et puis il y a peu de gens qui analysent les libs de compression 
Et pas forcément beaucoup plus qui analysent la plupart des autres lib…
si quand même (j’ai des preuves dans mon entourage)
Oui, avant un push, il y a quand même un minimum de validation, mais ça peut facilement laisser passer des trucs malveillants ou des erreurs bien planqués!
Et c’est un architecte (travail croisé + double revue de pair) et un build manager qui te dit ça… On laisse passer des boulettes « de compétition » tous les jours!
Et parfois plusieurs par jour 
Une petite pensée pour ce gros éditeur de logiciels (3 milliards de CA, 50 de capitalisation…) qui a publié 5 versions d’une de ses libs Python en 3 jours… La première introduisait une énorme régression, les deux suivantes étaient censées la corriger, l’avant dernière y est finalement arrivée, mais en en introduisant une nouvelle, corrigée dans la dernière Et y avait pourtant littéralement besoin de taper seulement 1 commande pour constater la régression initiale et la seconde régression 
Et histoire de balayer devant ma porte, il y a quelques années j’ai fait une boulette dans le code d’une API qui faisait que la chaîne de connexion à la base de données (incluant donc login et mot de passe…) s’affichait en clair dans la doc autogénérée… Et c’est passé comme une lettre à la poste à travers deux revues de code, puis resté en prod pendant 3 mois avant que je m’en rende finalement compte par hasard en voulant vérifier un autre truc dans la doc…
Bref, il est illusoire d’imaginer que quelques relectures de code par des collègues ou la communauté suffisent à garantir l’absence de gros bug ou de code malveillant… Et ce d’autant plus que celui qui introduit du code malveillant fera des efforts pour le rendre difficile à détecter par une simple relecture (du genre l’introduire par plusieurs touches successive, en sachant bien que dans l’écrasante majorité le reviewer se contente de vérifier les lignes modifiées, sans forcément regarder ce qu’il y a autour…).
Il y a un moment, il faut se remettre en question!
Un code sans bug, ça n’existe pas. Et un code avec des failles (volontaires ou non), c’est la norme malheureusement. Il ne faut JAMAIS l’oublier.
Le problème, c’est la mise en place d’un outil de surveillance généralisé : oui, aujourd’hui avec des exigences matérielles, et avec la possibilité de la paramétrer et de le désactiver.
Et ensuite ? Les fuites de données, même protégées, il paraît que ça existe … Et demain ? Le gouvernement US change (pas en bien) et impose à $crosoft d’activer définitivement la fonctionnalité … Sachant que +70% des OS tournant sur PC fixes/portables dans le Monde sont sous Microsoft (Source Wikipédia). Tout le monde passe sur autre chose ? Non. Tout le monde est fliqué. Et le pire, c’est d’accepter cela au nom du progrès.