Google ehdottaa uusien sääntöjen laatimista avoimen lähdekoodin turvallisuuden parantamiseksi

Avoimen lähdekoodin ohjelmistojen turvallisuus on herättänyt alan huomion, mutta ratkaisut edellyttävät yhteisymmärrystä haasteista ja yhteistyötä toteutuksessa.

Ongelma on monimutkainen ja käsiteltävänä on monia puolia, toimitusketjusta, riippuvuuksien hallinta, identiteetti mm. Tätä varten Google julkaisi äskettäin kehyksen ("Know, Prevent, Fix"), joka selittää, miten teollisuus voi ajatella haavoittuvuuksia avoimessa lähdekoodissa ja tietyillä alueilla, joihin on ensin puututtava.

Google selittää syyt:

"Viimeaikaisten tapahtumien takia ohjelmistomaailma on ymmärtänyt syvemmin toimitusketjuhyökkäysten todellisen riskin. Avoimen lähdekoodin ohjelmistojen ei pitäisi olla turvallisuuden kannalta vähemmän riskialttiita, koska kaikki koodit ja riippuvuudet ovat avoimia ja käytettävissä tarkastusta ja tarkistusta varten. Ja vaikka tämä onkin totta, oletetaan, että ihmiset todella tekevät tämän tarkastustyön. Niin monien riippuvuuksien vuoksi kaikkia on mahdotonta valvoa, ja monia avoimen lähdekoodin paketteja ei hoideta kunnolla.

- On tavallista, että ohjelma riippuu suoraan tai epäsuorasti tuhansista paketeista ja kirjastoista. Esimerkiksi Kubernetes riippuu nyt noin 1000 paketista. Avoin lähdekoodi käyttää todennäköisesti riippuvuuksia omien ohjelmistojen sijasta ja tulee useilta toimittajilta; luotettavien itsenäisten yksiköiden määrä voi olla hyvin suuri. Tämän vuoksi on erittäin vaikeaa ymmärtää, miten avointa lähdekoodia käytetään tuotteissa ja mitkä haavoittuvuudet saattavat olla merkityksellisiä. Ei ole myöskään takeita siitä, että rakennettu vastaa lähdekoodia.

Googlen ehdottamassa kehyksessä ehdotetaan, että tämä vaikeus jaetaan kolmeen pääosin itsenäiseen ongelma-alueeseen, joilla jokaisella on erityiset tavoitteet:

Tunne ohjelmistosi haavoittuvuudet

Ohjelmistohaavoittuvuuksien tunteminen on vaikeampaa kuin voisi odottaa monista syistä. kyllä ​​Okei on mekanismeja raportoida haavoittuvuuksista, on epäselvää, vaikuttavatko ne todella käyttämäsi ohjelmiston tiettyihin versioihin:

• Tavoite: Tarkat haavoittuvuustiedot: Ensinnäkin on tärkeää kerätä tarkat haavoittuvuuksien metatiedot kaikista käytettävissä olevista tietolähteistä. Esimerkiksi tietämys siitä, mikä versio on tuonut haavoittuvuuden, auttaa selvittämään, onko ohjelmistoon vaikutusta, ja tieto siitä, milloin se on korjattu, johtaa tarkkoihin ja ajankohtaisiin korjauksiin (ja kapeaan ikkunaan mahdolliselle hyödyntämiselle). Ihannetapauksessa tämä luokittelun työnkulku tulisi automatisoida.
• Toiseksi suurin osa haavoittuvuuksista on riippuvuussuhteissasi pikemmin kuin kirjoittamassasi tai suoraan hallinnoimassasi koodissa. Joten vaikka koodisi ei muutu, ohjelmistoon vaikuttavien haavoittuvuuksien maisema voi muuttua jatkuvasti - jotkut ovat kiinteitä ja osa lisätään.
• Tarkoitus: Haavoittuvuustietokantojen vakiokaavio Infrastruktuuri- ja teollisuusstandardeja vaaditaan avoimen lähdekoodin haavoittuvuuksien seuraamiseksi ja ylläpitämiseksi, niiden seurausten ymmärtämiseksi ja niiden lieventämisen hallitsemiseksi. Tavallinen haavoittuvuusjärjestelmä mahdollistaisi yhteisten työkalujen suorittamisen useissa haavoittuvuustietokannoissa ja yksinkertaistaisi seurantaa, varsinkin kun haavoittuvuudet ylittävät useita kieliä tai alijärjestelmiä.

Vältä uusien haavoittuvuuksien lisäämistä

Olisi ihanteellista välttää haavoittuvuuksien syntyminen Ja vaikka testaus- ja analyysityökalut voivat auttaa, ehkäisy on aina vaikea aihe.

täällä, Google ehdottaa keskittymistä kahteen erityisnäkökohtaan:

• Ymmärrä riskit, kun päätät uudesta riippuvuudesta
• Paranna kriittisiä ohjelmistokehitysprosesseja

Korjaa tai poista haavoittuvuudet

Google myöntää, että yleinen korjausongelma ei kuulu sen toimivaltaan, mutta kustantaja uskoo, että toimijat voivat tehdä paljon enemmän ongelman ratkaisemiseksi erityisiä riippuvuuksien haavoittuvuuksien hallitsemiseksi.

Siinä mainitaan myös: 

”Tänään tällä alalla on vähän apua, mutta kun parannamme tarkkuutta, kannattaa investoida uusiin prosesseihin ja työkaluihin.

"Yksi vaihtoehto on tietysti korjata haavoittuvuus suoraan. Jos pystyt tekemään tämän taaksepäin yhteensopivalla tavalla, ratkaisu on kaikkien saatavilla. Mutta haasteena on, että sinulla ei todennäköisesti ole kokemusta ongelmasta tai suoraa kykyä tehdä muutoksia. Haavoittuvuuden korjaaminen edellyttää myös, että ohjelmiston ylläpidosta vastaavat henkilöt ovat tietoisia ongelmasta ja heillä on tietoa ja resursseja heikkouden paljastamiseksi.

lähde: https://security.googleblog.com