Undersøg og valider kodebaser for overholdelse

  • 5 minutter

Før de implementerer automatiserede værktøjer til analyse af softwaresammensætning, skal organisationer forstå, hvad der skal inspiceres og valideres i deres kodebaser. Moderne applikationer indeholder hundredvis eller tusindvis af afhængigheder, hvilket gør manuel inspektion upraktisk. Systematiske tilgange til registrering af afhængighed, sårbarhedsvurdering og validering af overholdelse er afgørende.

Hvorfor inspektion og validering er vigtige

Afhængighedsudfordringen: Programmer er ikke kun afhængige af pakker, du importerer direkte. Hver direkte afhængighed afhænger typisk af yderligere pakker (transitive afhængigheder), hvilket skaber dybe afhængighedstræer. En typisk applikation kan direkte referere til 20-30 pakker, men transitivt afhængig af 200-500 pakker. Du er ansvarlig for sårbarheder og licensforpligtelser i alle afhængigheder, ikke kun direkte.

Sikkerhedskravet: Sikkerhedssårbarheder i afhængigheder udgør betydelige risici. Angribere udnytter aktivt kendte sårbarheder i populære pakker, hvilket gør upatchede afhængigheder til attraktive mål. Højt profilerede brud involverer ofte udnyttelse af kendte sårbarheder i open source-komponenter, som organisationer ikke har opdateret.

Kravet om overholdelse: Licensovertrædelser kan resultere i retssager, tvungen open-source af proprietær kode, distributionsbegrænsninger og skade på omdømme. Organisationer skal spore licensforpligtelser for hver afhængighed og sikre overholdelse af licensvilkårene.

Den operationelle virkelighed: Afhængigheder ændrer sig konstant. Nye sårbarheder afsløres dagligt, pakker modtager opdateringer, vedligeholdere opgiver projekter, og nye versioner udgives. Engangsinspektion er ikke nok – løbende validering er påkrævet.

Hvad skal inspiceres og valideres

Omfattende inspektion af kodebasen dækker flere dimensioner:

Afhængighedsopgørelse

Oprettelse af en komplet stykliste:

  • Direkte afhængigheder: Pakker, der eksplicit er angivet i pakkemanifestfiler (package.json, requirements.txt, pom.xml, *.csproj).
  • Transitive afhængigheder: Pakker, der kræves af dine direkte afhængigheder, flere niveauer dybe.
  • Udviklingsafhængigheder: Pakker, der bruges under udvikling og test, men som ikke leveres med produktionskode.
  • Sporing af versioner: Specifikke versioner af hver pakke, der er i brug.
  • Afhængighedskilder: Hvilke pakkeregistre giver afhængigheder (npm, PyPI, NuGet, Maven Central, private registre).

Hvorfor komplette beholdninger er vigtige:

  • Håndtering af sårbarheder: Du kan ikke rette sårbarheder, du ikke kender til.
  • Overholdelse af licens: Skal spore licensforpligtelser for alle afhængigheder, ikke kun direkte.
  • Opdater planlægning: Forståelse af afhængighedsrelationer hjælper med at planlægge opdateringer, der ikke bryder kompatibiliteten.
  • Synlighed i forsyningskæden: Ved præcis, hvilken ekstern kode der er inkluderet i dine applikationer.

Registrering af sikkerhedssårbarheder

Identificering af kendte sårbarheder:

  • Tilknytning af CVE (Common Vulnerabilities and Exposures): Match afhængighedsversioner med CVE-databaser, der indeholder kendte sårbarheder.
  • Vurdering af sværhedsgrad: Evaluer sværhedsgraden af sårbarhed ved hjælp af CVSS-scorer (Common Vulnerability Scoring System) fra 0-10.
  • Analyse af udnyttelsesmuligheder: Find ud af, om sårbarheder udnyttes aktivt i naturen.
  • Tilgængelighed af patch: Identificer, hvilke versioner der løser sårbarheder, og om der er tilgængelige programrettelser.

