מערכת AI לגילוי אוטומטי של פגיעויות בחוזים חכמים

ניתוח AI של חולשות בחוזים חכמים ונקודות עיוורות בביקורת

חולשות בחוזים חכמים לעתים רחוקות נראות כשגיאה מפורשת בפונקציה אחת. לעתים קרובות יותר זה קוד תקין שמתנהג באופן שגוי ברצף קריאות מסוים: עקיפת בדיקת הרשאות דרך פונקציית מתווכת, קריאה חוזרת שמחזירה את הביצוע לאמצע הפעולה לפני הכתיבה לאחסון, או שגיאת לוגיקה של החוזה בענף חישוב נדיר. בדיקה סטטית מפספסת זאת — היא מסתכלת על הפונקציה, ולא על מצב החוזה בין עסקאות.

לכן ניתוח AI של חוזים חכמים נבנה כשכבה מעל הסטטיקה: המודל עובר על גרף הקריאות כולו, משווה נקודות כניסה להרשאות שהן באמת מעניקות, ומסמן היכן קריאה חיצונית מתרחשת לפני שינוי המצב. בפלט — לא אזהרה מופשטת, אלא תרחיש ניצול: איזה רצף עסקאות, מאיזו כתובת ומה בדיוק הפרוטוקול מאבד.

Solidity מוסיף רובד משלו: ירושה, חוזי מתווך והאצלה מסתירים הרשאות אמיתיות מאחורי שרשרת קריאות, ונתונים ממקורות חיצוניים משתנים בין הבדיקה לשימוש. שגיאת לוגיקה של החוזה מתגלה לרוב דווקא כאן — התנאי נכון ברגע הקריאה ומפסיק להיות נכון עד רגע הכתיבה.

את הממצאים אנחנו מחלקים לפי מחלקות — עקיפת הרשאות, קריאה חוזרת, מניפולציה בנתונים חיצוניים, שגיאת לוגיקה — ועבור כל אחד מתארים אם הוא משוחזר ברשת בדיקה ואיך הוא נסגר בתיקון. בהמשך נבחן מה בדיוק נבדק אוטומטית ומה נשאר בידי המהנדס.

מה נותנת בדיקת קוד רציפה לפני כל ריליס

בדיקת קוד רציפה מוטמעת בצינור הבנייה ומופעלת על כל שינוי משמעותי, ולא בסוף המחזור. הניתוח מתבצע בשני מסלולים: ניתוח סטטי של עץ הקריאות על הענף העדכני Slither והרצת תרחישים על אינוריאנטים ברשת מבודדת. הממצא מגיע עם מעקב קריאות ושחזור מינימלי — מאמתים או מפריכים אותו, ולא מתווכחים על ניסוח האזהרה.

מה זה משנה, לפי סעיפים:

• מחלקת כשלים שהוסרה. כניסה חוזרת, שגיאות הרשאות וגלישות נחסמות לפני בניית ענף הריליס — כבר אי אפשר להעלות אותן לרשת הראשית.
• ניתוח לפני ריליס. דוח על השינויים מגיע לסקירה, ולא שבוע אחרי העלאה, ולכן התיקונים נכנסים לאותו מחזור.
• זרימת ממצאים מנוהלת. קריטי עולה למעלה, כפילויות מתקפלות, רעש נחסם על ידי כללים — במקום מפולת לפני השקה, הצוות מקבל תור עם עדיפויות.
• זמן ריליס. הבדיקה מתבצעת במקביל לפיתוח, והניתוח הסופי מפסיק להיות שלב המתנה נפרד.
• פחות הרצות ידניות. האוטומציה מכסה בדיקות טיפוסיות, והניתוח הידני נשאר ללוגיקת הכלכלה של הפרוטוקול ולהרשאות ניהול.

מדיניות הבדיקות חיה במאגר הקוד: סט כללים, סף חסימת ריליס והיסטוריית החלטות לכל ממצא. שיעור השינויים שנבדקו לפני ריליס ומספר הממצאים לכל ריליס נראים בדוח — האיכות מפסיקה להיות נושא לוויכוח מילולי.

מצבי בדיקת קוד: ביקורת חד-פעמית ומעגל רציף

