לא כל באג נכנס לטופס: אירופה נותנת ליצרני IoT ‏24 שעות לדווח על פרצה פעילה

זה נשמע בהתחלה כאילו כל יצרן של חיישן Wi-Fi יצטרך לשלוח טופס לבריסל בכל פעם שמתכנת מוצא באג. זו אינה הדרישה. ה־Cyber Resilience Act, או בקיצור CRA, מפריד בין תקלה רגילה, חולשת אבטחה, חולשה שמישהו כבר מנצל ואירוע שפגע בפועל באבטחת המוצר. רק שני המקרים האחרונים מפעילים את מנגנון הדיווח המהיר.

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

זו תקנה, לא עוד תקן שאפשר לבחור אם לאמץ. ה־CRA אינו תקן טכני כמו מסמך IEC או ETSI. זו תקנה אירופית מחייבת שחלה על "מוצרים עם רכיבים דיגיטליים" המוצעים בשוק האירופי. ההגדרה כוללת מוצרי חומרה ותוכנה שהשימוש המיועד או הסביר שלהם כולל חיבור ישיר או עקיף למכשיר אחר או לרשת.

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

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

לכן השאלה הראשונה של יצרן אינה "איזה כלי SBOM לקנות?", אלא "איזה חלק מהמוצר ומהשירות שלי נמצא בכלל בתחום התקנה?". במוצר שמורכב מחיישן, אפליקציה ושירות ענן, התשובה יכולה להיות שונה לכל שכבה.

יש שני תאריכים, ולא כדאי לערבב ביניהם. רוב דרישות ה־CRA יחולו במלואן החל מ־11 בדצמבר 2027. אלה כוללות הערכת סיכוני סייבר, דרישות תכנון, תיעוד טכני, טיפול בחולשות, הצהרת תאימות וסימון CE שמכסה גם את דרישות הסייבר.

אבל חובת הדיווח מקדימה אותן. סעיף 14 יתחיל לחול כבר ב־11 בספטמבר 2026. משמעות הדבר היא שארגון שדוחה את כל ההכנות לסוף 2027 עלול לגלות ששנה קודם לכן הוא כבר צריך לזהות אירוע ולשלוח דיווח בתוך שעות.

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

לא כל CVE הוא שעון שסופר לאחור. המונח החשוב ביותר הוא "חולשה שמנוצלת באופן פעיל". לפי ה־CRA, נדרשות ראיות אמינות לכך שגורם זדוני ניצל את החולשה במערכת ללא רשות בעליה.

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

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

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

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

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

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

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

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

הדיווחים יוגשו דרך Single Reporting Platform, או SRP, שמקימה ENISA. היצרן יגיש את המידע פעם אחת, והמערכת תעביר אותו ל־ENISA ולצוות תגובת הסייבר הלאומי, CSIRT, המתאים למיקום החברה או לנציג המורשה שלה באיחוד. משם ניתן יהיה להפיץ את הדיווח למדינות אירופיות נוספות שבהן המוצר מוצע.

לפי ה־FAQ שפרסמה ENISA ב־17 ביולי 2026, הכניסה למערכת תתבצע באמצעות חשבון EU Login. אימות הסמכות של אדם לדווח בשם יצרן מסוים יבוצע בידי ה־CSIRT המתאם, לאחר הכניסה הראשונה ובמקביל לתהליך הדיווח.

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

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

ENISA פרסמה מכרז להקמה ולהפעלה של ה־SRP בתקציב מרבי של 11 מיליון אירו לארבע שנים. פורטל הרכש של האיחוד מציג בין הגופים שנבחרו את UniSystems Luxembourg, ‏Wavestone, ‏Luxembourg House of Cybersecurity, ‏European Dynamics ו־Netcompany.

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

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

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

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

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

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

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

אחד הכלים המרכזיים הוא Software Bill of Materials, או SBOM: רשימה קריאה למחשב של רכיבי התוכנה והתלויות שנמצאים במוצר. אפשר לחשוב עליה כרשימת החומרים של הקושחה.

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

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

גם כאן, יצירת קובץ SPDX או CycloneDX היא רק ההתחלה. אם מערכת הבנייה אינה יודעת לקשר בין ה־SBOM לבין גרסת הקושחה שנצרבה ביחידה מסוימת, הרשימה לא תענה על השאלה החשובה בזמן אירוע: אילו לקוחות מחזיקים מוצר פגיע?

רוב קושחות ה־IoT אינן נכתבות מאפס. הן מכילות מערכת הפעלה, מחסנית תקשורת, ספריות הצפנה, SDK של יצרן השבב ולעיתים קוד של כמה קבלני משנה.

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

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

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

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

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

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

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

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

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

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

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

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

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