Pourquoi les constatations de faible gravité en disent plus sur votre audit que les bugs critiques De nombreuses entreprises d'audit axent leur argumentaire de vente sur le nombre de problèmes critiques trouvés, comme si ce chiffre n'était qu'un bruit sans contexte : audits précédents, revue par les pairs, niveaux de couverture des tests, complexité du code, nombre de lignes et bien d'autres métriques. C'est la forme la plus basse de vente, pas différente de la comparaison, par exemple, de la qualité des clés USB par leur longueur en millimètres. Pour montrer une alternative, nous devons d'abord affirmer la justesse de plusieurs affirmations de soutien : - La probabilité d'injection accidentelle de bugs n'a pas de biais vers des impacts plus élevés (les développeurs ne sont pas plus imprudents dans un code à enjeux élevés, généralement c'est l'inverse). - Les mêmes méthodologies complètes utilisées pour découvrir des défauts de diverses gravités découvriraient également des problèmes de haute gravité (l'inverse n'est pas vrai). - Il y a des exigences beaucoup plus élevées pour qu'un bug aléatoire soit qualifié de haute gravité (souvent, il serait conditionné par des conditions inaccessibles ou toucherait des fonctionnalités non critiques). - D'après des statistiques de base : un taux d'échantillonnage plus élevé est corrélé à une déviation/variance attendue plus faible et donc à une mesure plus précise. Définissons un rapport d'audit comme le résultat d'un échantillonnage de la qualité d'une base de code. Nous déduisons que le nombre vrai attendu (sans omissions) de problèmes critiques est beaucoup plus bas que celui des problèmes de faible gravité, et que la déviation attendue autour de celui-ci est beaucoup plus élevée (en raison d'un échantillon plus petit). En d'autres termes, le nombre de problèmes critiques nous en dit très peu sur le nombre de problèmes critiques manqués. Ainsi, de manière surprenante, un rapport de 1 problème critique et 10 problèmes de faible gravité est plus rassurant qu'un rapport de 10 problèmes critiques et 1 problème de faible gravité, toutes choses étant égales par ailleurs. Bien que, en fait, la grande majorité des vendeurs préféreraient montrer ce dernier comme une indication de qualité. Le point est qu'une métrique à haute fréquence est un meilleur outil pour mesurer des résultats à faible fréquence. Constructeurs de Web3, la prochaine fois que des entreprises vous montrent leurs comptes Crit/High et X milliards de $ sécurisés, vous savez où vous concentrer pour rechercher le véritable signal. Auditeurs de Web3, reconnaissez qu'il n'existe pas de formule secrète cohérente pour trouver tous les problèmes critiques sans également rechercher les problèmes de faible gravité - chaque problème de faible gravité non entièrement examiné est un potentiel problème critique - et accordez votre meilleure attention à chaque ligne. Votre client vous en remerciera. La faible gravité est définie comme des erreurs de codage concrètes qui ne résultent pas en impacts de niveau supérieur. N'inclut pas le formatage, les meilleures pratiques et les constatations accessoires.

Une vulnérabilité critique dans git a été publiée hier, pouvant être déclenchée par un git clone d'un dépôt non fiable. C'est le vecteur idéal pour compromettre les auditeurs et voler leurs primes / fonds d'audit. Mettez à jour vos systèmes avant de citer de nouveaux clients ! Et attendez-vous à des visiteurs dans votre boîte de réception dans les semaines à venir...

Il s'avère que vous pouvez obtenir des primes à 5 chiffres dans des concours sans réellement découvrir de problèmes, il suffit d'avoir un cerveau semi-fonctionnel. Lors du concours OP Fault Proofs de mars 2024, les développeurs ont corrigé un problème critique un jour avant le début, mais ne l'ont pas fusionné. 🔗 En regardant simplement le journal des commits publics, vous obtenez un score élevé 🔗 🔗 Cela a fini par être une prime de 16680 $ : C'est juste l'un des nombreux trucs pour trouver des bugs dans le champ d'application sans réellement les chercher. Essayez toujours de travailler intelligemment, pas durement.

J'ai décidé d'essayer Cantina en octobre dernier, 8 mois plus tard, les résultats sont enfin là... Des dizaines de découvertes en solo lors du premier audit Java et surpasser les meilleurs frères du classement Cantina de 3 à 7 fois, ça fait plutôt plaisir, je ne vais pas mentir. C'est dommage que l'expérience post-audit ait été si terrible que j'ai juré de ne jamais revenir sur cette plateforme. *avertissement de coup de gueule justifié* - Temps de résolution de 8 mois, au moment où j'écris - la récompense n'a toujours pas été envoyée. - Des dizaines d'heures passées à escalader et à défendre des soumissions contre des verdicts erronés. - J'ai compté environ 104 erreurs de jugement (faux doublons, invalides clairs, mauvaise gravité) qui ont été corrigées. Plus qui ne l'ont pas été. - Perte de valeur d'environ 110 000 $ en raison d'une résolution prenant 7 mois de plus que prévu et du token OP qui a chuté à environ 50 cents. Bien sûr, lorsqu'on participe à des pots de concours non en USD, les fluctuations sont un risque accepté. Mais 8 mois d'incompétence des juges et l'incapacité à conclure un concours ne faisaient pas partie de mon modèle de menace. Pendant les jours de jugement C4, je traitais entièrement 1000 découvertes en moins d'une semaine (en solo), OP-Java avait 360 et plusieurs juges. Il n'est pas surprenant que Cantina n'ait jamais annoncé les résultats sur les réseaux sociaux contrairement à 5 autres concours qui se sont terminés cette semaine, cela ne pourrait certainement pas être le cas qu'ils voulaient éviter une mauvaise presse ou mettre en avant la domination de TrustSec, n'est-ce pas ? C'est dommage que nous devions continuer à discuter des pratiques malveillantes des plateformes de récompenses au lieu de bugs critiques, mais il n'y a pas d'autre choix que de tenir tout le monde responsable. Un post technique sans coup de gueule pour les découvertes en solo arrivera bientôt.

Imaginez un monde où dire que les chercheurs ne devraient pas être abusés est un point de vue controversé.. C'est ce qui se passe lorsqu'une entreprise avec des fonds illimités arrive et achète sa place dans la domination du marché. Dévaloriser les chercheurs avec des politiques extractives devient simplement le nouvel équilibre de Nash.

Chaque jour qui passe, il devient de plus en plus clair pour nous que @cantinaxyz est une entité extractive et un net négatif pour l'espace. Une semaine après le remarquable article de @jack__sanford sur les nombreuses lacunes du concours Cork et aucune indication de réponse de leur part. Avec l'attention que cet article a reçue, s'ils pouvaient monter une défense, ils le feraient certainement, c'est-à-dire que le silence est une admission de culpabilité. Cette semaine, notre soumission de prime Cantina, qu'ils ont convenu montre une perte de fonds limitée pour un opérateur blockchain avec une forte probabilité, a été résolue en médiation avec une faible gravité. Ayant lu des dizaines de rapports Spearbit/Cantina et des centaines de rédactions de primes, une perte monétaire de n'importe quel montant n'est jamais inférieure à un impact moyen, donc ils relaient clairement la perspective du sponsor dans une mentalité classique de "le client a toujours raison", comme ils le font toujours. En fait, ils ne cachent même pas qu'ils le font. Selon leurs propres documents, ils se conforment à la perspective du client. Je suppose que ce n'est que dans les cas les plus flagrants qu'ils rejettent l'avis du client. Et que se passe-t-il si le client ignore simplement leur médiation ? Sur n'importe quelle autre plateforme (par exemple @immunefi) avec laquelle nous avons travaillé, ne pas respecter la médiation est un motif de retrait immédiat du client. Sur Cantina, le client a droit à 5 escroqueries de primes par an. Oui, vous avez bien lu. Nous avons également récemment découvert que leur programme de Fellowship a une clause d'exclusivité très agressive. Les Fellows ne peuvent soumettre quoi que ce soit à d'autres plateformes de primes, ni notifier directement les projets, même si des millions de dollars sont en jeu. Au lieu de cela, ces connaissances hautement sensibles et critiques doivent être partagées avec Cantina, qui décide de la marche à suivre. Ils sont le patron, ils prennent les décisions, mentalité de se plier ou de partir. Nous avons d'autres exemples de gestion scandaleuse sur Cantina, mais nous les laisserons pour un autre jour. Pour l'instant, nous voulons sensibiliser, comme d'autres membres éminents de la communauté, que les auditeurs devraient voter avec leurs pieds en ce qui concerne l'endroit où ils passent leur temps précieux à chasser. Une plateforme de sécurité qui perd son équilibre et favorise les projets au détriment des chasseurs de primes sape l'ensemble du processus des chapeaux blancs et encourage les chercheurs à gagner leur valeur par des moyens moins éthiques ! Travaillons en tant que communauté pour renforcer des organisations de haute intégrité, transparentes et net positives plutôt que des tyrans de l'industrie. La déclaration ci-dessus est l'opinion personnelle des membres de la direction de TrustSec et doit être interprétée comme telle.

- Gardez le LoC modifiant l'état en dessous de 500 - utilisez le modèle ++counter pour les clés de mappage - ne pas prendre en charge les tokens natifs - gardez la machine d'état en vue ouverte via des énumérations d'état - ratio test/LoC de 1:1 - formatez chaque ligne de code avec une règle Vous voyez, gagner le jeu n'est pas si difficile.

En tant que vétéran de l’industrie des concours d’audit, je vais vous dire comment de telles ententes sont conclues. > Soyez protocole avec de l’argent et faites 3+ audits collaboratifs > Sachez que la base de code n’a probablement pas de bogues significatifs > Vous voulez signaler à la communauté, aux investisseurs et aux autres parties prenantes que vous vous souciez de la sécurité > N’avez pas l’intention de dépenser plus d’argent pour la sécurité > plateforme « Concours » a solution > Mettre en place un concours de tapis garantissant que les pots High/Crit ne seront pas débloqués > Rendre le pot Med super petit > Si High a trouvé, minimisez la surprise, sinon le client est mécontent (vous vous souvenez d’Euler ?) > La plate-forme « Concours » et vous obtenez un marketing gratuit > SR robustes, mais vous vous en fichez > Répétez l’opération, mais rendez l’annonce du prochain concours de tapis encore plus optimiste.

Attention ⚠️ : Il ne s’agit pas d’un nouvel article sur les primes Nous, les auditeurs, aimons tous nous concentrer sur les critiques juteuses et réduire au minimum le travail non technique. Qui se soucie de la paperasse et des réunions alors que vous venez de trouver une nouvelle façon de vider un contrat DeFi ? Mais tout doit être fait avec modération, et trop souvent, nous voyons des chercheurs indépendants lésiner totalement sur la signature d’un accord même de base avec le client. C’est quelque chose que nous avons également fait dans les premiers mois de TrustSec - connectez-vous avec un client sur TG / discord, discutez de l’équipe, du prix et du calendrier, et commencez. Se sentait lisse et sans friction, alors quel est le problème ? Comme pour beaucoup de choses, cela fonctionne bien jusqu’à ce que ce ne soit plus le cas. Lorsque vous gérez + de 50 audits par an, vous commencez à rencontrer des cas limites. Et lorsque vous le faites, le fait d’avoir réglé les choses à l’avance permet d’éviter une tonne de frictions à des moments potentiellement sensibles de la chronologie de l’audit. Vous voyez, l’intérêt d’un contrat de services n’est pas qu’il puisse être plaidé devant un tribunal à des milliers de kilomètres de votre emplacement actuel. Bien sûr, dans le pire des cas, c’est possible. Mais la plupart du temps, c’est fait pour aligner les attentes des deux côtés, un moyen de forcer les deux parties à parler de détails qu’elles n’auraient pas autrement fait. Voici quelques scénarios qui se sont présentés et qui doivent être explicitement gérés : - Le client n’est pas prêt pour la validation finale avant la date de début. - Pour des raisons imprévues, un ou plusieurs auditeurs ne sont pas disponibles pour une partie ou la totalité de la fenêtre d’audit. - La portée finale nécessite un temps d’examen plus long, ce qui augmente les coûts. - Débat sur l’outil et le formatage utilisés pour compter le SLOC final. - Le client introduit une nouvelle fonctionnalité pour l’examen dans l’audit de correction. - Demander que le paiement ne soit envoyé qu’après la remise du rapport. - Le client souhaite annuler l’audit avec un préavis de 24 heures. - Le client souhaite envoyer le paiement sur la blockchain de son choix. - Objections à ce que le rapport soit publié après une période d’attente acceptable. En plus d’indiquer clairement comment gérer ces scénarios, un accord offre également aux auditeurs une protection essentielle : - Décline toute responsabilité pour les bugs et exploits manqués. - Maintient les droits de propriété intellectuelle sur les outils, les concepts d’attaque développés lors de l’audit (dans la mesure où la loi le permet). - S’occupe des acomptes, des frais d’annulation, etc. - Répond aux exigences de diligence raisonnable, au KYB et au cadre juridique. Ceci est pertinent pour les exigences en matière de fiscalité, de conformité et de source de fonds. Pour ces raisons, nous avons rapidement constaté qu’il valait la peine de passer un peu plus de temps avant de réserver des choses, et nous encourageons tous les auditeurs qui dirigent une entreprise légitime à faire de même.

Fin 2024, TrustSec a découvert un bug de consensus dans @OPLabsPBC client Optimism. Dans le pire des cas, op-node aurait une mauvaise vue de l’état L2, ce qui provoquerait une scission de la chaîne d’autres clients. Pour nos recherches, OP Labs nous a généreusement accordé une prime de 7,5 000 $. Découvrez tous les détails dans la rédaction technique ci-dessous !