Võimalik, et lühiajaliselt on suurenenud ohupotentsiaal, sest võite garanteerida, et ründajad traageldavad koodi läbi nõrkade kohtade leidmiseks, kuid sama teevad ka paljud valged mütsid, samuti organisatsioonide koodide ülevaatamise meeskonnad kes kasutavad Kaspersky-d, seega võib probleeme leida, kuid lõpptulemus on tõenäoliselt turvalisem koodibaas, kui see muidu oleks võinud olla.

Paljud silmad ja kõik see.

Suhtelist riski on siiski raske hinnata, sest on suur tõenäosus, et ründajad on niikuinii juba vastupidi töötanud ja AV-koodi keelanud - nii et sel juhul võib heade poiste lisamine ülevaadete kogumisse riski vähendada.

Kas see pole nii vana küsimus, kas avatud lähtekoodiga vähendatakse turvalisust või mitte? Vähemalt populaarne turvatöötajate teooria on see, et kui turvalisuse tagamiseks loodate, et teie koodile ei pääse juurde, siis on teil olemas vaid turvalisus varjus. See on põhjus, miks ainsad usaldusväärsed krüpteerimisalgoritmid on see, kus kood on olnud paljude aastate jooksul avatud ja neid on põhjalikult analüüsitud. Ma ei saa tegelikult aru, miks peaks turvatarkvara sel juhul Kapensky olema erinev.

See tähendab, et tegin järgmise punkti oma postituses avatud lähtekoodil:

Isegi OWASPi riskireitingute metoodikal on üldist riski suurendavate haavatavusteguritena hõlpsasti tuvastatav ja hõlpsasti kasutatav. Ettevõtetel on palju suurarvutikoode, millel on kindlasti palju turvaauke, kuid riskiskoori arvutamisel peab see olema väiksem kui saidiülese skriptimise haavatavus, mis on olemas just hiljuti alla laaditud avatud lähtekoodiga CMS-is. Nüüd võite võtta seisukoha, et see pistoda ripub teie pea kohal, on ainult aja küsimus, enne kui keegi selle leiab ja ära kasutab (nt Stuxnet ja SCADA). Alternatiivne seisukoht on, et piiratud ressursside korral on põhjaliku turvakontrolli kaitsmine ja lähtekoodi konfidentsiaalsena hoidmine õigustatud riskide maandamise strateegia.

Tõenäoliselt on efekt mõlemal juhul minimaalne.

Kindlasti, kui teie süsteemi turvalisus sõltub kriitiliselt koodi salajasusest, on see omaette probleem. Ärge unustage, et kompileeritud piltidest lähtekoodi tootmiseks on olemas tööriistad igal juhul ja on ka inimesi, kes suudavad masinakoodi dekompileerida kõrgetasemelistesse keeltesse nii kiiresti kui oskavad.

Ma arvan, et peamine risk, mis sellistel üritustel seisab, on äririsk: ettevõte tajub oma lähtekoodi varana, mis annab talle konkurentide ees eelise, alles nüüd on konkurentidel sellele varale võrdne juurdepääs. Teiseks on ilmselgelt kahjustatud ettevõtte mainet: turvaettevõte, mis ei suuda isegi oma äriprotsesse kindlustada?

Jah, tõenäoliselt on ka nõrku kohti, mida on allikale juurdepääsemisel lihtsam avastada, kuid põhimõtteline kahju on ettevõttele. Nagu teised on märkinud, on haavatavuse leidmine jõud, mida saab kasutada nii hea kui kurja jaoks.

Üks oluline punkt siin ... see, et lähtekood on "lekitatud", ei tähenda, et see oleks võrreldav vaba / avatud lähtekoodiga. Kui see oli tegelikult lekkinud (s.t ebaseaduslikult levitatud ja endiselt patentide, autoriõiguste, mitteametlike eraldiste jms alla kuuluv), on headel meestel selle kontrollimiseks parimal juhul õiguslik alus. Minu arvates peaksid omanikud / autorid pärast selle lekkimist vähemalt juriidiliselt kokku leppima, et ei hakka kohtu alla andma ega kohtusse kaevama kedagi, kes kontrollib praegu avalikku koodi.

Olen sysadmin / arendaja, tegelen peaaegu eranditult avatud lähtekoodiga ja veedan üsna palju oma ajast kaelas käimasolevas koodis. Mis puudutab siin tõstatatud avatud lähtekoodiga küsimust, siis me kõik teame, et ründajad tegelevad sulepea testimise ja varalise tarkvara dekompileerimisega. Mõistlik on lubada ka headel poistel pilk peale visata. Kui mitte mingil muul põhjusel, ma tahaksin kõik hoiatada haavatavuse eest (loodetavasti vastutustundlikul viisil), kui ründajad peaksid sellest ainult teadma, kuni müüja otsustab selle avaldada.