אף מצב בדיקה לא נותן תמונה מלאה בפני עצמו — הם מכסים מחלקות שונות של פגמים. ביקורת חד-פעמית של החוזה תופסת שגיאות לוגיות שלא מתוארות בתבנית, אבל עד הקומיט הבא המסקנות שלה מתיישנות. מעגל בדיקה רציף מופעל על כל שינוי, אבל רואה רק את מה שהצליחו למסד בכלל או בתרחיש. הבחירה תלויה במקום שבו החוזה נמצא במחזור החיים ובמחיר הטעות.

איך המצבים משתלבים

בכל קומיט מתבצע ניתוח סטטי, תרחישים רצים בהרצת לילה, עבור הליבה מוכחות תכונות, וביקורת ידנית מחוברת לפני ריליס גדול או שינוי במודל הגישה. בדיקות זולות חוסמות פגמים המוניים, ובדיקות יקרות מיועדות לאזורים שבהם הטעות עולה ביוקר.

איך מתבצעת הטמעה: שלבים מביקורת ועד מסירה

ההטמעה מתבצעת באיטרציות של שבוע עד שבועיים: תחילה מתעדים את מצב החוזים הנוכחי, אחר כך מרכיבים את מעגל הבדיקה, ורק לאחר מכן משתילים אותו בתהליך הריליס. הסדר הוא בדיוק כזה — אם מגדירים כללים מיד בלי מיפוי, המנתח מתחיל להרעיש על תבניות לגיטימיות בפרויקט, והצוות מפסיק לסמוך עליו.

1. ביקורת קוד החוזים. אוספים רשימת חוזים, הגרסאות שלהם, הקשרים ביניהם, הרשאות התפקידים וקריאות חיצוניות. בפלט — מפה של מה בכלל צריך לבדוק.
2. סכמת מעגל הבדיקה. קובעים היכן הניתוח מופעל: על כל שינוי, לפני מיזוג ענף או לפי לוח זמנים לחוזים שכבר פרוסים.
3. הגדרת כללים. מפעילים בדיקות בהתאם ללוגיקה העסקית: ניהול גישה, עבודה עם קריאות חיצוניות, סדר שינוי המצב. כללים לא רלוונטיים מכבים כדי לא ליצור רעש.
4. תרחישי בדיקה. מריצים את המעגל על ריליסים היסטוריים ועל שגיאות שהוחדרו בכוונה — רואים מה הוא תופס ומה מפספס.
5. ניתוח התראות שגויות. כל התראה שנויה במחלוקת מתויגת עם הצוות שלכם: בעיה מאושרת, תבנית מותרת או פער בכלל. בסיכום, הכללים מתוקנים.
6. השתלה בתהליך הפיתוח. הבדיקה הופכת לשלב חובה לפני ריליס, עם סטטוס ברור וסף שבו הריליס נחסם.
7. מסירת תיעוד והדרכה. מוסרים תיאור של המעגל, סט כללים עם נימוקים, הוראות לניתוח ממצאים ומבצעים הדרכת צוות.

את המוכנות מתעדים לפי קריטריונים מדידים: שיעור התראות שגויות בקוד שלכם, זמן בדיקת שינוי אחד ומספר ממצאים שאושרו כריאליים. אם הכללים מייצרים רעש מעל הסף המוסכם, השלב לא נסגר.

ארטיפקטים של מסירה: כללים, סכמות ותקנון הרצות

מסירת המעגל היא לא דוח מסכם, אלא סט ארטיפקטים שנשארים במאגר הקוד שלכם ועובדים בלעדינו. אם הצוות לא יכול בעצמו להפעיל את הבדיקה, לנתח ממצא ולהסביר את מקור התוצאה, העבודה לא נסגרה.

