Voitot:
- Kyky käyttää tekoälyä toisena silmänä ja merkitä OWASP-luokan haavoittuvuudet (injektio, kova salaisuus, pääsynhallinta) koodissa antamalla konteksti
- Kyky eliminoida tekoälyn tuottamat väärät positiiviset tulokset kontekstin kanssa ja estää jokaisen löydön käsittelemisen todellisena haavoittuvuudena ilman sen validointia
- Kyky tunnistaa, että tekoälyn ehdottama korjaus saattaa tuoda mukanaan uusia haavoittuvuuksia/virheitä ja siirtää jokaisen korjaustiedoston tarkistus- ja testausportin läpi
Ohjelmiston haavoittuvuudet ovat kalleimpia haavoittuvuuksia, koska ne on upotettu tuotteeseen alusta alkaen ja jaettu miljoonille käyttäjille. Suojattu koodin tarkistus on prosessi, jossa luetaan lähdekoodi rivi riviltä ja havaitaan haavoittuvuuksia – SQL-injektio, todennushaavoittuvuus, kovakoodattu salasana, virheellinen valtuutus – ennen kuin ne tulevat tuotantoon. Käsin tehtynä se on hidasta ja väsyttävää; Suuren koodikannan haavoittuvuus on helppo missata.
Tekoäly on tehokas koodintarkistuksessa kahdesta syystä: koodi on myös kieli ja tekoäly on hyvä hahmontunnistuksessa. Tekoäly voi nopeasti merkitä vaaralliset kuviot koodinpätkässä (käyttäjän syötteen lisääminen suoraan kyselyyn, salaamaton tiedon tallennus, puuttuvan syötteen validointi), selittää, miksi jokainen on riskialtista, ja ehdottaa korjausta. Mutta tekoäly ei näe koodin koko toimintakontekstia (syöte saatetaan tyhjentää toisella kerroksella), se voi keksiä haavoittuvuuden, jota ei ole olemassa (väärä positiivinen) tai missata todellisen haavoittuvuuden (väärä negatiivinen), ja mikä tärkeintä, sen ehdottama "korjaus" voi tuoda esiin uuden haavoittuvuuden tai bugin. AI on toinen silmä ja osoitin koodin tarkistuksessa; Kehittäjä ja tietoturvaasiantuntija päättävät, onko löydös todellinen haavoittuvuus ja onko korjaus oikea ja turvallinen.
Koodin tarkistuksen vaiheet
- Anna laajuus ja konteksti. Mikä kieli, mikä kehys, mistä tämä koodi ottaa syötteen, mistä se antaa tulosteen, millä tasolla se toimii? Koodin tarkistus ilman kontekstia tuottaa vääriä positiivisia tuloksia.
- Etsi vaarallisia kuvioita. Etsi tunnettuja tekoälyn haavoittuvuusluokkia (kuten OWASP Top 10): injektio, todennus, arkaluonteisten tietojen paljastaminen, kulunvalvonta.
- Perustele jokainen havainto. Jokaiselle lipulle: mikä rivi, mikä haavoittuvuusluokka, miten sitä voidaan hyödyntää, mitä todisteita on. Perusteetonta havaintoa ei oteta vakavasti.
- Poista väärä positiivinen. Onko syöte todella tyhjennetty, onko polku todella käytettävissä - tarkista kontekstin perusteella.
- Tarkista korjaus. Varmista, että tekoälyn suosittelema korjaustiedosto todella sulkee haavoittuvuuden, ei tuo uusia haavoittuvuuksia/virheitä ja että se on läpäissyt testauksen.
- Ihmisen hyväksyntä. Kehittäjä + tietoturva-asiantuntija tarkistaa löydön ja korjaa; Näin se tulee koodivarastoon.
Termit: SAST (Static Application Security Testing – staattinen tietoturvatestaus, joka analysoi lähdekoodia suorittamatta sitä). DAST (Dynamic – dynaaminen testaus, joka testaa käynnissä olevan sovelluksen ulkoisesti). OWASP Top 10 on tavallinen luettelo yleisimmistä verkkosovellusten haavoittuvuuksista. Injektio on haavoittuvuus, joka johtuu käyttäjän syötteen tulkitsemisesta komennona/kyselynä (esim. SQL-injektio). Parametrisoitu kysely on oikea menetelmä, joka estää lisäyksen erottamalla syötteen koodista.
Taulukko yleisistä haavoittuvuusluokista
Haavoittuvuusluokka
Oire (koodissa)
oikea ratkaisu
AI:n ansa
SQL-injektio
Syötteen liittäminen kyselyyn
Parametrisoitu kysely
Desinfioinnin voi jättää huomiotta
kova koodattu salaisuus
Salasana/näppäile koodi
Salainen tallelokero (holvi), ym
Väärä positiivinen (näyte/testi)
Heikko todennus
Puuttuva/virheellinen ohjaus
Tehokas, keskitetty ohjaus
kaipaa kontekstia
Viallinen kulunvalvonta
Ei valtuutuksen tarkistusta
Palvelinpuolen valtuutus
Ei ymmärrä monimutkaista virtausta
Arkaluonteisten tietojen paljastaminen
Salasanaton tallennus/lokikirjaus
Salaus, peittäminen
Ei voi tietää kriittisyyttä
Turvaton serialisointi
Suorita epäluotettavien tietojen sarjoittaminen
Turvallinen jäsentäminen
Harvinainen kuvio puuttuu
kolme minilaukkua
Tapaus 1 – Varsinaisen injektion kiinniotto. Kehittäjä pyytää tekoälyä tutkimaan tietojen käyttötoiminnon. Tekoäly merkitsee rivin, jossa käyttäjän userId-arvo ketjutetaan suoraan SQL-tekstiin ja sanoo "tämä on klassinen SQL-injektio, muuta se parametroiduksi kyselyksi"; Tarjoaa näytekorjauksen. Kehittäjä vahvistaa, että syötettä ei ole desinfioitu muualla, varmistaa, että se on todellinen haavoittuvuus, toteuttaa ehdotetun parametroidun kyselyn ja kirjoittaa testin. AI korosti haavoittuvuutta; varmistus- ja korjaustestaus tuli kehittäjältä.
Tapaus 2 – Väärä positiivinen kiinteä salaisuus. Tekoäly näkee tiedostossa salasanan = "test1234" ja sanoo "kriittinen: kovakoodattu salasana". Kehittäjä tarkistaa kontekstin: tämä on yksikkötestitiedosto, valetestidata, jota ei ole julkaistu tuotantoon eikä siirretty todelliseen järjestelmään. Löytö on väärä positiivinen. Kehittäjä dokumentoi tämän, mutta ei ryhdy toimiin, koska se ei ole todellinen salaisuus. Oppitunti: AI:n "kova salaisuus" -merkki on poistettava kontekstin perusteella; Jokainen merkkijono ei ole salaisuus.
Tapaus 3 – Uusi haavoittuvuuden korjaus. Tekoäly ehdottaa korjausta XSS-haavoittuvuuteen (cross-site scripting). mutta hänen ehdottamansa koodi tyhjentää syötteen väärässä paikassa ja ohittaa tulosteen koodauksen toisella alueella; Tämän seurauksena aukko ei sulkeudu kokonaan. Tietoturva-asiantuntija tarkistaa korjauksen, huomaa puuttuvan koodauksen ja korjaa sen oikealla tasolla. Oppitunti: tekoälyn suosittelema korjaustiedosto ei ole automaattisesti suojattu; Jokainen korjaus tarkistetaan ja testataan.
Heikko kehote / Vahva kehote
Heikko kehote:
Onko tässä koodissa porsaanreikä, korjaa se: [koodi]
Tämä kehote ei anna kontekstia (kieli, kehys, syöttölähde), ei vaadi perusteluja, ei kyseenalaista väärää positiivista ja on avoin sokeasti hyväksymään tekoälyn tuottama korjaus. Tekoäly sekoitti merkkejä sekä todellisesta haavoittuvuudesta että olemattomuudesta.
Tehokas kehotus:
Roolisi: avustaja, joka on TOINEN SILMÄ kehittäjälle suojatun koodin tarkistamisessa. Päätöksenteko; harkitse suoraan sovellettua korjausta. Koodi: [määritä kieli/kehys].Konteksti: tämä toiminto [syöttölähde: esim. vastaanottaa [ulkoisen HTTP-pyynnön], kirjoittaa [ulostulokohteeseen]. Tehtäväsi: (1) merkitse mahdolliset haavoittuvuudet OWASP-luokassa, anna rivinumero + miksi riskialtista + kuinka hyödynnetään + todisteet jokaiselle, (2) kirjoita vähintään 1 väärä positiivinen skenaario jokaiselle löydökselle (esim. jos syöte on desinfioitu toisella kerroksella), (3) ehdota korjausta, mutta "[tarkistaa + kirjoita testi]" -merkillä; Arvioi myös, tuoko korjaus uusia haavoittuvuuksia/virheitä. Väärennetyn haavoittuvuuden lisääminen.[code]
Vahva kehote antaa kontekstin, pyytää OWASP-luokkaa ja todisteita, kyseenalaistaa vääriä positiivisia tuloksia ja korjaamisen riskejä, pakottaa ihmisen arvioimaan.
Kopioitavat kehotemallit
HALUATTAVUUSSKANNAUSMALLI Tutki [kieli/kehys] OWASP Top 10 -koodia. Jokaisen mahdollisen löydön osalta: rivinumero, haavoittuvuusluokka, miksi se on riskialtista, esimerkki hyväksikäyttö, todisteiden vahvuus (varma/todennäköinen/heikko). Konteksti: tulo [lähde], lähtö [kohde]. Tekeellisten löydösten lisääminen; Jos et ole varma, kirjoita "[täytyy vahvistaa]". Koodi: [liitä]
VÄÄRÄ POSITIIVINEN POISTAMISKUVIO Luettele seuraavaa koodihakua varten skenaariot, joissa EI ole todellista haavoittuvuutta: voidaanko syöte tyhjentää toisessa kerroksessa, onko tämä polku käytettävissä, onko tämä arvo testi/näyte, onko kehys automaattisesti suojattu. Kirjoita jokaisen kohdalla vahvistusohjeet. Löytö: [liitä]
KORJAA ARVIOINTIMALLINESuosittele korjausta seuraavaan haavoittuvuuteen; sitten kritisoi omaa korjaustasi: (1) sulkeeko se todella haavoittuvuuden, (2) tuoko se uuden haavoittuvuuden/virheen, (3) mikä testi minun pitäisi kirjoittaa (positiivinen ja negatiivinen tapaus), (4) vaikutus suorituskykyyn/toiminnallisuuteen. Tarkistan ja testaan korjauksen. Haavoittuvuus + koodi: [liitä]
TURVALLINEN KUVION OPETUSMALLI haavoittuvuusluokalle [esim. SQL-injektio] näyttää suhteellisen turvallisen kirjoituskuvion ja yleiset virheelliset mallit tällä kielellä/kehyksellä. Yleissääntö + anna koodiesimerkki; mutta haluan sinun kysyvän kontekstia ennen kuin otat sen käyttöön koodissani. Kieli/kehys: [kirjoita]
Yleisiä virheitä
- Arvostelu ilman kontekstia. Ilman kieltä, viitekehystä ja syöttö-/tulostuskontekstia tekoäly sekoittaa sekä todelliset että harhaanjohtavat havainnot; Muista antaa konteksti.
- Ymmärtää jokainen merkki todelliseksi heikkoudeksi. AI tuottaa vääriä positiivisia tuloksia (testitiedot, syöte puhdistetaan toisesta kerroksesta); Seuloa jokainen löytö kontekstin kanssa.
- Sokeasti soveltamalla tekoälyn korjausta. Suositeltu korjaustiedosto saattaa sisältää uusia haavoittuvuuksia/virheitä; tarkistaa ja kirjoittaa testejä.
- Luottaen väärään negatiiviseen. Vaikka tekoäly sanoo "ei haavoittuvuuksia", tutki kriittiset polut itse; Staattinen tarkistus ei havaitse kaikkia haavoittuvuuksia.
- Koodin/salaisuuden antaminen ulkoiselle työkalulle. Yksityinen koodi ja todelliset salaisuudet (avain, salasana) ovat immateriaaliomaisuutta ja haavoittuvuutta; anonymisoida tai käyttää yksittäisiä yritystyökaluja.
Vinkki: Kun käytössä on tekoälyn tarkistuskoodi, tehokkain suodatin on kysyä "todisteen vahvuus" (varma/todennäköinen/heikko) jokaiselle löydökselle. Useimmat "heikoiksi" merkityt löydökset ovat vääriä positiivisia; kohdistat energiasi "varmille".
Varoitus: AI:n ehdottama tietoturvakorjaus ei saa tulla varastoon ilman testausta. Virheellinen "korjaus" voi sekä jättää haavoittuvuuden avoimeksi että johtaa toiminnalliseen virheeseen tuotannossa; Jokainen korjaustiedosto menee tarkistus- ja testausportin läpi.
Yhteenvetona
Suojattu koodin tarkistus on halvin tapa havaita haavoittuvuudet ennen kuin ne tulevat tuotantoon, ja koska koodi on kieli, tekoälystä tulee tässä tehokas toinen silmä: merkitsee vaarallisia malleja, selittää riskit, ehdottaa korjauksia. Mutta tekoäly ei näe koko toimintakontekstia, tuottaa vääriä positiivisia ja vääriä negatiivisia, ja sen suosittelema korjaustiedosto voi tuoda uusia haavoittuvuuksia. Tarkastuksessa on siis kuusi vaihetta (konteksti, seulonta, perustelu, väärän positiivisen poistaminen, korjausvarmennus, ihmisen hyväksyntä) ja päätöksen tekee kehittäjä ja tietoturvaasiantuntija. Kolme periaatetta: mitään löytöä ei tulkita ilman kontekstia, jokainen merkki eliminoidaan kontekstin kanssa, mikään korjaus ei mene varastoon testaamattomana. Ja koodia/salaisuutta ei koskaan anneta ulkopuoliselle työkalulle ilman anonymisointia.
Sovellustehtävä
Ota mallikoodinpätkä (joko poistamalla arkaluonteisia osia omasta koodistasi tai esimerkkikoodista, jossa on haavoittuvuuksia). Pyydä tekoälyä tutkimaan se "Vulnerability Scanning" -mallin avulla; Käytä "Väärä positiivinen eliminointi" -mallia jokaiselle löydökselle ja poista oikeat löydökset. Tee vakavimman löydön korjaus "Remediation Evaluation" -mallin avulla, tarkista se itse ja kirjoita yksi positiivinen + yksi negatiivinen testitapaus. Huomaa, kuinka monet löydökset olivat vääriä positiivisia.
tarkistuslista
- [ ] Annoin kielen, kehyksen ja syöttö-/tulostuskontekstin ennen koodin tarkistamista.
- [ ] Pyysin rivinumeroa, haavoittuvuusluokkaa, hyväksikäyttöpolkua ja todisteita jokaisesta löydöstä.
- [ ] Tarkastin jokaisen löydön väärien positiivisten tulosten varalta kontekstin kanssa.
- [ ] En käyttänyt sokeasti tekoälyn korjausta; Tarkistin ja kirjoitin testin.
- [ ] "Ei haavoittuvuuksia" -tuloksesta huolimatta tutkin kriittiset polut itse.
- [ ] Anonymisoin koodin/salaisuudet tai käytin yrityksen eristettyjä työkaluja.
- [ ] Olen läpäissyt löydön ja korjauksen kehittäjän + suojaushyväksynnän kautta.