קוד מקור מאובטח

1. סקירה כללית

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

דוגמאות לשיטות נפוצות לאבטחת קוד מקור:

  • ניפוי שגיאות בקוד: ניפוי שגיאות בקוד הוא תהליך של בדיקת קוד המקור כדי לזהות שגיאות ובעיות בסגנון. הבדיקה מתבצעת באמצעות כלי איתור שגיאות בקוד (lint), שהוא תוכנית שמנתחת את קוד המקור ומזהה בעיות פוטנציאליות. אפשר להשתמש בכלי Lint כדי לבדוק מגוון שגיאות, כולל שגיאות תחביר, שגיאות סמנטיות, שגיאות סגנון וחולשות אבטחה.
  • בדיקת אבטחה סטטית של אפליקציות (SAST): SAST הוא סוג של בדיקת אבטחה שמנתחת קוד מקור, קוד בינארי או קוד בייט כדי לזהות נקודות חולשה באבטחה. אפשר להשתמש בכלי SAST כדי למצוא נקודות חולשה במגוון שפות תכנות, כולל Go,‏ Java,‏ Python,‏ C++‎ ו-C#‎.
  • סריקת רישיונות: סריקת רישיונות היא תהליך של זיהוי הרישיונות של רכיבי תוכנה של צד שלישי שמשמשים באפליקציית תוכנה. חשוב לעשות זאת כדי לוודא שהאפליקציה עומדת בתנאים של הרישיונות, וכך למנוע בעיות משפטיות.

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

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

מה תלמדו

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

  • איתור שגיאות בקוד
  • בדיקות סטטיות לאבטחת אפליקציות
  • סריקה של רישיונות

כל הכלים והפקודות שבהם נשתמש במעבדה הזו יבוצעו ב-Cloud Shell.

2. הגדרה ודרישות

הגדרת סביבה בקצב אישי

  1. נכנסים למסוף Google Cloud ויוצרים פרויקט חדש או משתמשים מחדש בפרויקט קיים. אם עדיין אין לכם חשבון Gmail או חשבון Google Workspace, עליכם ליצור חשבון.

b35bf95b8bf3d5d8.png

a99b7ace416376c4.png

bd84a6d3004737c5.png

  • שם הפרויקט הוא השם המוצג של המשתתפים בפרויקט. זוהי מחרוזת תווים שלא משמשת את Google APIs. אפשר לעדכן את המיקום הזה בכל שלב.
  • מזהה הפרויקט הוא ייחודי לכל הפרויקטים ב-Google Cloud ואי אפשר לשנות אותו אחרי שמגדירים אותו. מסוף Cloud יוצר באופן אוטומטי מחרוזת ייחודית. בדרך כלל לא משנה מה המחרוזת הזו. ברוב ה-codelabs תצטרכו להפנות למזהה הפרויקט (בדרך כלל הוא מזוהה בתור PROJECT_ID). אם המזהה שנוצר לא מוצא חן בעיניכם, תוכלו ליצור מזהה אקראי אחר. לחלופין, אפשר לנסות שם משלכם ולבדוק אם הוא זמין. לא ניתן לשנות את השם אחרי השלב הזה, והוא יישאר למשך כל תקופת הפרויקט.
  • לידיעתכם, יש ערך שלישי, מספר פרויקט, שמשתמשים בו בחלק מממשקי ה-API. מידע נוסף על כל שלושת הערכים האלה זמין במסמכי העזרה.
  1. בשלב הבא, כדי להשתמש במשאבים או ב-API של Cloud, תצטרכו להפעיל את החיוב במסוף Cloud. השלמת הקודלאב הזה לא אמורה לעלות הרבה, אם בכלל. כדי להשבית את המשאבים ולמנוע חיובים אחרי סיום המדריך, אפשר למחוק את המשאבים שיצרתם או למחוק את הפרויקט כולו. משתמשים חדשים ב-Google Cloud זכאים להשתתף בתוכנית תקופת ניסיון בחינם בסך 300$.

הפעלת Cloud Shell Editor

סדנת ה-Lab הזו תוכננה ונבדקה לשימוש עם Google Cloud Shell Editor. כדי לגשת לעורך:

  1. נכנסים לפרויקט ב-Google בכתובת https://console.cloud.google.com.
  2. בפינה השמאלית העליונה, לוחצים על סמל עורך Cloud Shell.

8560cc8d45e8c112.png

  1. ייפתח חלון חדש בחלק התחתון של החלון.
  2. לוחצים על הלחצן 'פתיחת הכלי לעריכה'.

9e504cb98a6a8005.png

  1. הכלי ייפתח עם חלון 'עיון' בצד שמאל וחלון העריכה באזור המרכזי
  2. חלונית של מסוף אמורה להיות זמינה גם בתחתית המסך
  3. אם הטרמינל לא פתוח, משתמשים בשילוב המקשים ctrl+‎ כדי לפתוח חלון טרמינל חדש.

הגדרת הסביבה

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

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. איתור שגיאות בקוד

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

בנוסף, איתור שגיאות בקוד מאפשר לזהות שגיאות תחביר נפוצות שעלולות להוביל לנקודות חולשה נפוצות, כמו שימוש לא תקין או פחות יעיל בספריות או בממשקי 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) – ניתוח קוד סטטי שמטרתו לזהות נקודות חולשה וחשיפה נפוצות (CWEs)

התקנת הכלי 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. מזל טוב

כל הכבוד, סיימת את הקודלאב!

מה למדתם

  • כלים ושיטות לאבטחת קוד מקור

תאריך העדכון האחרון: 23 במרץ 2023