Forrester (Nasdaq: FORR) er et af de mest indflydelsesrige forsknings- og rådgivningsfirmaer i verden. Vi hjælper ledere på tværs af teknologi, marketing, kundeoplevelse, produkt- og salgsfunktioner med at bruge kundebesættelse til at accelerere vækst.
Fuld bio Udgivet i Forrester den 28. januar 2022 | Emne: Sikkerhed
Der har været et par højprofilerede sikkerhedsproblemer med open source-software. En utilfreds udvikler leverede for nylig bevidst modificerede udgivelser af sine faker.js og colors.js-pakker, som brød “tusindvis af projekter”, der var afhængige af dem. Nogle spekulerer på, om det overhovedet er sikkert at bruge open source-software. Det Hvide Hus er bestemt – de har bedt store teknologivirksomheder om at kommentere om softwaresikkerhed i kølvandet på Log4j-problemet, som udsatte utallige servere for fjernudnyttelse.
Er kode, der er skrevet af frivillige, mindre sikker end kode skrevet af professionelle udviklere? Har du brug for at få nogen til at sagsøge, hvis et produkt fejler? Får du virkelig, hvad du betaler for?
Hvad er Open Source?
Ligesom det ville være en fejl at sige, at alle lukkede kilde-projekter er fejlfrie, er det en fejl at sige, at alle open source-projekter er sikkerhedsrisici. Forskellige projekter har forskellige fokus; nogle af dem er meget mere optaget af sikkerheden ved deres udgivelser.
Josh Berkus har identificeret fem typer open source-projekter baseret på deres struktur:
Et solo-projekt er passionen hos én person eller højst, nogle få dedikerede mennesker med samme vision.
Et monarki er et vellykket soloprojekt som Linux, der har fået støtte fra et stort fællesskab af bidragydere, så den oprindelige skaber fungerer som en velvillig tyran.
Et fællesskab-projekt som PostgreSQL dukker op blandt jævnaldrende med et lignende mål og er drevet af konsensus.
Et virksomhedsprojekt udgives ofte som en forgrening af et kommercielt projekt, som da Sun udgav OpenOffice som en open source-fork af StarOffice. Dens retning er styret af det firma, der udgav den.
Et fundament, den mest formelle, er en selvstændig forretningsstruktur – som Apache måske er det bedste eksempel på. Der træffer en styregruppe beslutningerne.
Generelt er soloprojekter de mest udsatte for sikkerhedsrisici. Ligesom en forfatter kan opdatere sin webside med ethvert indhold, kan en solo-udvikler opdatere sin kode på samme måde. Ofte er der ikke nok interesse i et fællesskab til at fordele soloprojekter, så de bliver de facto standarder. Vi så dette med faker.js og colors.js, da Marak Squires ændrede sin kode til at udskrive flag og indtaste uendelige loops.
Sikkerheden for både open og closed source-projekter afhænger af deres bidragyders fokus snarere end deres struktur. Vi har været heldige, at Linus Torvalds har haft sikkerhed som en af sine bekymringer. Theo de Raadt, har været bevidst om sikkerheden for OpenBSD fra begyndelsen. I modsætning hertil havde både StarOffice (kommerciel) og OpenOffice sikkerhedshuller, der tillod fjernudførelse af vilkårlig kode i XML-dokumenter.
Mange øjne fokuseret andre steder?
En af ironierne ved open source er antagelsen om, at mange øjne forbedrer sikkerheden. I årevis hørte vi påstande om, at open source var mere sikker, fordi “fællesskabet” kunne gennemgå koden. Problemet: “Fællesskabet” gennemgår sjældent koden, og alle antog bare, at en anden gjorde det. Den falske følelse af sikkerhed eksploderede virkelig under Heartbleed – virkeligheden med for meget kode og for få øjne betyder, at vi har brug for bedre processer og automatisering for at forbedre open source-sikkerhed.
Der er dog en anden falsk følelse af sikkerhed: Antag ikke, at lukket kildesoftware har bedre processer, bare fordi du ikke kan se dem. I tilfældet med Heartbleed gennemgik “fællesskabet” til sidst hullerne i OpenSSL, og løsningen var … mere open source. LibreSSL, en forgrening af OpenSSL, havde fokus på sikkerhed snarere end bagudkompatibilitet.
Open Source kræver delt ansvarlighed
Selvom du ikke betaler penge, når du bruger open source-software, betyder det ikke, at du ikke har forpligtelser – over for din virksomhed, dine kunder og samfundet. Vær ansvarlig, når du bruger open source-software:
Ved, hvad du bruger. En af de største farer ved nogle økosystemer er den lethed, hvormed et open source-projekt kan inkludere et andet. Mange projekter omfatter i dag andre projekter som komponenter. Systemer som npm gør det nemt at bringe kode ind uden at være klar over det. Der findes værktøjer til at hjælpe med at generere softwarestyklister (SBOM'er) og til at scanne din kode for at se, om du er afhængig af noget, du ikke vidste om.
Undgå soloprojekter og forladte projekter. En enkelt ondsindet udvikler kan injicere meget skade – især hvis du opgraderer automatisk. Faren ved at bruge forladte projekter er, at de måske ikke tager højde for moderne sårbarheder. Evaluer status for de projekter, du bruger med hver udgivelse.
Test før du frigiver.Meget af faren ved open source-projekter kommer fra opgradering uden test. Hvis din kode indeholder et open source-bibliotek med en udnyttelse, vil dine brugere holde dig ansvarlig. Certificer med specifikke versioner af projekter og hold dem ajour. Fork open source-biblioteker, som du bruger, og dedikerer ressourcer til at gennemgå, hvad der er blevet forpligtet.
Planlæg for opdateringer. Log4j-sårbarheden var særlig farlig, fordi den tillod eksekvering af vilkårlig kode på platforme, der har software indbygget i ROM. For nogle internet-of-things-enheder er der ingen måde at opgradere Log4j-biblioteket for at rette op på. Dette efterlader en vedvarende sårbarhed, som ikke kan løses. Sæt ikke dit produkt i samme knibe. Angiv en opgradering (og nedgrader!) sti for hver komponent. Vent heller ikke på et sikkerhedsproblem for at opgradere din kode – planlæg at opdatere regelmæssigt til nyere versioner for at forbedre din kodes hygiejne.
Bidrag til open source-projekter. Mange open source-projekter leverer nyttig kode med få ressourcer. Forpligt dig til at bidrage enten økonomisk eller ved at levere udviklings- eller QA-ressourcer til de open source-biblioteker, du bruger. Begræns ikke dine open source-bidrag til den dag, du trækker biblioteket – open source har brug for løbende støtte, så inkluder open source-bidrag i dit årlige budget og langsigtede planlægning. Du vil være sikker på, at den seneste udgivelse er lige så sikker som den, du først hentede.
Invester i DevSecOps.Antag, at hyppige opdateringer er normen, ikke undtagelsen. Uanset om det er kode oprettet af dit eget team eller kode, du har hentet fra et open source-projekt, skal du indse, at der vil ske fejl, opdateringer vil være nødvendige, og at der i nogle tilfælde vil være behov for hurtig iteration for at følge med ændringer. DevOps, i form af CI/CD, er nu bordspil; op på ante ved at tilføje “Sec” – muligheden for at skifte til venstre automatiske sikkerhedstjek direkte ind i udviklercyklussen, så når disse opdateringer kommer ind, er du bedre forberedt til at få rettelsen ud af døren med færre hele natten og meget mindre slid og stress.
Vågn op fra mareridtet
Hvis du er bange for at bruge open source, er det for sent. Det er usandsynligt, at du bruger et produkt i dag uden open source-komponenter. Det er næsten sikkert, at du læser dette med en browser baseret på open source-teknologi, serveret af en webserver, der har en open source-kerne – alt sammen bygget med open source-værktøjer. Selvom et mareridt ikke er virkelighed, kan det være et svar på legitim angst. Brug open source-software ansvarligt for at undgå gåsehuden.
Dette indlæg er skrevet af senioranalytiker Andrew Cornwall, og det dukkede oprindeligt op her.
ZDNet anbefaler
Bedste Google Chrome-udvidelse 2022: Gratis og nyttige værktøjer Bedste Chromebook-tilbud: Samsung, Acer, HP og flere Bedste Apple AirPods-tilbud: 99 $ AirPods og mere Deal : Spar 200 USD på det nyligt udgivne GoPro Hero 10-kamera Køb af en brugt bærbar computer: Hvor finder du de bedste tilbud Sikkerheds-tv | Datastyring | CXO | Datacentre