Sikkerhed for afhængigheder og software composition analysis

Moderne applikationer består i høj grad af tredjepartsbiblioteker og -rammeværk med open source. En typisk Node.js-applikation kan have mere end 1.000 transitive afhængigheder, og et Java-projekt kan hente hundredvis af Maven-artefakter. Hver afhængighed er en potentiel angrebsflade. Log4Shell-sårbarheden (CVE-2021-44228) i Log4j-biblioteket viste, at en enkelt afhængighed inden for få dage efter offentliggørelsen kunne gøre millioner af applikationer verden over øjeblikkeligt sårbare over for udnyttelse.

Værktøjer til analyse af softwaresammensætning (SCA) opretter automatisk en fortegnelse over alle open source-komponenter i en applikation — herunder transitive afhængigheder (afhængighedernes afhængigheder) — og kontrollerer dem løbende mod sårbarhedsdatabaser for kendte CVE'er. SCA genererer en stykliste over software (SBOM), der viser alle komponenter og versioner, så berørte systemer hurtigt kan identificeres, når nye sårbarheder offentliggøres.

Transitive afhængigheder er biblioteker, som dine direkte afhængigheder selv afhænger af, og som du ikke udtrykkeligt har valgt. Du kan have en direkte afhængighed til Package A, som afhænger af Package B (version 1.2), der afhænger af Package C (version 3.0 — en sårbar version). Du kender ikke Package C, men din applikation kører det. SCA-værktøjer gennemgår hele afhængighedstræet for at synliggøre disse skjulte sårbarheder, som udviklere ikke har direkte indsigt i.

En stykliste over software (SBOM) er en formel, maskinlæsbar fortegnelse over alle komponenter i et softwareprodukt — svarende til en ingrediensliste på fødevarer. SBOM-formater omfatter SPDX (Linux Foundation) og CycloneDX (OWASP). USA's Executive Order 14028 (2021) krævede SBOM'er for software, der sælges til den føderale regering. Med en SBOM kan sikkerhedsteams straks spørge: 'Hvilke af vores produkter indeholder Log4j?' og få svar på få minutter i stedet for efter dages manuel søgning.

Fastlåsning af afhængigheder angiver præcise versioner af afhængigheder i stedet for fleksible intervaller (^1.2.3 eller *). Lock-filer (package-lock.json, yarn.lock, Pipfile.lock, Gemfile.lock) registrerer den præcise løste version af hver afhængighed på installationstidspunktet. De bør committes til kildekontrol for at sikre, at alle teammedlemmer og CI/CD-arbejdsgange bruger identiske afhængighedsversioner og dermed forhindre angreb på forsyningskæden, hvor pakkeversioner forgiftes mellem installationer.

Angreb på forsyningskæden retter sig mod afhængighedsøkosystemet. Typosquatting består i at udgive ondsindede pakker med navne, der ligner populære pakkers navne (f.eks. lodahs i stedet for lodash) i håb om, at udviklere skriver navnet forkert. Angreb med forveksling af afhængigheder udnytter den rækkefølge, som pakkehåndteringer søger i registre på — en angriber udgiver en ondsindet pakke med samme navn som en intern privat pakke, men med et højere versionsnummer, så pakkehåndteringen i stedet installerer den ondsindede offentlige version.

Flere SCA-værktøjer bruges i stor udstrækning i branchen. Snyk tilbyder udviklervenlig scanning af afhængigheder med automatiske pull requests til rettelser. OWASP Dependency-Check er et gratis og udbredt værktøj til Java, .NET, Python og Ruby. GitHub Dependabot åbner automatisk pull requests for at opdatere sårbare afhængigheder i GitHub-lagre. JFrog Xray og Sonatype Nexus IQ integrerer SCA i artefaktlagre for at blokere sårbare builds, før de når produktion.

SCA er mest effektiv, når den integreres som en kvalitetsport i CI/CD-arbejdsgangen. Ved hver pull request og hvert build kører arbejdsgangen SCA-værktøjet og får buildet til at fejle, hvis der findes CVE'er med kritisk eller høj alvorlighed i afhængighederne. Denne tilgang med at flytte sikkerheden til venstre opdager sårbare afhængigheder, før de når produktion — ikke måneder senere under en manuel sikkerhedsgennemgang eller efter et brud. Teams bør definere tydelige tærskler for sårbarheders alvorlighed, som blokerer udrulning, og skelne dem fra sårbarheder, der kun genererer advarsler.

Før du tilføjer en afhængighed, bør du vurdere dens sikkerhedsstatus ved hjælp af flere signaler. Vedligeholdelsesaktivitet: Vedligeholdes projektet aktivt? Hvornår blev den seneste commit og udgivelse foretaget? Historik over kendte sårbarheder: Hvor mange CVE'er har den haft, og hvor hurtigt blev de rettet? Downloadmængde: Pakkers udbredte anvendelse tiltrækker mere sikkerhedskontrol. Antal afhængigheder: Pakker med færre afhængigheder medfører mindre transitive risici. OpenSSF Scorecard leverer automatisk vurdering af open source-projekters sikkerhedspraksis.

Når SCA identificerer en sårbar afhængighed, findes der flere strategier til afhjælpning. Opgradér til en rettet version — den foretrukne mulighed, når den findes. Virtuel rettelse gennem WAF-regler kan begrænse kendte udnyttelsesveje, mens en opgradering forberedes. Fjern afhængigheden, hvis der ikke længere er brug for den. Acceptér risikoen med en dokumenteret begrundelse, hvis sårbarheden ikke kan udnyttes i den konkrete anvendelseskontekst (f.eks. en serversidesårbarhed i et klientsidebibliotek). Lad aldrig kritiske sårbarheder stå uafhjulpne uden en dokumenteret accept.

SCA-værktøjer har et dobbelt formål: De identificerer sikkerhedssårbarheder og markerer problemer med licensoverholdelse i open source-afhængigheder. Almindelige problematiske licenser omfatter GPL v2/v3 (copyleft — kræver, at dit produkt også udgives som open source, hvis du distribuerer det), AGPL (udvider GPL til netværkstjenester) og SSPL. Brug af et GPL-licenseret bibliotek i proprietær kommerciel software uden en kommerciel licens kan medføre et alvorligt juridisk ansvar. SCA-værktøjer som FOSSA, Black Duck og WhiteSource automatiserer licensscanning sammen med registrering af sårbarheder og sikrer overholdelse af forpligtelserne ved open source.

I denne lektion har du lært, at SCA-værktøjer scanner hele afhængighedstræet, inklusive transitive afhængigheder, for kendte CVE'er, at SBOM'er giver en maskinlæsbar fortegnelse, som muliggør hurtig reaktion, når nye sårbarheder offentliggøres, og at integration af SCA som en kvalitetsport i CI/CD opdager sårbare afhængigheder, før de når produktion. Som det næste ser vi på DevSecOps, og hvordan sikkerhedskontroller kan flyttes til venstre i hele CI/CD-arbejdsgangen.