מורא און לאָאַטהינג פון DevSecOps

מיר האָבן 2 קאָד אַנאַליזערז, 4 דינאַמיש טעסטינג מכשירים, אונדזער אייגענע קראַפס און 250 סקריפּס. עס איז נישט אַז אַלע דעם איז דארף אין דעם קראַנט פּראָצעס, אָבער אַמאָל איר אָנהייבן ימפּלאַמענינג DevSecOps, איר האָבן צו גיין צו די סוף.

מאָקער. כאַראַקטער קריייטערז: דזשאַסטין ראָילאַנד און דן האַרמאָן.

וואָס איז SecDevOps? וואָס וועגן DevSecOps? וואָס זענען די דיפעראַנסיז? אַפּפּליקאַטיאָן זיכערהייַט - וואָס איז עס וועגן? פארוואס טוט נישט דער קלאַסיש צוגאַנג אַרבעט ענימאָר? ווייסט די ענטפער צו אַלע די שאלות יורי שאבאלין פון סוואָרדפיש זיכערהייַט. יורי וועט ענטפֿערן אַלץ אין דעטאַל און אַנאַלייז די פראבלעמען פון יבערגאַנג פון די קלאַסיש אַפּפּליקאַטיאָן זיכערהייט מאָדעל צו די DevSecOps פּראָצעס: ווי צו רעכט צוגאַנג די ינטאַגריישאַן פון די זיכער אַנטוויקלונג פּראָצעס אין די DevOps פּראָצעס און נישט ברעכן עפּעס, ווי צו גיין דורך די הויפּט סטאַגעס פון זיכערהייט טעסטינג, וואָס מכשירים קענען זיין געוויינט, און וואָס זיי אַנדערש און ווי צו קאַנפיגיער זיי ריכטיק צו ויסמיידן פּיטפאָלז.

וועגן דעם רעדנער: יורי שאבאלין - הויפּט זיכערהייַט אַרטשיטעקט אין די פירמע סוואָרדפיש זיכערהייַט. פאַראַנטוואָרטלעך פֿאַר די ימפּלאַמענטיישאַן פון SSDL, פֿאַר די קוילעלדיק ינאַגריישאַן פון אַפּלאַקיישאַן אַנאַליסיס מכשירים אין אַ יונאַפייד אַנטוויקלונג און טעסטינג יקאָוסיסטאַם. 7 יאָר דערפאַרונג אין אינפֿאָרמאַציע זיכערהייט. געארבעט אין Alfa-Bank, Sberbank און Positive Technologies, וואָס דעוועלאָפּס ווייכווארג און גיט באַדינונגס. רעדנער ביי אינטערנאַציאָנאַלע קאַנפראַנסאַז ZerONights, PhDays, RISSPA, OWASP.

אַפּפּליקאַטיאָן זיכערהייַט: וואָס איז עס וועגן?

אַפּפּליקאַטיאָן זיכערהייַט - דאָס איז די זיכערהייט אָפּטיילונג וואָס איז פאַראַנטוואָרטלעך פֿאַר אַפּלאַקיישאַן זיכערהייט. דאָס איז נישט אַפּלייז צו ינפראַסטראַקטשער אָדער נעץ זיכערהייט, אָבער צו וואָס מיר שרייַבן און וואָס דעוועלאָפּערס אַרבעט אויף - דאָס זענען די שאָרטקאָמינגס און וואַלנעראַביליטיז פון די אַפּלאַקיישאַן זיך.

ריכטונג SDL אָדער SDLC - זיכערהייט אַנטוויקלונג לעבן ציקל - דעוועלאָפּעד דורך מייקראָסאָפֿט. די דיאַגראַמע ווייזט די קאַנאַנאַקאַל SDLC מאָדעל, די הויפּט אַרבעט פון וואָס איז די אָנטייל פון זיכערהייט אין יעדער בינע פון ​​אַנטוויקלונג, פֿון רעקווירעמענץ צו מעלדונג און פּראָדוקציע. מייקראָסאָפֿט האָט איינגעזען אַז עס זענען געווען צו פילע באַגז אין די ינדאַסטרי, עס זענען מער פון זיי און עפּעס האט צו זיין געטאן וועגן דעם, און זיי פארגעלייגט דעם צוגאַנג, וואָס איז געווארן קאַנאָניקאַל.

אַפּפּליקאַטיאָן סעקוריטי און SSDL זענען נישט אַימעד צו דיטעקטינג וואַלנעראַביליטיז, ווי איז קאַמאַנלי געגלויבט, אָבער צו פּרעווענטינג זייער פּאַסירונג. מיט דער צייט, מייקראָסאָפֿט ס קאַנאַנאַקאַל צוגאַנג איז ימפּרוווד, דעוועלאָפּעד און ינטראָודוסט אין אַ דיפּער, מער דיטיילד ונטערטוקנ זיך.

די קאַנאַנאַקאַל SDLC איז העכסט דיטיילד אין פאַרשידן מעטאַדאַלאַדזשיז - OpenSAMM, BSIMM, OWASP. די מעטאַדאַלאַדזשיז זענען אַנדערש, אָבער בכלל ענלעך.

בנין זיכערהייט אין צייַטיקייַט מאָדעל

איך ווי עס רובֿ BSIMM - בנין זיכערהייט אין צייַטיקייַט מאָדעל. די יקער פון די מעטאַדאַלאַדזשי איז די אָפּטייל פון די אַפּפּליקאַטיאָן סעקוריטי פּראָצעס אין 4 דאָומיינז: גאַווערנאַנס, ינטעלליגענסע, SSDL טאָוטשפּאָינץ און דיפּלוימאַנט. יעדער פעלד האט 12 פּראַקטיסיז, וואָס זענען רעפּריזענטיד ווי 112 אַקטיוויטעטן.

יעדער פון די 112 אַקטיוויטעטן האט 3 לעוועלס פון צייַטיקייַט: אָנהייבער, ינטערמידייט און אַוואַנסירטע. איר קענען לערנען אַלע 12 פּראַקטיסיז אָפּטיילונג דורך אָפּטיילונג, אויסקלייַבן זאכן וואָס זענען וויכטיק פֿאַר איר, געפֿינען אויס ווי צו ינסטרומענט זיי און ביסלעכווייַז לייגן עלעמענטן, למשל, סטאַטיק און דינאַמיש קאָד אַנאַליסיס אָדער קאָד אָפּשאַצונג. איר שרייַבן אַראָפּ אַ פּלאַן און רויק אַרבעט לויט אים ווי אַ טייל פון די ימפּלאַמענטיישאַן פון די אויסגעקליבן אַקטיוויטעטן.

פארוואס DevSecOps

DevOps איז אַ גענעראַל, גרויס פּראָצעס אין וואָס זיכערהייט מוזן זיין גענומען אין חשבון.