• מפת תפקידים והרשאות גישה: מי מפעיל הרצות, מי מאשר ממצא, מי מתקן את כללי הניתוח, מי רואה רק דוחות. הרשאות ניתנות בקבוצות — לא נשארות הרשאות אישיות ללא הגבלת זמן.
• סכמת ארכיטקטורה: רכיבי המעגל, גבולות האמון והנקודות שבהן קוד המקור של החוזים יוצא מההיקף שלכם ואיך התוצאה חוזרת בחזרה.
• קונפיגורציות ניתוח: קובצי כללים, ספי הפעלה ורשימת אזהרות מושתקות עם נימוקים — הכול מנוהל בגרסאות יחד עם הקוד.
• תקנון הרצות: מה מפעיל את הבדיקה (שינוי קוד, הכנת ריליס, הרצה תקופתית), העומק, הזמן הצפוי והתנהגות המעגל בעת תקלה.
• סט תרחישי בדיקה: חוזים עם פגמים ידועים, שלפיהם רואים שאחרי שיפורים המעגל לא התחיל לפספס את מה שתפס קודם.
• סדר ניתוח ממצאים: רמות קריטיות, זמן תגובה לכל אחת, מי מקבל החלטה ואיך נרשם פסק הדין «לוקחים לעבודה» או «התראת שווא».
• תיעוד המעגל: איך לעדכן כללים, מה לעשות בעת החלפת כלי בנייה ולאן להסתכל בלוגים כאשר התוצאה אינה מתיישבת.

מקרה בוחן: ניתוח קוד לפני השקה במקום ביקורת בדיעבד

הלקוח — צוות שמשיק פרוטוקול עם חוזים חכמים, שבו טעות בלוגיקת ההעברות עלולה לגרום לאובדן כספים בלי אפשרות לחזרה. לפני הטמעת הבדיקה עבדו בדיעבד: מבקרים התחברו לקוד קפוא כמה ימים לפני ריליס, ובין ביקורות מפתחים הזרימו שינויים בלי בדיקה אוטומטית. הדוחות הגיעו בערימות של אזהרות, שחלק ניכר מהן היה שגוי, ואחרי כמה שבועות הפסיקו לקרוא אותם.

הרכבנו מעגל שעובד על כל שינוי. הליבה — מנתח Slither, בתוספת מודל שאומן על ממצאים מתויגים של הפרויקט הספציפי הזה: הוא מדרג אזהרות לפי הסתברות לניצול אמיתי וחוסם רעש תבניתי. פסק הדין על הקומיט מגיע לבקשת המיזוג לפני הסקירה, ולא אחרי המיזוג.

מדדים לפני ואחרי

שיעור החולשות שהוסרו לפני ריליס עלה מכ-מחצית ל-92% — השאר נכנס לתוכנית תיקונים, ולא לאירועים. שיעור ההתראות השגויות ירד מ-60% ל-12%, ולכן מסתכלים על הדוח ולא מתעלמים ממנו. הזמן מקומיט ועד פסק דין על שינויים הצטמצם מחצי שעה של ניתוח ידני ל-6-8 דקות של הרצה אוטומטית.

בזמן ריליס זה נתן אפקט הפוך: מחזור הריליס התקצר משלושה שבועות לתשעה ימים, כי תיקוני אבטחה הפסיקו להצטבר לשלב נפרד בסוף. הדבר היקר ביותר הוא שהממצא מגיע למחבר השינוי בזמן שההקשר עוד בראשו.

במה ניתוח AI שונה מכללים ומחיפוש חתימות?

חיפוש חתימות וכללים עובדים על ניתוח הקוד לעץ ועל חיפוש תבניות מוכרות: קריאה לכתובת חיצונית לפני שינוי מצב, תוצאת קריאה לא מטופלת, בדיקת הרשאות לפי מקור העסקה.

במקום שבו מחלקת החולשה נכנסת לתבנית, הגישה נותנת תוצאה מדויקת ומוסברת — אפשר להראות את הממצא על שורה מסוימת ועל נתיב ביצוע מסוים.

הגבול מתחיל היכן שהתבנית מפסיקה להתאים למציאות. חוזי פרוקסי, עטיפות מעל ספריות צד שלישי, שרשרות קריאות מורכבות דרך כמה חוזים — הכללים מתפרקים לעשרות מקרים פרטיים.

שיטות פורמליות מכסות חלק מהפער: הן מוכיחות אינוריאנטים, אבל דורשות תיאור מפורש של מפרטים ומתאימות פחות לקוד שמשתנה כל שבוע.

