Il n'y en a pas puisque c'est la même chose. J'ai parlé, par exemple, d'un CMS : il peut très bien utiliser symfony (donc d'y dépendre) mais va assurer sa propre mise à jour de manière autonome...
Tu vois sincèrement pas en quoi un projet qui utilise un ORM connu et largement testé comme Doctrine aura beaucoup moins de chances d’avoir des SQL injections qu’un projet qui décide de faire toutes ses requêtes SQL à la main
Non, je ne vois toujours pas de rapport entre le nombre d'utilisateurs et les risques de sécurité. Il y a un ensemble de facteurs (complexité du projet, taille du projet, qualité technique du codeur...) mais celui-ci tout seul n'en est pas un !
Tu confonds un utilisateur/testeur avec quelqu'un qui :
va effectivement auditer le code
a les connaissances techniques pour trouver des bugs (failles incluses)
va les remonter UPSTREAM
Les récents événements ont montré que même les librairies les plus utilisées ne sont pas exemptes de bugs/failles depuis des années, elles ont "autant de chances" (pour reprendre ton expression) d'en avoir :
openssl tellement secure que forké en libressl,
debian : on se rappelle tous du petit problème de génération ssh
glibc
rails : qui se vantait d'une protection native des sql injections et s'en est mangé une monstrueuse il y a 2 ans...
A côté de ça, le stagiaire de ma boîte a peut-être fait toutes ses requêtes SQL à la main mais c'est de bonne qualité et sans sql injection. La qualité d'un projet ne dépend pas du nombre d'utilisateurs.
[^] # Re: C'était mieux avant
Posté par stopspam . En réponse au journal Installer un serveur Firefox Accounts et Firefox Sync. Évalué à 2. Dernière modification le 24 février 2016 à 17:35.
bower est marqué en pré-requis dans ce journal c'est donc un nième outil à installer.
Il n'y en a pas puisque c'est la même chose. J'ai parlé, par exemple, d'un CMS : il peut très bien utiliser symfony (donc d'y dépendre) mais va assurer sa propre mise à jour de manière autonome...
Non, je ne vois toujours pas de rapport entre le nombre d'utilisateurs et les risques de sécurité. Il y a un ensemble de facteurs (complexité du projet, taille du projet, qualité technique du codeur...) mais celui-ci tout seul n'en est pas un !
Tu confonds un utilisateur/testeur avec quelqu'un qui :
Les récents événements ont montré que même les librairies les plus utilisées ne sont pas exemptes de bugs/failles depuis des années, elles ont "autant de chances" (pour reprendre ton expression) d'en avoir :
A côté de ça, le stagiaire de ma boîte a peut-être fait toutes ses requêtes SQL à la main mais c'est de bonne qualité et sans sql injection. La qualité d'un projet ne dépend pas du nombre d'utilisateurs.