אָריגינאַללי DevOps ינוואַלווד זיכערהייַט טשעקס. אין פיר, די נומער פון זיכערהייט טימז איז געווען פיל קלענערער ווי איצט, און זיי אַקטאַד נישט ווי פּאַרטיסאַפּאַנץ אין דעם פּראָצעס, אָבער ווי אַ קאָנטראָל און סופּערווייזערי גוף וואָס ימפּאָוזאַז רעקווירעמענץ און קאָנטראָלירן די קוואַליטעט פון די פּראָדוקט אין די סוף פון די מעלדונג. דאָס איז אַ קלאַסיש צוגאַנג אין וואָס זיכערהייט טימז זענען געווען הינטער די וואַנט פון אַנטוויקלונג און האָבן נישט אָנטייל נעמען אין דעם פּראָצעס.

דער הויפּט פּראָבלעם איז אַז אינפֿאָרמאַציע זיכערהייט איז באַזונדער פון אַנטוויקלונג. יוזשאַוואַלי דאָס איז אַ סאָרט פון אינפֿאָרמאַציע זיכערהייט קרייַז און עס כּולל 2-3 גרויס און טייַער מכשירים. אַמאָל יעדער זעקס חדשים קומט דער מקור קאָד אָדער אַפּלאַקיישאַן וואָס דאַרף זיין אָפּגעשטעלט, און אַמאָל אַ יאָר זיי זענען געשאפן פּענטעסטן. אַלע דעם פירט צו דעם פאַקט אַז די מעלדונג טאָג פֿאַר די אינדוסטריע איז דילייד, און די דעוועלאָפּער איז יקספּאָוזד צו אַ ריזיק נומער פון וואַלנעראַביליטיז פון אָטאַמייטיד מכשירים. עס איז אוממעגלעך צו דיסאַסעמבאַל און פאַרריכטן אַלע דעם, ווייַל די רעזולטאַטן פֿאַר די פריערדיקע זעקס חדשים זענען נישט אויסגעשטעלט, אָבער דאָ איז אַ נייַע פּעקל.

אין די לויף פון אונדזער פירמע 'ס אַרבעט, מיר זען אַז זיכערהייט אין אַלע געביטן און ינדאַסטריז פארשטייט אַז עס איז צייט צו כאַפּן זיך און ומדריי מיט אַנטוויקלונג אויף די זעלבע ראָד - אין פלינק. די DevSecOps פּאַראַדיגם פיץ בישליימעס מיט די פלינק אַנטוויקלונג מעטאַדאַלאַדזשי, ימפּלאַמענטיישאַן, שטיצן און אָנטייל אין יעדער מעלדונג און יטעריישאַן.

יבערגאַנג צו DevSecOps

די מערסט וויכטיק וואָרט אין די זיכערהייט אנטוויקלונג ליפעסיקלע איז "פּראָצעס". איר מוזן פֿאַרשטיין דעם איידער איר טראַכטן וועגן בייינג מכשירים.

סימפּלי ינקאָרפּערייטינג מכשירים אין די DevOps פּראָצעס איז נישט גענוג - קאָמוניקאַציע און פארשטאנד צווישן פּראָצעס פּאַרטיסאַפּאַנץ איז וויכטיק.

מענטשן זענען מער וויכטיק, נישט מכשירים.

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

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

ערשטער, באַשרייַבן וואָס אַוטקאַם איר ווילן און ווי דער פּראָצעס וועט קוקן ווי. דאָס וועט העלפֿן פֿאַרשטיין די ראָלעס פון מכשירים און זיכערקייַט אין דעם פּראָצעס.

אָנהייבן מיט וואָס איז שוין אין נוצן

איידער איר קויפן טייַער מכשירים, קוק אין וואָס איר האָט שוין. יעדער פירמע האט זיכערהייט רעקווירעמענץ פֿאַר אַנטוויקלונג, עס זענען טשעקס, פּענטעסטן - וואָס טאָן ניט יבערמאַכן אַלע דעם אין אַ פאָרעם וואָס איז פאַרשטיייק און באַקוועם פֿאַר אַלעמען?

געווענליך זענען די פארלאנגען א פאפירענער תלמוד וואס ליגט אויף א פאליצע. עס איז געווען אַ פאַל ווען מיר געקומען צו אַ פירמע צו קוקן אין די פּראַסעסאַז און געבעטן צו זען די זיכערהייט רעקווירעמענץ פֿאַר די ווייכווארג. דער מומכע וואס האט זיך מיט דעם פארבראכט האט א לאנגע צייט געזוכט:

- איצט, ערגעץ אין די הערות איז געווען אַ וועג ווו דאָס דאָקומענט ליגט.

ווי אַ רעזולטאַט, מיר באקומען דעם דאָקומענט אַ וואָך שפּעטער.

פֿאַר רעקווירעמענץ, טשעקס און אנדערע זאכן, שאַפֿן אַ בלאַט אויף למשל. קאַנפלואַנס - עס איז באַקוועם פֿאַר אַלעמען.

עס איז גרינגער צו ריפאָרמאַט וואָס איר שוין האָבן און נוצן עס צו אָנהייבן.

ניצן זיכערהייט טשאַמפּיאָנס

טיפּיקאַללי, אין אַ דורכשניטלעך פירמע מיט 100-200 דעוועלאָפּערס, עס איז איין זיכערהייט מומכע וואָס פּערפאָרמז עטלעכע פאַנגקשאַנז און טוט נישט פיזיקלי האָבן צייט צו קאָנטראָלירן אַלץ. אפילו אויב ער פרוווט זיין בעסטער, ער אַליין וועט נישט קאָנטראָלירן אַלע די קאָד וואָס די אַנטוויקלונג דזשענערייץ. פֿאַר אַזאַ קאַסעס, אַ באַגריף איז דעוועלאָפּעד - זיכערהייט טשאַמפּיאָנס.

זיכערהייט טשאַמפּיאָנס זענען מענטשן אין די אַנטוויקלונג מאַנשאַפֿט וואָס זענען אינטערעסירט אין די זיכערהייט פון דיין פּראָדוקט.

זיכערהייט טשאַמפּיאָן איז אַ פּאָזיציע פונט אין די אַנטוויקלונג מאַנשאַפֿט און אַ זיכערהייט מבשר ראָולד אין איין.

יוזשאַוואַלי, ווען אַ זיכערהייט מומכע קומט צו אַ אַנטוויקלונג מאַנשאַפֿט און ווייזט אַ טעות אין די קאָד, ער באקומט אַ סאַפּרייזד ענטפער:

― און װער ביסטו? איך זע דיר צום ערשטן מאָל. אַלץ איז גוט מיט מיר - מיין עלטער פרייַנד האט מיר "צולייגן" אויף די קאָד רעצענזיע, מיר מאַך אויף!

דאָס איז אַ טיפּיש סיטואַציע, ווייַל עס איז פיל מער צוטרוי אין סיניערז אָדער פשוט טיממייץ מיט וועמען די דעוועלאָפּער קעסיידער ינטעראַקץ אין אַרבעט און אין קאָד אָפּשאַצונג. אויב, אַנשטאָט פון די זיכערהייט אָפיציר, דער זיכערהייט טשאַמפּיאָן ווייזט די גרייַז און קאַנסאַקווענסאַז, זיין וואָרט וועט האָבן מער וואָג.

אויך, דעוועלאָפּערס וויסן זייער קאָד בעסער ווי קיין זיכערהייט מומכע. פֿאַר אַ מענטש וואס האט בייַ מינדסטער 5 פּראַדזשעקס אין אַ סטאַטיק אַנאַליסיס געצייַג, עס איז יוזשאַוואַלי שווער צו געדענקען אַלע די נואַנסיז. זיכערהייט טשאַמפּיאָנס וויסן זייער פּראָדוקט: וואָס ינטעראַקץ מיט וואָס און וואָס צו קוקן אין ערשטער - זיי זענען מער עפעקטיוו.

אַזוי באַטראַכטן ימפּלאַמענינג זיכערהייט טשאַמפּיאָנס און יקספּאַנדינג די השפּעה פון דיין זיכערהייט מאַנשאַפֿט. דאָס איז אויך נוציק פֿאַר דער מייַסטער זיך: פאַכמאַן אַנטוויקלונג אין אַ נייַ פעלד, יקספּאַנדינג זיין טעכניש כערייזאַנז, אַפּגריידינג טעכניש, מאַנידזשיריאַל און פירערשאַפט סקילז, ינקריסינג מאַרק ווערט. דאָס איז עטלעכע עלעמענט פון געזעלשאַפטלעך ינזשעניעריע, דיין "אויגן" אין דער אַנטוויקלונג מאַנשאַפֿט.

טעסטינג סטאַגעס

פּאַראַדיגם 20 צו 80 זאגט אַז 20% פון מי טראגט 80% פון רעזולטאַטן. די 20% איז פּראַקטיסיז פון אַפּלאַקיישאַן אַנאַליסיס וואָס קענען און זאָל זיין אָטאַמייטיד. ביישפילן פון אַזאַ אַקטיוויטעטן זענען סטאַטיק אַנאַליסיס - SAST, דינאַמיש אַנאַליסיס - DAST и עפֿן מקור קאָנטראָל. איך וועט זאָגן איר אין מער דעטאַל וועגן די אַקטיוויטעטן, ווי געזונט ווי וועגן די מכשירים, וואָס פֿעיִקייטן מיר יוזשאַוואַלי טרעפן ווען ינטראָודוסינג זיי אין דעם פּראָצעס, און ווי צו טאָן דאָס ריכטיק.

הויפּט פּראָבלעמס פון מכשירים

איך וועל הויכפּונקט פּראָבלעמס וואָס זענען באַטייַטיק פֿאַר אַלע ינסטראַמאַנץ און דאַרפן ופמערקזאַמקייט. איך וועל אַנאַליזירן זיי אין מער דעטאַל אַזוי נישט צו איבערחזרן זיי ווייַטער.

לאנג אַנאַליסיס צייט. אויב עס נעמט 30 מינוט פֿאַר אַלע טעסץ און פֿאַרזאַמלונג פון יבערגעבן צו מעלדונג, אינפֿאָרמאַציע זיכערהייט טשעקס וועט נעמען אַ טאָג. אַזוי קיין איינער וועט פּאַמעלעך די פּראָצעס. נעמען דעם שטריך אין חשבון און מאַכן קאַנקלוזשאַנז.

הויך מדרגה פאַלש נעגאַטיוו אָדער פאַלש positive. אַלע פּראָדוקטן זענען אַנדערש, אַלע נוצן פאַרשידענע פראַמעוואָרקס און זייער אייגענע קאָדירונג סטיל. אויף פאַרשידענע קאָדעבאַסעס און טעקנאַלאַדזשיז, מכשירים קענען ווייַזן פאַרשידענע לעוועלס פון פאַלש נעגאַטיוו און פאַלש positive. אַזוי קוק אין וואָס פּונקט איז אין דיין קאָמפּאַניעס און פֿאַר דיין אַפּלאַקיישאַנז וועט ווייַזן גוט און פאַרלאָזלעך רעזולטאַטן.

קיין ינטאַגריישאַנז מיט יגזיסטינג מכשירים. קוק אין מכשירים אין טערמינען פון ינטאַגריישאַנז מיט וואָס איר שוין נוצן. פֿאַר בייַשפּיל, אויב איר האָבן Jenkins אָדער TeamCity, קאָנטראָלירן די ינטאַגריישאַן פון די מכשירים מיט דעם ווייכווארג, און נישט מיט GitLab CI, וואָס איר טאָן ניט נוצן.

פעלן אָדער יבעריק קאַמפּלעקסיטי פון קוסטאָמיזאַטיאָן. אויב אַ געצייַג טוט נישט האָבן אַ API, וואָס איז עס דארף? אַלץ וואָס קענען זיין געטאן אין די צובינד זאָל זיין בארעכטיגט דורך די API. ידעאַללי, די געצייַג זאָל האָבן די פיייקייט צו קאַסטאַמייז טשעקס.

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

פּראָצעס פֿעיִקייטן

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

אין סדר נישט צו פאַרפירן אַנטוויקלונג און מעלדונג דעדליינז, שאַפֿן פאַרשידענע כּללים און אַנדערש ווייַזן סטאַפּערז - קרייטיריאַ פֿאַר סטאָפּפּינג די בויען פּראָצעס אין דעם בייַזייַן פון וואַלנעראַביליטיז - פֿאַר פאַרשידענע ינווייראַנמאַנץ. פֿאַר בייַשפּיל, מיר פֿאַרשטיין אַז די קראַנט צווייַג גייט צו די אַנטוויקלונג שטיין אָדער UAT, וואָס מיטל אַז מיר טאָן ניט האַלטן און זאָגן:

"איר האָט וואַלנעראַביליטיז דאָ, איר וועט ניט גיין ערגעץ ווייַטער!"

אין דעם פונט, עס איז וויכטיק צו זאָגן דעוועלאָפּערס אַז עס זענען זיכערהייט ישוז וואָס דאַרפֿן ופמערקזאַמקייט.

די בייַזייַן פון וואַלנעראַביליטיז איז נישט אַ שטערונג פֿאַר ווייַטער טעסטינג: מאַנואַל, ינטאַגריישאַן אָדער מאַנואַל. אויף די אנדערע האַנט, מיר דאַרפֿן צו עפעס פאַרגרעסערן די זיכערהייט פון די פּראָדוקט, און אַזוי אַז דעוועלאָפּערס טאָן ניט פאַרלאָזן וואָס זיי געפֿינען זיכער. דעריבער, מאל מיר טאָן דאָס: ביי די שטיין, ווען עס איז ראָולד אויס צו די אַנטוויקלונג סוויווע, מיר נאָר געבנ צו וויסן די אַנטוויקלונג:

- גויס, איר האָבן פּראָבלעמס, ביטע געבן ופמערקזאַמקייַט צו זיי.

אין די UAT בינע מיר ווידער ווייַזן וואָרנינגז וועגן וואַלנעראַביליטיז, און אין די מעלדונג בינע מיר זאָגן:

— בחורים, מיר האבן אייך עטלעכע מאל געווארנט, איר האט גארנישט געטון – מיר וועלן אייך נישט ארויסלאזן מיט דעם.

אויב מיר רעדן וועגן קאָד און דינאַמיק, עס איז נייטיק צו ווייַזן און וואָרענען וועגן וואַלנעראַביליטיז בלויז פון די פֿעיִקייטן און קאָד וואָס איז פּונקט געשריבן אין דעם שטריך. אויב אַ דעוועלאָפּער באוועגט אַ קנעפּל מיט 3 בילדצעלן און מיר זאָגן אים אַז ער האט אַ סקל ינדזשעקשאַן דאָרט און דעריבער דאַרף ערדזשאַנטלי פאַרריכטן, דאָס איז פאַלש. קוק בלויז אין וואָס איז געשריבן איצט און אין די ענדערונג וואָס קומט צו די אַפּלאַקיישאַן.

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

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

זינט אַלע וואַלנעראַביליטיז זענען די זעלבע חסרונות, זיי זאָל זיין ליגן אין די זעלבע פּלאַץ ווי אַלע אַנטוויקלונג חסרונות. אַזוי פאַרגעסן וועגן ריפּאָרץ און סקערי פּדף ס וואָס קיין איינער לייענט.

ווען איך איז געווען ארבעטן אין אַ אַנטוויקלונג פירמע, איך באקומען אַ באַריכט פון סטאַטיק אַנאַליסיס מכשירים. איך האָב עס געעפֿנט, זיך דערשראָקן, געמאַכט קאַווע, געבלעטערט 350 בלעטער, פֿאַרמאַכט און ווײַטער געאַרבעט. גרויסע באריכטן זענען טויטע באריכטן. געווענליך גייען זיי ינ ערגעצ ניט, די אותיות ווערן אויסגעמעקט, פארגעסן, פארלוירן, אדער די ביזנעס זאגט אז עס נעמט אויף די ריסקס.

וואָס צו טאָן? מיר פשוט גער די באשטעטיקט חסרונות וואָס מיר געפֿונען אין אַ פאָרעם וואָס איז באַקוועם פֿאַר אַנטוויקלונג, למשל, מיר שטעלן זיי אין אַ באַקלאָג אין Jira. מיר פּרייאָראַטייז חסרונות און עלימינירן זיי אין סדר פון בילכערקייַט, צוזאַמען מיט פאַנגקשאַנאַל חסרונות און פּרובירן חסרונות.

סטאַטיק אַנאַליסיס - SAST

דאָס איז אַ קאָד אַנאַליסיס פֿאַר וואַלנעראַביליטיז., אָבער דאָס איז נישט די זעלבע ווי SonarQube. מיר טאָן ניט נאָר טשעק פֿאַר פּאַטערנז אָדער סטיל. א נומער פון אַפּראָוטשיז זענען געניצט אין די אַנאַליסיס: לויט די וואַלנעראַביליטי בוים, לויט צו DataFlow, דורך אַנאַלייזינג קאַנפיגיעריישאַן טעקעס. דאָס איז אַלע וואָס קאַנסערנז די קאָד זיך.

פּראָס פון דעם צוגאַנג: ידענטיפיצירן וואַלנעראַביליטיז אין קאָד אין אַ פרי בינע פון ​​אַנטוויקלונגווען עס זענען נאָך קיין סטאַנדז אָדער פאַרטיק מכשירים, און ינקראַמענטאַל סקאַנינג פיייקייַט: סקאַנינג אַ אָפּטיילונג פון קאָד וואָס איז פארענדערט, און בלויז די שטריך וואָס מיר איצט טאָן, וואָס ראַדוסאַז סקאַנינג צייט.

קאָנס - דאָס איז דער מאַנגל פון שטיצן פֿאַר די נייטיק שפּראַכן.

נויטיק אינטעגראציעס, וואָס זאָל זיין אין די מכשירים, אין מיין סאַבדזשעקטיוו מיינונג:

• ינטעגראַטיאָן געצייַג: Jenkins, TeamCity און Gitlab CI.
• אַנטוויקלונג סוויווע: Intellij IDEA, Visual Studio. עס איז מער באַקוועם פֿאַר אַ דעוועלאָפּער נישט צו נאַוויגירן אַ ינגקאַמפּראַכענסיבאַל צובינד וואָס נאָך דאַרף זיין מעמערייזד, אָבער צו זען אַלע די נויטיק ינטאַגריישאַנז און וואַלנעראַביליטיז וואָס ער האָט געפֿונען רעכט אויף די ווערקפּלייס אין זיין אייגענע אַנטוויקלונג סוויווע.
• קאָד רעצענזיע: SonarQube און מאַנואַל רעצענזיע.
• דעפעקט טראַקערז: Jira און Bugzilla.

די בילד ווייזט עטלעכע פון ​​די בעסטער פארשטייערס פון סטאַטיק אַנאַליסיס.

עס זענען נישט די מכשירים וואָס זענען וויכטיק, אָבער דער פּראָצעס, אַזוי עס זענען עפֿן מקור סאַלושאַנז וואָס זענען אויך גוט פֿאַר טעסטינג דעם פּראָצעס.

SAST עפֿן מקור וועט נישט געפֿינען אַ ריזיק נומער פון וואַלנעראַביליטיז אָדער קאָמפּלעקס דאַטאַפלאָווס, אָבער זיי קענען און זאָל זיין געוויינט ווען איר בויען אַ פּראָצעס. זיי העלפֿן צו פֿאַרשטיין ווי דער פּראָצעס וועט זיין געבויט, ווער וועט ריספּאַנד צו באַגז, ווער וועט באַריכט און ווער וועט באַריכט. אויב איר ווילן צו דורכפירן די ערשט בינע פון ​​בויען די זיכערהייט פון דיין קאָד, נוצן Open Source סאַלושאַנז.

ווי קען דאָס זיין ינאַגרייטיד אויב איר זענט אין די אָנהייב פון דיין נסיעה און האָבן גאָרנישט: קיין סי, קיין Jenkins, קיין TeamCity? זאל ס באַטראַכטן ינאַגריישאַן אין דעם פּראָצעס.

ינאַגריישאַן פון CVS מדרגה

אויב איר האָט Bitbucket אָדער GitLab, איר קענען ויסשטימען אויף דער מדרגה קאַנקעראַנט ווערסיעס סיסטעם.

דורך געשעעניש - ציען בעטן, טוען. איר יבערקוקן די קאָד און די בויען סטאַטוס ווייזט צי די זיכערהייט טשעק דורכגעגאנגען אָדער ניט אַנדערש.

באַמערקונגען. פון קורס, באַמערקונגען איז שטענדיק דארף. אויב איר נאָר מאַכן זיכערהייט אויף די זייַט, שטעלן עס אין אַ קעסטל און טאָן ניט זאָגן ווער עס יז וועגן אים, און אין די סוף פון די חודש דאַמפּט אַ בינטל פון באַגז - דאָס איז נישט ריכטיק און נישט גוט.

ינאַגריישאַן מיט די קאָד אָפּשאַצונג סיסטעם

אַמאָל, מיר אַקטאַד ווי די פעליקייַט ריוויוער פֿאַר אַ טעכניש אַפּפּסעק באַניצער אין אַ נומער פון וויכטיק פּראַדזשעקס. דעפּענדינג אויף צי ערראָרס זענען יידענאַפייד אין די נייַע קאָד אָדער עס זענען קיין ערראָרס, דער ריוויוער באַשטעטיקט די סטאַטוס אויף די ציען בעטן צו "אָננעמען" אָדער "דאַרפֿן אַרבעט" - אָדער אַלץ איז גוט, אָדער די לינקס צו וואָס פּונקט דאַרפֿן צו זיין ימפּרוווד דאַרפֿן צו זיין ימפּרוווד. פֿאַר ינאַגריישאַן מיט די ווערסיע וואָס איז געגאנגען אין פּראָדוקציע, מיר האָבן ענייבאַלד אַ צונויפגיסן פאַרווער אויב די אינפֿאָרמאַציע זיכערהייט פּראָבע איז נישט דורכגעגאנגען. מיר אַרייַנגערעכנט דעם אין די מאַנואַל קאָד רעצענזיע, און אנדערע פּאַרטיסאַפּאַנץ אין דעם פּראָצעס געזען די זיכערהייט סטאַטוסעס פֿאַר דעם באַזונדער פּראָצעס.

ינטעגראַטיאָן מיט SonarQube

פילע האָבן קוואַליטעט טויער אין טערמינען פון קאָד קוואַליטעט. דאָס איז די זעלבע דאָ - איר קענען מאַכן די זעלבע טויערן בלויז פֿאַר SAST מכשירים. עס וועט זיין דער זעלביקער צובינד, דער זעלביקער קוואַליטעט טויער, נאָר עס וועט זיין גערופן זיכערהייַט טויער. און אויך, אויב איר האָבן אַ פּראָצעס ניצן SonarQube, איר קענען לייכט ויסשטימען אַלץ דאָרט.

ינטעגראַטיאָן אויף די סי מדרגה

אַלץ דאָ איז אויך גאַנץ פּשוט:

• אין פּאַר מיט אַוטאָטעסטס, אַפּאַראַט טעסץ.
• אָפּטייל דורך אַנטוויקלונג סטאַגעס: דעוו, פּרובירן, פּראָד. פאַרשידענע סעט פון כּללים אָדער פאַרשידענע דורכפאַל טנאָים קען זיין אַרייַנגערעכנט: האַלטן די פֿאַרזאַמלונג, טאָן ניט האַלטן די פֿאַרזאַמלונג.
• סינטשראָנאָוס / אַסינטשראָנאָוס קאַטער. מיר ווארטן פֿאַר די סוף פון די זיכערהייט טעסץ אָדער נישט. אַז איז, מיר נאָר לאָנטשט זיי און מאַך אויף, און דעמאָלט מיר באַקומען די סטאַטוס אַז אַלץ איז גוט אָדער שלעכט.

עס ס אַלע אין אַ גאנץ ראָזעווע וועלט. עס איז ניט אַזאַ זאַך אין פאַקטיש לעבן, אָבער מיר שטרעבן. דער רעזולטאַט פון פליסנדיק זיכערהייט טשעקס זאָל זיין ענלעך צו די רעזולטאַטן פון אַפּאַראַט טעסץ.

פֿאַר בייַשפּיל, מיר גענומען אַ גרויס פּרויעקט און באַשלאָסן אַז איצט מיר וועלן יבערקוקן עס מיט SAST - OK. מיר פּושט דעם פּרויעקט אין SAST, עס האט אונדז 20 וואַלנעראַביליטיז און דורך אַ שטאַרק-ווילד באַשלוס מיר באַשלאָסן אַז אַלץ איז גוט. 000 וואַלנעראַביליטיז זענען אונדזער טעכניש כויוו. מיר שטעלן די כויוו אין אַ קעסטל, מיר וועט סלאָולי ויסמעקן עס און לייגן באַגז צו כיסאָרן טראַקערז. לאָמיר דינגען אַ פירמע, טאָן אַלץ זיך, אָדער האָבן זיכערהייט טשאַמפּיאָנס אונדז העלפֿן - און טעכניש כויוו וועט פאַרמינערן.

און אַלע נייַ ימערדזשינג וואַלנעראַביליטיז אין די נייַ קאָד מוזן זיין ילימאַנייטאַד אין די זעלבע וועג ווי ערראָרס אין אַ אַפּאַראַט אָדער אין אַוטאָטעסטס. לעפיערעך גערעדט, די פֿאַרזאַמלונג אנגעהויבן, מיר לויפן עס, צוויי טעסץ און צוויי זיכערהייט טעסץ דורכפאַל. גוט - מיר געגאנגען, געקוקט וואָס געטראפן, פאַרפעסטיקט איין זאַך, פאַרפעסטיקט אנדערן, לויפן עס די ווייַטער מאָל - אַלץ איז געווען גוט, קיין נייַ וואַלנעראַביליטיז ארויס, קיין טעסץ דורכפאַל. אויב די אַרבעט איז דיפּער און איר דאַרפֿן צו פֿאַרשטיין עס געזונט, אָדער פיקסיר וואַלנעראַביליטיז אַפעקץ גרויס לייַערס פון וואָס ליגט אונטער די קאַפּטער: אַ זשוק איז צוגעגעבן צו די כיסאָרן טראַקער, עס איז פּרייאָראַטייזד און קערעקטאַד. צום באַדויערן, די וועלט איז נישט גאנץ און טעסץ מאל פאַרלאָזן.

א ביישפּיל פון אַ זיכערהייט טויער איז אַן אַנאַלאָג פון אַ קוואַליטעט טויער אין טערמינען פון די בייַזייַן און נומער פון וואַלנעראַביליטיז אין די קאָד.

מיר ויסשטימען מיט SonarQube - די פּלוגין איז אינסטאַלירן, אַלץ איז זייער באַקוועם און קיל.

ינטעגראַטיאָן מיט אַנטוויקלונג סוויווע

ינאַגריישאַן אָפּציעס:

• לויפן אַ יבערקוקן פון די אַנטוויקלונג סוויווע איידער יבערגעבן.
• קוק רעזולטאַטן.
• אַנאַליסיס פון רעזולטאַטן.
• סינגקראַנאַזיישאַן מיט די סערווער.

דאָס איז ווי עס קוקט ווי צו באַקומען רעזולטאַטן פון די סערווער.

אין אונדזער אַנטוויקלונג סוויווע ינטעלידזש IDEA אַן נאָך נומער איז פשוט ארויס וואָס ינפאָרמז איר אַז אַזאַ וואַלנעראַביליטיז זענען דיטעקטאַד בעשאַס די יבערקוקן. איר קענען מיד רעדאַגירן די קאָד, קוק אין רעקאַמאַנדיישאַנז און לויפן גראַפיק. דאָס איז אַלע ליגן אויף די ווערקפּלייס פון די דעוועלאָפּער, וואָס איז זייער באַקוועם - עס איז ניט דאַרפֿן צו נאָכפאָלגן אנדערע לינקס און זען עפּעס נאָך.

עפענען מקור

דאָס איז מיין באַליבסטע טעמע. אַלעמען ניצט עפֿן מקור ביבליאָטעק - וואָס שרייַבן אַ בינטל פון קראַטשיז און בייסיקאַלז ווען איר קענען נעמען אַ פאַרטיק ביבליאָטעק אין וואָס אַלץ איז שוין ימפּלאַמענאַד?

