Steven Vaughan-Nichols Senior Contributing Editor
Steven J. Vaughan-Nichols er en frilansskribent.
Full Bio Publisert i Linux og Open Source 13. januar , 2022 | Emne: Sikkerhet
Sjansen er stor for at med mindre du er en JavaScript-programmerer, har du aldri hørt om åpen kildekode Javascript-bibliotekene 'colors.js' og 'faker.js.» De er enkle programmer som henholdsvis lar deg bruke farget tekst på noden din. js, en populær JavaScript kjøretid, konsoll, og skape falske data for testing. Faker.js brukes med mer enn 2500 andre Node Package Manager (NPM) programmer og lastes ned 2,4 millioner ganger per uke. Colors.js er innebygd i nesten 19 000 andre NPM-pakker og lastes ned 23 millioner ganger i uken. Kort sagt, de er overalt. Og da skaperen deres, JavaScript-utvikleren Marak Squires, spolerte dem, eksploderte titusenvis av JavaScript-programmer.
Dette er ikke første gang en utvikler bevisst saboterte sin egen åpen kildekode. Tilbake i 2016 slettet Azer Koçulu en 17-linjers npm-pakke kalt 'left-pad', som drepte tusenvis av Node.js-programmer som var avhengige av at den skulle fungere. Både da og nå var den faktiske koden triviell, men fordi den er brukt i så mange andre programmer, var effektene langt større enn brukere noen gang ville ha forventet.
Hvorfor gjorde Squires det? Vi vet egentlig ikke. I faker.js sin GitHub README-fil sa Squires: “Hva skjedde egentlig med Aaron Swartz?” Dette er en referanse til hackeraktivisten Aaron Swartz som begikk selvmord i 2013 da han ble anklaget for å ha forsøkt å offentliggjøre artikler i akademiske tidsskrifter fra MIT.
Din gjetning er like god som min om hva dette har å gjøre. gjøre med hva som helst.
Det som er mer sannsynlig å være årsaken til at han la en uendelig løkke inn i bibliotekene sine, er at han ville ha penger. I et siden slettet GitHub-innlegg sa Squires: “Respektfullt, jeg kommer ikke lenger til å støtte Fortune 500s (og andre mindre selskaper) med mitt gratis arbeid. Det er ikke mye annet å si. Ta dette som en mulighet å sende meg en sekssifret årskontrakt eller dele opp prosjektet og få noen andre til å jobbe med det.”
Unnskyld meg. Mens åpen kildekode-utviklere bør få en rimelig kompensasjon for arbeidet sitt, er det å ødelegge koden din ikke måten å overtale andre til å betale deg på.
Beste online dataprogrammeringsgrader 2021: Toppvalg
Dette er et svart øye for åpen kildekode og dens utviklere. Vi trenger ikke programmerere som driter i arbeidet sitt når de blir avkrysset i verden.
Et annet problem bak problemet er at for mange utviklere rett og slett automatisk laster ned og distribuerer kode uten å se på det. Denne typen bevisst blindhet ber bare om problemer.
Bare fordi en programvarepakke ble laget av en åpen kildekode-programmerer, betyr det ikke at den er feilfri. Åpen kildekode-utviklere gjør like mange feil som alle andre programmerere. Det er bare det at i tilfellet med åpen kildekode har du muligheten til å sjekke det ut først for problemer. Hvis du velger å ikke se før du distribuerer, er det opp til deg hva som skjer videre.
Noen kriminelle utviklere bruker allerede folks blinde tillit til å snike skadevare inn i programmene deres. For eksempel oppdaget DevOps-sikkerhetsfirmaet JFrog nylig 17 nye ondsinnede JavaScript-pakker i NPM-lageret som bevisst angriper og stjeler en brukers Discord-tokens. Disse kan deretter brukes på Discord kommunikasjons- og digital distribusjonsplattform.
Er det mye arbeid? Du vedder på at det er det. Men det er verktøy som NPM-revisjon, GitHubs DependendaBot og OWASP Dependency-Check som kan bidra til å gjøre det enklere.
I tillegg kan du ganske enkelt sørge for at før noen kode settes i produksjon, kjører du ganske enkelt en fornuftssjekk på den i din kontinuerlige integrasjon/kontinuerlige distribusjon (CI/CD) før du distribuerer den til produksjon.
Jeg mener, seriøst, hvis du bare hadde drevet et av disse bibliotekene i laboratoriet, ville de ha eksplodert under testing og aldri, aldri kommet inn i den virkelige verden. Det er ikke så vanskelig!
I mellomtiden foreslår GitHub at du går tilbake til eldre, sikrere versjoner. For å være nøyaktig, det er colors.js 1.40 og faker.js 5.5.3.
Som CodeNotary, et leverandørkjedeselskap for programvare, påpekte i et nylig blogginnlegg, “Programvaren er aldri komplett, og kodebasen inkludert dens avhengigheter er et dokument som alltid oppdateres. Det betyr automatisk at du må spore det, både godt og dårlig, og holde seg inne. huske på at noe godt kan bli dårlig.” Akkurat!
Derfor, fortsatte de, “Den eneste virkelige løsningen her er å være på toppen av avhengighetsbruken og distribusjonen. Software Bill of Materials (SBOMs) kan være en løsning på det problemet, men de trenger for å være manipulasjonssikker, søkbar på en rask og skalerbar måte og versjonert.
CodeNotary foreslår selvfølgelig at du bruker programvaren deres, Codenotary Cloud og vcn-kommandolinjeverktøyet, for denne jobben. er andre selskaper og prosjekter som også adresserer SBOM. Hvis du ønsker å være trygg, må du fremover – jeg gjentar må – bruke en SBOM. Supply chain-angrep, både innenfra og utenfra, er raskt i ferd med å bli en av de våre viktigste sikkerhetsproblemer.
Relaterte historier:
Ondsinnede npm-pakker stjeler Discord-tokensKodenotar: Notariser og verifiser programvarefortegnelsen din
Linux Foundation kunngjør ny åpen kildekode-signeringstjeneste for programvare
Enterprise Software | Security TV | Data Management | CXO | Datasentre