‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

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

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

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

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

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

מה תלמדו

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

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