דאָך, דאָס איז אמת, אָבער ביבליאָטעקן זענען אויך געשריבן דורך מענטשן, זיי אויך אַרייַננעמען זיכער ריסקס און עס זענען אויך וואַלנעראַביליטיז וואָס זענען פּיריאַדיקלי, אָדער קעסיידער, געמאלדן. דעריבער, עס איז דער ווייַטער שריט אין אַפּפּליקאַטיאָן סעקוריטי - דאָס איז די אַנאַליסיס פון עפֿן מקור קאַמפּאָונאַנץ.

עפֿן מקור אַנאַליסיס - אָסאַ

די געצייַג כולל דריי גרויס סטאַגעס.

זוכן פֿאַר וואַלנעראַביליטיז אין לייברעריז. פֿאַר בייַשפּיל, די געצייַג ווייסט אַז מיר נוצן עטלעכע ביבליאָטעק, און אַז אין CVE אָדער עס זענען עטלעכע וואַלנעראַביליטיז אין זשוק טראַקערז וואָס פאַרבינדן צו דעם ווערסיע פון ​​​​די ביבליאָטעק. ווען איר פּרובירן צו נוצן עס, די געצייַג וועט אַרויסגעבן אַ ווארענונג אַז די ביבליאָטעק איז שפּירעוודיק און אַדווייזיז איר צו נוצן אן אנדער ווערסיע וואָס טוט נישט האָבן וואַלנעראַביליטיז.

אַנאַליסיס פון דערלויבעניש ריינקייַט. דאָס איז נאָך נישט דער הויפּט פאָלקס דאָ, אָבער אויב איר אַרבעט אין אויסלאנד, איר קענען פֿון צייט צו צייט באַקומען אַ שטייער פֿאַר ניצן אַן אָפֿן מקור קאָמפּאָנענט וואָס קענען ניט זיין געוויינט אָדער מאַדאַפייד. לויט די לייסאַנסט ביבליאָטעק ס פּאָליטיק, מיר קענען נישט טאָן דאָס. אָדער, אויב מיר מאַדאַפייד עס און נוצן עס, מיר זאָל פּאָסטן אונדזער קאָד. פון קורס, קיין איינער וויל צו אַרויסגעבן די קאָד פון זייער פּראָדוקטן, אָבער איר קענען אויך באַשיצן זיך פון דעם.

אַנאַליסיס פון קאַמפּאָונאַנץ וואָס זענען געניצט אין אַ ינדאַסטריאַל סוויווע. לאָמיר ימאַדזשאַן אַ כייפּאַטעטיקאַל סיטואַציע אַז מיר האָבן לעסאָף געענדיקט אַנטוויקלונג און באפרייט די לעצטע מעלדונג פון אונדזער מיקראָסערוויס. ער וווינט דאָרט ווונדערלעך - אַ וואָך, אַ חודש, אַ יאָר. מיר טאָן ניט קלייַבן עס, מיר טאָן ניט אָנפירן זיכערקייַט טשעקס, אַלץ מיינט צו זיין גוט. אָבער פּלוצלינג, צוויי וואָכן נאָך די מעלדונג, אַ קריטיש וואַלנעראַביליטי איז ארויס אין די עפֿן מקור קאָמפּאָנענט, וואָס מיר נוצן אין דעם באַזונדער בויען, אין די ינדאַסטריאַל סוויווע. אויב מיר טאָן ניט רעקאָרדירן וואָס און ווו מיר נוצן, מיר פשוט וועלן נישט זען דעם וואַלנעראַביליטי. עטלעכע מכשירים האָבן די פיייקייט צו מאָניטאָר וואַלנעראַביליטיז אין לייברעריז וואָס זענען דערווייַל געניצט אין די אינדוסטריע. עס איז זייער נוציק.

פֿעיִקייטן:

• פאַרשידענע פּאַלאַסיז פֿאַר פאַרשידענע סטאַגעס פון אַנטוויקלונג.
• מאָניטאָרינג קאַמפּאָונאַנץ אין אַן ינדאַסטריאַל סוויווע.
• קאָנטראָל פון לייברעריז אין דער אָרגאַניזאַציע.
• שטיצן פֿאַר פאַרשידן בויען סיסטעמען און שפּראַכן.
• אַנאַליסיס פון דאָקקער בילדער.

עטלעכע ביישפילן פון ינדאַסטרי פירער וואָס זענען פאַרקנאַסט אין עפֿן מקור אַנאַליסיס.

דער בלויז פריי איינער איז דאָס אָפענגיקייַט-טשעק פֿון OWASP. איר קענען קער עס אויף אין דער ערשטער סטאַגעס, זען ווי עס אַרבעט און וואָס עס שטיצט. בייסיקלי, דאָס זענען אַלע וואָלקן פּראָדוקטן, אָדער אויף-האַנאָכע, אָבער הינטער זייער באַזע זיי זענען נאָך געשיקט צו די אינטערנעט. זיי שיקן נישט דיין לייברעריז, אָבער האַשעס אָדער זייער אייגענע וואַלועס, וואָס זיי רעכענען, און פינגגערפּרינץ צו זייער סערווער צו באַקומען אינפֿאָרמאַציע וועגן דעם בייַזייַן פון וואַלנעראַביליטיז.

פּראָצעס ינטאַגריישאַן

פּערימעטער קאָנטראָל פון לייברעריז, וואָס זענען דאַונלאָודיד פון פונדרויסנדיק קוואלן. מיר האָבן פונדרויסנדיק און ינערלעך ריפּאַזאַטאָריז. פֿאַר בייַשפּיל, Event Central לויפט נעקסוס, און מיר ווילן צו ענשור אַז עס זענען קיין וואַלנעראַביליטיז אין אונדזער ריפּאַזאַטאָרי מיט אַ "קריטיש" אָדער "הויך" סטאַטוס. איר קענען קאַנפיגיער פּראַקסיינג ניצן די Nexus Firewall Lifecycle געצייַג אַזוי אַז אַזאַ וואַלנעראַביליטיז זענען שנייַדן אַוועק און טאָן ניט סוף אַרויף אין די ינערלעך ריפּאַזאַטאָרי.

ינאַגריישאַן אין סי. אויף דער זעלביקער מדרגה מיט אַוטאָטעסט, אַפּאַראַט טעסץ און אָפּטייל אין אַנטוויקלונג סטאַגעס: דעוו, פּרובירן, פּראָד. אין יעדער בינע, איר קענען אראפקאפיע קיין לייברעריז, נוצן עפּעס, אָבער אויב עס איז עפּעס שווער מיט די "קריטיש" סטאַטוס, טאָמער עס איז ווערט צו ציען די ופמערקזאַמקייט פון דעוועלאָפּערס צו דעם אין דער בינע פון ​​מעלדונג אין פּראָדוקציע.

ינאַגריישאַן מיט אַרטאַפאַקץ: נעקסוס און דזשפראָג.