Om sårbarhedsdatabaser:

  • National sårbarhedsdatabase (NVD): Den amerikanske regerings lager af sårbarhedsdata baseret på CVE-identifikatorer.
  • GitHub Advisory Database: Organiserede sikkerhedsmeddelelser til pakker på tværs af flere økosystemer.
  • Mailinglister til sikkerhed: Sprog- og rammespecifikke sikkerhedsmeddelelser.
  • Leverandørers databaser: Kommercielle SCA-værktøjer vedligeholder proprietære sårbarhedsdatabaser med yderligere intelligens.

Sårbarhedskategorier i afhængigheder:

  • Fejl ved injektion: SQL-injektion, kommandoinjektion, sårbarheder i forbindelse med scripting på tværs af websteder i webframeworks.
  • Problemer med godkendelse: Svage godkendelsesimplementeringer, problemer med sessionsstyring, fejl i håndtering af legitimationsoplysninger.
  • Eksponering af følsomme data: Usikker datalagring, utilstrækkelig kryptering, informationslækage.
  • Forkert konfiguration af sikkerhed: Standardkonfigurationer med kendte svagheder, unødvendige funktioner aktiveret.
  • Dent service: Sårbarheder i forbindelse med ressourceudmattelse, problemer med algoritmisk kompleksitet.
  • Deserialisering fejl: Usikker deserialisering, der fører til fjernudførelse af kode.

Validering af licensoverholdelse

Identifikation af licensforpligtelser:

  • Registrering af licens: Identificer, hvilke licenser der gælder for hver afhængighed.
  • Licens klassificering: Kategoriser licenser som eftergivende, svage copyleft, stærke copyleft eller proprietære.
  • Analyse af kompatibilitet: Kontrollér, at licenser med forskellige afhængigheder er kompatible, når de kombineres.
  • Sporing af forpligtelser: Dokumentkrav som f.eks. kreditering, offentliggørelse af kildekode eller licensering af afledte værker.

Almindelige problemer med overholdelse af angivne standarder:

  • Copyleft-forurening: GPL-licenserede afhængigheder i proprietær software kan kræve open-source af hele applikationen.
  • Tilskrivningsfejl: Manglende påkrævede meddelelser om ophavsret og licenstekst i distribueret software.
  • Uforenelige kombinationer: Brug af afhængigheder med modstridende licenser, der ikke lovligt kan kombineres.
  • Ændringer af licens: Projekter skifter nogle gange licenser mellem versioner, hvilket kræver reevaluering.

Risikovurdering af licens:

  • Høj risiko: Stærke copyleft-licenser (GPL, AGPL) i proprietær softwaredistribution.
  • Middel risiko: Svage copyleft-licenser (LGPL, MPL), der kræver omhyggelig integrationspraksis.
  • Lav risiko: Tilladte licenser (MIT, Apache 2.0, BSD) med minimale begrænsninger.
  • Ukendt risiko: Brugerdefinerede licenser, uklare licenser eller manglende licensoplysninger.

Kvalitetsvurdering af afhængighed

Evaluering af vedligeholdelse af afhængighed:

  • Vedligeholdelse status: Find ud af, om afhængigheder opretholdes aktivt eller opgives.
  • Hyppighed af opdateringer: Vurder, hvor ofte afhængigheder modtager opdateringer og fejlrettelser.
  • Sundhed i Fællesskabet: Evaluer bidragyderaktivitet, svartider for problemer og engagement i fællesskabet.
  • Dokumentationens kvalitet: Gennemgå, om afhængigheder har tilstrækkelig dokumentation til korrekt brug.
  • Sikkerhedspraksis: Kontrollér, at projekter har ansvarlige oplysningsprocesser og sikkerhedsrådgivninger.

Kvalitetsindikatorer:

  • Aktiv vedligeholdelse: Regelmæssige commits, seneste udgivelser, responsive vedligeholdere.
  • Stort fællesskab: Mange bidragydere, stjerner, gafler og brugere leverer bæredygtighed.
  • Klar kommunikation: Aktiv problemsporing, responsive diskussioner, klare udgivelsesnoter.
  • Sikkerhedsbevidsthed: Offentliggjort sikkerhedspolitik, hurtig patching af sårbarheder, sikkerhedsadvarsler.

Røde flag:

  • Afbrudte projekter: Ingen opdateringer i årevis, ikke-reagerende vedligeholdere, akkumulering af uløste problemer.
  • Risiko for en enkelt vedligeholder: Kritisk afhængighed opretholdt af en person, der kan blive utilgængelig.
  • Dårlig kvalitet: Utilstrækkelig test, hyppige fejl, ændringer i mindre versioner.
  • Manglende sikkerhed: Ingen sikkerhedspolitik, langsom sårbarhedsrespons, uoplyste sikkerhedsproblemer.

Udfordringer med manuel inspektion

Hvorfor manuel inspektion ikke skaleres:

Volumen overvældende

  • Hundredvis af afhængigheder: Selv små applikationer er transitivt afhængige af hundredvis af pakker.
  • Flere applikationer: Organisationer vedligeholder snesevis eller hundredvis af applikationer, hvilket mangedobler antallet af afhængigheder.
  • Konstante ændringer: Nye versioner, der udgives dagligt, gør enhver manuel beholdning straks forældet.
  • Menneskelige fejl: Manuel sporing overser uundgåeligt afhængigheder, især transitive.

Information spredt

  • Flere kilder: Oplysninger om sårbarheder kommer fra CVE-databaser, sikkerhedsmailinglister, GitHub-meddelelser, leverandørmeddelelser og sikkerhedsforskeres afsløringer.
  • Licens forskning: Bestemmelse af nøjagtige licenser kræver undersøgelse af kildekodefiler, readme-dokumenter og licensfiler i hver pakke.
  • Versionsspecifikke detaljer: Sårbarheder og licenser kan ændre sig mellem versioner, hvilket kræver versionsspecifik forskning.
  • Modstridende oplysninger: Forskellige kilder giver nogle gange modstridende sårbarheds- eller licensoplysninger.

Tidskrævende analyse

  • Vurdering af sårbarhed: Det tager lang tid at undersøge hver sårbarheds alvorsgrad, udnyttelsesmuligheder og patch-status.
  • Licens analyse: Forståelse af licensvilkår, kompatibilitet og forpligtelser kræver juridisk ekspertise.
  • Opdater planlægning: Det er komplekst at bestemme sikre opdateringsstier under hensyntagen til ubrudte ændringer og afhængighedskonflikter.
  • Kontinuerlig overvågning: Løbende overvågning af nye sårbarheder og opdateringer kræver dedikerede ressourcer.

Forsinket registrering

  • Opdagelsesforsinkelse: Manuelle processer registrerer sårbarheder uger eller måneder efter offentliggørelse.
  • Reaktiv respons: Organisationer lærer om sårbarheder fra sikkerhedshændelser i stedet for proaktiv scanning.
  • Revisionscyklusser: Periodiske revisioner gør applikationer sårbare mellem revisioner.
  • Nødplastre: Uden kontinuerlig overvågning kræver kritiske sårbarheder forstyrrende nødrettelser.

Den automatiserede løsning

Software Composition Analysis-værktøjer løser manuelle inspektionsudfordringer:

Automatiseret opdagelse

  • Afhængighedsanalyse: SCA-værktøjer fortolker automatisk pakkemanifestfiler for at identificere afhængigheder.
  • Transitiv opløsning: Værktøjer følger afhængighedskæder for at oprette komplette styklister.
  • Analyse af låsefil: Analyser låsefiler (package-lock.json, Pipfile.lock), der viser nøjagtigt, hvilke versioner der er installeret.
  • Binær scanning: Nogle værktøjer scanner kompilerede binære filer og objektbeholdere for at finde integrerede afhængigheder.

