במאמר הזה מתוארות שיטות מומלצות להגנה על תהליכי הבנייה. המונח 'קוד בניין' יכול להתייחס לסוגים שונים של פעולות, כמו:
- אופטימיזציה או טשטוש של קוד: לדוגמה, הכלי של Google בקוד פתוח Closure Compiler מנתח JavaScript, מסיר קוד לא פעיל וכותב מחדש את מה שנשאר בצורה מצומצמת. הוא גם בודק את הקוד כדי למצוא בעיות נפוצות ב-JavaScript.
- קומפילציה של קוד לקוד ביניים: לדוגמה, אפשר לבצע קומפילציה של קוד Java לקובץ מחלקה של Java (
.class), או של קוד C++ לקובץ אובייקט (.obj). - קומפילציה של קוד וקישור, יצירת ספרייה או קובץ הפעלה: לדוגמה, קומפילציה של קוד C++ לספרייה משותפת (
.so) או לקובץ הפעלה של Windows (.exe). - אריזת קוד בפורמט שניתן להפצה או לפריסה: דוגמאות כוללות יצירת קובצי Java WAR (
.war) מקובצי מחלקות Java, יצירת קובץ אימג' של Docker או יצירת הפצה מובנית של Python (.whl).
בהתאם לשפת התכנות שבה אתם משתמשים ולסביבה שבה אתם מבצעים פריסה, יכול להיות שה-build שלכם יכלול שילובים שונים של הפעולות האלה. לדוגמה, יכול להיות שבתהליך בנייה ייארז קוד Python להפצה מוכנה מראש, והוא יועלה למאגר ארטיפקטים כמו Artifact Registry או PyPI, כדי שתוכלו להשתמש בו כתלות בפונקציות של Cloud Run. אפשר גם להכניס את קוד Python לקונטיינר ולפרוס את קובץ אימג' של קונטיינר ב-Cloud Run או ב-Google Kubernetes Engine.
השיטות המומלצות במסמך הזה מתמקדות בבניית קוד לאריזה או לפריסה בסביבות זמן ריצה, ולא בהידור קוד.
שימוש בבנייה אוטומטית
ב-build אוטומטי או ב-build מבוסס סקריפט מוגדרים כל שלבי ה-build בסקריפט ה-build או בהגדרת ה-build, כולל השלבים לאחזור קוד המקור והשלבים ליצירת ה-build של הקוד. הפקודה הידנית היחידה, אם יש כזו, היא הפקודה להרצת הבנייה.
לדוגמה, סקריפט build יכול להיות:
- Cloud Build
cloudbuild.yaml. - קובץ Makefile שמריצים באמצעות הכלי
make. - קובץ של תהליך עבודה של GitHub Actions בפורמט YAML שמאוחסן בספרייה
.github/workflows/.
גרסאות build אוטומטיות מספקות עקביות בשלבי ה-build. עם זאת, חשוב גם להריץ את הבנייה בסביבה עקבית ומהימנה.
למרות ש-build מקומי יכול להיות שימושי למטרות ניפוי באגים, הפצת תוכנה מ-build מקומי עלולה להוביל להרבה בעיות אבטחה, חוסר עקביות וחוסר יעילות בתהליך ה-build.
- אפשרות לבצע build מקומי מאפשרת לתוקף עם כוונות זדוניות לשנות את תהליך build.
- חוסר עקביות בסביבות המקומיות של המפתחים ובשיטות העבודה שלהם מקשה על שחזור של בנייה ועל אבחון בעיות בבנייה.
בנייה ידנית הופכת את התהליך ללא יעיל כי היא מסתמכת על יותר משאבי תשתית כמו מחשוב, אחסון ורשתות. בדרישות של מסגרת SLSA, גרסאות build אוטומטיות הן דרישה לרמה 1 של SLSA, ושימוש בשירות build במקום בסביבות פיתוח לגרסאות build הוא דרישה לרמה 2 של SLSA.
Cloud Build הוא שירות מנוהל של build ב-Google Cloud. הוא משתמש בקובץ תצורת build כדי לספק שלבי build ל-Cloud Build. אתם יכולים להגדיר את תהליכי הבנייה כך שיאחזרו יחסי תלות, יריצו בדיקות יחידה, ניתוחים סטטיים ובדיקות שילוב, וייצרו ארטיפקטים באמצעות כלי בנייה כמו Docker, Gradle, Maven, Go ו-Python. Cloud Build משולב באופן מלא עם שירותי CI/CD אחרים ב-Google Cloud , כמו Artifact Registry ו-Cloud Deploy, וגם עם סביבות זמן ריצה כמו GKE ו-Cloud Run. הוא גם מספק שילוב עם מערכות ניהול קוד מקור מרכזיות כמו GitHub ו-Bitbucket.
יצירת אישור המקור של Build
אישור המקור של Build הוא אוסף של נתונים שניתנים לאימות לגבי build.
מטא-נתונים של מקורות מידע כוללים פרטים כמו תקצירי התמונות שנוצרו, מיקומי מקורות הקלט, שרשרת הכלים של הבנייה ומשך הבנייה.
יצירת אישור המקור של Build עוזרת לכם:
- מוודאים שנוצר ארטיפקט build ממקור מהימן וממערכת build מהימנה.
- זיהוי קוד שהוזרק ממיקום מקור או ממערכת build לא מהימנים.
אתם יכולים להשתמש במנגנוני התראות ומדיניות כדי להשתמש באופן יזום בנתוני אישור המקור של Build. לדוגמה, אתם יכולים ליצור כללי מדיניות שמאפשרים פריסה של קוד שנבנה ממקורות מאומתים בלבד.
ברמת SLSA 1, אישור המקור של Build חייב להיות זמין לצרכנים של הארטיפקטים שנבנו. בנוסף, כדי לעמוד בדרישות של SLSA ברמה 2, נתוני המקור של הבנייה צריכים להיות:
- נוצר על ידי שירות ה-build או שניתן לקרוא אותו ישירות משירות ה-build.
- הצרכן יכול לאמת את האותנטיות והתקינות של הנתונים. הפעולה הזו צריכה להתבצע באמצעות חתימה דיגיטלית שנוצרת על ידי השירות שיוצר את נתוני המקור של הבנייה.
במקרה של SLSA ברמה 3, תוכן המקוריות חייב לכלול גם:
- נקודת הכניסה להגדרת ה-build.
- כל פרמטרי הבנייה נמצאים בשליטת המשתמש.
Cloud Build יכול ליצור אישור המקור של Build עבור קובצי אימג' של קונטיינרים שמספקים הבטחת גרסת build ברמה 3 של SLSA. מידע נוסף זמין במאמר בנושא הצגת מקורות של build.
שימוש בסביבת בנייה זמנית
סביבות זמניות הן סביבות שנועדו לפעול רק בזמן הפעלת build יחידה. אחרי הבנייה, הסביבה נמחקת. בנייה זמנית מבטיחה ששירות הבנייה ושלבי הבנייה יפעלו בסביבה זמנית, כמו קונטיינר או מכונה וירטואלית. במקום לעשות שימוש חוזר בסביבת build קיימת, שירות ה-build מקצה סביבה חדשה לכל build ואז משמיד אותה אחרי שתהליך ה-build מסתיים.
סביבות זמניות מבטיחות גרסאות build נקיות כי אין קבצים שיוריים או הגדרות סביבה מגרסאות build קודמות שיכולים להפריע לתהליך ה-build. סביבה לא זמנית מאפשרת לתוקפים להחדיר קבצים ותוכן זדוניים. סביבה זמנית גם מפחיתה את עלויות התחזוקה ואת חוסר העקביות בסביבת build.
Cloud Build מגדיר סביבה חדשה של מכונה וירטואלית לכל בנייה ומשמיד אותה אחרי הבנייה.
הגבלת הגישה לשירות הבנייה
כדי לשמור על עקרון האבטחה של הרשאות מינימליות, צריך להעניק לשירות ה-build ולמשאבי ה-build את ההרשאות המינימליות הנדרשות. כדאי גם להשתמש בזהות לא אנושית כדי להריץ בנייה ולקיים אינטראקציה עם שירותים אחרים בשם הבנייה.
אם אתם משתמשים ב-Cloud Build:
- מעניקים לחברי הארגון את ההרשאות המינימליות הנדרשות.
- התאמה אישית של ההרשאות לחשבון השירות שפועל בשם Cloud Build, כך שיהיו לו רק ההרשאות שנדרשות לשימוש שלכם. עורכים את ההרשאות של חשבון השירות שמוגדר כברירת מחדל ב-Cloud Build, או שוקלים להשתמש בחשבון שירות בהתאמה אישית.
- משתמשים במדיניות הארגון Allowed integrations (שילובים מותרים) של Cloud Build כדי לשלוט בשירותים החיצוניים שמורשים להפעיל טריגרים של בנייה.
ממקמים את Cloud Build בגבולות גזרה לשירות באמצעות VPC Service Controls. גבולות הגזרה מאפשרים תקשורת חופשית בין שירותים בתוך גבולות הגזרה, אבל מגבילים את התקשורת מעבר לגבולות הגזרה על סמך כללים שאתם מציינים. Google Cloud ההיקף גם מצמצם את הסיכון לזליגת נתונים.
Cloud Build תומך ב-VPC Service Controls רק ב-builds שאתם מריצים במאגר פרטי.
הגנה על פרטי הכניסה
תהליכי Build כוללים בדרך כלל חיבורים למערכות אחרות, כמו בקרת גרסאות, מאגרי ארטיפקטים וסביבות פריסה. הגנה על פרטי הכניסה שבהם אתם משתמשים ב-builds עוזרת למנוע גישה לא מורשית למערכות בשרשרת אספקת התוכנה ולמנוע זליגת נתונים.
לא מומלץ לאחסן פרטי כניסה שמוגדרים בהארדקוד ישירות בניהול גרסאות או בתצורת build. במקום זאת, מאחסנים את פרטי הכניסה במאגר מפתחות מאובטח.
ב- Google Cloud, Secret Manager מאחסן בצורה מאובטחת מפתחות API, סיסמאות ונתונים רגישים אחרים. אפשר להגדיר את Cloud Build כך שישתמש בסודות שמאוחסנים ב-Secret Manager.
ניהול יחסי התלות
התקינות של האפליקציות שלכם תלויה בתקינות של הקוד שאתם מפתחים ושל כל התלויות שבהן אתם משתמשים. בנוסף, צריך לשקול איפה מפרסמים את התלות, למי יש גישת קריאה וכתיבה למאגרי הארטיפקטים, ומהי המדיניות לגבי מקורות מהימנים של ארטיפקטים של בנייה שפורסים בסביבות זמן הריצה.
מידע נוסף על ניהול יחסי תלות זמין במאמר ניהול יחסי תלות.
ב-Cloud Build, משתמשים בכלי בנייה ב-Cloud כדי להריץ פקודות. Builders הם קובצי אימג' של קונטיינרים שמותקנות בהם שפות וכלים נפוצים. אתם יכולים להשתמש בקובצי אימג' ציבוריים של קונטיינרים ממאגרי אימג' ציבוריים כמו Docker Hub, ב-builders שסופקו על ידי Cloud Build, ב-builders שנוצרו על ידי הקהילה וב-builders בהתאמה אישית שאתם יוצרים. אפשר גם להשתמש ב-buildpacks ככלי בנייה, כולל buildpacks של Google Cloud.
בודקים את כלי ה-build שבהם אתם משתמשים ב-build של Cloud Build, מבררים מי מספק אותם ומחליטים אם אתם סומכים עליהם בשרשרת האספקה של התוכנה. כדי לשמור על שליטה רבה יותר בקוד בכלי ליצירת אפליקציות, אתם יכולים ליצור כלים בהתאמה אישית במקום להשתמש בכלים ממקור ציבורי.
הפחתת ההזדמנויות לשינוי המבנה
יש עוד מגוון גורמים שיכולים להשפיע על בנייה, כולל:
- גרסאות build שפועלות במקביל ויכולות להשפיע זו על זו, או גרסת build שמתמידה ומשפיעה על גרסת build עוקבת.
- גרסאות build שמקבלות פרמטרים של משתמשים מלבד נקודת הכניסה של הגרסה ומיקום המקור ברמה העליונה.
- גרסאות Build שמציינות יחסי תלות עם טווחים או יחסי תלות שניתנים לשינוי (לדוגמה, באמצעות תמונה עם התג
latest). הגישות האלה יוצרות סיכון לכך שבנייה תשתמש בגרסאות לא טובות או לא רצויות של תלות.
השיטות הבאות עוזרות לצמצם את הסיכונים האלה:
- להריץ כל בנייה בסביבה זמנית.
- כדאי להימנע מהרצת בנייה עם פרמטרים נוספים כדי שהמשתמשים לא יוכלו להשפיע על משתנים שמוגדרים בסקריפטים של הבנייה.
- הגבלת הגישה לשירות הבנייה ולמשאבי הבנייה.
- במקום מזהים כמו תגים שיכולים להצביע על גרסה אחרת של הארטיפקט בעתיד, כדאי להפנות לגרסאות קבועות של יחסי תלות. מידע נוסף על יחסי תלות זמין במאמר בנושא ניהול יחסי תלות.
אבטחת שרשרת האספקה של תוכנות
Google Cloud מספקת קבוצה של יכולות וכלים מודולריים שאפשר להשתמש בהם כדי לשפר את רמת האבטחה של שרשרות אספקת התוכנה. הוא מציג תובנות לגבי אבטחה לאפליקציות שנוצרו באמצעות Cloud Build. למשל:
- רמת ה-SLSA, שמזהה את רמת הבשלות של אבטחת שרשרת האספקה של התוכנה.
- נקודות חולשה, רשימת חומרים (SBOM) והצהרות Vulnerability Exploitability eXchange (VEX) לגבי ארטיפקטים של בנייה.
- ליצור אישור המקור של Build, שהוא אוסף של מטא-נתונים שניתנים לאימות לגבי גרסת build. הוא כולל פרטים כמו תקצירי התמונות שנבנו, מיקומי מקור הקלט, שרשרת הכלים של ה-build, שלבי ה-build ומשך ה-build.
הוראות לצפייה בתובנות אבטחה לגבי אפליקציות מובנות זמינות במאמר יצירת אפליקציה וצפייה בתובנות אבטחה.