ינאַגריישאַן אין דער אַנטוויקלונג סוויווע. די מכשירים איר קלייַבן זאָל האָבן ינאַגריישאַן מיט אַנטוויקלונג ינווייראַנמאַנץ. דער דעוועלאָפּער מוזן האָבן אַקסעס צו די סקאַנינג רעזולטאַטן פֿון זיין ווערקפּלייס, אָדער די פיייקייט צו יבערקוקן און קאָנטראָלירן די קאָד זיך פֿאַר וואַלנעראַביליטיז איידער ער קאַמיטינג צו CVS.

סי ינאַגריישאַן. דאָס איז אַ קיל שטריך וואָס איך טאַקע ווי און וואָס איך האָבן שוין גערעדט וועגן - מאָניטאָרינג די ימערדזשאַנס פון נייַע וואַלנעראַביליטיז אין אַן ינדאַסטריאַל סוויווע. עס אַרבעט עפּעס ווי דאָס.

מיר האבן ציבור קאָמפּאָנענט ריפּאַזאַטאָריז - עטלעכע מכשירים אַרויס, און אונדזער ינערלעך ריפּאַזאַטאָרי. מיר וועלן אַז עס זאָל אַנטהאַלטן בלויז טראַסטיד קאַמפּאָונאַנץ. ווען פּראַקסיינג אַ בקשה, מיר קאָנטראָלירן אַז די דאַונלאָודיד ביבליאָטעק האט קיין וואַלנעראַביליטיז. אויב עס פאלן אונטער זיכער פּאַלאַסיז וואָס מיר שטעלן און דאַווקע קאָואָרדאַנאַט מיט דער אַנטוויקלונג, מיר טאָן ניט ופּלאָאַד עס און זענען פּראַמפּטיד צו נוצן אן אנדער ווערסיע. אַקקאָרדינגלי, אויב עס איז עפּעס טאַקע קריטיש און שלעכט אין דער ביבליאָטעק, דער דעוועלאָפּער וועט נישט באַקומען די ביבליאָטעק אין די ייַנמאָנטירונג בינע - לאָזן אים נוצן אַ ווערסיע העכער אָדער נידעריקער.

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

דינאַמיש אַנאַליסיס - DAST

דינאַמיש אַנאַליסיס מכשירים זענען פאַנדאַמענטאַלי אַנדערש פון אַלץ וואָס איז געזאָגט פריער. דאָס איז אַ מין פון נאָכמאַך פון די באַניצער 'ס אַרבעט מיט די אַפּלאַקיישאַן. אויב דאָס איז אַ וועב אַפּלאַקיישאַן, מיר שיקן ריקוועס, סימיאַלייטינג די אַרבעט פון דעם קליענט, דריקט אויף די קנעפּלעך אויף די פראָנט, שיקן קינסטלעך דאַטן פֿון די פאָרעם: קוואָטעס, בראַקאַץ, אותיות אין פאַרשידענע קאָדירונג, צו זען ווי די אַפּלאַקיישאַן אַרבעט און פּראַסעסאַז. פונדרויסנדיק דאַטן.

דער זעלביקער סיסטעם אַלאַוז איר צו קאָנטראָלירן מוסטער וואַלנעראַביליטיז אין עפֿן מקור. זינט DAST קען נישט וויסן וואָס עפֿן מקור מיר נוצן, עס פשוט ווארפט ער "בייזע" פּאַטערנז און אַנאַליזעס די סערווער ס רעספּאָנסעס:

- יאָ, דאָ איז אַ דעסעריאַליזיישאַן פּראָבלעם, אָבער נישט דאָ.

עס זענען גרויס ריסקס אין דעם, ווייַל אויב איר פירן דעם זיכערהייט פּראָבע אויף דער זעלביקער באַנק מיט וואָס די טעסטערס אַרבעט, פּריקרע זאכן קענען פּאַסירן.

• הויך מאַסע אויף די אַפּלאַקיישאַן סערווער נעץ.
• קיין ינאַגריישאַנז.
• פיייקייט צו טוישן די סעטטינגס פון די אַנאַלייזד אַפּלאַקיישאַן.
• עס איז קיין שטיצן פֿאַר די נייטיק טעקנאַלאַדזשיז.
• שוועריקייט באַשטעטיקן.

מיר האָבן אַ סיטואַציע ווען מיר לעסאָף לאָנטשט אַפּפּסקאַן: מיר פארבראכט אַ לאַנג צייַט טריינג צו באַקומען אַקסעס צו די אַפּלאַקיישאַן, גאַט 3 אַקאַונץ און זענען צופרידן - מיר וועלן לעסאָף קאָנטראָלירן אַלץ! מיר לאָנטשט אַ יבערקוקן, און דער ערשטער זאַך אַפּסקאַן האט איז געווען גיין אין די אַדמיניסטראַטאָר טאַפליע, דורכשטעכן אַלע די קנעפּלעך, טוישן האַלב פון די דאַטן, און דאַן גאָר טייטן די סערווער מיט זיין. פּאָסטפאָרם-ריקוועס. אַנטוויקלונג מיט טעסטינג האט געזאגט:

— בחורים, האסטו מיר א געלעכטער?! מיר האָבן דיר געגעבן אַקאַונץ, און איר שטעלן זיך אַ שטיין!

באַטראַכטן מעגלעך ריסקס. ידעאַללי, צוגרייטן אַ באַזונדער שטיין פֿאַר טעסטינג אינפֿאָרמאַציע זיכערהייט, וואָס וועט זיין אפגעזונדערט פון די רעשט פון די סוויווע אין מינדסטער עפעס, און קאַנדישאַנאַלי קאָנטראָלירן די אַדמיניסטראַטאָר טאַפליע, פּרעפעראַבלי אין מאַנואַל מאָדע. דאָס איז אַ פּענטעסט - די רוען פּראָצענט פון מי וואָס מיר זענען נישט קאַנסידערינג איצט.

עס איז ווערט קאַנסידערינג אַז איר קענען נוצן דעם ווי אַן אַנאַלאָג פון מאַסע טעסטינג. אין דער ערשטער בינע, איר קענען ווענדן אויף אַ דינאַמיש סקאַנער מיט 10-15 פֿעדעם און זען וואָס כאַפּאַנז, אָבער יוזשאַוואַלי, ווי פיר ווייזט, גאָרנישט גוט.

עטלעכע רעסורסן וואָס מיר יוזשאַוואַלי נוצן.

ווערט כיילייטינג בערפּ סוויט איז אַ "שווייצער מעסער" פֿאַר קיין זיכערהייט פאַכמאַן. אַלעמען ניצט עס און עס איז זייער באַקוועם. א נייַע דעמאָ ווערסיע פון ​​די פאַרנעמונג אַדישאַן איז איצט באפרייט. אויב פריער עס איז געווען בלויז אַ סטאַנדאַלאָנע נוצן מיט פּלוגינס, איצט די דעוועלאָפּערס לעסאָף מאַכן אַ גרויס סערווער פון וואָס עס וועט זיין מעגלעך צו פירן עטלעכע אגענטן. דאָס איז קיל, איך רעקאָמענדירן איר פּרובירן עס.

פּראָצעס ינטאַגריישאַן

ינטעגראַטיאָן כאַפּאַנז גאַנץ גוט און פּשוט: אָנהייב סקאַנינג נאָך געראָטן ינסטאַלירונג אַפּלאַקיישאַנז פֿאַר די שטיין און סקאַנינג נאָך מצליח ינטאַגריישאַן טעסטינג.

