Sammendrag

  • 8 minutter

I denne modulen utforsket du hvordan moderne programvareutvikling er avhengig av åpen kildekode-komponenter og lærte strategier for å implementere åpen kildekode-programvare samtidig som du håndterer tilhørende sikkerhets-, juridiske og operasjonelle risikoer. Ved å forstå disse konseptene kan du utnytte fordelene med åpen kildekode samtidig som du beskytter organisasjonen mot potensielle forpliktelser.

Hvordan moderne programvare bygges

Du lærte at moderne applikasjoner er satt sammen av komponenter i stedet for å bygges helt fra bunnen av:

  • Komponent sammensetning: Moderne applikasjoner består av omtrent 80% eksisterende komponenter som vedlikeholdes utenfor prosjektet, med bare 20% som original forretningslogikkkode.
  • Åpen kildekode kontra lukket kildekode: Komponenter med åpen kildekode gir offentlig tilgjengelig kildekode som alle kan inspisere, endre og distribuere, mens komponenter med lukket kildekode bare distribuerer binærfiler uten kildetilgang.
  • Pakke økosystemer: Komponenter distribueres gjennom pakkebehandlere som npm, PyPI, NuGet og Maven Central, som automatiserer avhengighetsadministrasjon.
  • Fordeler med komponentbasert utvikling: Gjenbruk av velprøvde komponenter akselererer utviklingen, forbedrer kvaliteten gjennom fellesskapskontroll, reduserer kostnader ved å unngå lisensavgifter og gir tilgang til banebrytende innovasjoner.
  • Utviklingshastighet: Bruk av åpen kildekode-komponenter reduserer tiden til markedet dramatisk ved å la team fokusere på unik forretningsverdi i stedet for å gjenoppbygge felles infrastruktur.

Bedriftens bekymringer om programvare med åpen kildekode

Du undersøkte de betydelige risikoene organisasjoner står overfor når de tar i bruk åpen kildekode-komponenter:

Sikkerhetsbekymringer:

  • Kjente sårbarheter: Tusenvis av sikkerhetssårbarheter oppdages i åpen kildekode-komponenter årlig, noe som krever kontinuerlig overvåking og rask oppdatering.
  • Angrep i forsyningskjeden: Angripere kompromitterer pakkevedlikeholdskontoer, bruker typosquatting eller utnytter avhengighetsforvirring for å injisere skadelig kode.
  • Prosjekter som ikke vedlikeholdes: Mange åpen kildekode-prosjekter mangler aktivt vedlikehold, noe som gjør at sårbarheter ikke blir oppdatert når vedlikeholdere forlater prosjekter.

Kvalitet og pålitelighet:

  • Variabel kvalitet: Åpen kildekode-komponenter spenner fra profesjonelt vedlikeholdte prosjekter til dårlig testet hobbykode.
  • Brytende endringer: Komponenter prioriterer ikke alltid bakoverkompatibilitet, noe som krever kodeendringer ved oppdatering.
  • Mangler i dokumentasjonen: Mangelfull dokumentasjon øker integrasjonsfeil og misbruk.

Juridiske og lisensieringsmessige bekymringer:

  • Forpliktelser til overholdelse av lisenser: Hver åpen kildekode-lisens stiller krav som spenner fra enkel attribusjon til obligatorisk åpen kildekode av avledede verk.
  • Copyleft-utbredelse: Sterke copyleft-lisenser som GPL kan kreve åpen kildekode for hele applikasjonen din hvis den ikke administreres nøye.
  • Spredning av lisenser: Programmer kan være avhengige av hundrevis av pakker med dusinvis av forskjellige lisenser, noe som skaper komplekse samsvarsbyrder.

Operasjonelle bekymringer:

  • Avhengighet av ekstern infrastruktur: Programmer er avhengige av offentlige pakkeregistre som kan oppleve avbrudd eller fjerning av pakker.
  • Oppdateringsadministrasjonsbyrde: Å holde avhengigheter oppdatert krever kontinuerlig innsats, testing og distribusjon.

Hva åpen kildekode-programvare er

Du lærte de grunnleggende egenskapene til åpen kildekode-programvare:

  • Definisjon: Programvare hvis kildekode er offentlig tilgjengelig for inspeksjon, endring og distribusjon, underlagt en åpen kildekode-lisens.
  • Samarbeidsutvikling: Åpen kildekode-prosjekter involverer distribuerte bidragsytere over hele verden som deltar frivillig, med utvikling som skjer transparent i offentlige arkiver.
  • Utbredt bruk: Over 90% av bedriftene bruker åpen kildekode-programvare i produksjonen, og åpen kildekode-teknologier driver internettinfrastruktur, skyplattformer og mobile enheter.
  • Microsofts transformasjon: Microsoft gikk over fra å se på åpen kildekode som en trussel til å omfavne den omfattende, åpne kildekoden .NET, bidra til Linux og Kubernetes, og lage populære åpen kildekode-verktøy som Visual Studio Code og TypeScript.
  • Strategisk begrunnelse: Organisasjoner velger åpen kildekode for kostnadsbesparelser, fleksibilitet og kontroll, åpenhet og sikkerhet gjennom kodeinspeksjon, og unngår leverandørlåsing, fellesskapsstøtte og tidlig tilgang til innovasjoner.

