שימוש בכלי סריקת חולשות של Snyk

הקדמה

Snyk נועדה לשרת כפלטפורמה לאבטחת מפתחים ועם גמישות בדעת. המטרה העיקרית שלה היא לעזור לך לזהות ולתקן חוסרי אבטחה בקוד המקור של היישום שלך, בתלותי צד שלישי, בתמונות התכולה של הקונטיינר, ובקבצי התצורה של התשתית (לדוגמה, Kubernetes, Terraform וכו ').

Snyk מתחלקת לארבעה רכיבים:

1. Snyk Code – מסייעת לך למצוא ולתקן חוסרי אבטחה בקוד המקור של היישום שלך.
2. Snyk Open Source – מסייעת לך למצוא ולתקן חוסרי אבטחה בספריות או בתלותי צד שלישי שהיישום שלך תלוי בהם.
3. Snyk Container – מסייעת לך למצוא ולתקן חוסרי אבטחה בתמונות הקונטיינר או בעבודות Kubernetes שמשמשות באשכול שלך.
4. Snyk Infrastructure as Code – מסייעת לך למצוא ולתקן הגדרות שגויות במאניפסטי Kubernetes שלך (תומכת גם ב-Terraform, CloudFormation ו-Azure).

Snyk יכולה להתפעל בדרכים שונות:

• באמצעות ממשק השורת פקודה באמצעות Snyk CLI. זהו הדרך המועדפת להפעלה בתוך סקריפטים ובמגוון של אוטומציות שונות, כולל צינורות CI/CD.
• בדפדפן כמו ממשק משתמש האינטרנט של Snyk. Snyk מציעה פלטפורמה בענן בנוסף, אשר תוכל להשתמש בה לחקור דיווחי סריקה, לקבל המלצות ולבצע פעולות נדרשות לתיקון בעיות שדווחו, וכו '. תוכל גם לחבר ספריות GitHub ולבצע סריקות/בדיקות מממשק האינטרנט.
• באמצעות תוספות IDE. בכך תוכל לזהות בעיות במהלך הפיתוח באמצעות ה-IDE האהוב עליך (לדוגמה, Visual Studio Code).
• באופן תכנותי, באמצעות ממשק ה-API של Snyk. ממשק ה-API של Snyk זמין ללקוחות בתוכניות שלוות ומאפשר לך לשכלל באופן תכנותי עם Snyk.

האם Snyk היא חינמית?

כן, הכלי הוא חינמי, למעט ממשק ה-API של Snyk וכמה תכונות מתקדמות מממשק ה-Web (כגון דיווח מתקדם). יש גם הגבלה על מספר הבדיקות שניתן לבצע לחודש.

ראה תוכניות מחירים לקבלת מידע נוסף.

האם Snyk היא פתוחה לשימוש ציבורי?

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

עוד אחוד מבנה של מושגים חשוב שסניק משתמשת בהם הם יעדים ו־פרויקטים.

יעדים מייצגים משאב חיצוני שסניק סרק דרכו אינטגרציה, CLI, ממשק משתמש או API. דוגמאות ליעדים הם מאגר קוד מערכת של SCM, עומס עבודה של Kubernetes, וכו'.

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

• A scannable item external to Snyk.
• תצורה להגדרת איך להפעיל את הסריקה הזו.

באפשרותך לקרוא עוד על מושגי היסוד של סניק כאן.

במדריך זה, תשתמש ב־Snyk CLI כדי לבצע ניתוח סיכון עבור שרשרת אספקת היישומים של Kubernetes (תמונות תכולת תכולת התכנים, הצגות YAML של Kubernetes). לאחר מכן, תלמד כיצד לפעול באופן הולם כדי לתקן את המצב. לבסוף, תלמד כיצד לאינטגרציה סניק בצינור CI/CD כדי לסרוק אחר פגיעויות בשלבים הראשונים של הפיתוח.

תוכן

• מבוא
• דרישות
• שלב 1 – הכרת CLI של Snyk
• שלב 2 – להכיר את ממשק ה-Web של Snyk
  • הבנת רמות חומרה של Snyk
  • תיקון מוסך לבעיות אבטחה שדווחו
• שלב 3 – השימוש ב-Snyk כדי לסרוק את התקפיות התצורה של Kubernetes בצינור CI/CD
  • יישום זרימת עבודה CI/CD של GitHub Actions
• שלב 4 – חקר תוצאות הסריקה של Snyk ותיקון בעיות שדווחו
  • חקירה ותיקון של חולשות בתמונות ה-Container
  • חקירה ותיקון של חולשות בתצורות ה-Kubernetes
  • עקוב אחר פרויקטים שלך באופן קבוע
  • טיפול במקרים חריגים
  • Snyk עבור IDEs
• שלב 5 – הפעלת זרימת העבודה של Snyk CI/CD אוטומטית
• שלב 6 – אפשרות הודעות Slack
• מסקנה
• משאבים נוספים

דרישות מוקדמות

כדי להשלים את כל השלבים מהמדריך הזה, תצטרך:

1. A working DOKS cluster running Kubernetes version >=1.21 that you have access to. For additional instructions on configuring a DigitalOcean Kubernetes cluster, see: How to Set Up a DigitalOcean Managed Kubernetes Cluster (DOKS).
2. A DigitalOcean Docker Registry. A free plan is enough to complete this tutorial. Also, make sure it is integrated with your DOKS cluster as explained here.
3. Kubectl CLI לאינטראקציה עם Kubernetes. עקוב אחר ההוראות הללו כדי להתחבר לאשכול שלך עם kubectl ו־doctl.
4. CLI של Snyk לאינטראקציה עם סורק הפגיעויות של Snyk.
5. A free Snyk cloud account account used to periodically publish scan results for your Kubernetes cluster to a nice dashboard. Also, the Snyk web interface helps you with investigations and risk analysis. Please follow How to Create a Snyk Account documentation page.
6. A Slack workspace you own, and a dedicated Slack app to get notified of vulnerability scan issues reported by Snyk.

שלב 1 – להכיר את Snyk CLI

ניתן לסרוק באופן ידני את הפרצות האבטחה באמצעות ממשק השורת פקודה snyk. ממשק ה-CLI של Snyk מיועד לשימוש בתסריטים ובאוטומציות שונים. דוגמה מעשית היא בצינור CI/CD שמיושם באמצעות כלים שונים כמו Tekton, Jenkins, זרימות עבודה של GitHub, וכו'

כאשר מופעל ממשק ה-CLI של Snyk, הוא מתחיל מיד את תהליך הסריקה ומדווח על בעיות בפורמט ספציפי. כברירת מחדל, הוא ידפיס טבלה סיכום באמצעות הפלט התקני או המסוף. Snyk יכול ליצור דוחות בפורמטים אחרים גם, כגון JSON, HTML, SARIF, וכו'

ניתן לבחור לדחוף את התוצאות ל-פורטל ענן Snyk (או ממשק האינטרנט) באמצעות הדגל --report כדי לאחסן ולהציג את תוצאות הסריקה מאוחר יותר.

ממשק ה-CLI של Snyk מחולק למספר תת־פקודות. כל תת־פקודה מיועדת לתכונה ספציפית, כמו:

• סריקת קוד פתוח – מזהה תלויות פרויקט נוכחיות ומדווח על בעיות אבטחה שנמצאו.
• סריקת קוד – מדווחת על בעיות אבטחה שנמצאו בקוד המקור של היישום שלך.
• סריקת תמונות – מדווחת על בעיות אבטחה שנמצאו בתמונות המיכל (לדוגמה, Docker).
• סריקת קבצי תשתית כקוד – מדווחת על בעיות אבטחה שנמצאו בקבצי התצורה המשמשים על ידי Kubernetes, Terraform וכו'

לפני המשך, אנא וודאו שיצרתם חשבון חינמי באמצעות ממשק ה-UI של Snyk. בנוסף, יש לאמת את snyk CLI עם החשבון הענן שלכם כדי שפקודות / פקודות משניות יעבדו (לדוגמה, snyk code test).

A few examples to try with Snyk CLI:

1. סריקת קוד פתוח:

# סורק את קוד הפרויקט מהתיקייה הנוכחית
snyk test
# סריקת נתיב מסוים מתיקיית הפרויקט שלך (ודא שאתה מחליף את מילות המפתח `<>` בהתאם)
snyk test <path/to/dir>

2. סריקת קוד:

# סרוק את קוד הפרויקט מהתיקייה הנוכחית
snyk code test

# סרוק נתיב מסוים מתיקיית הפרויקט שלך (ודא שאתה מחליף את המקום שבו כתוב `<>` בהתאם)
snyk code test <path/to/dir>

3. סריקת תמונה:

# סרוק את תמונת הדוקר של debian על ידי משיכתה תחילה
snyk container debian

# ספק הקשר נוסף לסורק על ידי הצגת קובץ Dockerfile (ודא שאתה מחליף את המקום שבו כתוב `<>` בהתאם)
snyk container debian --file=<path/to/dockerfile>

4. סריקת תשתיות כקוד:

# סרוק את קוד הפרויקט מהתיקייה הנוכחית
snyk iac test

# סרוק נתיב מסוים מתיקיית הפרויקט שלך (ודא שאתה מחליף את המקום שבו כתוב `<>` בהתאם)
snyk iac test <path/to/dir>

# סרוק פרויקטים בהתאמה באמצעות Kustomize (תחילה עליך ליצור את התבנית הסופית, ואז להעביר אותה לסורק)
kustomize build > kubernetes.yaml
snyk iac test kubernetes.yaml

CLI של Snyk מספק עמודי עזר עבור כל האפשרויות הזמינות. הפקודה להלן יכולה לשמש להדפסת עמוד העזר הראשי:

snyk --help

הפלט נראה דומה ל:

Output
CLI commands help
  Snyk CLI scans and monitors your projects for security vulnerabilities and license issues.

  For more information visit the Snyk website https://snyk.io

  For details see the CLI documentation https://docs.snyk.io/features/snyk-cli

How to get started
  1. Authenticate by running snyk auth
  2. Test your local project with snyk test
  3. Get alerted for new vulnerabilities with snyk monitor

Available commands
  To learn more about each Snyk CLI command, use the --help option, for example, snyk auth --help or 
  snyk container --help

  snyk auth
    Authenticate Snyk CLI with a Snyk account.

  snyk test
    Test a project for open source vulnerabilities and license issues.

לכל פקודת CLI של Snyk (או פקודה משנית), יש עמוד עזר משויך כמו כן, אשר ניתן לגשת אליו דרך snyk [פקודה] --help.

אנא בקר בדף התיעוד הרשמי של CLI של Snyk לדוגמאות נוספות.

שלב 2 – היכרות עם ממשק ה-Web של Snyk

לאחר שנרשמת לחשבון של Snyk, אימתת זהות והתחברות ל-Snyk, ממשק ה-Web נפתח אל לוח המחוונים, עם אשף שמנחה אותך דרך שלבי ההגדרה הבאים:

• זיהוי המיקום של הקוד שברצונך למטרות ב-Snyk.
• הגדרת הפרוייקטים בקוד שלך שברצונך ש-Snyk תסרוק.
• חיבור Snyk לפרוייקטים רלוונטיים לסריקה שלהם.
• סקירת תוצאות הסריקה של Snyk שלך.

התכונות הבאות זמינות דרך ממשק ה-Web:

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

אנא בקר בדף התיעוד הרשמי כדי ללמוד עוד על ממשק ה-Snyk web UI.

הבנת רמות חומרה של Snyk

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

רמות החומרה יכולות לקבל אחת מהערכים הבאים:

• נמוכה: היישום עשוי לחשוף חלק מהנתונים מאפשר קרטוגרפיה של פגיעות, אשר יכולה לשמש יחד עם פגיעות אחרות לתקוף את היישום.
• בינונית: עשוי לאפשר לתוקפים בתנאים מסוימים לגשת לנתונים רגישים ביישום שלך.
• גבוהה: עשוי לאפשר לתוקפים לגשת לנתונים רגישים ביישום שלך.
• קריטית: עשוי לאפשר לתוקפים לגשת לנתונים רגישים ולהריץ קוד ביישום שלך.

מערכת המדרגת אי-ביטחוניות משתמשת במערכת ציון תקלות נפוצה (CVSS) כדי לקבוע את רמת החומרה של פגיעות באבטחה. Snyk משתמשת בגרסת המסגרת CVSS 3.1 כדי לתקשר את התכונות ואת רמת החומרה של פגיעות.

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

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

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

תיקון נתוני האבטחה שדווחו

תכונה נוספת ושימושית המסופקת על ידי ממשק ה-UI של Snyk היא סיוע בתיקון נתוני אבטחה. זה אומר שתקבל המלצה על כיצד לתקן כל בעיה באבטחה שנמצאה על ידי סורק ה-snyk. זה חשוב מאוד מכיוון שזה מקל על התהליך ומסגר את הלולאה עבור כל איטרציה שתצטרך לבצע כדי לתקן כל בעיה באבטחה שדווחה.

התמונה למטה ממחישה את התהליך עוד יותר:

לכל בעיה שנדווח, יש כפתור שבאפשרותך ללחוץ עליו ולקבל סיוע בתיקון:

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

שלב 3 – שימוש ב-Snyk לסריקת אי-אבטחה בהגדרות Kubernetes בצינור CI/CD

כיצד תרוויח מהטמעת כלי סריקת עמידה בתקניות אבטחה בצינור CI/CD שלך ותמנע מצבים לא נעימים בסביבת הייצור?

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

לכן, כלי הסריקה לאבטחה (לדוגמה, snyk) משמש כשומר שער, מונע ארטיפקטים לא רצויים מהכניסה לסביבת ההפקה שלך משלבי ההתפתחות המוקדמים. באותה הדרך, צינורי העבודה בסביבות העליונות משתמשים ב־snyk כדי לאפשר או לא לאפשר לארטיפקטים של היישום להיכנס לשלב ההפקה הסופי.

מימוש תהליך עבודה CI/CD של GitHub Actions

בשלב זה, תלמד כיצד ליצור ולבדוק צינור CI/CD דוגמא עם סריקת שורשות מובנית דרך זרימות עבודה של GitHub. כדי ללמוד את היסודות של שימוש בפעולות GitHub עם Kubernetes של DigitalOcean, יש לעיין במדריך הזה tutorial.

הצינור שסופק בחלק הבא בונה ומפרסם את היישום game-2048-example ממאגר ה-kubernetes-sample-apps של DigitalOcean.

ברמה גבוהה מבט, זרימת עבודה של game-2048 CI/CD שסופקה במאגר ה-kubernetes-sample-apps מורכבת משלבים הבאים:

1. שלב בנייה ובדיקה של היישום – מבנה את הפריטים העיקריים של היישום ומריץ בדיקות אוטומטיות.
2. שלב סריקת תמונת היישום של Snyk – סורק את תמונת ה- Docker של היישום לשורשות ידועות. הוא פועל כשער, ומצב הצינור הסופי (עבר/נכשל) תלוי בשלב זה. במקרה של כשלון, נשלחת הודעת Slack.
3. שלב בניית תמונת היישום והעברה – מבנה ומסמן את תמונת היישום באמצעות SHA של הציון האחרון ב-Git. לאחר מכן, התמונה מועברת ל-DOCR.
4. שלב הסריקה של Snyk כתשתית כקוד מקור (IAC) – מסריק לחורי אבטחה ידועים בקבצי ה-YAML של Kubernetes הקשורים לאפליקציה. משמש כשער, ומצב הצינור הסופי (עבר/נכשל) תלוי בשלב זה. במקרה של כשל, מתבצעת התראה ב-Slack גם.
5. שלב התקנת האפליקציה – מתקין את האפליקציה ב-Kubernetes (DOKS).

התרשים למטה ממחיש כל עבודה מהצינור והשלבים הקשורים עם הפעולות (הוצגה רק התצורה הרלוונטית):

איך ניתן להפעיל את הצינור אם רמת האימות לא עומדת בתקנים מסוימים לאבטחה?

ה-CLI של Snyk מספק דגל בשם --severity-threshold למטרה זו. דגל זה מתאים לרמת חומרה כוללת שנחשבת לאחר כל סריקה. במקרה של Snyk, רמת החומרה מקבלת אחת מהערכים הבאים: נמוכה, בינונית, גבוהה, או קריטית. ניתן לכשל או לעבור את הצינור התכנות בהתבסס על ערך רמת החומרה ולהפסיק את הפרסום של היישום אם התנאים לא נתקיימו.

התמונה למטה ממחישה את הזרימה עבור הצינור CI/CD של הדוגמה המשמשת במדריך זה:

נא לעקוב אחר השלבים הבאים כדי ליצור ולבדוק את תהליך העבודה של GitHub של Snyk CI/CD שמסופק במאגר ה-GitHub kubernetes-sample-apps:

1. בצע העתקת מאגר ה-GitHub kubernetes-sample-apps.
2. צור את ה־סודות המוצפנים של GitHub הבאים עבור העתקת kubernetes-sample-apps שלך (לשונית ההגדרות -> סודות -> פעולות):
   • DIGITALOCEAN_ACCESS_TOKEN – מחזיק את האסימון של חשבון ה-DigitalOcean שלך.
   • DOCKER_REGISTRY – מחזיק את שם הרישום של דוקר של DigitalOcean שלך כולל הנקודת קצה (לדוג' registry.digitalocean.com/sample-apps).
   • DOKS_CLUSTER – מחזיק את שם האשכול של DOKS שלך. תוכל להריץ את הפקודה הבאה כדי לקבל את שם האשכול של DOKS שלך: doctl k8s cluster list --no-header --format Name.
   • SNYK_TOKEN – מחזיק את זיהוי המשתמש שלך ב־Snyk – הרץ: snyk config get api כדי לקבל את הזיהוי. אם זה לא עובד, תוכל לאחזר את האסימון מעמוד ההגדרות של חשבון המשתמש שלך.
   • SLACK_WEBHOOK_URL – מחזיק את כתובת ה־Webhook הנכנס של Slack שלך המשמשת להתראות סריקה של Snyk.
3. נווט ללשונית פעולות של ה- repo שלך ובחר ב- דוגמת CI/CD של משחק 2048 של Snyk:
   
4. לחץ על הכפתור הרץ תהליך עבודה והשאר את הערכים ברירת המחדל:
   

A new entry should appear in the below list after clicking the Run Workflow green button. Select the running workflow to observe the pipeline progress:

הצינור יכשל ויעצור כאשר יתבצע ה- job של בדיקת אבטחת התכולה של snyk-container. מצפה לכך מכיוון שערך החומרה המוגדר כברירת המחדל בקלט התהליך, שהוא בינוני, לא עומד בציפיות. כמו כן, תקבל התראת Slack עם פרטים על ריצת התהליך:

בשלבים הבאים, תלמד איך לחקור את הדוח של סריקת snyk כדי לתקן את הבעיות, להוריד את רמת החומרה ולעבור את הצינור.

שלב 4 – חקירת תוצאות הסריקה של Snyk ותיקון בעיות שדווחו

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

הזרימת העבודה של משחק 2048 מריצה שני בדיקות אבטחה:

1. בדיקות אבטחת תמונת ההתקנה של הקונטיינר – משימת בדיקת אבטחת הקונטיינר של Snyk משמשת למטרה זו. הפקודה השקולה של Snyk היא – snyk container test <תמונת-משחק-2048>:<תג> --file=/path/to/game-2048/Dockerfile.
2. בדיקות הגדרות שגויות של מנפסטים של Kubernetes – משימת בדיקת אבטחת מנפסטים של Snyk משמשת למטרה זו. הפקודה השקולה של Snyk היא – snyk iac test /path/to/project/kubernetes/manifests.

לכן, להוריד את רמת החומרה ולעבור על הזרימה כולל:

1. חקירת ותיקון הבעיות שדווחו על ידי משימת בדיקת אבטחת הקונטיינר של Snyk.
2. חקירת ותיקון הבעיות שדווחו על ידי משימת בדיקת אבטחת מנפסטים של Snyk.

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

במכלולי התקנה

הצינור הדוגמא שמשמש במדריך זה מריץ בדיקות אבטחה עבור תמונת התכולה game-2048 וה-Dockerfile המקושרת באמצעות המשימה snyk-container-security-check.

המשימה snyk-container-security-check מריצה את השלבים הבאים:

1. בניית תמונת Docker של אפליקציית game-2048 באופן מקומי. שלב זה מיושם באמצעות פעולת GitHub docker-build-push.
2. הרצת בדיקות אבטחה של Snyk עבור תמונת התכולה של האפליקציה וה-Dockerfile. שלב זה מיושם באמצעות פקודת snyk container test. תוצאות הסריקה מיוצאות בתבנית GitHub SARIF. סף הרמת האבטחה נשלט על ידי הפרמטר הקלט snyk_fail_threshold אם התהליך מופעל ידנית, או באמצעות משתנה הסביבה SNYK_FAIL_THRESHOLD, אם התהליך מופעל אוטומטית.
3. התוצאות של הסריקה (בתבנית SARIF) מתפרסמות בטאב האבטחה של ספריית היישום שלך. שלב זה מיושם באמצעות פעולת codeql של GitHub.

הקטע הבא מציג את הלוגיקה העיקרית של המשימה snyk-container-security-check:

- name: Build App Image for Snyk container scanning
  uses: docker/build-push-action@v3
  with:
    context: ${{ env.PROJECT_DIR }}
    push: false
    tags: "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}"

- name: Check application container vulnerabilities
  run: |
    snyk container test "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}" \
      --file=Dockerfile \
      --severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
      --target-name=${{ env.PROJECT_NAME }} \
      --target-reference=${{ env.ENVIRONMENT }} \
      --sarif --sarif-file-output=snyk-container-scan.sarif
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
  working-directory: ${{ env.PROJECT_DIR }}

- name: Upload Snyk report SARIF file
  if: ${{ always() }}
  uses: github/codeql-action/upload-sarif@v2
  with:
    sarif_file: ${{ env.PROJECT_DIR }}/snyk-container-scan.sarif
    category: snyk-container-scan

–file=Dockerfile \

–severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \

–target-name=${{ env.PROJECT_NAME }} \

–sarif –sarif-file-output=snyk-container-scan.sarif

כדי לתקן את הבעיות שדווחו, עליך לבדוק תחילה את טאב האבטחה של מערכת ה-kubernetes-sample-apps המעותקה שלך:

FROM node:18.6.0-slim AS builder
WORKDIR /usr/src/app
COPY . .
RUN npm install --include=dev
תראה רשימה של פגיעויות עבור תמונת ה-Docker בבסיס במקרה זה. לחץ על כל אחת כדי להרחיב ולראות פרטים נוספים:
כדי לסיים את החקירות ולראות המלצות שמציעה Snyk, עליך לבדוק את פלט המשימה snyk-container-security-check מתהליך העבודה הראשי:
הערה:
בדיקת המיכל של Snyk מציעה את האפשרות לייצא תוצאות בתבנית SARIF, אך היא לא יודעת להעלות דוחות לפורטל העננים של Snyk. מאידך, מוניטור המיכל של Snyk מציע את האפשרות להעלות תוצאות לפורטל העננים של Snyk, אך הוא לא יכול לייצא SARIF. לכן, מדריך זה משתמש בבדיקת מיכל Snyk עם יכולת הייצוא של SARIF. חלק מההמלצות אינם זמינות בפלט SARIF לצערנו. לכן, עליך גם לחפש בפלט המקונסול העבודה להמלצות.
הפלט של העבודה snyk-container-security-check מראה ש-Snyk ממליץ לעדכן את גרסת התמונה הבסיסית מ־node:16-slim ל־node:18.6.0-slim. השינוי הזה מסיר את הבעיה(ות) ברמת הסיכון הגבוהה, וגם מוריד את מספר הפרצות אחרות שדווחו מ־70 ל־44 - זו הורדה משמעותית בכמות של כמעט 50% !!!
ENV NODE_ENV=development
RUN npm run build

FROM node:18.6.0-slim
RUN npm install http-server -g
RUN mkdir /public
WORKDIR /public
COPY --from=builder /usr/src/app/dist/ ./
EXPOSE 8080
USER 1000
CMD ["http-server"]

עכשיו, פתחו את קובץ ה־Dockerfile של אפליקציית המשחק 2048 מהפיצום שלכם, ושנו את ההנחיות FROM כך שיצביעו על הגרסה החדשה (node:18.6.0-slim בזמן כתיבת זה):

#

# ניתן להגדיר את מצב הבנייה באמצעות משתנה הסביבה NODE_ENV (פיתוח או ייצור)

# ראו את package.json ו־webpack.config.js של הפרויקט

#

לבסוף, התחייבו את השינויים למאגר ה־GitHub שלכם והפעילו שוב את התהליך (בהשארת הערכים ברירת המחדל). הפעם עבודת ה־snyk-container-security-check אמורה לעבור:

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

איך מוודאים שנוכל להפחית את פרצות התמונה הבסיסית בעתיד?

1. הגישה הטובה ביותר היא להשתמש בתמונת בסיס עם רגל רעננה – ככל שפחות הבינארים או התלויות בתמונת הבסיס, היא טובה יותר. עוד דרך טובה היא למפות באופן רציף את הפרויקטים שלך, כפי שמוסבר במדור לנטר את הפרויקטים שלך באופן קבוע של מדריך זה.
2. תשימו לב שהצינור עדיין נכשל, אך הפעם בשלב בדיקת אבטחת snyk-iac. ככל הנראה זה צפוי מאחר ויש בעיות אבטחה עם קבצי ה-Kubernetes שמשמשים להתקנת היישום. במדור הבא, תלמדו כיצד לחקור את המצב הזה וליישם את ההמלצות האבטחה של Snyk כדי לתקן את הבעיות שדווחו.

חקירת ותיקון השוליים בקבצי ה-Kubernetes

- name: Check for Kubernetes manifests vulnerabilities
  run: |
    snyk iac test \
      --severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
      --target-name=${{ env.PROJECT_NAME }} \
      --target-reference=${{ env.ENVIRONMENT }} \
      --sarif --sarif-file-output=snyk-iac-scan.sarif \
      --report
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
  working-directory: ${{ env.PROJECT_DIR }}

- name: Upload Snyk IAC SARIF file
  if: ${{ always() }}
  uses: github/codeql-action/upload-sarif@v2
  with:
    sarif_file: ${{ env.PROJECT_DIR }}/snyk-iac-scan.sarif
    category: snyk-iac-scan

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

1. משימת בדיקת אבטחת snyk-iac בודקת את השוליים (או ההגדרות הלא תקיניות) בקבצי ה-Kubernetes, ומבצעת את השלבים הבאים:
2. הבדיקות לאבטחה של Snyk עבור המניפסטים של Kubernetes מתבצעות מתיקיית הפרויקט game-2048-example. צעד זה מיושם באמצעות הפקודה snyk iac test. תוצאות הסריקה מיוצאות באמצעות פורמט ה-SARIF של GitHub. סף הרמה של האבטחה נשלט באמצעות הארגומנט –severity-threshold – הוא מוגדר או לפרמטר הקלט snyk_fail_threshold אם זרימת העבודה מופעלת באופן ידני, או למשתנה הסביבה SNYK_FAIL_THRESHOLD אם העבודה רצה באופן אוטומטי. לבסוף, הארגומנט –report משמש גם הוא לשליחת תוצאות הסריקה לפורטל העננים של Snyk.

תוצאות הסריקה (בפורמט SARIF) מפורסמות בכרטיס האבטחה של ספריית היישום שלך. צעד זה מיושם באמצעות הפעולה של codeql ב-GitHub.

החלק הבא מציג את המימוש המופעל של כל שלב מתוך המשימה snyk-iac-security-check:

–severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \

–target-name=${{ env.PROJECT_NAME }} \

–target-reference=${{ env.ENVIRONMENT }} \

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: game-2048
spec:
  replicas: 1
  selector:
    matchLabels:
      app: game-2048
  strategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: game-2048
    spec:
      containers:
        - name: backend
          --sarif --sarif-file-output=snyk-iac-scan.sarif \
          image: registry.digitalocean.com/sample-apps/2048-game:latest
          ports:
            - name: http
              containerPort: 8080
          resources:
            requests:
              cpu: 100m
              memory: 50Mi
            limits:
              cpu: 200m
              memory: 100Mi
          securityContext:
            readOnlyRootFilesystem: true
            runAsNonRoot: true
            allowPrivilegeEscalation: false
            capabilities:
              drop:
                - all

כדי לתקן את הבעיות שדווחו יש לך שתי אפשרויות:

• השתמש בפורטל העננים של Snyk וגש לפרויקט game-2048 כדי לבדוק פרטים:
• השתמשו בלשונית האבטחה של מאגר האפליקציות שלכם של משחק 2048 כדי לבדוק את הפרטים:
  
• בכל מקרה, תקבלו המלצות לגבי איך לתקן את הבעיות שדווחו.
• עבור מדריך זה, תשתמשו בפורטל הענן של Snyk כדי לחקור את בעיות האבטחה שדווחו. תחילה, לחצו על רשומת הפרוייקט game-2048-example מרשימת הפרוייקטים, ואז בחרו את הקובץ kustomize/resources/deployment.yaml:

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

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

A few final checks can be performed as well on the Kubernetes side to verify if the reported issues were fixed:

1. לאחר שאספתם את כל המידע מכל כרטיס, תוכלו לערוך את קובץ deployment.yaml מהמאגר שלכם (נמצא בתת-תיקיית game-2048-example/kustomize/resources). התיקונים כבר נעשו, אתם רק צריכים לבטל את ההערות מהשורות האחרונות של הקובץ. הקובץ deployment.yaml הסופי צריך להיראות כמו שמתואר למטה:
2. readOnlyRootFilesystem – מפעיל תמונת תוכן במצב קריאה בלבד (לא ניתן לשנות קבצים באמצעות kubectl exec בתוך הקונטיינר).

allowPrivilegeEscalation – הגדרת allowPrivilegeEscalation ל־false מבטיחה שלא יוכל תהליך משנה של קונטיינר לקבל יותר הרשאות מאביו.

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

לבסוף, עשה commit לשינויים בקובץ deployment.yaml והעלה לסנף הראשי. לאחר הפעלת תהליך העבודה ידנית, הוא צריך להשלים בהצלחה הפעם:

כמו כן, עליך לקבל הודעת סלאק ירוקה מתקן הסריקה של snyk. נווט לקישור לפורטל של Snyk ובדוק האם הבעיות שתיקנת לאחרונה נעלמו – לא צריך להיות בעיות ברמת אבטחה בינונית מדווחות.

בדוק אם פריסת המשחק-2048 כוללת מערכת קבצים לקריאה בלבד (לא ניתנת לשינוי) על ידי כתיבה לקובץ index.html המשמש על ידי אפליקציית המשחק-2048:

kubectl exec -it deployment/game-2048 -n game-2048 -- /bin/bash -c "echo > /public/index.html"

הפלט דומה לזה:

פלט
/bin/bash: /public/index.html: מערכת קבצים לקריאה בלבד
פקודה סיימה עם קוד סיום 1

בדוק אם פריסת המשחק-2048 כוללת מערכת קבצים לקריאה בלבד (לא ניתנת לשינוי) על ידי כתיבה לקובץ index.html המשמש על ידי אפליקציית המשחק-2048:

הפלט דומה לזה:

snyk-container-security-check:
    runs-on: ubuntu-latest
    needs: build-and-test-application

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      ...

      - name: Check application container vulnerabilities
        run: |
          snyk container test "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}" \
            --file=${{ env.PROJECT_DIR }}/Dockerfile \
            --severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
            --target-name=${{ env.PROJECT_NAME }} \
            --target-reference=${{ env.ENVIRONMENT }} \
            --sarif-file-output=snyk-container-scan.sarif
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

      - name: Monitor the application container using Snyk
        run: |
          snyk container monitor "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}" \
            --file=${{ env.PROJECT_DIR }}/Dockerfile
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
      
      ...

בדוק האם המיכל פועל כמשתמש שאינו root (צריך להדפיס מספר שלם שונה מאפס – לדוגמה, 1000):

kubectl exec -it deployment/game-2048 -n game-2048 -- id -u

בדוק האם המיכל פועל כמשתמש שאינו root (צריך להדפיס מספר שלם שונה מאפס – לדוגמה, 1000):

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

build-and-test-application:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: npm install, build, and test
        run: |
          npm install
          npm run build --if-present
          npm test
        working-directory: ${{ env.PROJECT_DIR }}

      - name: Snyk code test and monitoring
        run: |
          snyk test ${{ env.PROJECT_DIR }}
          snyk monitor ${{ env.PROJECT_DIR }}
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

נטור את הפרויקטים שלך באופן קבוע

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

בעיה אחת עם הגישה הנוכחית היא שאתה לעולם לא יודע מתי יודו על בעיות חדשות עבור הנכסים שכבר העמקת בסביבותיך. במילים אחרות, הערכת את סיכוני האבטחה ונקיטת הצעדים לתיקון הבעיות בנקודת זמן ספציפית אחת – כאשר האוטומציה שלך ל-CI/CD נכנסת לתוקפה.

אבל מה אם דיווחים חדשים נדווים בינתיים, והיישום שלך עדיין מוצפן? Snyk עוזרת לך להתמודד עם המצב הזה דרך התכונה של ניטור. התכונה לניטור של Snyk מסייעת לך לטפל בפגיעויות חדשות, שמתגלות באופן קבוע. כאשר משולבת עם אינטגרציה של Snyk Slack (מוסברת ב-שלב 6 – הפעלת התראות ב-Slack), תוכל לפעול מיידית כדי לתקן נושאים שנגלו חדשים שעלולים להשפיע על היישום שלך בסביבה פרודקציונית.

כדי להרוויח מהתכונה הזו, כל שעליך לעשות הוא להשתמש בפקודת snyk monitor לפני כל שלבי האפסה בצינור ה- CI/CD שלך. התחביר דומה מאוד לפקודות snyk test (אחת מהדברים המעניינים ביותר על CLI של snyk הוא שנוצר עם ייחוס קבוע בדעת). הפקודה snyk monitor תשלח צילום לפורטל הענן של Snyk, ומשם תקבל התראה על פגיעויות שנגלו חדשות עבור הפרוייקט שלך.

A more efficient approach is where you integrate vulnerability scan tools directly in your favorite IDE (or Integrated Development Environment). This way, you can detect and fix security issues ahead of time in the software development cycle.

מבחינת אוטומציה של הזרימה העבודה ב-GitHub, תוכל לבצע ניטור של מיכל היישום שלך בעבודת ה-בדיקת אבטחת המיכלים של snyk-container, לאחר בדיקה עבור פגיעויות. הקטע הבא מציג מימוש מעשי עבור הצינור המשמש במדריך זה (חלק מהשלבים נעצרו למען בהירות):

1. –file=${{ env.PROJECT_DIR }}/Dockerfile \
2. –severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
3. –target-name=${{ env.PROJECT_NAME }} \
4. –target-reference=${{ env.ENVIRONMENT }} \

–sarif-file-output=snyk-container-scan.sarif

–file=${{ env.PROJECT_DIR }}/Dockerfile

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

לאחר הרצת פקודת ניטור Snyk, תוכל להתחבר לממשק משתמש האינטרנט של Snyk כדי לראות את הצילומים האחרונים וההיסטוריה של הפרויקט:

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

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

לבסוף, תקבל הודעות דרך Slack באופן קבוע על פרסום חדש של פגיעויות לפרויקט שלך.

טיפול בחריפות

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

ניתן לקרוא עוד על תכונה זו כאן.

Snyk עבור IDEs

Snyk מציע תמיכה למגוון של IDEs, כמו:

תוסף Eclipse.

תוסף של JetBrains.

• הרחבת Visual Studio.
• הרחבת של Visual Studio Code.
• התוספות האמורות מסייעות לך לזהות ולתקן בעיות בשלבי התפתחות מוקדמים, מה שמבטיח להסיר רגעי אכזבה, עלויות, ושגיאות אבטחה במערכות הייצור. בנוסף, זה עוזר לך להפחית את המאמצים האנושיים והאיטרציות בעתיד. כדוגמה, לכל בעיה בטיחותית שמדווחת על ידי האוטומציה של CI/CD, עליך לחזור ולתקן את הבעיה בקוד שלך, לבצע שינויים, לחכות לאוטומציה של CI/CD שוב, ולחזור על התהליך במקרה של כשל.
• מתוך התיעוד הרשמי, ניתן לקרוא עוד על התכונות הללו בעמוד Snyk עבור IDEs.
• שלב 5 – הפעלת זרימת עבודה אוטומטית של Snyk CI/CD
• ניתן להגדיר את זרימת העבודה כך שתפעל אוטומטית בכל הצטרפות או PR לענף הראשי על ידי הסרת ההערות מהשורות הבאות בראש קובץ game-2048-snyk.yaml:
• לאחר עריכת הקובץ, יש לבצע commit לשינויים בענף הראשי שלך, ותהליך ההפעלה יהיה מוכן.
• שלב 6 – הפעלת הודעות Slack
• ניתן להגדיר את Snyk כך שתשלח הודעות Slack על גילוי חדש של פגיעויות בפרוייקטים שלך ועל שדרוגים או תיקונים חדשים שהתקבלו.
• כדי להגדיר זאת, יש ליצור webhook של Slack. ניתן לעשות זאת דרך Incoming WebHooks או על ידי יצירת Slack App משלך. לאחר שיצרת את כתובת ה-Webhook שלך של Slack, יש לעבור אל הגדרות 'ניהול ארגון', להזין את ה-URL וללחוץ על הכפתור Connect: