סטארטאפ בשלב Pre-Seed: אבטחה מינימלית שלא תהרוס את ה-Due Diligence

אתם ארבעה אנשים בחדר אחד, ה-MVP עלה לפני שבועיים, ויש כבר לקוח פיילוט אחד שמשלם. אבטחת מידע נמצאת אי-שם בתחתית הרשימה, מתחת ל״לתקן את הבאג ב-checkout״ ו״לגייס עוד מפתח״ — וזה בסדר גמור, כי בשלב הזה מהירות היא הכול. הבעיה מתחילה מאוחר יותר, ותמיד באותה נקודה: אמצע בדיקת נאותות (Due Diligence). הקרן שנתנה Term Sheet מבקשת גישה לחשבון ה-GitHub, או הלקוח האנטרפרייז הראשון שולח שאלון אבטחה — ופתאום מתברר שהמפתח הראשי הוא אדמין על הכול, ש-API key של הספק שלכם יושב בקוד ב-repo פומבי, ושאף אחד לא יודע איפה בדיוק שמור המידע של המשתמשים. אף אחת מהבעיות האלה לא הייתה עולה כסף לתקן ביום הראשון. עכשיו, באמצע עסקה, כל אחת מהן עולה זמן — ולפעמים אמון. במאמר הזה נעבור על הבסיס בעלות אפס שסטארטאפ בן 2–10 אנשים יכול להעמיד בעצמו בעוד אחר צהריים אחד, ועל מה לא לעשות בשלב הזה — כי over-engineering של אבטחה מוקדם מדי מבזבז בדיוק את המשאב שאין לכם.

המתח האמיתי: מהירות מול חוב האבטחה שמתפוצץ ב-DD

כמו חוב טכני, חוב אבטחה הוא לא בעיה — עד שהוא כן. ההבדל הוא בתזמון שבו הוא צף: לא כשנוח לכם לטפל בו, אלא ברגע הכי רגיש — כשמישהו חיצוני בודק אתכם לפני שהוא נותן לכם כסף או נותן לכם את הדאטה שלו. בשלב Pre-Seed אף אחד לא מצפה מכם ל-ISO 27001 או ל-SOC 2. מה שכן בודקים מוקדם הוא הרבה יותר בסיסי, ובדיוק בגלל זה הרבה יותר מביך להיכשל בו:

• בסיס שאלון האבטחה. גם הגרסה הקצרה של שאלון ספק שואלת שאלות של כן/לא: האם יש MFA על כל החשבונות? האם יש הפרדת סביבות? מי ניגש לסביבת הייצור? האם המידע מוצפן? על שאלות כאלה אפשר לענות ״כן״ בזול היום — או להסביר במבוכה למה ״לא״ בעוד חצי שנה.
• תשובות על טיפול במידע. ״איזה מידע אתם אוספים על המשתמשים ואיפה הוא נשמר?״ היא שאלה שנשמעת פשוטה עד שמנסים לענות עליה בלי הכנה. צוות שלא יודע לענות עליה בפסקה אחת משדר חוסר בשלות.
• דליפות פומביות מביכות. לפני שהמשקיע נכנס לשיחה, מישהו כבר עשה חיפוש. secret שדלף ל-GitHub, credentials בהיסטוריית commit, סביבת staging חשופה לאינטרנט — כל אחד מאלה נמצא בכמה דקות, ומשנה את הטון של הפגישה.

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

הבסיס של יום אחד: SSO ו-MFA על הכול

אם תעשו רק דבר אחד מכל המאמר — תעשו את זה. אימות רב-שלבי (MFA) הוא הבקרה הכי חזקה ביחס לעלות שקיימת. מחקר של Microsoft על נתוני Azure מצא ש-MFA מפחית את הסיכון להשתלטות על חשבון בכ-99.22%, וב-98.56% גם כשהסיסמה עצמה כבר דלפה. מבחינת עסקה — זו גם השאלה הראשונה כמעט בכל שאלון אבטחה. בסטארטאפ שעדיין לא נעל את זה, כל חשבון עם סיסמה בלבד הוא דלת פתוחה.

