תנועת ה-0deps: תלויות מקומיות ואבטחה
מפתחי תוכנה מתקינים מאות ספריות חיצוניות ברוב הפרויקטים. פריימוורקים מודרניים מסתמכים על אלפי תלויות עקיפות (transitive dependencies). המשמעות היא שהאפליקציה שלכם מריצה קוד שנכתב על ידי מאות אנשים שאינם מוכרים לכם.
המערכת האקולוגית הזו מאיצה את הפיתוח, אך היא גם יוצרת סיכוני שרשרת אספקה (supply chain) עצומים.
תנועת ה-0deps שואלת שאלה פשוטה: מה אם האפליקציה שלכם הייתה מריצה רק את הקוד שאתם באמת שולטים בו?
כל תלות מוסיפה שטח תקיפה (attack surface) חדש. תלות יכולה:
- להכניס פרצות אבטחה.
- להפוך למטרה להתקפות שרשרת אספקה.
- להינטש על ידי היוצר שלה.
- לשנות את ה-API הציבורי שלה.
- לשבור תאימות לאחור.
במודל ה-0deps, אתם מעבירים את כל התלויות הדרושות ישירות לתוך רפוזיטורי הפרויקט שלכם. אתם מפסיקים להוריד חבילות באופן דינמי בזמן ה-build. כל מה שדרוש להרצת האפליקציה נשאר ברפוזיטורי מרגע ששכפלתם (clone) אותו.
גישה זו מספקת:
- בנייה ניתנת לשחזור (reproducible builds).
- פחות תלות ברישומות חבילות (package registries) חיצוניות.
- ביקורות אבטחה מרכזיות.
- תוצאות צפויות.
המטרה אינה להפוך את הקוד לסטטי. מימושים ואלגוריתמים חייבים להתפתח כדי לתקן באגים ולשמור על אבטחה. המטרה היא לשמור על החוזה (contract) הציבורי יציב.
כל ספרייה חושפת ממשק (interface) ספציפי. לדוגמה:
- authenticate()
- createSession()
- verifyPasskey()
פונקציות אלו יוצרות חוזה. החוזה נשאר זהה גם אם אתם כותבים מחדש את הקוד שבבסיסו. אתם יכולים להחליף ספריות או לשנות פרוטוקולים מבלי לשבור את שאר האפליקציה שלכם.
כאשר מופיעה פגיעות (vulnerability), אתם בדרך כלל מתמודדים עם שתי בעיות:
- לתקן את הבאג.
- לבדוק אם העדכון שובר את האפליקציה שלכם.
בארכיטקטורת 0deps, הבעיה השנייה נעלמת. אתם מעדכנים את המימוש שמאחורי הממשק. ה-API הציבורי נשאר זהה. האפליקציה שלכם ממשיכה לעבוד ללא שינויים בקוד.
על ידי בידוד קוד חיצוני מאחורי מתאמים (adapters) פנימיים, אתם מפחיתים סיכון לטווח ארוך. אם ספרייה תיעלם מחר, תצטרכו לעדכן רק את המתאם.
0deps לא נלחם בקוד פתוח. הוא משנה את האופן שבו אתם צורכים אותו. ספריות הופכות לרכיבים משולבים במקום לקישורים חיצוניים דינמיים.
זה יוצר תוכנה צפויה, עמידה וקלה לתחזוקה. המימושים מתפתחים. החוזה נשאר.