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

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

סכומי ביקורת בודקים אם הקבצים תואמים

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

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

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

חתימות דורשות בדיקת הזהות הצפויה

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

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

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

מקור הבנייה מקשר חבילה לתהליך ייצורה

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

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

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

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

בנייה ניתנת לשחזור דורשת קלט וסביבה מפורשים

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

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

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

סדר מעשי לבדיקת הורדה

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

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

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

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

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