• Google Workspace / Microsoft 365 כמקור זהות אחד. הגדירו את חשבון הארגון כ-Single Sign-On לכל הכלים שתומכים בזה, במקום משתמש וסיסמה נפרדים לכל שירות. פחות סיסמאות = פחות משטח תקיפה, וגם ניתוק גישה בקליק אחד כשעובד עוזב.
• אכיפת 2FA ברמת הארגון. ב-Google Workspace אפשר לחייב 2-Step Verification לכל המשתמשים; ב-GitHub Organization יש הגדרת ‎Require two-factor authentication‎ שחוסמת כל חבר בלי 2FA. לא ״להמליץ״ — לאכוף. המלצה בלי אכיפה שווה אפס.
• מפתחי אפליקציית authenticator או מפתח חומרה, לא SMS. קוד ב-SMS עדיף על כלום, אבל חשוף להחלפת קו (SIM swap). אפליקציה (Google Authenticator, Authy) או מפתח FIDO2 חזקים משמעותית.
• המנהלים והחשבונות הרגישים ראשונים. חשבון ה-root של ספק הענן, בעל ה-GitHub org, חשבון ה-billing — אלה החשבונות שפריצה אליהם הורסת הכול. עליהם MFA הוא לא אופציה.

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

סודות מחוץ לקוד: הקלאסיקה של ה-API key שדלף ל-GitHub

זו כנראה הדליפה הנפוצה והמביכה ביותר בעולם הסטארטאפים: מפתח גישה, סיסמת מסד נתונים או token של שירות, שנכתב ישירות בקוד ונדחף ל-repo. לפי דוח State of Secrets Sprawl 2026 של GitGuardian, במהלך 2025 זוהו כ-29 מיליון סודות חדשים (hardcoded secrets) שנוספו ל-commits פומביים ב-GitHub — עלייה של 34% לעומת השנה הקודמת, הקפיצה השנתית הגדולה שנמדדה, בין היתר בגלל קוד שנכתב בעזרת AI. הבוטים של התוקפים סורקים commits חדשים תוך דקות. גם אם ה-repo פרטי היום — הוא עלול להיפתח מחר, וההיסטוריה נשארת.

• כלום לא בקוד. כל סוד — מפתח, סיסמה, token, connection string — עובר ל-environment variables או ל-secret manager (AWS Secrets Manager, GCP Secret Manager, או לכל הפחות קובץ ‎.env‎ שנמצא ב-‎.gitignore‎).
• ‎.gitignore‎ מהשורה הראשונה. ודאו ש-‎.env‎ ותיקיות credentials מוחרגים לפני ה-commit הראשון, לא אחריו.
• סריקת secrets אוטומטית. GitHub Secret Scanning מובנה וחינמי ל-repos פומביים, ואפשר להפעיל push protection שחוסמת דחיפת סוד עוד לפני שהוא נכנס. כלים כמו gitleaks רצים גם ב-CI.
• מפתח שדלף — מבטלים, לא מוחקים. ברגע שסוד נחשף, הנחת העבודה היא שהוא כבר בידי מישהו. ‎git revert‎ לא מספיק — צריך לבטל (rotate) את המפתח אצל הספק. מחיקת ה-commit לבדה משאירה אותו בהיסטוריה ובמראות.

משמעת גישה לייצור: מי בכלל יכול לגעת ב-Production

ב-Pre-Seed קל מאוד שכולם יהיו אדמין על הכול — זה פשוט מהיר יותר. אבל ״כולם אדמין״ הוא בדיוק מה שהופך טעות אחת של אדם אחד (או פריצה לחשבון אחד) לאירוע ברמת החברה. עקרון ה-Least Privilege לא דורש מערכת הרשאות מורכבת גם בארבעה אנשים — הוא דורש רק להחליט מי צריך מה:

• רשימה קצרה של מי ניגש לייצור. מי יכול להתחבר לסביבת ה-production, למסד הנתונים של המשתמשים, לחשבון הענן? ככל שהרשימה קצרה יותר, כך משטח התקיפה קטן יותר. מפתח שעובד רק על ה-frontend לא צריך גישת כתיבה ל-DB של הלקוחות.
• הפרדת סביבות. production, staging ו-dev מופרדים — עם credentials שונים. טעות ב-dev לא אמורה לגעת בדאטה אמיתי של לקוחות.
• חשבונות אישיים, לא משותפים. אף פעם לא ‎admin@‎ אחד שכולם משתמשים בו. כשמישהו עוזב או כשמשהו משתבש, צריך לדעת מי עשה מה — ולנתק אדם בודד בלי לשבור את כולם.
• Root מנוהל בזהירות. חשבון ה-root של ספק הענן ננעל עם MFA, לא בשימוש יומיומי, ומופרד מחשבונות העבודה הרגילים.