אויב די ינטאַגריישאַנז טאָן ניט אַרבעט אָדער עס זענען סטאַבס און רייצנ פאַנגקשאַנז, עס איז ומזיסט און אַרויסגעוואָרפן - קיין ענין וואָס מוסטער מיר שיקן, דער סערווער וועט נאָך ריספּאַנד די זעלבע וועג.

• ידעאַללי, אַ באַזונדער טעסטינג שטיין.
• איידער טעסטינג, שרייַבן די לאָגין סיקוואַנס.
• טעסטינג פון די אַדמיניסטראַציע סיסטעם איז בלויז מאַנואַל.

פּראָצעס

א ביסל גענעראַליזעד וועגן דעם פּראָצעס אין אַלגעמיין און וועגן די אַרבעט פון יעדער געצייַג אין באַזונדער. אַלע אַפּלאַקיישאַנז זענען אַנדערש - איינער אַרבעט בעסער מיט דינאַמיש אַנאַליסיס, אנדערן מיט סטאַטיק אַנאַליסיס, אַ דריט מיט OpenSource אַנאַליסיס, פּענטעסט אָדער עפּעס אַנדערש, למשל, געשעענישן מיט Waf.

יעדער פּראָצעס דאַרף קאָנטראָל.

צו פֿאַרשטיין ווי אַ פּראָצעס אַרבעט און ווו עס קענען זיין ימפּרוווד, איר דאַרפֿן צו זאַמלען מעטריקס פון אַלץ איר קענען באַקומען דיין הענט אויף, אַרייַנגערעכנט פּראָדוקציע מעטריקס, מעטריקס פון מכשירים און פון דעפעקט טראַקערז.

קיין אינפֿאָרמאַציע איז נוציק. עס איז נייטיק צו קוקן פון פאַרשידענע אַנגלעס ווו דאָס אָדער אַז געצייַג איז בעסער געניצט, ווו דער פּראָצעס ספּאַסיפיקלי סאַגז. עס קען זיין ווערט צו קוקן אין אַנטוויקלונג ענטפער צייט צו זען ווו צו פֿאַרבעסערן דעם פּראָצעס באזירט אויף צייט. די מער דאַטן, די מער סעקשאַנז קענען זיין געבויט פון שפּיץ-מדרגה צו די דעטאַילס פון יעדער פּראָצעס.

זינט אַלע סטאַטיק און דינאַמיש אַנאַליזערז האָבן זייער אייגענע אַפּיס, זייער אייגענע קאַטער מעטהאָדס, פּרינסאַפּאַלז, עטלעכע האָבן סקעדזשולערז, אנדערע טאָן ניט - מיר שרייַבן אַ געצייַג אַפּפּסעק אָרקעסטער, וואָס אַלאַוז איר צו שאַפֿן אַ איין פּאָזיציע פונט אין די גאנצע פּראָצעס פֿון דעם פּראָדוקט און פירן עס פֿון איין פונט.

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

שליסל נעמען

מכשירים זענען נישט די הויפּט זאַך. ערשטער טראַכטן דורך דעם פּראָצעס - דעמאָלט ינסטרומענט די מכשירים. די מכשירים זענען גוט אָבער טייַער, אַזוי איר קענען אָנהייבן מיט דעם פּראָצעס און בויען קאָמוניקאַציע און פארשטאנד צווישן אַנטוויקלונג און זיכערהייט. פון זיכערקייט שטאנדפונקט דארף מען נישט "אפשטעלן" אלעס, פון אנטוויקלונג שטאנדפונקט, אויב עס איז דא עפעס הויכע מעגא סופר קריטיק, דארף מען עס עלימינירן, און נישט פארבלענדן דעם פראבלעם.

פּראָדוקט קוואַליטעט - פּראָסט ציל ביידע זיכערהייט און אַנטוויקלונג. מיר טאָן איין זאַך, מיר פּרובירן צו ענשור אַז אַלץ אַרבעט ריכטיק און עס זענען קיין רעפּיאַטיישאַנאַל ריסקס אָדער פינאַנציעל לאָססעס. אַז ס וואָס מיר העכערן אַ DevSecOps, SecDevOps צוגאַנג צו פֿאַרבעסערן קאָמוניקאַציע און פֿאַרבעסערן די קוואַליטעט פון די פּראָדוקט.

אָנהייבן מיט וואָס איר שוין האָבן: רעקווירעמענץ, אַרקאַטעקטשער, פּאַרטיייש טשעקס, טריינינג, גיידליינז. עס איז ניט דאַרפֿן צו מיד צולייגן אַלע פּראַקטיסיז צו אַלע פּראַדזשעקס - מאַך יטעראַטיוולי. עס איז קיין איין נאָרמאַל - עקספּערימענט און פּרובירן פאַרשידענע אַפּראָוטשיז און סאַלושאַנז.

עס איז אַן גלייַך צייכן צווישן אינפֿאָרמאַציע זיכערהייט חסרונות און פאַנגקשאַנאַל חסרונות.

אָטאַמאַטיק אַלץוואָס באוועגט. וואָס טוט נישט רירן, מאַך עס און אָטאַמייט עס. אויב עפּעס איז געטאן דורך האַנט, עס איז נישט אַ גוט טייל פון דעם פּראָצעס. טאָמער עס איז ווערט ריוויוינג עס און אָטאַמייטינג עס אויך.

אויב די גרייס פון די IS מאַנשאַפֿט איז קליין - נוצן זיכערהייט טשאַמפּיאָנס.

טאָמער וואָס איך גערעדט וועגן וועט נישט פּאַסן איר און איר וועט געפֿינען עפּעס פון דיין אייגן - און דאָס איז גוט. אבער קלייַבן מכשירים באזירט אויף די רעקווירעמענץ פֿאַר דיין פּראָצעס. קוק נישט אויף וואס די קהילה זאגט, אז דאס כלי איז שלעכט און דאס איז גוט. טאָמער דער פאַרקערט וועט זיין אמת פֿאַר דיין פּראָדוקט.

רעקווירעמענץ פֿאַר מכשירים.

• נידעריק מדרגה פאַלש positive.
• גענוג צייט פֿאַר אַנאַליסיס.
• די קאַנוויניאַנס פון נוצן.
• אַוואַילאַביליטי פון ינטאַגריישאַנז.
• פֿאַרשטיין די ראָאַדמאַפּ פון פּראָדוקט אַנטוויקלונג.
• די מעגלעכקייט פון קאַסטאַמייזינג מכשירים.

יורי ס באַריכט איז געווען אויסדערוויילט ווי איינער פון די בעסטער אין DevOpsConf 2018. צו באַקומען באַקאַנט מיט אפילו מער טשיקאַווע געדאנקען און פּראַקטיש קאַסעס, קומען צו Skolkovo אויף 27 און 28 מאי DevOpsConf ין פעסטיוואַל RIT ++. בעסער נאָך, אויב איר זענט גרייט צו טיילן דיין דערפאַרונג צולייגן פֿאַר דעם באַריכט ביז 21 אפריל.

מקור: www.habr.com