קוד פתוח מטיל חובת זהירות

איזו הסתמכות אנחנו מזמינים

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

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

לדייק את ההבטחה ואת גבולותיה

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

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

כשהיעדר ממצאים נראה כמו אישור

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

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

הזכות לפרסם והדרך להשתמש

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

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

אחריות שאפשר לקיים וגם לסיים

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

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