لماذا تقول النتائج منخفضة الخطورة عن تدقيقك أكثر من الأخطاء الحرجة تركز العديد من شركات التدقيق على عرض مبيعاتها على عدد الارتفاعات التي تم العثور عليها كما لو أن هذا الرقم ليس مجرد ضوضاء دون الدخول في السياق: عمليات التدقيق السابقة ، ومراجعة الأقران ، ومستويات تغطية الاختبار ، وتعقيد الكود ، وعدد الأسطر والعديد من المقاييس الأخرى. إنه أدنى شكل من أشكال مهارة المبيعات ، ولا يختلف عن المقارنة على سبيل المثال ، جودة محرك أقراص USB بطولها بالمليمترات. لإظهار بديل ، يجب علينا أولا التأكيد على صحة العديد من الادعاءات الداعمة: - احتمال حقن الأخطاء العرضي ليس له أي تحيز تجاه التأثيرات الأعلى (المطورون ليسوا أكثر تهورا في التعليمات البرمجية عالية المخاطر ، وعادة ما يكون العكس). - نفس المنهجيات الشاملة المستخدمة لاكتشاف عيوب مختلفة الخطورة ستكتشف أيضا مشكلات عالية الخطورة (العكس لا يصمد). - هناك متطلبات أعلى بكثير لتصنيف الخطأ العشوائي على أنه عالي الخطورة (غالبا ما يكون محطا بظروف يتعذر الوصول إليها ، أو يلمس وظائف غير حرجة). - من الإحصائيات الأساسية: يرتبط معدل أخذ العينات المرتفع بانخفاض الانحراف / التباين المتوقع وبالتالي قياس أكثر دقة. دعنا نحدد تقرير التدقيق كنتيجة لأخذ عينات من جودة قاعدة التعليمات البرمجية. نستنتج أن العدد الحقيقي المتوقع (بدون أخطاء) من الارتفاعات أقل بكثير من أدنى المستويات ، والانحراف المتوقع حوله أعلى بكثير (بسبب العينة الأصغر). بمعنى آخر ، يخبرنا عدد الارتفاعات القليل جدا عن عدد الارتفاعات الفائتة. من المثير للدهشة أن تقرير 1 High و 10 Lows أكثر اطمئنانا من تقرير 10 ارتفاعات ، 1 منخفض كل شيء آخر متساو. على الرغم من أن الغالبية العظمى من الباعة يفضلون في الواقع إظهار هذا الأخير كمؤشر على الجودة. النقطة المهمة هي أن المقياس عالي التردد هو أداة أفضل لقياس نتائج التردد المنخفض. بناة Web3 ، في المرة القادمة التي تلوح فيها الشركات بعدد Crit / High و X مليارات من الخط الآمن $ ، فأنت تعرف أين تركز للبحث عن إشارة حقيقية. يدرك مدققو Web3 أنه لا توجد صيغة سرية متسقة للعثور على جميع الارتفاعات دون البحث أيضا عن القيعان - كل انخفاض لم يتم التحقيق فيه بالكامل هو ارتفاع محتمل - وإعطاء أفضل اهتمام لكل سطر على حدة. سوف يشكرك عميلك على ذلك. يتم تعريف الخطورة المنخفضة على أنها أخطاء ترميز ملموسة لا تؤدي إلى تأثيرات أعلى المستوى. لا يتضمن التنسيق وأفضل الممارسات ونتائج التعبئة.

تم إصدار أمر حرج في git أمس يمكن تشغيله بواسطة استنساخ git لمستودع غير موثوق به. هذا هو ناقل الحلم لدفع المدققين وسرقة مكافآتهم / أموال التدقيق. قم بتصحيح أنظمتك قبل الاقتباس من أي عملاء جدد! وتوقع الزوار في صندوق الوارد الخاص بك في الأسابيع المقبلة ...