המחשבים: הגנה שלוקחת חמש דקות למחשב

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

• הצפנת דיסק דלוקה. FileVault ב-Mac, BitLocker ב-Windows. בלי זה, מי שמחזיק את המחשב מחזיק את כל מה שעליו.
• נעילת מסך אוטומטית. נעילה אחרי דקות ספורות של חוסר פעילות, עם סיסמה/ביומטריה. ברירת מחדל שרוב האנשים לא טרחו להדליק.
• Find My / איתור מכשיר. מאפשר לאתר ולמחוק מרחוק מחשב אבוד או גנוב.
• עדכונים אוטומטיים. מערכת הפעלה ודפדפן מתעדכנים לבד. רוב הפריצות מנצלות פגיעות ישנה שכבר יש לה תיקון.

שאלת מידע הלקוחות — כבר עכשיו, לא ״אחר כך״

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

1. לאסוף פחות. כל שדה מידע שאתם אוספים הוא שדה שצריך להגן עליו, לתעד ולהסביר בבדיקת נאותות. אל תבקשו תעודת זהות, תאריך לידה או מיקום אם המוצר לא באמת צריך אותם. מידע שלא אספתם הוא מידע שאי אפשר לדלוף ואי אפשר לשאול עליו.
2. לדעת איפה הוא נמצא. מיפוי מסד נתונים של פסקה אחת: איזה מידע אישי אתם מחזיקים, באיזה טבלה/שירות הוא יושב, ומי ניגש אליו. זה לא מסמך של עשרים עמודים — זה טבלה קצרה שכל פאונדר צריך להיות מסוגל לשלוף. זו גם בדיוק התשובה לשאלת ה-DD ״איפה נשמר מידע הלקוחות״.

שליטה בבלגן הכלים: בעיית 30 ה-SaaS של ה-Seed

סטארטאפ צעיר צובר כלי SaaS במהירות מסחררת: ניסיתם Analytics אחד, עברתם לשני; חיברתם בוט לסלאק; נתתם ל-Notion גישה ל-Drive; רשמתם את הצוות לחמישה כלי AI שונים בשבוע. כל אחד מהם קיבל הרשאות, אולי גישה למידע, ולעיתים token שנשאר חי הרבה אחרי שהפסקתם להשתמש בכלי. זה משטח תקיפה שמתרחב בשקט.

• רשימת כלים חיה. מסמך אחד שמפרט אילו שירותי SaaS פעילים, מי הבעלים, ואיזו גישה יש להם. גם רשימה ב-Sheets עדיפה על ״אף אחד לא זוכר״.
• Offboarding של כלים שניסיתם. כלי שנפסל אחרי פיילוט — נכנסים ומבטלים לו את הגישה ומוחקים את החשבון, לא רק ״מפסיקים להיכנס״. token שנשכח דולף כמו כל סוד אחר.
• להעדיף חיבור דרך ה-SSO הארגוני. כלי שמתחבר דרך Google Workspace מתנתק אוטומטית כשעובד עוזב — במקום עוד סיסמה יתומה שנשארת פעילה.

היגיינת קוד פתוח ו-AI: פסקה אחת שחוסכת אירוע

רוב הקוד שלכם הוא לא שלכם — הוא dependencies מ-npm/PyPI, ולעיתים גם קוד שנכתב על ידי כלי AI. שני אלה מכניסים סיכון שקל לפספס: dependency confusion — תוקף שמפרסם חבילה זדונית בשם דומה לחבילה פנימית שלכם, בתקווה שה-build ימשוך אותה; וקוד שנוצר על ידי AI שעלול להכיל פגיעות, סוד מוטמע או תלות לא בטוחה שאף אחד לא בדק. הבסיס: נעלו גרסאות dependencies (lockfile), הפעילו סריקת חבילות (Dependabot חינמי ב-GitHub), ואל תמזגו קוד שנוצר ב-AI בלי שאדם קרא אותו — במיוחד קוד שנוגע ב-auth, בתשלומים או במידע אישי. הרחבנו על שימוש בטוח בכלי AI במאמר ChatGPT בעסק: איך נהנים מ-AI בלי להדליף מידע.

