Parceque typiquement, aujourd'hui qu'est ce qui te permet de dire qu'un bug va être exploitable ou pas?
Quand j'étais à Microsoft, c'était notre boulot journalier: évaluer la dangerosité des bugs qui nous sont rapportés. Cela demande une expertise particulière en exploitation, mais c'est tout à fait faisable, la preuve étant que plein de gens font cela à longueur de journée dans leur boulot.
Et oui, ce n'est pas une science exacte, et il y a toujours la question de "on va être conservateur, et marquer des bugs exploitables si on est pas sûr" ou "c'est peu probable, marquons le non-exploitable" , mais cela a une valeur significative pour les utilisateurs (entreprises principalement). Il faut bien comprendre qu'à Microsoft on avait pas décidé de nous même de faire tout cela, ce sont les clients qui le demandaient, histoire de pouvoir mettre une priorité sur leur travail de test et deployment, parce que ces étapes ont un coût clair pour eux.
De même que rester exposés à des failles car ils ne sont même pas au courant qu'une faille existait et qu'ils n'ont dés lors pas patché, c'est un vrai gros problème pour eux.
[^] # Re: N'importe quoi...
Posté par pasBill pasGates . En réponse au journal L'entreprise est-elle responsable des fuites de données dans le cadre du télétravail ?. Évalué à 2.
Quand j'étais à Microsoft, c'était notre boulot journalier: évaluer la dangerosité des bugs qui nous sont rapportés. Cela demande une expertise particulière en exploitation, mais c'est tout à fait faisable, la preuve étant que plein de gens font cela à longueur de journée dans leur boulot.
Et oui, ce n'est pas une science exacte, et il y a toujours la question de "on va être conservateur, et marquer des bugs exploitables si on est pas sûr" ou "c'est peu probable, marquons le non-exploitable" , mais cela a une valeur significative pour les utilisateurs (entreprises principalement). Il faut bien comprendre qu'à Microsoft on avait pas décidé de nous même de faire tout cela, ce sont les clients qui le demandaient, histoire de pouvoir mettre une priorité sur leur travail de test et deployment, parce que ces étapes ont un coût clair pour eux.
De même que rester exposés à des failles car ils ne sont même pas au courant qu'une faille existait et qu'ils n'ont dés lors pas patché, c'est un vrai gros problème pour eux.