מידע על Codelab זה
1. סקירה כללית
טכניקות של קוד מקור מאובטח הן סדרת שיטות שניתן להשתמש בהן כדי לשפר את האבטחה של קוד מקור. הטכניקות האלה יכולות לעזור בזיהוי ובתיקון נקודות חולשה בקוד המקור, למנוע גישה לא מורשית לקוד המקור ולהגן על קוד המקור מפני שינוי.
מספר טכניקות נפוצות של קוד מקור מאובטח כוללות:
- איתור שגיאות בקוד: איתור שגיאות בקוד הוא התהליך של בדיקת קוד המקור לאיתור שגיאות ובעיות סגנון. לשם כך, משתמשים בכלי לאיתור שגיאות בקוד, תוכנית שמנתחת את קוד המקור ומזהה בעיות פוטנציאליות. אפשר להשתמש בכלים של Linux כדי לאתר מגוון שגיאות, כולל שגיאות תחביר, שגיאות סמנטיות, שגיאות סגנון ונקודות חולשה באבטחה.
- בדיקה של אבטחת אפליקציות סטטיות (SAST): SAST הוא סוג של בדיקת אבטחה שמנתחת קוד מקור, קוד בינארי או קוד בייט כדי לזהות נקודות חולשה באבטחה. אפשר להשתמש בכלי SAST כדי לאתר נקודות חולשה במגוון שפות תכנות, כולל Go, Java, Python, C++ ו-C#.
- סריקת רישיונות: סריקת רישיונות היא התהליך של זיהוי הרישיונות של רכיבי תוכנה של צד שלישי שנעשה בהם שימוש באפליקציית תוכנה. זה חשוב כי הוא עוזר לוודא שהאפליקציה עומדת בתנאי הרישיונות. כך נמנעים מבעיות משפטיות.
אפשר להשתמש בשיטות האלה כדי לשפר את האבטחה של קוד המקור בכל השלבים של מחזור החיים של פיתוח התוכנה. ניתן להשתמש באיתור שגיאות בקוד כדי לזהות שגיאות בשלב מוקדם בתהליך הפיתוח. ניתן להשתמש ב-SAST כדי לאתר נקודות חולשה לפני הידור או הפריסה של הקוד, וסריקת רישיונות כדי לוודא שהאפליקציה עומדת בתנאי הרישיונות.
השימוש בשיטות האלה יכול לעזור לשפר את האבטחה של קוד המקור ולהפחית את הסיכון לפרצות אבטחה.
מה תלמדו
שיעור ה-Lab הזה יתמקד בכלים ובטכניקות לאבטחת קוד מקור של תוכנה.
- איתור שגיאות בקוד (linting)
- בדיקת אבטחת אפליקציות סטטיות
- סריקת רישיונות
כל הכלים והפקודות שייעשה בהם שימוש בשיעור ה-Lab הזה יבוצעו ב-Cloud Shell.
2. הגדרה ודרישות
הגדרת סביבה בקצב אישי
- נכנסים למסוף Google Cloud ויוצרים פרויקט חדש או עושים שימוש חוזר בפרויקט קיים. אם אין לכם עדיין חשבון Gmail או חשבון Google Workspace, עליכם ליצור חשבון.
- Project name הוא השם המוצג של המשתתפים בפרויקט. זו מחרוזת תווים שלא משמשת את Google APIs. אפשר לעדכן אותו בכל שלב.
- Project ID הוא ייחודי בכל הפרויקטים ב-Google Cloud ואי אפשר לשנות אותו (אי אפשר לשנות אותו אחרי שמגדירים אותו). מסוף Cloud יוצר מחרוזת ייחודית באופן אוטומטי; בדרך כלל לא מעניין אותך מה זה. ברוב ה-Codelabs תצטרכו להפנות אל מזהה הפרויקט (בדרך כלל הוא מזוהה כ-
PROJECT_ID
). אם המזהה שנוצר לא מוצא חן בעיניך, יש לך אפשרות ליצור מזהה אקראי אחר. לחלופין, אפשר לנסות תבנית משלך ולבדוק אם היא זמינה. לא ניתן לשנות אותו אחרי השלב הזה, והוא יישאר למשך הפרויקט. - לידיעתך, יש ערך שלישי – Project Number (מספר פרויקט), שחלק מממשקי ה-API משתמשים בו. מידע נוסף על כל שלושת הערכים האלה זמין במסמכי התיעוד.
- בשלב הבא צריך להפעיל את החיוב במסוף Cloud כדי להשתמש במשאבים או בממשקי API של Cloud. מעבר ב-Codelab הזה לא אמור לעלות הרבה, אם בכלל. כדי להשבית את המשאבים ולא לצבור חיובים מעבר למדריך הזה, אתם יכולים למחוק את המשאבים שיצרתם או למחוק את הפרויקט כולו. משתמשים חדשים ב-Google Cloud זכאים להצטרף לתוכנית תקופת ניסיון בחינם בשווי 1,200 ש"ח.
הפעלת Cloud Shell Editor
שיעור ה-Lab הזה תוכנן ונבדק לשימוש עם Google Cloud Shell Editor. כדי לגשת לכלי העריכה:
- נכנסים לפרויקט Google בכתובת https://console.cloud.google.com.
- בפינה השמאלית העליונה, לוחצים על סמל העורך של Cloud Shell
- חלונית חדשה תיפתח בחלק התחתון של החלון
- לוחצים על הלחצן 'פתיחת העורך'.
- העורך ייפתח בצד שמאל עם כלי חקירה משמאל ועורך באזור המרכזי.
- חלונית טרמינל אמורה להיות זמינה גם בחלק התחתון של המסך
- אם הטרמינל לא פתוח, משתמשים בשילוב המקשים של 'Ctrl+' כדי לפתוח חלון טרמינל חדש
הגדרת סביבה
צריך להגדיר את GOPATH לספרייה אחת כדי לפשט את הפקודות שבהן נעשה שימוש בשיעור ה-Lab הזה.
export GOPATH=$HOME/gopath
ליצור ספרייה לשמירת העבודה שלנו
mkdir -p workspace
cd workspace
שכפול המאגר של קוד המקור
git clone https://gitlab.com/gcp-solutions-public/shift-left-security-workshop/source-code-lab.git
cd source-code-lab
export WORKDIR=$(pwd)
3. איתור שגיאות בקוד (linting)
איתור שגיאות בקוד (linting) משמש לבדיקת שגיאות או פגמים נפוצים הקשורים לתחביר, שמבוססים על סגנון. איתור שגיאות בקוד (linting) מקנה דפוס תחביר נפוץ בצוותים מרובים, שמוביל לבדיקות מהירות יותר של קוד, שיתוף ידע ובהירות הקוד.
בנוסף, איתור שגיאות בקוד (linting) מזהה שגיאות תחביר נפוצות שעלולות להוביל לנקודות חולשה נפוצות, כמו שימוש לא הולם או פחות יעיל בספריות או בממשקי API מרכזיים.
התקנת כלי הקישור של staticcheck
go get honnef.co/go/tools/cmd/staticcheck@latest
מריצים את Go Linter (staticcheck) בספריית השורש של הפרויקט
staticcheck
בדיקת הפלט
main.go:42:29: unnecessary use of fmt.Sprintf (S1039)
קיבלתם את השגיאה כי http.ListenAndServe()
מקבל מחרוזת, והקוד הנוכחי משתמש ב-Sprintf
בלי להעביר משתנים למחרוזת
בודקים את סטטוס הסיום של הפקודה.
echo $?
במקרה כזה, מכיוון שהפקודה גרמה לשגיאה, סטטוס היציאה יהיה 1 או יותר. זאת שיטה אחת שבה אפשר להשתמש בצינור עיבוד נתונים של CI/CD כדי לקבוע אם הכלי הצליח או נכשל.
עורכים את הקובץ main.go
ומתקנים את הקוד:
- יש להוסיף הערה על השורה שמתחת ל-
LINTING - Step 1
שבתוך השיטהmain()
, על ידי הוספת לוכסנים(//
) בהתחלה. - מבטלים את ההערה של שתי השורות ישירות מתחת ל-
LINTING - Step 2
שבתוך השיטהmain()
, על ידי הסרת הלוכסנים המובילים.
מריצים מחדש את הפקודה staticcheck
בתיקיית השורש של הפרויקט
staticcheck
הפקודה לא אמורה להחזיר תוצאות (כלומר, שורה ריקה).
בודקים את סטטוס היציאה של הפקודה.
echo $?
במקרה כזה, מכיוון שהפקודה לא הובילה לשגיאה, סטטוס היציאה יהיה אפס.
4. בדיקת אבטחת אפליקציות סטטיות
AST/Static Security Testing – בדיקת קוד סטטי, שמחפשת נקודות חולשה נפוצות וחשיפות נפוצות ( CWE)
התקנת כלי ה-AST (gosec
)
export GOSEC_VERSION="2.15.0"
curl -sfL https://raw.githubusercontent.com/securego/gosec/master/install.sh | \
sh -s -- -b $(go env GOPATH)/bin v${GOSEC_VERSION}
מריצים את הפקודה gosec
עם קובץ המדיניות על סמך קוד המקור
gosec -conf policies/gosec-policy.json -fmt=json ./...
הפלט אמור להיות דומה
{ "Golang errors": {}, "Issues": [ { "severity": "HIGH", "confidence": "LOW", "cwe": { "ID": "798", "URL": "https://cwe.mitre.org/data/definitions/798.html" }, "rule_id": "G101", "details": "Potential hardcoded credentials", "file": "/home/random-user-here/shift-left-security-workshop/labs/source-code-lab/main.go", "code": "31: \t// STEP 2: Change this and the reference below to something different (ie, not \"pawsword\" or \"password\")\n32: \tvar pawsword = \"im-a-cute-puppy\"\n33: \tfmt.Println(\"Something a puppy would use: \", username, pawsword)\n", "line": "32", "column": "6" } ], "Stats": { "files": 1, "lines": 89, "nosec": 0, "found": 1 } }
הכלי זיהה בעיה אפשרית: Potential hardcoded credentials
5. סריקת רישיונות
חשוב לשמור על האבטחה כי רישיונות יכולים לחייב אתכם על פי חוק לחשוף קוד מקור שייתכן שאתם לא רוצים לחשוף. הקונספט נקרא " copyleft" רישיונות שמחייבים אתכם לחשוף את קוד המקור אם אתם משתמשים ביחסי תלות עם הרישיונות האלה.
התקנה של golicense
mkdir -p /tmp/golicense
wget -O /tmp/golicense/golicense.tar.gz https://github.com/mitchellh/golicense/releases/download/v0.2.0/golicense_0.2.0_linux_x86_64.tar.gz
pushd /tmp/golicense
tar -xzf golicense.tar.gz
chmod +x golicense
mv golicense $(go env GOPATH)/bin/golicense
popd
יצירת הקובץ הבינארי
go build
מריצים את בדיקת הרישיון באמצעות קובץ המדיניות הנוכחי שלא מאפשר שימוש ב-BSD-3-Clause רישיונות
golicense policies/license-policy.hcl hello-world
הערה: הפעולה הזו אמורה להיכשל עם הפלט הדומה:
🚫 rsc.io/sampler BSD 3-Clause "New" or "Revised" License 🚫 rsc.io/quote BSD 3-Clause "New" or "Revised" License 🚫 golang.org/x/text BSD 3-Clause "New" or "Revised" License
צריך לשנות את קובץ המדיניות policies/license-policy.hcl
כדי להעביר את ה-BSD-3-Clause מהרשימה deny
לרשימה של allow
.
הרצה מחדש של בדיקת הרישיון
golicense policies/license-policy.hcl hello-world
הערה: הפקודה הזו אמורה להצליח עם פלט דומה:
✅ rsc.io/quote BSD 3-Clause "New" or "Revised" License ✅ rsc.io/sampler BSD 3-Clause "New" or "Revised" License ✅ golang.org/x/text BSD 3-Clause "New" or "Revised" License
6. מזל טוב
כל הכבוד, סיימת את ה-Codelab!
מה למדת
- כלים ושיטות לאבטחת קוד מקור
—
עדכון אחרון: 23.03.23