تبين أنه يمكنك تسجيل مكافآت من 5 تين في المسابقات دون اكتشاف أي مشكلات فعليا ، فقط هناك حاجة إلى دماغ شبه وظيفي. في مسابقة OP Fault Proofs في مارس 2024 ، قام المطورون بإصلاح مشكلة حرجة قبل يوم واحد من بدئها ولكن لم يدمجوها. 🔗 بمجرد النظر إلى سجل الالتزام العام ، فإنك تسجل درجة عالية 🔗 🔗 انتهى الأمر بمكافأة قدرها 16680 دولارا: إنها مجرد واحدة من العديد من الحيل للعثور على الأخطاء داخل النطاق دون البحث عنها فعليا. حاول دائما العمل بذكاء وليس بجد.

قررت تجربة كانتينا في أكتوبر الماضي ، بعد 8 أشهر ظهرت النتائج أخيرا ... عشرات النتائج الفردية في تدقيق Java الأول والتفوق على أفضل إخوان Cantina المتصدرين بمقدار 3-7x تبدو جيدة جدا ، ولن تكذب. إنه لأمر مخز أن تجربة ما بعد التدقيق كانت فظيعة للغاية لدرجة أنني تعهدت بعدم العودة إلى تلك المنصة. *تحذير صخب مبرر* - 8 أشهر من وقت الحل ، حتى كتابة هذا التقرير - لم يتم إرسال المكافأة بعد. - قضى عشرات الساعات في تصعيد الطلبات والدفاع عنها من الأحكام الخاطئة. - تم احتساب ~ 104 أخطاء الحكم (مخادعون خاطئون ، وباطلون واضحون ، وشدة خاطئة) تم تصحيحها. أكثر من ذلك لم يحدث. - خسارة القيمة ~ 110,000 دولار بسبب الحل الذي يستغرق 7 أشهر أطول مما ينبغي وانخفاض رمز OP إلى ~ 50 سنتا. بالتأكيد ، عند التنافس في أواني المسابقة غير الدولار الأمريكي ، تكون التقلبات مخاطرة مقبولة. لكن 8 أشهر من عدم كفاءة القضاة وعدم القدرة على إنهاء المسابقة لم تكن جزءا من نموذج التهديد الخاص بي. خلال أيام التحكيم C4 ، كنت أعالج 1000 نتيجة بالكامل في أقل من أسبوع (منفردا) ، وكان لدى OP-Java 360 وعدة قضاة. ليس من المستغرب أن Cantina لم تعلن أبدا على وسائل التواصل الاجتماعي عن النتائج على عكس 5 مسابقات أخرى اكتملت هذا الأسبوع ، وبالتأكيد لا يمكن أن يكون الأمر كذلك أنهم أرادوا تجنب الصحافة السيئة أو تسليط الضوء على هيمنة TrustSec ، أليس كذلك؟ إنه لأمر مخز أن نستمر في مناقشة الممارسات الخاطئة لمنصة المكافآت بدلا من الأخطاء الحرجة ، ولكن لا يوجد خيار آخر سوى مساءلة الجميع. سيأتي قريبا منشور تفصيل فني خال من الصراخ للاكتشافات الفردية.

تخيل عالما يكون فيه القول بأنه لا ينبغي إساءة استخدام الباحثين أمرا مثيرا للجدل. هذا ما يحدث عندما تظهر شركة ذات أموال غير محدودة وتشتر طريقها إلى الهيمنة على السوق. يصبح الإغراق على الباحثين الذين يتبعون سياسات استخراجية ببساطة توازن ناش الجديد