Grunnleggende om lisens for åpen kildekode

Du utforsket hvordan åpen kildekode-lisenser styrer programvarebruk:

Lisensens formål:

  • Definer tillatelser: Lisenser gir rettigheter til å bruke, modifisere og distribuere programvare som opphavsrettsloven ellers ville forbudt.
  • Pålegge forpliktelser: Lisenser krever attribusjon, avsløring av kildekode, lisensbevaring og noen ganger copyleft-samsvar.
  • Fraskriver seg ansvar: Forfattere er ikke ansvarlige for skader, og programvare leveres "som den er" uten garantier.

Kriterier for definisjon av åpen kildekode:

  • Gratis omfordeling: Ingen restriksjoner på salg eller bortlevering av programvare.
  • Kildekode tilgjengelighet: Må inkludere kilde i foretrukket form for modifikasjoner.
  • Avledede verk tillatt: Må tillate modifikasjoner og avledede verk.
  • Ingen diskriminering: Kan ikke diskriminere personer, grupper eller arbeidsfelt.
  • Teknologi nøytral: Kan ikke kreve spesifikke teknologier eller grensesnitt.

Lisens kategorier:

  • Tillatte lisenser: Tillat inkorporering av kode i proprietær programvare med minimale begrensninger (MIT, Apache 2.0, BSD).
  • Copyleft-lisenser: Krev at avledede verk bruker samme lisens, og sørg for at programvaren forblir åpen kildekode (GPL, AGPL).
  • Svake copyleft-lisenser: Krev endringer med åpen kildekode på komponenten, men tillat proprietær bruk (LGPL, MPL).

Vanlige lisenser for åpen kildekode

Du undersøkte populære lisenser og deres viktigste egenskaper:

Tillatte lisenser:

  • MIT-lisensen: Enkleste tillatt lisens som bare krever navngivelse, maksimerer adopsjon og kommersiell bruk.
  • Apache-lisens 2.0: Tillatt lisens med eksplisitte patentbevilgninger og defensiv oppsigelse, som gir klarhet i patentet.
  • BSD-lisenser: I likhet med MIT, med 3-klausul BSD som legger til begrensninger for navnebruk for varemerkebeskyttelse.

Sterke copyleft-lisenser:

  • GPL v2 og v3: Kreve at avledede verk er GPL-lisensiert og distribuere kildekode med binærfiler; GPL v3 legger til patentbeskyttelse og internasjonale kompatibilitetsforbedringer.
  • AGPL: Utvider GPL v3 med klargjøring av nettverksbruk som krever kildeavsløring for SaaS-tilbud.

Svake copyleft-lisenser:

  • LGPL: Tillater kobling til biblioteker fra proprietære applikasjoner samtidig som det kreves endringer i selve biblioteket for å være åpen kildekode.
  • MPL 2.0: Gir copyleft på filnivå, som krever kildeavsløring bare for MPL-lisensierte filer, ikke proprietær kode i samme applikasjon.

Lisens kompatibilitet:

  • Kompatible kombinasjoner: MIT + Apache 2.0, MIT + GPL v3, Apache 2.0 + GPL v3, LGPL + GPL.
  • Inkompatible kombinasjoner: GPL v2 + Apache 2.0, GPL + proprietære, forskjellige copyleft-lisenser kombinert.

Lisensimplikasjoner og risikovurderinger

Du lærte hvordan du evaluerer lisensrisikoer og implementerer samsvar:

Rammeverk for lisensrisiko:

  • Lav risiko (grønn): Tillatt lisenser som MIT, BSD, Apache 2.0 er trygge for all kommersiell bruk.
  • Middels risiko (gul): Svake copyleft-lisenser som LGPL, MPL tillater proprietær bruk med begrensninger på modifikasjoner.
  • Høy risiko (rød): Sterke copyleft-lisenser som GPL, AGPL er inkompatible med proprietær programvaredistribusjon.
  • Ukjent risiko (oransje): Egendefinerte eller uklare lisenser krever juridisk gjennomgang før bruk.

Kommersielle programvareimplikasjoner:

  • Tillatte lisenser: Aktiver proprietær distribusjon med bare attribusjonskrav.
  • Svak copyleft: Tillat bruk av biblioteker i proprietære applikasjoner, men krever endringer i biblioteker med åpen kildekode.
  • Sterk copyleft: Krev avledede verk med åpen kildekode, noe som gjør dem inkompatible med proprietær programvare.

Hensyn til immaterielle rettigheter:

  • Proprietær IP-beskyttelse: Tillatte lisenser bevarer proprietær kode; Copyleft-lisenser krever offentliggjøring.
  • Bestemmelser om patent: Apache 2.0 og GPL v3 inkluderer eksplisitte patenttildelinger; MIT/BSD mangler åpenbar klarhet.
  • Tap av forretningshemmeligheter: Avsløring av kildekode eliminerer beskyttelse av forretningshemmeligheter.

