SLSA, מסגרת של גוגל להגנה מפני התקפות על שרשרת אספקת התוכנה

ل מפתחי גוגל הציגו "SLSA" (רמות שרשרת אספקה ​​לחפצי תוכנה) שמטרתן לטפל ב הגנה על תשתיות פיתוח התקפות שבוצעו בשלב קידוד, בדיקה, בנייה והפצה של מוצר.

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

אודות SLSA

מוזכר כי SLSA מתמקדת בשני העקרונות הבסיסיים הבאים:

לא חד צדדי - איש אינו רשאי לשנות את חפץ התוכנה בשום מקום בשרשרת אספקת התוכנה ללא בדיקה ואישור מפורשים לפחות מ"אדם מהימן "אחר. [^ 1] המטרה היא מניעה, הרתעה או איתור מוקדם של סיכונים / שינויים גרועים.

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

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

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

SLSA רמה 1

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

SLSA רמה 2

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

SLSA רמה 3

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

SLSA רמה 4

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

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

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

סוגי התקיפה שנלקחים בחשבון הם:

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

2.- התחייבות לפלטפורמת בקרת המקור.

3.- בצע שינויים בשלב העברת הקוד במערכת האוסף או האינטגרציה הרציפה (נאסף הקוד שאינו תואם את קוד המאגר).

4.- התחייבות פלטפורמת הבנייה

5.- קידום קוד זדוני באמצעות תלות באיכות נמוכה.

6.- טעינת חפצים שלא נוצרו במערכת CI / CD.

7.- פשרה של מאגר החבילות.

8.- בלבול אצל המשתמש להתקין חבילה שגויה.

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