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

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

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

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

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

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

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

מה תלמדו

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

איתור שגיאות בקוד (linting)
בדיקת אבטחת יישומים סטטית (SAST)
סריקת רישיונות

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

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

הגדרת סביבה בקצב עצמי

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

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

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

הפעלת Cloud Shell Editor

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

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

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

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

בדיקות אבטחה סטטיות (AST) – מספקות ניתוח סטטי של קוד כדי לחפש חולשות ונקודות חשיפה נפוצות (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 במרץ 2023