كل يوم يمر ، يصبح من الواضح لنا بشكل متزايد أن @cantinaxyz كيان استخراجي وسلبي صاف للفضاء. بعد أسبوع من @jack__sanford ، القطعة القاتلة حول أوجه القصور التي لا حصر لها في مسابقة كورك ولا يوجد أي تلميح للرد قريبا. مع مقدار الاهتمام الذي حظيت به هذه المقالة ، إذا تمكنوا من الدفاع عن أنفسهم ، فإنهم سيفعلون ذلك بالتأكيد ، ويعرف أيضا باسم الصمت هو اعتراف بالذنب. هذا الأسبوع ، يظهر تقديم مكافأة Cantina ، والذي اتفقوا عليه ، خسارة متوقفة للأموال لمشغل blockchain على احتمال كبير ، تم حلها في الوساطة إلى الخطورة المنخفضة. بعد قراءة 10 ثوان من تقارير Spearbit / Cantina و 100 من عمليات كتابة المكافآت ، فإن الخسارة المالية لأي مبلغ لا تقل أبدا عن التأثير المتوسط ، لذلك من الواضح أنهم ينقلون منظور الراعي في عقلية كلاسيكية "العميل دائما على حق" ، كما يفعلون دائما. في الواقع ، لا يختبئون حتى القيام بذلك. من خلال مستنداتهم الخاصة ، فإنهم يتفقون افتراضيا على منظور العميل. أعتقد فقط في الحالات الأكثر فظاعة أنهم يرفضون رأي العميل. وماذا لو تجاهل العميل ببساطة وساطته؟ في أي منصة أخرى (على سبيل المثال، @immunefi) عملنا معها، يعد عدم احترام الوساطة سببا للإزالة الفورية للعميل. في Cantina ، يحصل العميل على بدل 5 عمليات احتيال في السنة. نعم ، لقد قرأت ذلك بشكل صحيح. لقد وجدنا مؤخرا أيضا أن برنامج الزمالة الخاص بهم يحتوي على بند حصري شديد العدوانية لا يمكن للزملاء تقديم أي شيء إلى منصات المكافآت الأخرى ، أو إخطار المشاريع مباشرة ، حتى لو كانت ملايين الدولارات معرضة للخطر. بدلا من ذلك ، يجب مشاركة هذه المعرفة شديدة الحساسية والحرجة للوقت مع كانتينا ، التي تقرر كيفية المضي قدما. إنهم الرئيس ، وهم يطلقون النار ، أو ينحنون أو يتركون العقلية. لدينا المزيد من الأمثلة على التعامل الفظيع مع كانتينا ، لكننا سنتركها ليوم آخر. في الوقت الحالي ، نريد زيادة الوعي ، مثل أعضاء المجتمع الرائدين الآخرين ، بأن المدققين يجب أن يصوتوا بأقدامهم عندما يتعلق الأمر بالمكان الذي يقضون فيه وقتهم الثمين في الصيد. منصة الأمان التي تفقد توازنها وتفضل المشاريع على صائدي الجوائز تقوض عملية القبعة البيضاء بأكملها وتشجع الباحثين على كسب قيمتهم من خلال وسائل أقل أخلاقية! دعونا نعمل كمجتمع لتعزيز المنظمات عالية النزاهة والشفافية والإيجابية الصافية على المتنمرين في الصناعة. البيان أعلاه هو الرأي الشخصي لأعضاء إدارة TrustSec ويجب تفسيره على هذا النحو.

- حافظ على خط التماس الذي يغير الحالة أقل من 500 - استخدم نمط العداد ++ لتعيين المفاتيح - لا تدعم الرموز الأصلية - إبقاء جهاز الحالة في عرض مفتوح عبر تعدادات الحالة - نسبة اختبار 1: 1 / خط الاعتماد - تنسيق كل سطر من التعليمات البرمجية بمسطرة انظر ، الفوز باللعبة ليس بهذه الصعوبة

بصفتي مخضرما في صناعة مسابقات التدقيق ، سأخبرك كيف يتم إجراء مثل هذه الصفقات. > كن بروتوكولا بالمال وقم بإجراء 3+ عمليات تدقيق تعاونية > اعلم أن قاعدة التعليمات البرمجية ربما لا تحتوي على أخطاء كبيرة > تريد أن تشير إلى المجتمع والمستثمرين وأصحاب المصلحة الآخرين بأنك تهتم بالأمان > ليس لديك نية لإنفاق المزيد من الأموال على الأمن > منصة "المسابقة" لديها حل > قم بإعداد مسابقة سجاد تضمن عدم فتح الأواني العالية / الحرجة > اجعل وعاء ميد صغير جدا > إذا وجدت عالية ، فقم بتقليل التعليق وإلا فإن العميل غير سعيد (تذكر أويلر؟) > كل من منصة "المسابقة" وتحصل على تسويق مجاني > SRs وعرة ولكنك لا تهتم > كرر ولكن اجعل إعلان مسابقة البساط التالي أكثر تفاؤلا.

