Me 2 analîzkerên kodê, 4 amûrên ceribandina dînamîkî, hunerên xwe û 250 nivîsarên me hebûn. Ne ku ev hemî di pêvajoya heyî de hewce ne, lê gava ku hûn dest bi pêkanîna DevSecOps bikin, hûn hewce ne ku heya dawiyê biçin.
. Krediyên karakter: Justin Roiland û Dan Harmon.
SecDevOps çi ye? DevSecOps çi ye? cudahî çi ne? Ewlekariya Serlêdanê - ew li ser çi ye? Çima nêzîkatiya klasîk êdî bi ser nakeve? Bersiva van hemû pirsan dizane Yuri Shabalin ji Ewlekariya Swordfish. Yuri dê bi hûrgulî bersivê bide her tiştî û pirsgirêkên veguheztina ji modela Ewlekariya Serlêdanê ya klasîk berbi pêvajoya DevSecOps vekolîne: meriv çawa rast nêzikî yekbûna pêvajoya pêşkeftina ewledar di pêvajoya DevOps de dibe û tiştek neşikîne, meriv çawa di qonaxên sereke re derbas dibe ceribandina ewlehiyê, kîjan amûr dikarin werin bikar anîn, û ew çi cûda ne û meriv çawa wan bi rêkûpêk saz dike da ku ji xeletiyan dûr nekevin.
Li ser axaftvan: Yuri Shabalin - Mîmarê Ewlekariya Serekê di pargîdaniyê de Ewlekariya Swordfish. Berpirsiyar ji bo bicihanîna SSDL, ji bo yekbûna giştî ya amûrên analîzkirina serîlêdanê di yek ekosîstema pêşkeftin û ceribandinê de. Tecrubeya 7 salan di ewlehiya agahdariyê de. Li Alfa-Bank, Sberbank û Teknolojiyên Positive, ku nermalava pêşdebir dike û karûbaran peyda dike, xebitî. Axaftvan li konferansên navneteweyî ZerONights, PHDays, RISSPA, OWASP.
Ewlekariya Serlêdanê: ew li ser çi ye?
Ewlekariya Serlêdanê beşa ewlehiyê ye ku ji ewlehiya serîlêdanê berpirsiyar e. Ev ne bi binesaziyê an ewlehiya torê ve girêdayî ye, lê bi ya ku em dinivîsin û ya ku pêşdebiran li ser dixebitin re têkildar e - ev kêmasî û qelsiyên serîlêdanê bixwe ne.
Destûra - Jiyana pêşveçûna ewlehiyê - ji hêla Microsoft ve hatî pêşve xistin. Diagram modela SDLC-ya kanonîkî nîşan dide, ku peywira wê ya sereke beşdarbûna ewlehiyê di her qonaxa pêşkeftinê de ye, ji hewcedariyên berdan û berdana hilberandinê. Microsoft fêm kir ku di pîşesaziyê de pir xeletî hene, ji wan zêdetir bûn û diviyabû tiştek li ser wê were kirin, û wan ev nêzîkatiya ku bûye kanonîkî pêşniyar kir.
Ewlekariya Serlêdanê û SSDL ne ji bo tespîtkirina qelsiyan, wekî ku bi gelemperî tê bawer kirin, lê ji bo pêşîlêgirtina rûdana wan têne armanc kirin. Bi demê re, nêzîkatiya kanonîkî ya Microsoft-ê baştir bûye, pêşde çûye û ketiye nav kûrtir, hûrgulî.
SDLC-ya kanonîkî di metodolojiyên cihêreng de pir berfireh e - OpenSAMM, BSIMM, OWASP. Rêbaz cuda ne, lê bi gelemperî dişibin hev.
Avakirina Ewlekariya Di Modela Mezinbûnê de
Ez herî baş jê hez dikim BSIMM - . Bingeha metodolojiyê dabeşkirina pêvajoya Ewlekariya Serlêdanê li 4 domanan e: Rêvebirî, Îstixbarat, SSDL Touchpoints û Deployment. Her domain 12 pratîk hene, ku di forma 112 çalakiyan de têne destnîşan kirin.
Her yek ji 112 çalakiyan hene 3 astên mezinbûnê: destpêk, navîn û pêşketî. Hemî 12 pratîk dikarin di beşan de bêne xwendin, tiştên ku ji we re girîng in hilbijêrin, fêr bibin ka meriv çawa wan bicîh tîne û hêdî hêdî hêmanan lê zêde dike, mînakî, analîza kodê ya statîk û dînamîkî an vekolîna kodê. Hûn plansaziyek dinivîsin û bi aramî li gorî wê di çarçoveya pêkanîna çalakiyên hilbijartî de dixebitin.
Çima DevSecOps
DevOps pêvajoyek mezin a giştî ye ku tê de pêdivî ye ku ewlehî were girtin.
di destpêkê de tevlî kontrolên ewlehiyê. Di pratîkê de, hejmara tîmên ewlehiyê ji ya niha pir kêmtir bû, û ew ne wekî beşdarên pêvajoyê, lê wekî saziyek kontrol û çavdêriyê tevdigerin ku hewcedariyên li ser wê ferz dike û di dawiya pêvajoyê de kalîteya hilberê kontrol dike. berdan. Ev nêzîkatiyek klasîk e ku tê de tîmên ewlehiyê ji pêşveçûnê li pişt dîwar bûn û beşdarî pêvajoyê nebûn.
Pirsgirêka sereke ev e ku ewlehiya agahdariyê ji pêşveçûnê cuda ye. Bi gelemperî ev celebek dorhêla ewlehiya agahdariyê ye û 2-3 amûrên mezin û biha dihewîne. Her şeş mehan carekê, koda çavkaniyê an serîlêdanê tê ku were kontrol kirin, û salê carekê ew têne hilberandin . Hemî ev rê li ber vê yekê vedike ku tarîxa serbestberdanê ji bo pîşesaziyê tê paşve xistin, û pêşdebir bi hejmareke mezin ji qelsiyên ji amûrên otomatîkî re rû bi rû dimîne. Ne mumkun e ku meriv van hemîyan ji hev veqetîne û tamîr bike, ji ber ku wan şeş mehên berê encam dernexistiye, lê li vir komek nû heye.
Di pêvajoya xebata pargîdaniya me de, em dibînin ku ewlehî di hemî dever û pîşesaziyê de têdigihîje ku ew dem e ku meriv bi pêşkeftinê re li ser yek çerxerê bigire û bizivire. . Paradîgmaya DevSecOps di her berdan û dubarekirinê de bi metodolojiya pêşkeftinê, pêkanîn, piştgirî û tevlêbûnê re bêkêmasî li hev dike.
Veguhastina DevSecOps
Peyva herî girîng di Jiyana Pêşkeftina Ewlekariyê de ev e "doz". Berî ku hûn li ser kirîna amûran bifikirin, divê hûn vê yekê fêm bikin.
Tenê tevlêkirina amûran di pêvajoya DevOps de ne bes e - danûstendin û têgihîştina di navbera beşdarên pêvajoyê de girîng e.
Mirov girîngtir in, ne amûr in.
Bi gelemperî, plansazkirina ji bo pêvajoyek pêşkeftina ewledar bi hilbijartin û kirîna amûrekê dest pê dike, û bi hewildanên entegrekirina amûrê di pêvajoya heyî de, ku hewildan dimînin, bi dawî dibe. Ev dibe sedema encamên xemgîn, ji ber ku hemî amûr taybetmendî û sînorên xwe hene.
Bûyerek hevpar ev e ku dema beşa ewlehiyê amûrek baş, biha û bi kapasîteyên berfireh hilbijart, û hat pêşdebiran da ku wê di pêvajoyê de entegre bike. Lê ew bi ser nakeve - pêvajo bi vî rengî hatî çêkirin ku tixûbên amûra ku jixwe hatî kirîn di paradîgmaya heyî de cih nagire.
Pêşîn, diyar bikin ka hûn çi encam dixwazin û pêvajo dê çawa xuya bike. Ev ê ji we re bibe alîkar ku hûn di pêvajoyê de rola amûr û ewlehiyê fam bikin.
Bi tiştê ku jixwe tê bikar anîn dest pê bikin.
Berî ku hûn amûrên biha bikirin, li tiştên ku we berê hene binihêrin. Her pargîdanî ji bo pêşkeftinê hewcedariyên ewlehiyê hene, kontrol, pentest hene - çima vê yekê ji her kesî re di formek têgihîştî û hêsan de naguherînin?
Bi gelemperî hewcedarî Talmûdek kaxezê ye ku li ser refikek rûniştiye. Bûyerek hebû ku em hatin pargîdaniyek ku li pêvajoyan binihêrin û me xwest ku em hewcedariyên ewlehiyê yên nermalavê bibînin. Pisporê ku bi vê yekê re mijûl bû demek dirêj lê geriya:
- Naha, li derekê di notan de rêyek hebû ku ev belge tê de ye.
Di encamê de me ev belge hefteyek şûnda wergirt.
Ji bo hewcedarî, kontrol, hwd., rûpelek li ser mînakek çêbikin. Konhev - ji bo her kesî rehet e.
Ew hêsantir e ku hûn tiştê ku we berê heye nûve bikin û wê bikar bînin da ku dest pê bikin.
Şampiyonên Ewlekariyê bikar bînin
Bi gelemperî, di pargîdaniyek navîn de, ji bo 100-200 pêşdebiran, pisporek ewlehiyê heye ku çend fonksiyonan pêk tîne û bi fîzîkî dem tune ku her tiştî kontrol bike. Tewra ku ew çêtirîn xwe biceribîne, ew ê tenê hemî koda ku pêşkeftin çêdike kontrol neke. Ji bo rewşên wiha konseptek hatiye çêkirin. .
Şampiyonên Ewlekariyê kesên di nav tîmê pêşkeftinê de ne ku bi ewlehiya hilberê we re eleqedar in.
Şampiyona Ewlekariyê xalek têketinê ye di nav tîmê pêşkeftinê de û mizgînvanek ewlehiyê ye ku ketiye yek.
Bi gelemperî, dema ku pisporek ewlehiyê tê tîmê pêşkeftinê û xeletiyek di kodê de destnîşan dike, ew bersivek ecêb distîne:
- Û tu kî yî? Ez te cara ewil e dibînim. Her tişt bi min re baş e - hevalê min ê mezin li ser vekolîna kodê "serlêdan" da min, em bi pêş de diçin!
Ev rewşek tîpîk e, ji ber ku bawerî bi kalûpîr an bi tenê hevkarên tîmê ku pêşdebir bi domdarî li ser kar û di vekolîna kodê de bi wan re têkiliyek pir zêde heye. Ger li şûna karmendê asayîşê, Şampiyonê Ewlekariyê xeletî û encaman nîşan bide, wê demê gotina wî girantir dibe.
Di heman demê de, pêşdebiran koda xwe ji her pisporek ewlehiyê çêtir dizanin. Ji bo kesek ku di amûrek analîzek statîk de herî kêm 5 proje hene, bi gelemperî dijwar e ku meriv hemî nuwazeyan bi bîr bîne. Şampiyonên Ewlekariyê hilbera xwe dizanin: çi bi çi re têkildar e û pêşî li çi binihêre - ew bi bandortir in.
Ji ber vê yekê bicîhanîna Şampiyonên Ewlekariyê û berfirehkirina bandora tîmê ewlehiya xwe bifikirin. Ev ji bo şampiyon bixwe jî bikêr e: pêşkeftina pîşeyî di qadek nû de, berfirehkirina asoyên xwe yên teknîkî, nûvekirina jêhatîyên teknîkî, rêveberî û serokatiyê, zêdekirina nirxa bazarê. Ev hin hêmanek endezyariya civakî ye, "çavên" we di tîmê pêşkeftinê de.
Qonaxên ceribandinê
diyar dike ku 20% ji hewldanan% 80 encam dide. Ev 20% pratîkên analîzkirina serîlêdanê ne ku dikarin û divê bêne otomatîk kirin. Mînakên van çalakiyên analîzên statîk in. SAST, analîza dînamîk - DAST и Kontrola Çavkaniya Vekirî. Ez ê di derbarê çalakiyan de, û hem jî di derbarê amûran de bêtir ji we re vebêjim, dema ku em bi gelemperî gava ku wan di nav pêvajoyê de didin nasîn bi kîjan taybetmendiyan re rû bi rû dimînin, û meriv çawa wiya rast dike.
Pirsgirêkên sereke yên amûran
Ez ê pirsgirêkên ku ji bo hemî amûran re têkildar in û baldarî hewce dikin ronî bikim. Ez ê wan bi hûrgulî analîz bikim da ku ez xwe bêtir dubare nekim.
Dema analîzê ya dirêj. Ger ji bo serbestberdana hemî ceribandin û kombûnê 30 hûrdem digire, wê hingê dê kontrolên ewlehiya agahdariyê rojek bidome. Tu kes wê pêvajoyê bi vî awayî sist neke. Vê taybetmendiyê li ber çavan bigirin û encamên xwe derxînin.
Asta bilind Derew Negative an Derew Positive. Hemî hilber cûda ne, hemî çarçoveyek cûda bikar tînin û şêwaza kodkirina xwe hene. Li ser bingehên kod û teknolojiyên cihêreng, dibe ku amûr astên cûda yên Neyînî û Erênî Derew nîşan bidin. Ji ber vê yekê binihêrin ka bi rastî di çi de ye hûn şîrket û ji bo ya te serîlêdan dê encamên baş û pêbawer nîşan bidin.
Bi amûrên heyî re yekbûn tune. Ji hêla entegrasyonê ya ku hûn berê bikar tînin li amûran binêrin. Mînakî, heke we Jenkins an TeamCity heye, yekbûna amûran bi vê nermalavê re kontrol bikin, ne bi GitLab CI, ku hûn bikar neynin.
Kêmasî an tevliheviya zêde ya xwerûkirinê. Ger amûrek xwedan API nebe, wê hingê çima hewce ye? Her tiştê ku di navberê de dikare were kirin divê bi navgîniya API-ê peyda bibe. Bi îdeal, amûr divê xwedan şiyana xweşkirina kontrolan be.
Nexşeya Rêya Pêşveçûna Hilberê tune. Pêşveçûn sekinî ne, em her gav çarçove û fonksiyonên nû bikar tînin, koda kevn ji nû ve di zimanên nû de dinivîsin. Em dixwazin pê ewle bin ku amûra ku em bikirin dê çarçove û teknolojiyên nû piştgirî bike. Ji ber vê yekê, girîng e ku hûn zanibin ku hilberek rast û rast heye pêşveçûnî.
Taybetmendiyên pêvajoyê
Ji bilî taybetmendiyên amûran, taybetmendiyên pêvajoya pêşveçûnê jî bigirin. Mînak, rê li ber pêşveçûnê girtin xeletiyek hevpar e. Ka em binihêrin ka kîjan taybetmendiyên din divê bêne hesibandin û tîmê ewlehiyê divê bala xwe bide çi.
Ji bo ku pêşkeftin û demên serbest bernedin, biafirînin qaîdeyên cuda û cûrbecûr rawestgehan nîşan bidin - pîvanên rawestandina pêvajoya avakirinê ger qelsî hebin - ji bo derdorên cuda. Mînakî, em fam dikin ku şaxa heyî diçe stasyona pêşkeftinê an UAT, ku tê vê wateyê ku em nesekinin û nebêjin:
— Li vir qelsiyên we hene, hûn ê bêtir neçin deverek!
Di vê qonaxê de, girîng e ku meriv ji pêşdebiran re bêje ku pirsgirêkên ewlehiyê hene ku hêjayî balê ne.
Hebûna qelsiyan ji bo ceribandinên din ne asteng e: destan, entegrasyon an destan. Ji hêla din ve, pêdivî ye ku em bi rengek ewlekariya hilberê zêde bikin, û da ku pêşdebiran tiştên ku ew ewle dibînin ji bîr nekin. Ji ber vê yekê, carinan em vê yekê dikin: li standê, gava ku ew berbi hawîrdora pêşkeftinê ve tê avêtin, em tenê pêşveçûnê agahdar dikin:
- Gelî hevalno, pirsgirêkên we hene, ji kerema xwe bala xwe bidin wan.
Di qonaxa UAT de em dîsa di derbarê qelsiyan de hişyariyan nîşan didin, û di qonaxa berdanê de em dibêjin:
- Gelî hevalan, me gelek caran we hişyar kir, we tiştek nekir - em ê we ji vê yekê nehêlin.
Ger em li ser kod û dînamîk biaxivin, wê hingê pêdivî ye ku meriv qelsiyên wan taybetmendî û kodên ku tenê di vê taybetmendiyê de hatine nivîsandin nîşan bidin û hişyar bikin. Ger pêşdebirek bişkokek bi 3 pixelan bihejîne û em jê re bibêjin ku li wir derziyek SQL heye û ji ber vê yekê pêdivî ye ku bi lezgînî sererast bike, ev xelet e. Tenê li tiştên ku niha hatine nivîsandin û li guhertinên ku di serîlêdanê de têne nivîsandin binêrin.
Ka em bibêjin ku me hin kêmasiyek fonksiyonel heye - awayê ku pêdivî ye ku serîlêdan nexebite: drav nayê veguheztin, gava ku hûn li ser bişkokek bikirtînin veguheztina rûpela din çênabe, an hilber bar nake. Kêmasiyên Ewlekariyê - ev heman kêmasî ne, lê ne di warê operasyona serîlêdanê de, lê di ewlehiyê de.
Ne hemî pirsgirêkên kalîteya nermalavê pirsgirêkên ewlehiyê ne. Lê hemî pirsgirêkên ewlehiyê bi kalîteya nermalavê ve girêdayî ne. Şerîf Mensûr, Expedia.
Ji ber ku hemî qelsî kêmasî ne, divê ew li heman cîhê hemî kêmasiyên pêşkeftinê bêne bicîh kirin. Ji ber vê yekê rapor û PDFên tirsnak ên ku kes naxwîne ji bîr bikin.
Dema ku ez di pargîdaniyek pêşveçûnê de dixebitim, min raporek ji amûrên analîzên statîk wergirt. Min vekir, tirsiyam, qehwe çêkir, 350 rûpel gêr kir, girt û ketim ser kar. Raporên mezin raporên mirî ne. Bi gelemperî ew naçin cîhek, e-name têne jêbirin, ji bîr kirin, winda dibin, an karsazî dibêje ku ew xeternak e.
Çi bikim? Em bi tenê kêmasiyên pejirandî yên ku me dîtiye vediguhezînin formek ji bo pêşkeftinê rehet, mînakî, em wan di paşvekêşana Jira de dihêlin. Em kêmasiyan pêşîn dikin û wan di heman rêza pêşîn de wekî kêmasiyên fonksiyonel û kêmasiyên ceribandinê ji holê radikin.
Analyza Statîk - SAST
Ev analîzek kodê ye ji bo hebûna qelsiyan., lê ew ne wekî SonarQube ye. Em ne tenê qalib û şêwazê kontrol dikin. Di analîzê de çend nêzîkatî têne bikar anîn: li gorî dara lawaziyê, li gorî , bi analîzkirina pelên veavakirinê. Ev hemî kodê bixwe ye.
Pros yên nêzîkatiya: naskirina qelsiyên di kodê de di qonaxek destpêkê ya pêşkeftinê dedema ku hê tu standên an amûrên amade hene, û kapasîteya şopandina zêde: şopandina beşek kodê ya ku hatî guhertin û tenê taybetmendiya ku em niha dikin, ku dema şopandinê kêm dike.
Минусы - ev nebûna piştgiriya zimanên pêwîst e.
entegrasyonên pêwîst, ya ku divê di nav amûran de be, bi dîtina min a subjektîf:
- Amûra entegrasyonê: Jenkins, TeamCity û Gitlab CI.
- Jîngeha pêşkeftinê: Intellij IDEA, Visual Studio. Ji bo pêşdebirek hêsantir e ku nehêle navgînek nefêmkirî ya ku hîn jî pêdivî ye ku ji bîr bike, lê ji bo dîtina hemî entegrasyon û qelsiyên hewce yên ku wî rast li cîhê xebata xwe di hawîrdora pêşkeftina xwe de dîtine.
- Vekolîna kodê: SonarQube û vekolîna destan.
- Şopên kêmasiyê: Jira û Bugzilla.
Wêne çend nûnerên çêtirîn ên analîzên statîk nîşan dide.
Ew ne amûr in, lê pêvajo girîng in, ji ber vê yekê çareseriyên Çavkaniya Vekirî hene ku ji bo ceribandina pêvajoyê jî baş in.
Çavkaniya Vekirî ya SAST dê hejmareke mezin ji qelsî an DataFlowên tevlihev nabîne, lê ew dikarin û divê di dema avakirina pêvajoyek de werin bikar anîn. Ew ji we re dibin alîkar ku hûn fêm bikin ka dê pêvajo çawa were avakirin, kî dê bersivê bide xeletiyan, kî dê rapor bike, kî dê rapor bike. Heke hûn dixwazin qonaxa destpêkê ya avakirina ewlehiya koda xwe pêk bînin, çareseriyên Çavkaniya Vekirî bikar bînin.
Ger hûn di destpêka rêwîtiya xwe de ne û tiştek tune be ev çawa dikare were yek kirin: ne CI, ne Jenkins, ne jî TeamCity? Werin em li entegrasyona pêvajoyê binêrin.
Yekbûn di asta CVS de
Ger we Bitbucket an GitLab heye, hûn dikarin li ser yek bikin .
Bi bûyerê - Daxwaza kişandin, kirina. Hûn kodê dişoxilînin û di statûya çêkirinê de nîşan didin ka kontrolkirina ewlehiyê derbas bû an têk çû.
Feedback. Bê guman, bersiv her dem hewce ye. Ger we tenê ewlekarî di aliyê ewlehiyê de kir, ew xiste nav qutiyek û tiştek li ser wê ji kesî re negot, û dûv re di dawiya mehê de komek xelet avêtin, ev ne rast û ne baş e.
Yekbûn bi pergala vekolîna kodê re
Carekê, me di gelek projeyên girîng de ji bo bikarhênerek teknîkî ya AppSec wekî vekolînek xwerû tevdigeriya. Bi ve girêdayî ye ku di koda nû de xeletî têne nas kirin an xeletî tune ne, lênihêrker li ser daxwaza kişandinê statûyê destnîşan dike ku "qebûl bike" an "karê hewce bike" - an her tişt baş e, an jî pêdivî ye ku were çêtir kirin û bi çi ve girêdayî ye. tam pêdivî ye ku were baştir kirin. Ji bo entegrasyona bi guhertoya ku ber bi hilberînê ve diçe, heke ceribandina ewlehiya agahdariyê derbas nebe me qedexeyek yekbûnê çalak kiriye. Me ev yek di vekolîna koda destan de kir, û beşdarên mayî yên pêvajoyê ji bo vê pêvajoya taybetî statûyên ewlehiyê dîtin.
Yekbûn bi SonarQube re
Gelek kes hene bi kalîteya kodê. Li vir jî heman e - hûn dikarin heman deriyan tenê ji bo amûrên SAST bikin. Dê heman navbeynkar, heman deriyê kalîteyê hebe, tenê ew ê jê re were gotin deriyê ewlehiyê. Û bi heman awayî, heke we pêvajoyek bi karanîna SonarQube heye, hûn dikarin bi hêsanî her tiştî li wir yek bikin.
Yekbûn di asta CI de
Her tişt li vir jî pir hêsan e:
- Di heman astê de ototests, testên yekîneyê.
- Dabeşkirina li gorî qonaxên pêşveçûnê: dev, ceribandin, prod. Dibe ku rêzikên cihêreng an şert û mercên têkçûnê yên cihêreng werin nav kirin: meclîsê rawestînin, civînê rawestînin.
- Destpêka hevdem / asînkron. Em li benda dawiya testên ewlehiyê ne yan na. Ango, me tenê wan dan destpêkirin û bi pêş ve diçin, û paşê em digihîjin statûya ku her tişt baş e an xirab e.
Ew hemî di cîhanek pembe ya bêkêmasî de ye. Di jiyana rast de tiştekî wisa tune, lê em ji bo wê têdikoşin. Encama xebitandina kontrolên ewlehiyê divê mîna encamên ceribandinên yekîneyê be.
Mînakî, me projeyek mezin girt û biryar da ku naha em ê wê bi SAST-ê bişopînin - OK. Me ev proje xist nav SASTê, wê 20 qelsî da me û bi biryarek bi îrade me biryar da ku her tişt baş e. 000 qelsî deynê me yê teknîkî ye. Em ê deynê têxin qutiyekê, em ê hêdî hêdî paqij bikin û xeletiyan li şopînerên kêmasiyê zêde bikin. Werin em pargîdaniyek bikirin, her tiştî bi xwe bikin, an jî Şampiyonên Ewlekariyê ji me re bibin alîkar - û deynê teknîkî dê kêm bibe.
Û hemî qelsiyên nû yên ku di koda nû de derketine divê bi heman rengî wekî xeletiyên di yekîneyek an di ceribandinên otomatîkî de bêne rakirin. Bi awayekî nisbî, meclîsê dest pê kir, me meşand, du ceribandin û du ceribandinên ewlehiyê têk çûn. Baş e - me çû, li çi qewimî mêze kir, tiştek rast kir, yekî din rast kir, carek din ew bi rêve kir - her tişt baş e, ne qelsiyên nû xuya bûn, ne ceribandin bi ser neketin. Ger ev peywir kûrtir be û pêdivî ye ku hûn wê baş fam bikin, an jî rastkirina qelsiyan bandorê li qatên mezin ên tiştê ku di binê kapê de ye dike: xeletiyek li şopînera kêmasiyê hate zêdekirin, ew tête pêşîn û rast kirin. Mixabin, cîhan ne îdeal e û ceribandin carinan têk diçin.
Mînaka dergehek ewlehiyê analogek dergehek kalîteyê ye, di warê hebûn û hejmara qelsiyên di kodê de.
Em bi SonarQube re tevdigerin - pêvek hatî saz kirin, her tişt pir rehet û xweş e.
Yekbûnek bi hawîrdora pêşkeftinê re
Vebijarkên entegrasyonê:
- Berî ku tevbigerin, ji hawîrdora pêşkeftinê vekolînek dest pê kirin.
- Encaman bibînin.
- Analîza encamên.
- Hevdemkirinê bi server.
Ev dixuye ku meriv encaman ji serverê werdigire.
Di hawîrdora pêşveçûna me de hêmanek pêvek tenê xuya dike ku we agahdar dike ku di dema şopandinê de qelsiyên weha hatine dîtin. Hûn dikarin tavilê kodê biguherînin, li pêşniyaran binihêrin û . Ev hemî li cîhê xebata pêşdebiran e, ku pir hêsan e - hûn ne hewce ne ku hûn girêdanên din bişopînin û li tiştek din binêrin.
Open Source
Ev mijara min a hezkirî ye. Her kes pirtûkxaneyên Çavkaniya Vekirî bikar tîne - çima gava ku hûn dikarin pirtûkxaneyek amade ya ku tê de her tişt jixwe hatî bicîh kirin hilînin, çima komek kulm û bisîkletan binivîsin?
Bê guman, ev rast e, lê pirtûkxane jî ji hêla mirovan ve têne nivîsandin, di heman demê de hin xetereyan jî hene, û her weha qelsiyên ku bi periyodîk, an bi domdarî têne ragihandin jî hene. Ji ber vê yekê, di Ewlekariya Serlêdanê de gavek din heye - ev analîzkirina hêmanên Çavkaniya Vekirî ye.
Analîza Çavkaniya Vekirî - OSA
Amûr sê gavên mezin dihewîne.
Di pirtûkxaneyan de li qelsiyan digere. Mînakî, amûr dizane ku em hin pirtûkxane bikar tînin, û ew an jî di şopînerên xeletiyan de hin qelsî hene ku bi vê guhertoya pirtûkxaneyê re têkildar in. Dema ku hûn hewl didin ku wê bikar bînin, amûr dê hişyariyek bide ku pirtûkxane lawaz e û ji we re şîret dike ku hûn guhertoyek din a ku qelsî tune bikar bînin.
Analîza paqijiya lîsansê. Ew hîn li vir bi taybetî ne populer e, lê heke hûn li derveyî welêt bixebitin, hûn dikarin bi awayekî periyodîk li wir ji bo karanîna pêkhateyek çavkaniyek vekirî ya ku nayê bikar anîn an guheztin xercek bistînin. Li gorî polîtîkaya pirtûkxaneya destûrdar, em nikarin vê yekê bikin. An jî, heke me ew guherand û bikar anî, wê hingê divê em koda xwe bişînin. Bê guman, kes naxwaze koda hilberên xwe biweşîne, lê hûn dikarin xwe ji vê yekê jî biparêzin.
Analîza pêkhateyên ku di hawîrdorek pîşesaziyê de têne bikar anîn. Ka em rewşek hîpotetîk bifikirin: me di dawiyê de pêşkeftin qedand û serbestberdana herî dawî ya mîkroxizmeta xwe derxist. Ew li wir ecêb dijî - hefteyek, mehek, salek. Em wê kom nakin, em kontrolên ewlehiyê nakin, her tişt baş xuya dike. Lê ji nişkê ve, du hefte piştî serbestberdanê, di hêmana Çavkaniya Vekirî de, ku em di vê avahîsaziya taybetî de, di hawîrdora pîşesaziyê de bikar tînin de, xirapiyek krîtîk xuya dike. Ger em çi û li ku derê bikar tînin tomar nekin, wê hingê em ê bi hêsanî vê qelsiyê nebînin. Hin amûr xwedan şiyana şopandina qelsiyên pirtûkxaneyên ku niha di pîşesaziyê de têne bikar anîn hene. Pir bikêr e.
Features:
- Polîtîkayên cuda ji bo qonaxên cuda yên pêşveçûnê.
- Çavdêriya pêkhateyên di hawîrdora pîşesaziyê de.
- Kontrolkirina pirtûkxaneyên di nava rêxistinê de.
- Piştgiriya ji bo pergalên çêkirinê û zimanan ên cihêreng.
- Analîzkirina wêneyên Docker.
Çend mînakên serokên pîşesaziyê yên ku di analîza Çavkaniya Vekirî de mijûl in.
Tenê yek belaş e ji OWASP. Hûn dikarin di qonaxên yekem de wê vekin, bibînin ka ew çawa dixebite û çi piştgirî dike. Di bingeh de, ev hemî hilberên ewr in, an li ser bingehê ne, lê li pişt bingeha wan ew hîn jî ji Înternetê re têne şandin. Ew ne pirtûkxaneyên we, lê haş an nirxên xwe yên ku ew dihejmêrin, û şopa tiliyan ji servera xwe re dişînin da ku agahdariya li ser hebûna qelsiyan bistînin.
Entegrasyonê di pêvajoyê de
Kontrolkirina pirtûkxaneyan di perimeterê de, ku ji çavkaniyên derveyî têne daxistin. Depoyên me yên derve û hundir hene. Mînakî, Event Central Nexus-ê dimeşîne, û em dixwazin ku depoya me bi statûyek "krîtîk" an "bilind" tune be. Hûn dikarin bi karanîna amûra Nexus Firewall Lifecycle vesazkirinê mîheng bikin da ku xesariyên weha qut bibin û nekevin depoya hundurîn.
Yekbûna nav CI. Di heman astê de bi autotests, testên yekîneyê û dabeşkirina qonaxên pêşkeftinê: dev, test, prod. Di her qonaxê de, hûn dikarin her pirtûkxaneyan dakêşin, her tiştî bikar bînin, lê heke di statûya "krîtîk" de tiştek dijwar hebe, dibe ku hêjayî vê yekê be ku di qonaxa berdanê de di pîşesaziyê de bala pêşdebiran bikişîne.
Yekbûna bi huneran re: Nexus û JFrog.
Entegrasyonê di hawîrdora pêşveçûnê de. Amûrên ku hûn hildibijêrin divê bi hawîrdorên pêşkeftinê re bibin yek. Pêşdebir pêdivî ye ku bigihîje encamên şopandinê ji cîhê xebata xwe, an jî şiyana ku kodê ji bo qelsiyan bişopîne û kontrol bike berî ku CVS bike.
Yekbûna nav CD. Ev taybetmendiyek xweş e ku ez bi rastî jê hez dikim û min berê jî qala wê kiriye - şopandina derketina xirapiyên nû di hawîrdorek pîşesaziyê de. Ew tiştek bi vî rengî dixebite.
Me heye Depoyên Pêkhateyên Giştî - hin amûrên li derve, û depoya meya navxweyî. Em dixwazin ku ew tenê hêmanên pêbawer bihewîne. Dema ku daxwazek proxy dike, em kontrol dikin ku pirtûkxaneya dakêşandî ne xwedî qelsî ye. Ger ew bikeve bin hin polîtîkayên ku em saz dikin û pêdivî bi pêşkeftinê re hevrêz dikin, wê hingê em wê dakêşin û neçar in ku guhertoyek din bikar bînin. Li gorî vê yekê, heke di pirtûkxaneyê de tiştek bi rastî krîtîk û xirab hebe, wê hingê pêşdebir dê di qonaxa sazkirinê de pirtûkxaneyê wernegire - bila ew guhertoyek bilindtir an jêrîn bikar bîne.
- Dema ku çêdike, em kontrol dikin ku kesek tiştek xirab nexistiye, ku hemî pêkhate ewle ne û kesî tiştek xeternak li ser ajokera flash-ê neaniye.
- Di depoyê de em tenê hêmanên pêbawer hene.
- Dema ku bicîh dikin, em careke din pakêtê bixwe kontrol dikin: şer, jar, DL an wêneya Docker da ku pê ewle bibin ku ew bi siyasetê re tevdigere.
- Dema ku dikevin pîşesaziyê, em çavdêriya tiştên ku di hawîrdora pîşesaziyê de diqewimin dikin: qelsiyên krîtîk xuya dibin an naxuyin.
Analîza Dînamîk - DAST
Amûrên analîzkirina dînamîk bi bingehîn ji her tiştê ku heya nuha hatî gotin cûda ne. Ev celebek teqlîdkirina xebata bikarhêner bi serîlêdanê re ye. Ger ev serîlêdanek webê ye, em daxwazan dişînin, xebata xerîdar simulasyonan dikin, li ser bişkokên li pêş bikirtînin, daneyên sûnî ji formê bişînin: binavkirin, bend, tîpên di şîfreyên cihêreng de, da ku binihêrin ka serîlêdan çawa dixebite û daneyên derveyî pêvajoyê dike.
Heman pergal dihêle hûn di Çavkaniya Vekirî de qelsiyên şablonê kontrol bikin. Ji ber ku DAST nizane ku em kîjan Çavkaniya Vekirî bikar tînin, ew bi tenê qalibên "xerab" diavêje û bersivên serverê analîz dike:
- Erê, li vir pirsgirêka deserialîzasyonê heye, lê ne li vir.
Di vê yekê de metirsiyên mezin hene, ji ber ku heke hûn vê ceribandina ewlehiyê li ser heman doşeka ku ceribandiner pê re dixebitin pêk bînin, dibe ku tiştên xirab çêbibin.
- Barkirina bilind li ser servera torê ya serîlêdanê.
- Bê entegrasyon.
- Kapasîteya guheztina mîhengên serîlêdana analîzkirî.
- Ji bo teknolojiyên pêwîst piştgirî tune.
- Zehmetiya sazkirinê.
Dema ku me di dawiyê de AppScan da destpêkirin rewşek me hebû: me demek dirêj hewl dida ku bigihîje serîlêdanê, 3 hesab girtin û kêfxweş bûn - em ê di dawiyê de her tiştî kontrol bikin! Me dest bi şopandinê kir, û yekem tiştê ku AppScan kir ev bû ku çû nav panela rêveberiyê, hemî bişkokan qul kir, nîvê daneyê biguhezîne, û dûv re bi tevahî serverê bi ya xwe bikuje. -daxwazan. Pêşveçûn bi ceribandinê re got:
— Gelî hevalno, hûn henekê xwe bi min dikin?! Me hesabên we dan, we jî standek ava kir!
Rîskên gengaz bifikirin. Bi îdeal, ji bo ceribandina ewlehiya agahdarî, ku dê bi kêmanî bi rengekî ji hawîrdora mayî were veqetandin, rawestgehek veqetandî amade bikin, û panela rêveberiyê, bi tercîhî di moda destan de, kontrol bikin. Ev pentestek e - ew rêjeyên mayî yên hewildanê yên ku em niha nahesibînin.
Hêjayî gotinê ye ku hûn dikarin vê wekî analogek ceribandina barkirinê bikar bînin. Di qonaxa yekem de, hûn dikarin di 10-15 mijaran de skanerek dînamîkî vekin û bibînin ka çi diqewime, lê bi gelemperî, wekî ku pratîk destnîşan dike, tiştek baş nîne.
Çend çavkaniyên ku em bi gelemperî bikar tînin.
Hêjayî balkişandinê ye ji bo her pisporê ewlehiyê "kêrê Swîsre" ye. Her kes wê bikar tîne û ew pir hêsan e. Guhertoyek nû ya demo ya guhertoya pargîdanî nuha derketiye. Ger berê ew bi pêvekan re tenê karûbarek bi tenê bû, naha pêşdebir di dawiyê de serverek mezin çêdikin ku jê dê gengaz be ku gelek nûneran birêve bibin. Ev xweş e, ez pêşniyar dikim ku hûn wê biceribînin.
Entegrasyonê di pêvajoyê de
Yekbûn pir baş dibe û hêsan e: piştî sazkirina serketî dest bi şopandinê bikin sepanên ji bo stand û şopandin piştî ceribandina entegrasyonê ya serketî.
Ger entegrasyon nexebitin an stû û fonksiyonên xapînok hebin, ew bêwate û bêkêr e - ferq nake ku em kîjan nimûne bişînin, server dê dîsa jî bi heman rengî bersivê bide.
- Bi îdeal, stendek ceribandinê ya cihêreng.
- Berî ceribandinê, rêzika têketinê binivîsin.
- Testkirina pergala rêveberiyê tenê bi destan e.
pêvajoya
Li ser pêvajoyê bi gelemperî û di derbarê xebata her amûrek bi taybetî de gelemperî gelemperî. Hemî serîlêdan cûda ne - hin bi analîzên dînamîkî re çêtir dixebitin, yên din bi analîzên statîk, yên din bi vekolîna OpenSource, pentest, an jî tiştek din bi tevahî re dixebitin, mînakî, bûyerên bi .
Her pêvajo hewceyê kontrolê ye.
Ji bo ku hûn fêm bikin ka pêvajoyek çawa dixebite û li ku derê dikare were çêtir kirin, hûn hewce ne ku metrîkan ji her tiştê ku hûn têkevin destên xwe berhev bikin, di nav de metrîkên hilberînê, metrîkên ji amûran, û ji şopînerên xeletiyê.
Her agahdarî alîkar e. Pêdivî ye ku hûn ji perspektîfên cihêreng binihêrin ka yek an amûrek din çêtir tê bikar anîn, li ku derê pêvajo bi taybetî xera dibe. Dibe ku hêja ye ku meriv li dema bersiva pêşveçûnê binihêre da ku fêm bike ka meriv li ku derê pêvajoyê li gorî demê çêtir dike. Daneyên bêtir, bêtir beş dikarin ji asta jorîn heya hûrguliyên her pêvajoyê bêne çêkirin.
Ji ber ku hemî analîzkerên statîk û dînamîkî API-yên xwe hene, rêbazên destpêkirina wan, prensîbên xwe hene, hinekan plansazker hene, yên din tune - em amûrek dinivîsin AppSec Orkestrator, ku destûrê dide te ku hûn xalek têketinê di tevahiya pêvajoyê de ji hilberê biafirînin û wê ji yek xalê birêve bibin.
Rêvebir, pêşdebir û endezyarên ewlehiyê yek nuqteyek têketinê heye ku ew dikarin bibînin ka çi diqewime, mîheng bikin û şopandinekê bimeşînin, encamên şopandinê bistînin, û hewcedariyên bişînin. Em hewl didin ku ji kaxezê dûr bikevin, her tiştî veguhezînin pêşkeftina mirovî, ya ku ji hêla pêşkeftinê ve tê bikar anîn - rûpelên li ser Têkeliya bi statû û metrikan, kêmasiyên li Jira an di şopînerên cihêreng ên kêmasiyê de, an jî di pêvajoyek hevdem/asynchronous de di CI/CD de bi cih kirin. .
Key Takeaways
Amûr ne ya herî girîng in. Pêşî pêvajoyê bifikire - dûv re amûran bicîh bîne. Amûr baş in lê biha ne, ji ber vê yekê hûn dikarin bi pêvajoyê dest pê bikin û di navbera pêşkeftin û ewlehiyê de têkilî û têgihîştinê ava bikin. Ji aliyê ewlehiyê ve, ne hewce ye ku her tişt "raweste" Ji hêla pêşveçûnê ve, heke tiştek mega super krîtîk hebe, wê hingê pêdivî ye ku ew ji holê were rakirin, û çavê xwe ji pirsgirêkê re neyê girtin.
Kalîteya hilberê - armanca hevpar hem ewlehî û hem jî pêşveçûn. Em yek tişt dikin, em hewl didin ku her tişt rast bixebite û xetereyên navdar an zirarên darayî tune ne. Ji ber vê yekê em nêzîkatiyek DevSecOps, SecDevOps pêşve dixin da ku pêwendiyê baştir bikin û hilberek çêtir çêbikin.
Bi tiştê ku we berê heye dest pê bikin: hewcedarî, mîmarî, kontrolên qismî, perwerdehî, rênîşandan. Ne hewce ye ku tavilê hemî pratîkan li ser hemî projeyan bicîh bikin. dubare tevbigerin. Standardek yekane tune - ceribandinî û rê û rêbazên cuda biceribîne.
Di navbera kêmasiyên ewlehiya agahdariyê û kêmasiyên fonksiyonel de nîşanek wekhev heye.
Her tiştî otomatîk bikinku tevdigere. Her tiştê ku nagere tevbigerin û otomatîk bikin. Ger tiştek bi destan were kirin, ew ne beşek baş a pêvajoyê ye. Dibe ku ew hêjayî nirxandina wê û otomatîkkirina wê jî ye.
Ger mezinahiya tîmê IS piçûk be, Şampiyonên Ewlekariyê bikar bînin.
Dibe ku ya ku min behs kir dê ne li gorî we be û hûn ê tiştek ji xwe derxînin - û ew baş e. Lebê Amûrên li ser bingeha hewcedariyên ji bo pêvajoya xwe hilbijêrin. Li civatê çi dibêje nenêrin, ku ev amûr xerab e û ev baş e. Dibe ku berevajî wê ji bo hilberê we rast be.
Pêdiviyên ji bo amûran.
- Asta kêm Derew Positive.
- Dema analîzê ya têr.
- Kêrhatiya karanînê.
- Hebûna entegrasyonên.
- Fêmkirina nexşeya rê ya pêşveçûna hilberê.
- Ihtîmala xwerûkirina amûrên.
Rapora Yuri di DevOpsConf 2018 de wekî yek ji çêtirîn hate hilbijartin. Ji bo ku hûn bi ramanên hê balkêştir û dozên pratîkî re werin nas kirin, di 27 û 28ê Gulanê de werin Skolkovo di nav . Hê çêtir, heke hûn amade ne ku ezmûna xwe parve bikin, wê hingê ji bo raporê heta 21ê Nîsanê.
Source: www.habr.com