Løbende overvågning

  • Advarsler om sårbarheder i realtid: Modtag øjeblikkelige meddelelser, når nye sårbarheder påvirker dine afhængigheder.
  • Automatiserede opdateringer: Værktøjer som GitHub Dependabot opretter automatisk pullanmodninger, når sikkerhedsopdateringer er tilgængelige.
  • Synlighed på instrumentbrættet: Centraliserede dashboards viser sårbarhedsstatus på tværs af alle applikationer.
  • Planlagt scanning: Regelmæssige automatiserede scanninger sikrer, at afhængighedsdata forbliver aktuelle.

Omfattende databaser

  • Aggregerede sårbarhedsdata: SCA-værktøjer samler oplysninger fra NVD, GitHub Advisory Database, sikkerhedsmailinglister og leverandørdatabaser.
  • Licens databaser: Oprethold omfattende licensoplysninger, herunder fulde licenstekster og forpligtelsesoversigter.
  • Kuratering og verifikation: Leverandører verificerer og kuraterer sårbarhedsdata for at reducere falske positiver.
  • Proprietær intelligens: Kommercielle værktøjer giver yderligere forskning og analyse ud over offentlige databaser.

Intelligent analyse

  • Scoring af sværhedsgrad: Beregn automatisk CVSS-scorer og prioriter sårbarheder efter risiko.
  • Analyse af tilgængelighed: Find ud af, om sårbare kodestier rent faktisk bruges i dit program.
  • Vejledning til afhjælpning: Giv specifikke versionsanbefalinger, der løser sårbarheder, samtidig med at kompatibiliteten opretholdes.
  • Håndhævelse af politikker: Fejl automatisk builds, eller bloker udrulninger, når der registreres politikovertrædelser.

Oprettelse af valideringsbaselines

Før du implementerer automatiseret scanning, skal du etablere valideringskriterier:

Sikkerhedspolitikker

  • Tolerance over for sårbarheder: Definer, hvilke sværhedsgrader af sårbarheder der er acceptable (f.eks. ingen kritisk eller høj, begrænset medium).
  • Tidsrammer for patch: Find ud af, hvor hurtigt sårbarheder med forskellig alvorsgrad skal afhjælpes.
  • Undtagelsesprocesser: Opret procedurer for at acceptere risici, når øjeblikkelig patching ikke er mulig.
  • Rapporteringskrav: Definer, hvem der har brug for meddelelser om sårbarheder, og hvor hurtigt.

Politikker for overholdelse af angivne standarder

  • Godkendte licenser: Angiv licenser, der altid er acceptable (f.eks. MIT, Apache 2.0).
  • Begrænsede licenser: Identificer licenser, der kræver særlig godkendelse (f.eks. LGPL) eller forbud (f.eks. GPL for proprietær software).
  • Krav til tilskrivning: Definer, hvordan tilskrivning skal leveres i distribueret software.
  • Revisionsspor: Angiv dokumentationskrav for overensstemmelsesbeviser.

Kvalitetsstandarder

  • Krav til vedligeholdelse: Definer minimumsforventninger til vedligeholdelse (f.eks. opdateringer inden for det sidste år).
  • Samfundets størrelse: Etabler tærskler for acceptable sundhedsmålinger i samfundet.
  • Standarder for dokumentation: Angiv minimumskrav til dokumentation for afhængigheder.
  • Sikkerhedspraksis: Kræv, at afhængigheder har publicerede sikkerhedspolitikker og responsiv håndtering af sårbarheder.

At forstå, hvad der skal inspiceres og valideres, giver grundlaget for implementering af automatiserede værktøjer til analyse af softwaresammensætning. Den næste enhed udforsker SCA's grundlæggende principper, og hvordan automatiserede værktøjer løser udfordringerne ved manuel afhængighedsstyring.