Implementering av samsvar:

  • Avhengighetsbeholdning: Oppretthold omfattende stykklister som sporer alle komponenter og versjoner med åpen kildekode.
  • Verifisering av lisenskompatibilitet: Bruk automatiserte verktøy for å identifisere lisensinkompatibiliteter.
  • Overholdelse av attribusjon: Generer lisensaggregasjonsfiler, inkluder i Om-dialogbokser og vedlikehold i dokumentasjonen.
  • Klargjøring av kildekode: For copyleft-lisenser, oppgi fullstendig kildekode med byggeinstruksjoner.

Sikkerhet for forsyningskjede for programvare:

  • Skanning av sårbarhet: Skann kontinuerlig avhengigheter for kjente sårbarheter ved hjelp av verktøy som Snyk, Dependabot eller WhiteSource.
  • Reduksjon av angrep i forsyningskjeden: Bekreft pakkesignaturer, foretrekk anerkjente kilder, bruk private registre og fest avhengighetsversjoner.
  • Vurdering av kvalitet: Evaluer vedlikeholdsstatus, fellesskapsstørrelse, dokumentasjonskvalitet og sikkerhetspraksis.

Organisasjonspolicyer:

  • Arbeidsflyter for godkjenning: Implementer evaluering før bruk for sikkerhet, lisensiering og kvalitet før du tar i bruk nye avhengigheter.
  • Godkjente pakkelister: Oppretthold kuraterte lister over forhåndskontrollerte komponenter som utviklere kan bruke umiddelbart.
  • Utviklerutdanning: Lær opp utviklere i lisensimplikasjoner, sikkerhetspraksis og samsvarsprosesser.
  • Kontinuerlig overvåking: Spor avhengighetsoppdateringer, lisensendringer og avsløringer av sårbarheter.

Viktige punkter

Når du implementerer programvare med åpen kildekode i organisasjonen din, husk disse viktige prinsippene:

Omfavn åpen kildekode strategisk: Åpen kildekode gir enorme fordeler, inkludert utviklingshastighet, kvalitet, kostnadsbesparelser og innovasjonstilgang. I stedet for å unngå åpen kildekode på grunn av risiko, implementer styringsprosesser som muliggjør sikker innføring.

Kjenn dine avhengigheter: Oppretthold omfattende beholdninger av alle komponenter med åpen kildekode, inkludert transitive avhengigheter. Du kan ikke håndtere risikoer du ikke vet om, noe som gjør avhengighetssynlighet grunnleggende for effektiv administrasjon av åpen kildekode.

Forstå lisensimplikasjoner: Ulike lisenser har dramatisk forskjellige implikasjoner for kommersiell programvare. Tillatt lisenser som MIT er trygge for proprietær programvare; copyleft-lisenser som GPL krever avledede verk med åpen kildekode. Tilpass lisensvalg til forretningsmodellen din.

Vurder lisenskompatibilitet: Kontroller at lisenser for forskjellige komponenter lovlig kan kombineres. Inkompatible lisenser kan skape juridiske problemer som krever kostbar utbedring, inkludert utskifting av komponenter eller omskriving av kode.

Implementer automatisert samsvar: Manuell lisenssporing skaleres ikke til moderne programmer med hundrevis av avhengigheter. Bruk automatiserte verktøy for avhengighetsskanning, lisensgjenkjenning og overvåking av sårbarheter.

Prioriter sikkerhet: Sikkerhetssårbarheter i avhengigheter påvirker programmet ditt uavhengig av hvor de kommer fra. Implementer kontinuerlig sårbarhetsskanning og etabler raske oppdateringsprosesser for kritiske sikkerhetsoppdateringer.

Administrer risikoer i forsyningskjeden: Utover kjente sårbarheter kan du beskytte deg mot forsyningskjedeangrep gjennom pakkeverifisering, vurdering av kildeomdømme, private registre og avhengighetsfesting.

Balansekontroll med frihet: Utviklere trenger frihet til å bruke moderne verktøy og rammeverk. I stedet for å blokkere innføring av åpen kildekode, implementer godkjenningsarbeidsflyter og godkjente pakkelister som muliggjør sikker bruk.

Utdann teamet ditt: Utviklerens bevissthet om lisensiering og sikkerhetsproblemer er avgjørende. Opplæringsprogrammer hjelper utviklere med å ta gode beslutninger om komponentvalg og forstå organisasjonspolicyer.

Overvåk kontinuerlig: Administrasjon med åpen kildekode er ikke en engangsaktivitet. Nye sårbarheter avsløres kontinuerlig, lisenser endres noen ganger, og prosjekter kan forlates. Kontinuerlig overvåking sikrer kontinuerlig samsvar og sikkerhet.

Ved å bruke disse prinsippene og implementere systematisk administrasjonspraksis for åpen kildekode, gjør du det mulig for organisasjonen din å utnytte de enorme fordelene med åpen kildekode-programvare samtidig som du effektivt håndterer sikkerhets-, juridiske og operasjonelle risikoer.

Mer informasjon