Palaist a koda kvalitātes pārbaude uz koda bāzes, un jūs saņemat pārskatu par sarežģītību, dublēšanos, nederīgu kodu un nosaukumu piešķiršanu. Palaidiet code security pārbaudīt uz tās pašas koda bāzes, un jūs saņemat pārskatu par SQL injekcija, vietņu skriptu izveide, un autentifikācijas trūkumiTie paši faili. Divas atskaites. Parasti divi dažādi rīki, divi dažādi dashboards, un divas komandas, kas reti salīdzina savas pozīcijas.
Šis sadalījums programmatūras izstrādē ir tik ierasts, ka lielākā daļa komandu to vairs nepamana. Tas ir arī iemesls, kāpēc uzturēšanas problēma un drošības problēma vienā un tajā pašā funkcijā tiek uzskatītas par divām nesaistītām pieteikumiem, nevis vienu.
Lūk, ko katra pārbaude faktiski dara, kur tās pārklājas un kur darbojas “divu rīku” modelis.
Kas ir koda kvalitātes pārbaude?
Koda kvalitātes pārbaude ir statiskas analīzes process, kas mēra, cik viegli uzturējama, lasāma un strukturāli pamatota ir koda bāze neatkarīgi no tā, vai to var izmantot. Tā nejautā: "Vai uzbrucējs var to uzlauzt?". Tā jautā: "Vai izstrādātājs var to droši mainīt pēc sešiem mēnešiem?".
Koda kvalitātes pārbaude parasti novērtē:
- Kods smaržostrukturālie modeļi, kas laika gaitā apgrūtina koda maiņu
- Ciklomātiskā un kognitīvā sarežģītība: funkcijas un klases, kas ir izaugušas tiktāl, ka ikviens tās var droši modificēt
- Uzturēšana: kopējās izmaksas, kas saistītas ar darba turpināšanu noteiktā failā vai modulī
- Mirušais kodsnesasniedzams vai neizmantots kods, kas tiek pārskaitīts par pastāvīgu maksu
- Kopēšanakopēšanas un ielīmēšanas parāds, kur viens labojums jāveic piecās vietās, bet tiek veikts trijās
- Nosaukšanas konvencijaspārkāpumi, kas palielina katra nākamā lasītāja izmaksas
Koda kvalitātes pārbaudes rezultāts parasti ir rezultāts, tendences līnija un garš atradumu saraksts, kas sakārtoti pēc fiksēta noteikuma nopietnības, nevis pēc faktiskās ietekmes.
Kas ir a Code Security Pārbaudīt?
A code security pārbaude, formālāk Statiskā lietojumprogrammu drošības testēšana (SAST), skenē pirmkodu, lai atrastu izmantojamas ievainojamības, pirms lietojumprogramma tiek palaista. Tā meklē konkrētus modeļus, kas ļauj uzbrucējam darīt kaut ko tādu, ko lietojumprogramma nekad nebija paredzēta.
A code security pārbaude parasti uzķeras:
- Injekcijas defektiSQL injekcija, komandu injekcija, koda injekcija
- Starpvietņu skriptēšana (XSS): neattīrīta ievade, kas ļauj uzbrucējam palaist skriptus cita lietotāja sesijā
- Nepareizas konfigurācijas un informācijas noplūdeiestatījumi un koda ceļi, kas netīšām atklāj datus
- Bufera pārpildesatmiņas apstrādes problēmas, kas var apdraudēt lietojumprogrammas integritāti
- Autentifikācijas un autorizācijas nepilnībasvāja vai trūkstoša piekļuves kontrole
Secinājumi no a code security pārbaudiet, vai ir CWE klasifikācija, nopietnības pakāpe un (nobriedušos rīkos) pierādījumi par izmantojamību, kas atšķir nopietnu SAST rīks no tāda, kas tikai salīdzina modeļus un cer.
Koda kvalitātes pārbaude salīdzinājumā ar Code Security Pārbaudiet: Galvenās atšķirības
| Koda kvalitātes pārbaude | Code Security Pārbaudiet (SAST) | |
|---|---|---|
| Galvenais jautājums | Vai to var droši uzturēt? | Vai to var izmantot? |
| Ko tas mēra | Sarežģītība, dublēšanās, nedzīvs kods, nosaukšana, uzturēšanas iespējas | Injekcija, XSS, nepareiza konfigurācija, autentifikācijas kļūdas, atmiņas problēmas |
| Standard atsauce | Iekšējais kvalitātes modelis, nav universālas sertifikācijas standard | CWE (Common Weakness Enumeration — izplatītāko vājumu uzskaitījums), validēts pret tādiem kritērijiem kā OWASP |
| Tipisks īpašnieks | Inženierzinātnes / Inženierzinātņu viceprezidents | Lietotņu drošība / Izstrādātāju drošības darbība |
| Ignorēšanas sekas | Pieaugošās pārmaiņu izmaksas, lēnāka ieviešana, trauslas versijas | Datu noplūde, atbilstības pārkāpums, ražošanas sistēmas ļaunprātīga izmantošana |
| Kur tas darbojas | CI, lokālā CLI | CI, lokālā komandrindas saskarne un (modernākos rīkos) IDE |
Tās nav konkurējošas pārbaudes. Tās atbild uz diviem dažādiem jautājumiem par vienām un tām pašām koda rindām, tāpēc to atsevišķa palaišana rada problēmas.
Kāpēc vairums koda analīzes rīku tos tur atsevišķi
Lielākā daļa organizāciju jau veic abas pārbaudes. Tās vienkārši veic tās divos dažādos produktos, ar divām dažādām konsolēm, diviem dažādiem uzdevumu reģistriem un diviem dažādiem prioritāšu modeļiem, izmantojot vienus un tos pašus repozitorijus.
Šis sadalījums rada trīs paredzamas problēmas:
- Neviens neredz abus kavējumus kopā. Funkcija ar kritisku drošības atradumu un uzturēšanas rādītāju bīstamajā zonā parādās kā divas atvienotas pieprasījuma atbildes divos atvienotos rīkos, lai gan patiesībā tā ir viena koda daļa, kurai jāpievērš uzmanība divreiz steidzamāk.
- Atklājumi krājas ātrāk, nekā kāds tos var salabot. Visi tirgū pieejamie koda analīzes rīki labi identificē problēmas. Problēmas nekad nav bijušas saistītas ar problēmu atrašanu. Tā ir tā, ka kvalitatīva skenēšana vai drošības skenēšana jebkurā reālā koda bāzē sniedz vairāk atradumu, nekā jebkurai komandai ir stundas, lai ar tiem strādātu, un nemainīga nopietnības pakāpe nepasaka, kuri desmit ir jālabo vispirms.
- Fiksēta noteikuma stingrība nav prioritāte. “Kritisks” no noteikumu dzinēja puses un “kritisks, jo tas faktiski ir sasniedzams un izmantojams” ir dažādi apgalvojumi. Lielākā daļa koda analīzes rīku izsaka tikai pirmo apgalvojumu.
Labāks veids: viena platforma, viens mākslīgais intelekts, viens prioritāšu modelis
Xygeni vada koda kvalitāti un code security analīze vienā un tajā pašā skenerī, tajā pašā konsolē un tajā pašā prioritāšu modelī, tāpēc uzturēšanas problēma un drošības trūkums vienā un tajā pašā failā ir redzami kopā, nevis atrodas divās nesaistītās sistēmās.
- Mērs. Ksigēni code security pārbaudīt (SAST) skenē injekcijas kļūdas, XSS, nepareizas konfigurācijas, bufera pārpildes un autentifikācijas vājumus, katram atradumam piešķirot CWE klasifikāciju. Xygeni koda kvalitātes pārbaude veic vienu un to pašu analīzes disciplīnu desmit valodās: Java, JavaScript, Python, PHP, C#, Go, HTML, Swift, Kotlin un C/C++, mērot sarežģītību, uzturēšanas iespējas, dublēšanos, nederīgu kodu un nosaukšanu vienā konsekventā sistēmā. standard, tāpēc kvalitātes konstatējumiem ir tāds pats nopietnības līmenis, CWE (attiecīgā gadījumā) un failu un rindu detalizētība kā drošības konstatējumiem.
- Noteikt prioritāti. Abi pārbaužu veidi tiek izmantoti vienā un tajā pašā mākslīgā intelekta triāžas piltuvē, kas sakārto atradumus pēc reālās ietekmes, nevis fiksēta noteikuma nopietnības, un abi piedalās vienotā visu risku skatā, tāpēc drošības vadītājs un inženierijas vadītājs aplūko vienu un to pašu riska ainu, nevis divas atsevišķas izklājlapas.
- Novērst. Xygeni neapstājas pie identificēšanas. AI Remediation piedāvā gatavus labojumus drošības nepilnībām, tostarp pull request izveidei, un to pašu dara ar kvalitatīviem atradumiem, kas sakārtoti pēc labošanas sarežģītības ar aptuveno ietaupīto piepūli. Jautājums, uz kuru koda analīzes rīkam vajadzētu atbildēt, nav "cik daudz noteikumu jums ir". Bet gan "kad tas atrod tūkstoš problēmu, kas tās novērš?"
Tas darbojas neatkarīgi no tā, vai atradumi ir iegūti no Xygeni pašu skeneriem vai no trešo pušu rīkiem, kas jau ir integrēti platformā. Mākslīgā intelekta triāža un mākslīgā intelekta labošana attiecas gan uz Xygeni pašu drošības atradumiem, gan uz drošības atradumiem, kas iegūti no tādiem rīkiem kā Snyk, Veracode vai Checkmarx, tāpēc pāreja uz vienotu pārbaudi nenozīmē vispirms kaut ko izvilkt.
Kas jāmeklē koda analīzes rīkos
Ja jūs novērtējat koda analīzes rīkus, neatkarīgi no tā, vai tie ir paredzēti koda kvalitātes pārbaudei vai code security pārbaudiet vai abus, daži jautājumi ātri palīdz tikt galā ar lielāko daļu pārdevēju piedāvājumu:
- Vai tajā atklājumi tiek klasificēti pēc reālās ietekmes vai tikai pēc fiksēta noteikuma nopietnības? Smaguma pakāpes etiķete nav prioritātes noteikšana.
- Vai tas apstiprina savu noteikšanas precizitāti, salīdzinot ar neatkarīgu etalonu? SAST Precizitātes apgalvojumus ir viegli izvirzīt, bet grūti pierādīt; publicēts OWASP etalona rezultāts, atklājot patiesi pozitīvo un kļūdaini pozitīvo rezultātu rādītājus, ir atšķirība starp apgalvojumu un pierādījumiem.
- Vai noteikumi ir caurspīdīgi? Detektoru katalogs, ko varat pārlūkot pirms skenēšanas veikšanas, norāda, ko rīks pārbauda pirms skenēšanas veikšanas. commit uz to.
- Vai tas apstājas pie identificēšanas, vai arī piedāvā risinājumu? Atklājums bez ceļa uz labošanu ir ilgāks kavējums, nevis atrisināta problēma.
- Vai tas darbojas visā jūsu rīku komplektā, ieskaitot atradumus no jau izmantotajiem rīkiem? Redzamības konsolidēšana ir labāka nekā piegādātāju apvienošana pirmajā dienā.
- Vai tas integrējas ar to, kur jau notiek darbs? CI/CD pull request pārbaudes un drošības konstatējumu gadījumā IDE atgriezenisko saiti koda rakstīšanas laikā, ne tikai pēc tā apvienošanas.
Īsā versija
Koda kvalitātes pārbaudē tiek jautāts, vai jūsu kodu var droši uzturēt. code security Pārbaudē tiek jautāts, vai to var izmantot. Abi jautājumi ir svarīgi, abi sniedz atklājumus, uz kuriem jāreaģē, un, tos palaižot, izmantojot divus savstarpēji nesaistītus rīkus, viens un tas pats kods izskatās pēc divām atsevišķām problēmām, nevis viena prioritārā saraksta.
Ksigēni veic abas pārbaudes vienā skenerī, sarindo abas pēc reālās ietekmes vienā piltuvē un abas novērš ar pull requests tā vietā, lai atstātu jūs ar ilgāku kavēšanos.
Gribas redzēt savējo code security Vai atradumi ir prioritāri, nevis tikai uzskaitīti? Sāciet skenēšanu bez maksas, izmantojot Xygeni izstrādātāja plānu.
Vai vēlaties uzzināt vairāk par vienotu kvalitātes un drošības skatījumu visā jūsu portfelī? Pieprasīt demonstrāciju par Xygeni koda kvalitāti līdzās Code Security.
FAQ
Vai koda kvalitātes pārbaude ir tāda pati kā code security pārbaude?
Nē. Koda kvalitātes pārbaude mēra uzturēšanas iespējas, sarežģītību, dublēšanos un nosaukumu piešķiršanu. code security pārbaudīt (SAST) mēra izmantojamību: injekcijas kļūdas, XSS, nepareizas konfigurācijas un autentifikācijas vājās vietas. Tie analizē vienu un to pašu kodu, bet atbild uz dažādiem jautājumiem, un atradums var tikt atzīmēts ar kvalitātes karodziņu, drošības karodziņu vai abiem vienlaikus.
Kas ir SAST, un kā tas ir saistīts ar code security pārbaude?
SAST apzīmē statisko lietojumprogrammu drošības testēšanu. Tas ir tehniskais nosaukums tam, ko vairums cilvēku saprot ar “code security "check": pirmkoda skenēšana, lai noteiktu ievainojamības pirms lietojumprogrammas palaišanas, to neizpildot. Katru code security pārbaudiet šo ierakstu, kas attiecas uz SAST konkrēti, atšķirībā no DAST, kas testē darbojošos lietojumprogrammu no ārpuses.
Vai viens rīks var veikt gan koda kvalitātes pārbaudi, gan code security pārbaude?
Jā. Xygeni nodrošina koda kvalitāti un code security analīze vienā un tajā pašā skenerī un konsolē, tāpēc abiem pārbaužu veidiem ir viens prioritāšu modelis, nevis divi atsevišķi rīki ar diviem atsevišķiem uzdevumu reģistriem. Katra veida atradumiem joprojām ir sava klasifikācija (CWE drošībai, sarežģītības/uzturēšanas rādītāji kvalitātei).
Cik bieži jāveic koda kvalitātes pārbaude vai code security pārbaude?
Abiem vajadzētu darboties nepārtraukti, nevis kā vienreizējam auditam. standard raksts ir skenējums uz katra pull request CI, ar guardrails ka vārti tiek ņemti vērā, ņemot vērā jaunizveidotās problēmas, nevis visu mantoto nepabeigto darbu skaitu, tāpēc komandas tiek vērtētas pēc tā, ko tās ir pievienojušas, nevis pēc uzkrātā parāda gadiem.