تحذير ⚠️ : ليست كتابة مكافأة جديدة نحن المدققون جميعا نحب التركيز على النكات المثيرة والحفاظ على العمل غير التقني إلى الحد الأدنى. من يهتم بالأعمال الورقية والاجتماعات عندما وجدت للتو طريقة جديدة لاستنزاف عقد DeFi؟ ولكن يجب أن تتم كل الأشياء باعتدال ، وفي كثير من الأحيان نرى باحثين مستقلين يبخلون تماما في توقيع اتفاقية أساسية مع العميل. كان هذا شيئا فعلناه أيضا في الأشهر الأولى من TrustSec - التواصل مع عميل على TG / discord ، ومناقشة الفريق والسعر والجدول الزمني ، والبدء للتو. شعرت بالنعومة والاحتكاك ، فما هي المشكلة؟ كما هو الحال مع العديد من الأشياء ، فإنه يعمل بشكل جيد حتى لا يحدث. عندما تدير 50+ عملية تدقيق سنويا ، تبدأ في مواجهة حالات الحافة. وعندما تفعل ذلك ، فإن إزالة الأشياء في وقت مبكر يتجنب الكثير من الاحتكاك في النقاط الحساسة المحتملة في الجدول الزمني للتدقيق. انظر ، الهدف من اتفاقية الخدمات ليس أنه يمكن التقاضي في محكمة على بعد آلاف الأميال من موقعك الحالي. بالتأكيد ، في أسوأ الحالات ، يمكن أن يكون. ولكن في الغالب يتم ذلك لمحاذاة التوقعات من كلا الجانبين ، وهي طريقة لإجبار الجانبين على التحدث عن التفاصيل التي لن يفعلوا لولا ذلك. فيما يلي بعض السيناريوهات التي ظهرت ، ويجب التعامل معها بشكل صريح: - العميل غير جاهز مع الالتزام النهائي قبل تاريخ البدء. - لأسباب غير متوقعة ، لا يتوفر مدقق حسابات واحد أو أكثر لجزء من نافذة التدقيق بأكملها أو بأكملها. - يتطلب النطاق النهائي وقتا أطول للمراجعة ، مما يزيد من التكاليف. - مناقشة الأداة والتنسيق المستخدم لحساب SLOC النهائي. - يقدم العميل وظائف جديدة للمراجعة في تدقيق الإصلاح. - طلب إرسال المبلغ فقط بعد تسليم التقرير. - يرغب العميل في إلغاء التدقيق بإشعار مسبق مدته 24 ساعة فقط. - يرغب العميل في إرسال المدفوعات على blockchain المفضل لديه. - الاعتراضات على نشر التقرير بعد فترة انتظار مقبولة. بصرف النظر عن توضيح كيفية التعامل مع هذه السيناريوهات ، توفر الاتفاقية أيضا للمدققين حماية حاسمة: - يتنازل عن أي مسؤولية عن الأخطاء والثغرات الفائتة. - يحتفظ بحقوق الملكية الفكرية على الأدوات ومفاهيم الهجوم التي تم تطويرها أثناء التدقيق (بالقدر الذي يسمح به القانون). - يرتب الدفعات المقدمة ورسوم الإلغاء وما إلى ذلك. - يفي بمتطلبات العناية الواجبة وبنك "كينك ب" والإطار القانوني. هذا مناسب للضرائب والامتثال ومتطلبات مصدر الأموال. لهذه الأسباب ، سرعان ما وجدنا أن قضاء بعض الوقت الإضافي قبل حجز الأشياء يستحق كل هذا العناء ، ونحن نشجع كل مدقق يدير نشاطا تجاريا مشروعا على فعل الشيء نفسه.

في أواخر عام 2024 ، اكتشفت TrustSec خطأ في الإجماع في عميل @OPLabsPBC Optimism. في أسوأ الحالات ، سيكون لدى العقدة المرجعية رؤية خاطئة للحالة L2 ، مما يتسبب في انفصال السلسلة عن العملاء الآخرين. بالنسبة لبحثنا ، منحتنا OP Labs بسخاء مكافأة قدرها 7.5 ألف دولار. تحقق من جميع التفاصيل في الكتابة الفنية أدناه!