מה לדלג עליו בכוונה — נגד over-engineering

אבטחה מוקדמת מדי מבזבזת את המשאב היחיד שאין לכם: זמן. חלק מהמלצות האבטחה שתשמעו נכונות — אבל לא עכשיו. הנה מה שסטארטאפ Pre-Seed צריך לדחות במודע, ומתי כל אחד הופך רלוונטי:

ה-One-Pager של מוכנות ל-DD: 12 השאלות שתישאלו

לכל השלבים למעלה יש מכנה משותף אחד: הם הופכים 12 שאלות שתישאלו בבדיקת נאותות מ״לא נעים״ ל״כן, הנה״. לענות ״כן״ עליהן היום עולה אחר צהריים; לענות עליהן באמצע עסקה עולה שבועות ולפעמים אמון. זה ה-One-Pager שכדאי שיהיה מוכן במגירה:

1. האם MFA נאכף על כל החשבונות (Workspace, GitHub, ענן)?
2. האם יש הפרדה בין production, staging ו-dev?
3. מי ניגש לסביבת הייצור ולמסד הנתונים של הלקוחות?
4. האם כל הסודות מחוץ לקוד (env vars / secret manager)?
5. האם מופעלת סריקת secrets על ה-repos?
6. איזה מידע אישי אתם אוספים על משתמשים?
7. איפה המידע נשמר, והאם הוא מוצפן (at rest ו-in transit)?
8. האם הצוות משתמש בחשבונות אישיים, לא משותפים?
9. האם הצפנת דיסק דלוקה על כל המחשבים?
10. האם יש רשימה של כלי ה-SaaS ומי ניגש למה?
11. איך מנוהלות הרשאות כשעובד מצטרף ועוזב?
12. מי הכתובת שאחראית על אבטחה בחברה?

צ׳קליסט לביצוע השבוע

• אכיפת MFA ברמת הארגון ב-Google Workspace/Microsoft 365 וב-GitHub Organization — לא המלצה, אכיפה.
• נעילת חשבונות ה-root/admin של הענן וה-billing עם MFA, מופרדים מהשימוש היומיומי.
• סריקה מהירה של ה-repos אחרי secrets שדלפו — הפעילו GitHub Secret Scanning + push protection; מפתח שנמצא, בטלו אותו.
• הוצאת כל הסודות מהקוד ל-env vars/secret manager, עם ‎.env‎ ב-‎.gitignore‎.
• רשימת ״מי ניגש לייצור״ קצרה ומעודכנת; החלפת ‎admin@‎ משותף בחשבונות אישיים.
• הדלקת הצפנת דיסק (FileVault/BitLocker), נעילת מסך ו-Find My על כל מחשב.
• מיפוי מידע של פסקה אחת — סוג המידע, איפה, מי ניגש, כמה זמן, האם מוצפן.
• ניקוי כלי SaaS — רשימה חיה, וביטול גישה לכלים שכבר לא בשימוש.
• הפעלת Dependabot וסריקת dependencies; כלל צוות: קוד AI לא ממוזג בלי code review.
• דחייה מודעת של ISO/SOC 2/SIEM/Pen-Test — סמנו מתי כל אחד יהפוך רלוונטי.

השורה התחתונה

בשלב Pre-Seed אבטחה היא לא פרויקט ולא הוצאה — היא כמה הגדרות שכבר קיימות בכלים שלכם, ושתי דקות של חשיבה על מי ניגש למה. הרצפה הזו לא תהפוך אתכם למבצר, וזו גם לא המטרה. המטרה צנועה ומדויקת: שכשיגיע רגע בדיקת הנאותות — ותמיד מגיע — תוכלו לענות ״כן, הנה״ במקום ״תנו לנו שבועיים לבדוק״. אבטחה מוקדמת נכונה היא לא זו שעושה הכי הרבה; היא זו שעושה את הדברים הנכונים בזול, ודוחה במודע את השאר עד שיהיו רלוונטיים. תעשו את אחר הצהריים הזה עכשיו — הוא הכי זול שהוא אי פעם יהיה.

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