ניתוח AI של קוד מסיר את המגבלה הזו בדרך אחרת: המודל לומד על תיוג ממצאים — מאושרים ומופרכים. הוא לומד להבדיל בין התראה שמהנדס סגר כשגויה לבין נתיב אמיתי לניצול חולשה, ומדרג את הפלט לפי הסתברות. מעבר ראשוני מהיר על מחלקות מוכרות נותן Slither — המודל משלים את מה שלא נכנס לתבנית.

בפועל השילוב נראה כך: כללים נותנים כיסוי זול של מחלקות מוכרות, שיטות פורמליות — הוכחות באזורים קריטיים, והמודל מסיר את עיקר העומס של התראות שגויות. שיעור הממצאים שנכנסים לדוח בלי בדיקה ידנית חוזרת עולה — דווקא הוא קובע כמה זמן תופס הניתוח לפני ריליס של החוזה.

שאלות שמהנדסים שואלים לפני התחלה

לפני ההתחלה מהנדסים שואלים אותן שאלות: היכן הגבול בין ניתוח אוטומטי לביקורת ידנית, כמה רעש נותן המודל ואיך הפלט שלו ייכנס לצינור הבנייה. המודל עובר על החוזה כולו, כולל ענפים שאליהם מבקר בזמן מוגבל לא מגיע; לאדם נשארים תרחישים כלכליים ובדיקת ממצאים קריטיים.

החוזה כבר פרוס — האם יש טעם בבדיקה?

הניתוח מתבצע על הקוד המפורסם ועל הבייט-קוד: הרשאות הבעלים, פונקציות זמינות, קליטת קריאות חיצוניות. כך רואים מה הסיכון של הגרסה הפרוסה עצמה.

איך בודקים חוזים שמתעדכנים?

הניתוח אינו חד-פעמי: מימוש חדש עובר את אותן בדיקות לפני פרסום, בין גרסאות משווים לוגיקה ואחסון. אחרת תיקון פותח בשקט את מה שהיה סגור.

לאן מוסרים קוד פרטי?

אין צורך להעלות אותו לשירותים ציבוריים: הניתוח במעגל מבודד, גישה לפי תפקידים, והתוצאות נשארות אצלכם. סדר העבודה ומחיקת עותקים מתועדים בכתב.

איך משתילים את הבדיקה בצינור הבנייה?

בשלב נפרד לפני פרסום: הפעלה על שינויים, דוח קריא למכונה, חסימת ריליס כאשר יש ממצאים מעל הסף שנקבע.

נדון במשימה ונחזור עם הערכה ותוכנית

כדי שהערכת הפרויקט תתבסס על עובדות ולא על ניחושים, לשיחה די בכמה נתוני פתיחה. אין צורך לשלוח את כל הקוד מראש — חשוב להבין איך הבדיקה משולבת בתהליך הפיתוח והסקירה שלכם.

• רשימת רשתות וסוגי חוזים: טוקנים, גשרים, פרוטוקולי הלוואה — מה בדיוק צריך לבדוק.
• מאגר קוד או ארכיון עם דוגמאות — לפחות כמה חוזים במצבם הנוכחי.
• מחלקות חולשות קריטיות דווקא לכם: כניסה חוזרת, שגיאות בקרת גישה, גלישות.
• איך ממצאים מגיעים למפתחים: דוח, משימה במעקב, הערה לשינוי קוד.
• מגבלות גישה: היכן הקוד נמצא, מה אפשר לחבר למעגל הבנייה.
• מי מאשר כללים ומנתח התראות שווא.
• דוגמאות מצטברות של ממצאים והחמצות — לפיהן מכוונים את הרגישות.

בתשובה אתם מקבלים סכמה של המעגל: היכן נמצא ניתוח החולשות, איך הוא קשור לבנייה ולבדיקת שינויים, היכן נשמרות התוצאות ואיך הן מגיעות למשימות. בהמשך — תוכנית עבודה לפי שלבים עם נקודות בקרה ותאריך להרצת ניסיון ראשונה על החוזים שלכם.

לפי תוצאות ההרצה רואים איזה שיעור מהממצאים מהנדסים מאשרים וכמה הולך לרעש — על המספרים האלה נבנית ההערכה הסופית של הפרויקט.