במסמך הזה מתוארות שיטות מומלצות לניהול קוד מקור של תוכנה.
אחד השלבים הבסיסיים שצוותי פיתוח תוכנה מבצעים כדי לנהל את המקור שלהם הוא אימוץ מערכת לניהול גרסאות (VCS). מערכות בקרת גרסאות מספקות היסטוריה ויכולת ביקורת של השינויים. מערכות בקרת גרסאות מתארחות כמו GitHub מספקות יתרונות נוספים כמו זמינות, יציבות, אמצעי בקרה לאבטחה, כלים משולבים לסקר קוד ושילוב עם שירותי ענן אחרים.
רוב הצוותים משתמשים היום בניהול גרסאות, אבל יש הרבה דרכים להגדיר מערכת לניהול גרסאות ואת השילובים שלה עם חלקים אחרים בצינור CI/CD.
במסמך הזה מפורטים שיקולים בנושא אבטחת שרשרת האספקה של תוכנות, שצריך לקחת בחשבון כשמגדירים מערכת לניהול גרסאות. במאמר הזה מתוארות שיטות מומלצות מתוך Supply chain Levels for Software Artifacts, מסגרת להגנה על שרשרת אספקת התוכנה. המסגרת כוללת דרישות בכמה רמות כדי לעזור לכם ליישם שינויים בהדרגה, כולל דרישות לגבי מקורות.
מערכת לניהול גרסאות עם היסטוריית שינויים ועדכונים שלא ניתן לשנות היא דרישה ברמה 2 של SLSA. מומלץ להתחיל עם התאמה לרמה 2 של SLSA כרמת בסיס לשרשרת אספקת התוכנה.
ברמה 3 של SLSA, פלטפורמות המקור והבנייה עומדות בדרישות אבטחה מחמירות יותר, כולל היסטוריית מקור מאומתת ומדיניות שימור מקור. ברמה 4 של SLSA נוספות דרישות לגבי מקורות, כולל בדיקות של שני אנשים.
שימוש בניהול גרסאות למטרות נוספות מעבר לקוד המקור של האפליקציה
אחסון המקור של האפליקציה בבקרת גרסאות הוא שיטה מקובלת כשנדרשות ביקורות היסטוריות וביקורות. עם זאת, יש סוגים אחרים של מקורות שגם הם יכולים להפיק תועלת מבקרת גרסאות, כולל הגדרות, מדיניות ונתונים. האיסור כולל קבצים ש:
- השפעה על הזמינות והאבטחה של תשתיות המחשוב
- נדרש שיתוף פעולה כדי להשלים את התהליך
- נדרש תהליך אישור שניתן לחזור עליו
- דרישה של היסטוריית שינויים
דוגמאות:
- תשתית כקוד: ארגונים שרוצים לנהל את התשתית שלהם בצורה מאובטחת וניתנת להרחבה משתמשים בתשתית כקוד כמתודולוגיה מרכזית. לדוגמה, אפשר לאחסן במערכת לניהול גרסאות מודולים של Terraform שיוצרים מאגרי Artifact Registry.
- ניהול הגדרות: ניהול הגדרות דומה ל-infrastructure-as-code, אבל הוא מתמקד בניהול הגדרות של אפליקציות באמצעות כלים כמו Ansible, Puppet ו-Chef. אתם מאחסנים ומנהלים את קובצי התצורה של האפליקציה במערכת לניהול גרסאות.
- תצורות של מסדי נתונים וסקריפטים להעברה: אחסון של התצורה והסקריפטים של מסדי הנתונים של המוצרים ושל מסדי הנתונים של Analytics או של רישום ביומן.
- Jupyter notebooks: יש מגוון דרכים לעבוד עם notebooks שמאוחסנים ב-GitHub, כולל התוסף ל-JupyterLab, Colaboratory ו-Vertex AI Workbench
- מדיניות אבטחה: אחסון קובצי מדיניות לאכיפה אוטומטית של מדיניות. לדוגמה, אתם יכולים לאחסן מדיניות של Gatekeeper שמאפשרת או אוסרת התנהגות פריסה ב-GKE או מדיניות של Sentinel שמונעת מ-Terraform הקצאת משאבים של תשתית שמפירים את המדיניות.
במחקר DORA DevOps זוהתה יכולת טכנית שמשפרת את הכנת התוכנות להפצה ואת הביצועים של הארגון. אחת מהיכולות האלה היא בקרת גרסאות. אחסון הסקריפטים, קוד המקור וקובצי ההגדרות במערכת לניהול גרסאות עוזר לשחזר סביבות, לעקוב אחרי שינויים ולבדוק אותם, ולהגיב במהירות לפגמים.
הגדרת מאגר
מאגרים הם היחידה הלוגית הבסיסית לארגון קוד ותפקידים, הרשאות, שילובים ואישורים שקשורים לקוד.
בעיות שיכולות לקרות בהגדרת המאגר כוללות:
- הגדרת המאגרים לא אחידה, ולכן קשה לוודא שהאבטחה של המאגר מתאימה לאפליקציה שהוא מייצג, במיוחד בתרחיש הנפוץ שבו לארגון יש מאות או אלפי מאגרים.
- מי שיוצר את המאגר הופך לבעלים עם הרשאות אדמין מלאות, כולל היכולת לבצע מיזוגים בלי שיהיו בודקים אחרים.
- שילוב מאגרי מידע עם ניתוח קוד, שרתי בנייה, מערכות למעקב אחרי בעיות, שירותי התראות וחלקים אחרים בתשתית CI/CD יכול להיות משימה מורכבת. היכולת ליצור ולהגדיר מאגרי מידע בדרך סטנדרטית חוסכת עבודה חוזרת ותומכת בשיטות מומלצות.
כדי לפתור את הבעיות האלה, כדאי לפעול לפי השיטות המומלצות הבאות:
- הגדרת מאגרי מידע באמצעות תהליך אוטומטי, חוזר ומודע לאבטחה. לדוגמה, אפשר להגדיר מודולים של Terraform שמשלבים את דרישות האבטחה של האפליקציה שאליה מתייחס המאגר. אפליקציות ברמת אבטחה גבוהה דורשות יותר מאשר אפליקציות ברמת אבטחה נמוכה, וגם דורשות מאשר אפליקציות ברמת אבטחה נמוכה, וגם דורשות
- ליצור דרך לאדמינים של מאגרים לבחור מתוך קבוצה של תבניות הגדרה של מאגרים שמניעות הגדרה של מאגרים חדשים, במקום להגדיר כל מאגר מאפס. התבניות האלה צריכות לשקף את רמות האבטחה השונות של האפליקציות שלכם, ולהיות מסונכרנות עם זהויות המשתמשים שנדרשות לכל רמת אבטחה. בפועל, זה בדרך כלל אומר שצריך להשתמש במערכת היררכית לניהול זהויות והרשאות גישה (IAM) שמשקפת את האפליקציות והתשתית בארגון ואת המשתמשים שאחראים עליהן.
- נדרש ניהול זהויות מרכזי עם אימות רב-שלבי (MFA) למשתמשי המאגר.
- ניהול זהויות מרכזי מבטיח שכאשר משתמשים עוזבים את הארגון או עוברים לצוותים חדשים, אתם שומרים על הרשאות מינימליות לניהול המקור.
- אימות רב-שלבי מפחית באופן משמעותי את הסיכון לפישינג ולסוגים אחרים של מתקפות על המקור. אימות דו-שלבי הוא אחת מהדרישות ברמה 4 של SLSA למאשרי קוד.
- הגבילו את הגישה לבעלי מאגרים למספר קטן של עובדים מהימנים. יכול להיות שיהיה צורך לשלב ניהול גרסאות עם מערכת לניהול זהויות, ולהעביר את היכולת להגדיר מדיניות לרמה גבוהה יותר בארגון. אם אפשר, כדאי להסיר את האפשרות של בעלי מאגרים לבצע מיזוגים בלי בודק שני.
סקר קוד
סקר קוד היא הדרך העיקרית שבה ארגונים שומרים על האיכות והאבטחה של התוכנה שלהם. בביקורת קוד מנסים לטפל במצבי כשל שונים, כמו:
- הוספת קוד עם פגמים בתוכנה או עיצוב לא גמיש.
- ממשקי API שלא הוגדרו בצורה טובה
- הצגת בעיות אבטחה בגלל קוד לא מאובטח שנכתב על ידי המפתח
- הוספה של ספריות של צד שלישי שהן לא מאובטחות או שעלולות להפוך ללא מאובטחות, וגורמות לבעיות אבטחה.
כמה דרכים לצמצום הסיכון:
- הטמעה של אוטומציה של בדיקות לאורך מחזור החיים של התוכנה. בדיקות אוטומטיות שמופעלות כשמבצעים קומיט של קוד המקור למערכת בקרת הגרסאות מאפשרות למפתחים לקבל במהירות משוב על בעיות שנמצאו בבדיקות.
- מספר הבודקים והזהות שלהם צריכים להתאים לרמת האבטחה של האפליקציה. לדוגמה, לאפליקציית אינטראנט עם שימוש נמוך יהיו דרישות אבטחה נמוכות יותר מאשר לאפליקציה קריטית לעסק שפונה לציבור.
- הקצאת בודקים על סמך מומחיות טכנית ורמת האמון הנדרשת לשינוי בהתחייבות. הבודק צריך להיות מומחה בשפה שנבדקת, במערכות שהקוד מתקשר איתן ובסיכוני האבטחה בסוג האפליקציה הזה. יש הרבה היבטים שקשורים לדרישה של מומחיות טכנית. לדוגמה:
- האם אפשר לקרוא את הקוד?
- האם זה מאובטח?
- האם נעשה שימוש בספריות מתאימות של צד שלישי?
- האם יש תהליך לאבטחת ספריות של צד שלישי?
- האם אפשר להרכיב את הקוד?
- האם עיצוב ה-API תואם לשיטות המומלצות?
הביקורות לא צריכות להיות שלב בירוקרטי, אלא שיחה מתמשכת על שיטות מומלצות. כדאי ליצור רשימות משימות, מדריכי סגנון ותקני עיצוב לכל חלק בסטאק התוכנות, וגם תוכניות לימוד למפתחים חדשים. בסביבות פיתוח משולבות מסוימות, כמו VS Code ו-IntelliJ, יש כלי ניתוח קוד שיכולים לסמן באופן אוטומטי שגיאות תכנותיות או שגיאות שקשורות לסגנון. כלי Linter עוזרים למפתחים ליצור קוד עקבי יותר, ומאפשרים לבודקי קוד להתמקד יותר בבעיות שלא קל לזהות באמצעות בדיקות אוטומטיות.
Developing Secure Software הוא קורס אונליין חינמי שנוצר על ידי Open Source Security Foundation (OpenSSF). הוא מתאר שיטות בסיסיות לפיתוח תוכנה בהקשר של אבטחת שרשרת אספקת התוכנה.
אפשר לבצע בדיקות קוד באמצעות בקשות משיכה של ענפי תכונות ברגע שמפתח בודד מוכן. אל תחכו עד לרגע שלפני פרסום גרסה חדשה כדי לבצע בדיקות אבטחה ובדיקות קוד.
שילוב של סריקת פגיעויות, כולל סריקה של ספריות של צד שלישי, בבקשות משיכה ובסביבות פיתוח משולבות (IDE) עוזר לזהות בעיות מוקדם ככל האפשר. On-Demand Scanning API ב- Google Cloud מאפשר לסרוק קונטיינרים באופן מקומי כדי לזהות נקודות חולשה.
שילוב של בדיקות אוטומטיות לפני מיזוג, כדי שהמפתחים יוכלו לזהות ולתקן שינויים שיגרמו לשבירת האפליקציה. מידע נוסף על אוטומציה של בדיקות
מיזוג אישורים
בצינורות עיבוד נתונים של CI/CD עם אינטגרציה רציפה, מיזוג קוד לענף ייצור עשוי להוביל לשינויים במורד הזרם, כולל build והשקה אוטומטיים. לכן, אבטחת האנשים שיכולים למזג היא חלק חשוב באבטחת פריסות תוכנה. השיקולים כוללים:
- מגדירים בעלים של ענפים מוגנים בענפי הייצור. המספר והזהות של מי שמורשים למזג צריכים להתאים לדרישות האבטחה של האפליקציה. רמה 4 ב-SLSA מחייבת שני גורמים מאשרים עם אימות חזק, אבל מספר הגורמים המאשרים צריך להיות מתאים לתוכן המאגר.
- חשוב לשלוט באופן הדוק בזהויות של בעלי מאגרי מידע, כי ברוב מערכות בקרת הגרסאות הם יכולים לבצע מיזוגים בעצמם.
- תהליכי אישור נפרדים לפריסה ולמיזוג להשקות של כמה מאגרי מידע וכמה ארטיפקטים.
כלים לאבטחת הפיתוח
Google Cloud מספקת קבוצה של יכולות וכלים מודולריים שבהם אפשר להשתמש כדי לשפר את מצב האבטחה של שרשרת אספקת התוכנה. המרכיבים הבאים עוזרים להגן על קוד המקור של התוכנה:
Cloud Workstations (גרסת Preview)
Cloud Workstations מספקת סביבות פיתוח מנוהלות באופן מלא ב-Google Cloud. היא מאפשרת למנהלי IT ואבטחה להקצות, להרחיב, לנהל ולאבטח בקלות את סביבות הפיתוח שלהם, ולמפתחים לגשת לסביבות פיתוח עם הגדרות עקביות וכלים שניתנים להתאמה אישית.
Cloud Workstations עוזרת להעביר את האבטחה שמאלה על ידי שיפור מצב האבטחה של סביבות פיתוח האפליקציות. יש לו תכונות אבטחה כמו VPC Service Controls, תעבורת נתונים פרטית נכנסת או יוצאת, עדכון תמונות בכפייה וכללי מדיניות גישה של ניהול זהויות והרשאות גישה (IAM). מידע נוסף זמין במאמרי העזרה בנושא Cloud Workstations.
הגנת מקור ב-Cloud Code (גרסת Preview)
Cloud Code מספק תמיכה בסביבת פיתוח משולבת (IDE) ליצירה, לפריסה ולשילוב של אפליקציות עם Google Cloud. הוא מאפשר למפתחים ליצור ולהתאים אישית אפליקציה חדשה מתוך תבניות לדוגמה ולהריץ את האפליקציה המוגמרת. התכונה 'הגנה על המקור' ב-Cloud Code מספקת למפתחים משוב אבטחה בזמן אמת, כמו זיהוי של תלות פגיעה ודיווח על רישיונות, בזמן שהם עובדים בסביבות הפיתוח המשולבות שלהם. הוא מספק משוב מהיר ופרקטי שמאפשר למפתחים לבצע תיקונים בקוד שלהם בתחילת תהליך פיתוח התוכנה.
זמינות התכונות: התכונה 'הגנת מקור' ב-Cloud Code לא זמינה לגישה ציבורית. כדי לקבל גישה לתכונה הזו, אפשר לעיין בדף בקשת הגישה.