{"id":31852,"date":"2019-10-31T21:43:30","date_gmt":"2019-10-31T18:43:30","guid":{"rendered":"https:\/\/prohoster.info\/blog\/strah-i-nenavist-devsecops\/"},"modified":"2019-10-31T21:43:30","modified_gmt":"2019-10-31T18:43:30","slug":"strah-i-nenavist-devsecops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/strah-i-nenavist-devsecops","title":{"rendered":"R\u00e4dsla och hat DevSecOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Vi hade 2 kodanalysatorer, 4 verktyg f\u00f6r dynamisk testning, egna skapelser och 250 skript. Inte s\u00e5 att allt detta var n\u00f6dv\u00e4ndigt i den nuvarande processen, men eftersom jag b\u00f6rjade implementera DevSecOps, s\u00e5 m\u00e5ste man g\u00e5 hela v\u00e4gen.<\/p>\n

\"R\u00e4dsla
\n
\nK\u00e4lla<\/a><\/noindex>. Karakt\u00e4rernas skapare: Justin Roiland och Dan Harmon.<\/i><\/p>\n

Vad \u00e4r SecDevOps? Och DevSecOps? Vad \u00e4r skillnaderna? Applikationss\u00e4kerhet \u2013 vad handlar det om? Varf\u00f6r fungerar den klassiska metoden inte l\u00e4ngre? P\u00e5 alla dessa fr\u00e5gor har svaret. Jurij Shabalin<\/b> fr\u00e5n\u00a0Swordfish Security. <\/b>Jurij kommer grundligt att svara p\u00e5 allt och g\u00e5 igenom problemen med \u00f6verg\u00e5ngen fr\u00e5n den klassiska modellen f\u00f6r applikationss\u00e4kerhet till DevSecOps-processen: hur man r\u00e4tt ska g\u00e5 tillv\u00e4ga f\u00f6r att integrera processen f\u00f6r s\u00e4ker utveckling i DevOps-processen utan att bryta n\u00e5got, hur man g\u00e5r igenom huvudsakliga faser av s\u00e4kerhetstestning, vilka verktyg som kan anv\u00e4ndas, hur de skiljer sig och hur man korrekt konfigurerar dem f\u00f6r att undvika fallgropar.
\n<\/a><\/noindex>
\n

\r\n \"Spela\r\n
<\/div>\r\n <\/div><\/center>
\nOm talaren:<\/b> Jurij Shabalin \u2013 <\/b>Chief Security Architect p\u00e5 Swordfish Security.<\/b>. Ansvarar f\u00f6r implementeringen av SSDL, f\u00f6r den totala integrationen av programanalysverktyg i ett enhetligt utvecklings- och testekosystem. 7 \u00e5rs erfarenhet inom informationss\u00e4kerhet. Har arbetat p\u00e5 Alfa-Bank, Sberbank och p\u00e5 Positive Technologies, som utvecklar programvara och tillhandah\u00e5ller tj\u00e4nster. Talare vid internationella konferenser som ZerONights, PHDays, RISSPA, OWASP.<\/p>\n

Applikationss\u00e4kerhet: vad handlar det om?<\/h2>\n

\nApplikationss\u00e4kerhet<\/b>\u00a0\u2013 \u00e4r ett omr\u00e5de inom s\u00e4kerhet som ansvarar f\u00f6r s\u00e4kerheten hos applikationer. Detta r\u00f6r sig inte om infrastruktur eller n\u00e4tverkss\u00e4kerhet, utan just det vi skriver och det utvecklarna arbetar med \u2013 det handlar om brister och s\u00e5rbarheter i sj\u00e4lva applikationen.<\/p>\n

Inriktning SDL eller SDLC<\/a><\/noindex>\u00a0\u2014 Security development lifecycle<\/b>\u00a0\u2013 utvecklades av Microsoft. P\u00e5 schemat \u2013 den kanoniska modellen av SDLC, vars huvudsakliga uppgift \u00e4r att s\u00e4kerhet ska ing\u00e5 i varje steg av utvecklingen, fr\u00e5n krav till release och produktion. Microsoft ins\u00e5g att det fanns f\u00f6r m\u00e5nga buggar i produktion, att de blev fler och att n\u00e5got m\u00e5ste g\u00f6ras \u00e5t det, vilket ledde till detta tillv\u00e4gag\u00e5ngss\u00e4tt som blev kanoniskt.<\/p>\n

\"R\u00e4dsla
\n
\nApplikationss\u00e4kerhet och SSDL syftar inte till att uppt\u00e4cka s\u00e5rbarheter, som man vanligtvis tror, utan till att f\u00f6rhindra att de uppst\u00e5r. Med tiden har den kanoniska metoden fr\u00e5n Microsoft f\u00f6rb\u00e4ttrats, utvecklats, och det har tillkommit en djupare och mer detaljerad insikt.<\/p>\n

\"R\u00e4dsla
\n
\nDen kanoniska SDLC \u00e4r starkt detaljerad i olika metoder \u2013 OpenSAMM, BSIMM, OWASP. Metoderna skiljer sig \u00e5t, men \u00f6vergripande liknar de varandra.<\/p>\n

Bygg s\u00e4kerhet in i mognadsmodellen<\/h3>\n

\nJag gillar mest BSIMM<\/b>\u00a0\u2014 Bygg s\u00e4kerhet in i mognadsmodellen<\/a><\/noindex>. Grunden i metoden \u00e4r att dela upp processen f\u00f6r applikationss\u00e4kerhet i 4 dom\u00e4ner: Governance, Intelligence, SSDL Touchpoints och Deployment. I varje dom\u00e4n finns 12 praktiker som presenteras i form av 112 aktiviteter.<\/p>\n

\"R\u00e4dsla
\n
\nVarje av de 112 aktiviteterna har 3 mognadsniv\u00e5er<\/b>: grundl\u00e4ggande, medel och avancerad. Alla 12 praktiker kan studeras avsnitt f\u00f6r avsnitt, v\u00e4lja viktiga f\u00f6r er och f\u00f6rst\u00e5 hur de ska implementeras och gradvis l\u00e4gga till element, till exempel statisk och dynamisk kodanalys eller code review. Ni skriver en plan och arbetar lugnt enligt den i implementeringen av de valda aktiviteterna.<\/p>\n

Varf\u00f6r DevSecOps<\/h2>\n

<\/p>\n

DevOps \u00e4r en stor helhet d\u00e4r man m\u00e5ste ta ansvar f\u00f6r s\u00e4kerheten.<\/p><\/blockquote>\n

\nUrsprungligen DevOps<\/b><\/a><\/noindex> antog s\u00e4kerhetskontroller. I praktiken var s\u00e4kerhetsteamen mycket mindre \u00e4n idag, och de fungerade inte som deltagare i processen, utan som en kontroll- och tillsynsorganisation som st\u00e4ller krav och kontrollerar kvaliteten p\u00e5 produkten i slutet av release. Detta \u00e4r den klassiska metoden d\u00e4r s\u00e4kerhetsteamen stod bakom en v\u00e4gg fr\u00e5n utvecklingen och inte deltog i processen.<\/p>\n

\"R\u00e4dsla
\n
\nHuvudproblemet ligger just i att s\u00e4kerheten \u00e4r separat fr\u00e5n utvecklingen. Vanligtvis \u00e4r det en s\u00e4kerhetskontur med 2-3 stora och dyra verktyg. En g\u00e5ng var sj\u00e4tte m\u00e5nad kommer k\u00e4llkoden eller applikationen som beh\u00f6ver kontrolleras, och en g\u00e5ng om \u00e5ret g\u00f6rs pentester<\/a><\/noindex>. Detta leder till att tidslinjen f\u00f6r produktlansering f\u00f6rsenas, och utvecklaren f\u00e5r en enorm m\u00e4ngd s\u00e5rbarheter fr\u00e5n automatiserade verktyg. Allt detta \u00e4r om\u00f6jligt att sortera ut och \u00e5tg\u00e4rda, eftersom resultaten fr\u00e5n tidigare sex m\u00e5nader inte har sorterats, och h\u00e4r kommer en ny bunt.<\/p>\n

Under v\u00e5rt f\u00f6retags arbete ser vi att s\u00e4kerhet inom alla omr\u00e5den och industrier f\u00f6rst\u00e5r att det \u00e4r dags att samarbeta med utvecklingen \u2013 i\u00a0Agile<\/b><\/a><\/noindex>. DevSecOps-paradigmet passar utm\u00e4rkt in i metoden f\u00f6r agil utveckling, f\u00f6r implementering, st\u00f6d och deltagande i varje release och iteration.<\/p>\n

\"R\u00e4dsla
\n<\/p>\n

\u00d6verg\u00e5ngen till DevSecOps<\/h2>\n

\nDet viktigaste ordet i s\u00e4kerhetsutvecklingslivscykeln \u00e4r \"process\"<\/b>Du m\u00e5ste f\u00f6rst\u00e5 detta innan du t\u00e4nker p\u00e5 att k\u00f6pa verktyg.<\/p>\n

Att bara inkludera verktyg i DevOps-processen \u00e4r inte tillr\u00e4ckligt - det \u00e4r viktigt med samverkan och f\u00f6rst\u00e5else mellan deltagarna i processen.<\/p><\/blockquote>\n

<\/p>\n

M\u00e4nniskor \u00e4r viktigare \u00e4n verktygen.<\/h3>\n

\nOfta b\u00f6rjar planeringen av en s\u00e4ker utvecklingsprocess med valet och k\u00f6pet av verktyg, och slutar med f\u00f6rs\u00f6k att integrera verktyget i den p\u00e5g\u00e5ende processen, som ofta f\u00f6rblir just f\u00f6rs\u00f6k. Detta leder till sorgliga konsekvenser, eftersom varje verktyg har sina egna egenskaper och begr\u00e4nsningar.<\/p>\n

Ett vanligt fall \u00e4r n\u00e4r s\u00e4kerhetsavdelningen valt ett bra, dyrt verktyg med m\u00e5nga m\u00f6jligheter och kom till utvecklarna f\u00f6r att integrera det i processen. Men det fungerar inte - processen \u00e4r s\u00e5dan att begr\u00e4nsningarna f\u00f6r det redan ink\u00f6pta verktyget inte passar in i den nuvarande paradigm.<\/p>\n

B\u00f6rja med att beskriva vilket resultat du vill ha och hur processen ska se ut. Detta hj\u00e4lper till att f\u00f6rst\u00e5 verktygets och s\u00e4kerhetens roller i processen.<\/p><\/blockquote>\n

<\/p>\n

B\u00f6rja med det som redan anv\u00e4nds.<\/h3>\n

\nInnan du k\u00f6per dyra verktyg, ta en titt p\u00e5 vad du redan har. Varje f\u00f6retag har s\u00e4kerhetskrav som st\u00e4lls p\u00e5 utvecklingen, det finns granskningar, pentester - varf\u00f6r inte omvandla allt detta till en begriplig och anv\u00e4ndarv\u00e4nlig form?<\/p>\n

Vanligtvis \u00e4r kraven en pappersh\u00f6g som ligger p\u00e5 hyllan. Det har funnits fall d\u00e4r vi kommer till ett f\u00f6retag f\u00f6r att titta p\u00e5 processerna och ber om att f\u00e5 se s\u00e4kerhetskraven f\u00f6r mjukvaran. Specialisten som hanterade detta letade l\u00e4nge:<\/p>\n

- Nu, n\u00e5gonstans i anteckningarna var det en v\u00e4g till det h\u00e4r dokumentet.<\/i><\/p>\n

Till slut fick vi dokumentet efter en vecka.<\/p>\n

F\u00f6r krav, kontroller och annat, skapa en sida, till exempel p\u00e5\u00a0Confluence<\/b>\u00a0\u2013 det \u00e4r praktiskt f\u00f6r alla.<\/p>\n

Det \u00e4r enklare att omforma det som redan finns och anv\u00e4nda det som start.<\/p><\/blockquote>\n

<\/p>\n

Anv\u00e4nd Security Champions. <\/h3>\n

\nVanligtvis, i ett medelstort f\u00f6retag med 100-200 utvecklare, arbetar en s\u00e4kerhetsansvarig som utf\u00f6r flera funktioner och har fysiskt sv\u00e5rt att kolla allt. \u00c4ven om han f\u00f6rs\u00f6ker sitt b\u00e4sta - ensam kan han inte kontrollera hela koden som utvecklarna genererar. F\u00f6r s\u00e5dana fall har konceptet balanserats - Security Champions<\/b><\/a><\/noindex>.<\/p>\n

Security Champions \u00e4r en person inom utvecklingsteamet som \u00e4r intresserad av s\u00e4kerheten i din produkt.<\/p><\/blockquote>\n

\"R\u00e4dsla
\n
\nSecurity Champion \u00e4r ing\u00e5ngen till utvecklingsteamet och s\u00e4kerhetens evangelist i en och samma person.<\/p>\n

Vanligtvis, n\u00e4r en s\u00e4kerhetsexpert kommer till utvecklingsteamet och p\u00e5pekar ett fel i koden, f\u00e5r de ett f\u00f6rv\u00e5nat svar:<\/p>\n

\u2014 Vem \u00e4r du? Jag ser dig f\u00f6r f\u00f6rsta g\u00e5ngen. Jag m\u00e5r bra \u2014 min seniora kollega gav godk\u00e4nt p\u00e5 code review, vi g\u00e5r vidare!<\/i><\/p>\n

Detta \u00e4r en typisk situation, eftersom det finns mycket st\u00f6rre f\u00f6rtroende f\u00f6r seniorer eller bara kollegor i teamet som utvecklaren st\u00e4ndigt interagerar med i sitt arbete och under code review. Om Security Champion ist\u00e4llet p\u00e5pekar felet och konsekvenserna kommer deras ord att v\u00e4ga tyngre.<\/p>\n

Utvecklare k\u00e4nner ocks\u00e5 till sin kod b\u00e4ttre \u00e4n n\u00e5gon s\u00e4kerhetsexpert. F\u00f6r en person som har minst 5 projekt i verktyget f\u00f6r statisk analys \u00e4r det vanligtvis sv\u00e5rt att komma ih\u00e5g alla detaljer. Security Champions k\u00e4nner sitt produkt: vad som interagerar med vad och vad som b\u00f6r beaktas f\u00f6rst \u2014 de \u00e4r mer effektiva.<\/p>\n

S\u00e5 t\u00e4nk p\u00e5 att implementera Security Champions och ut\u00f6ka s\u00e4kerhetsteamets inflytande. F\u00f6r sj\u00e4lva m\u00e4staren \u00e4r detta ocks\u00e5 f\u00f6rdelaktigt: professionell utveckling inom ett nytt omr\u00e5de, utvidgning av teknisk kunskap, f\u00f6rb\u00e4ttring av tekniska, ledarskaps- och ledarniv\u00e5er, \u00f6kad marknadsv\u00e4rde. Det \u00e4r en viss form av social ingenj\u00f6rskonst, dina \"\u00f6gon\" i utvecklingsteamet.<\/p>\n

Testningssteg<\/h2>\n

\nParadigmet 20 av 80<\/a><\/noindex>\u00a0anger att 20% av insatserna ger 80% av resultaten. Dessa 20% \u00e4r praxis f\u00f6r analys av applikationer som kan och b\u00f6r automatiseras. Exempel p\u00e5 s\u00e5dana aktiviteter \u00e4r statisk analys \u2014 SAST<\/b>, dynamisk analys \u2014 DAST,<\/b> och\u00a0kontroll av Open Source<\/b>. Jag kommer att ber\u00e4tta mer om aktiviteterna samt om de verktyg och specifika egenskaper vi vanligtvis st\u00f6ter p\u00e5 n\u00e4r vi implementerar dem i processen, och hur man g\u00f6r det korrekt.<\/p>\n

\"R\u00e4dsla
\n<\/p>\n

Huvudproblem med verktygen<\/h3>\n

\nJag kommer att lyfta fram aktuella problem f\u00f6r alla verktyg som kr\u00e4ver uppm\u00e4rksamhet. Jag kommer att g\u00e5 igenom dem mer ing\u00e5ende f\u00f6r att undvika upprepning.<\/p>\n

L\u00e5ngsam analys. <\/b>Om det tar 30 minuter fr\u00e5n commit till produktionslansering f\u00f6r alla tester och byggprocessen, kommer s\u00e4kerhetskontrollerna att ta ett dygn. Ingen kommer att vilja bromsa processen. T\u00e4nk p\u00e5 denna aspekt och dra slutsatser.<\/p>\n

H\u00f6g niv\u00e5 av False Negative eller False Positive. <\/b>Alla produkter \u00e4r olika, alla anv\u00e4nder olika ramverk och sin egen kodstil. P\u00e5 olika kodbaser och teknologier kan verktygen visa olika niv\u00e5er av False Negative och False Positive. S\u00e5 se p\u00e5 vad som faktiskt g\u00e4ller f\u00f6r\u00a0ert<\/b> f\u00f6retag och era<\/b> applikationer, som kommer att ge bra och tillf\u00f6rlitliga resultat.<\/p>\n

Det finns inga integrationer med befintliga verktyg<\/b>. Titta p\u00e5 verktygen ur integrationsperspektiv, baserat p\u00e5 det ni redan anv\u00e4nder. Till exempel, om ni anv\u00e4nder Jenkins eller TeamCity \u2014 kontrollera integrationen av verktygen med just denna programvara, och inte med GitLab CI, som ni inte anv\u00e4nder.<\/p>\n

Avsaknad eller \u00f6verdriven komplexitet av anpassningar. <\/b>Om verktyget inte har ett API, varf\u00f6r skulle det d\u00e5 vara n\u00f6dv\u00e4ndigt? Allt som kan g\u00f6ras i gr\u00e4nssnittet b\u00f6r ocks\u00e5 vara tillg\u00e4ngligt via API. I en idealisk situation b\u00f6r verktyget ha m\u00f6jlighet att anpassa kontroller.<\/p>\n

Ingen produktutvecklingsplan. <\/b>Utvecklingen st\u00e5r inte still, vi anv\u00e4nder alltid nya ramverk och funktioner, och skriver om gammal kod till nya spr\u00e5k. Vi vill vara s\u00e4kra p\u00e5 att verktyget vi k\u00f6per kommer att st\u00f6dja nya ramverk och teknologier. D\u00e4rf\u00f6r \u00e4r det viktigt att veta att produkten har en verklig och korrekt Roadmap<\/a><\/noindex> utvecklingsplan.<\/p>\n

Processens s\u00e4rdrag<\/h3>\n

\nF\u00f6rutom verktygens s\u00e4rdrag b\u00f6r ni ocks\u00e5 ta h\u00e4nsyn till utvecklingsprocessens s\u00e4rdrag. Till exempel, att st\u00f6ra utvecklingen \u00e4r ett typiskt misstag. L\u00e5t oss titta p\u00e5 vilka andra s\u00e4rdrag som b\u00f6r beaktas och vad s\u00e4kerhetsteamet b\u00f6r fokusera p\u00e5.<\/p>\n

F\u00f6r att inte f\u00f6rsena utvecklings- och lanseringsscheman, skapa olika regler<\/b> och show stoppers\u00a0<\/b>\u2014 kriterier som stoppar byggprocessen vid f\u00f6rekomst av s\u00e5rbarheter \u2014 f\u00f6r olika milj\u00f6er<\/b>. Till exempel, vi f\u00f6rst\u00e5r att den aktuella grenen g\u00e5r till utvecklingsmilj\u00f6n eller UAT, vilket betyder att vi inte stoppar eller s\u00e4ger:<\/p>\n

\u2014 H\u00e4r finns s\u00e5rbarheter, ni kan inte g\u00e5 vidare!<\/i><\/p>\n

I detta skede \u00e4r det viktigt att informera utvecklarna om att det finns s\u00e4kerhetsproblem som de b\u00f6r uppm\u00e4rksamma.<\/p>\n

N\u00e4rvaron av s\u00e5rbarheter \u00e4r inget hinder f\u00f6r fortsatt testning<\/b>: manuell, integrations- eller manuellt. \u00c5 andra sidan beh\u00f6ver vi p\u00e5 n\u00e5got s\u00e4tt \u00f6ka produktens s\u00e4kerhet s\u00e5 att utvecklarna inte ignorerar det som s\u00e4kerheten uppt\u00e4cker. D\u00e4rf\u00f6r g\u00f6r vi ibland s\u00e5 h\u00e4r: vid stand-upen, n\u00e4r det lanseras p\u00e5 utvecklingsmilj\u00f6n, informerar vi helt enkelt utvecklingen:<\/p>\n

\u2014 Grabbar, ni har problem, v\u00e4nligen ta en titt p\u00e5 dem.<\/i><\/p>\n

Under UAT-steget visar vi \u00e5terigen varningar om s\u00e5rbarheter, och n\u00e4r vi g\u00e5r live s\u00e4ger vi:<\/p>\n

\u2014 Grabbar, vi har varnat flera g\u00e5nger, ni har inte gjort n\u00e5got \u2013 vi kan inte sl\u00e4ppa ut er med detta.<\/i><\/p>\n

Om vi pratar om kod och dynamik, s\u00e5 \u00e4r det n\u00f6dv\u00e4ndigt att bara visa och varna f\u00f6r s\u00e5rbarheterna i de funktioner och koder som just har skrivits i denna funktion. Om utvecklaren flyttade en knapp med 3 pixlar och vi s\u00e4ger till honom att han har en SQL-injektion och d\u00e4rf\u00f6r m\u00e5ste fixa detta omedelbart \u2013 det \u00e4r fel. Titta bara p\u00e5 det som har skrivits nu och p\u00e5 den \u00e4ndring som kommer till applikationen.<\/p>\n

L\u00e5t oss s\u00e4ga att vi har en viss funktionell defekt \u2013 det som applikationen inte ska g\u00f6ra: pengar \u00f6verf\u00f6rs inte, det blir inget klick p\u00e5 knappen som leder till n\u00e4sta sida eller varan laddas inte. S\u00e4kerhetsdefekter<\/b>\u00a0\u2014 det \u00e4r samma typ av defekter, men inte i termer av applikationens funktion, utan av s\u00e4kerhet. <\/p>\n

Inte alla problem med mjukvarukvalitet \u00e4r s\u00e4kerhetsproblem. Men alla s\u00e4kerhetsproblem \u00e4r relaterade till mjukvarukvalitet. Sherif Mansour, Expedia.<\/p><\/blockquote>\n

\nEftersom alla s\u00e5rbarheter \u00e4r samma typ av defekter, b\u00f6r de finnas d\u00e4r d\u00e4r alla utvecklingsdefekter finns. S\u00e5 gl\u00f6m rapporterna och de skr\u00e4mmande PDF:erna som ingen l\u00e4ser.<\/p>\n

\"R\u00e4dsla
\n
\nN\u00e4r jag arbetade p\u00e5 ett f\u00f6retag som sysslade med utveckling fick jag en rapport fr\u00e5n verktyg f\u00f6r statisk analys. Jag \u00f6ppnade den, blev f\u00f6rskr\u00e4ckt, gjorde kaffe, bl\u00e4ddrade igenom 350 sidor, st\u00e4ngde den och gick tillbaka till mitt arbete. Stora rapporter \u00e4r d\u00f6da rapporter<\/b>. Ofta g\u00e5r de ingenstans, e-postmeddelanden raderas, gl\u00f6ms bort, tappar bort eller s\u00e5 s\u00e4ger aff\u00e4rssidan att de accepterar riskerna.<\/p>\n

Vad ska man g\u00f6ra? De bekr\u00e4ftade defekter som har hittats omvandlar vi helt enkelt till en utvecklingsv\u00e4nlig form, till exempel genom att l\u00e4gga dem i backloggen i Jira. Vi prioriterar defekterna och \u00e5tg\u00e4rdar dem i prioritetsordning tillsammans med funktionella defekter och testdefekter.<\/p>\n

Statisk analys - SAST<\/h2>\n

\nDetta \u00e4r en analys av koden f\u00f6r att uppt\u00e4cka s\u00e5rbarheter.<\/b>, men det \u00e4r inte detsamma som SonarQube. Vi kontrollerar inte bara utifr\u00e5n m\u00f6nster eller stil. Under analysen till\u00e4mpas en rad tillv\u00e4gag\u00e5ngss\u00e4tt: efter s\u00e5rbarhetsstrukturen, genom\u00a0DataFlow<\/a><\/noindex>, genom analys av konfigurationsfiler. Det handlar allt om koden.<\/p>\n

F\u00f6rdelar med tillv\u00e4gag\u00e5ngss\u00e4ttet<\/b>: uppt\u00e4ckte s\u00e5rbarheter i koden i ett tidigt skede av utvecklingen<\/b>, n\u00e4r det \u00e4nnu inte finns n\u00e5gra milj\u00f6er eller f\u00e4rdiga verktyg, och\u00a0m\u00f6jligheten till inkrementell skanning<\/b>: skanning av den del av koden som har \u00e4ndrats, och endast den funktion som vi just nu arbetar med, vilket minskar skanningstiden.<\/p>\n

Nackdelar<\/b>\u00a0\u2014 det \u00e4r avsaknaden av st\u00f6d f\u00f6r n\u00f6dv\u00e4ndiga spr\u00e5k.<\/p>\n

N\u00f6dv\u00e4ndiga integrationer, <\/b>som b\u00f6r finnas i verktygen, enligt min subjektiva \u00e5sikt:<\/p>\n