Trusler i supply chain

Angribere udgiver skadelige pakker med navne, der ligner populære pakker, og satser på en fatal tastefejl.

• Typosquatting — reqeusts i stedet for requests
• Combosquatting — python-requests efterligner det rigtige navn
• Afhængighedsforveksling — en offentlig pakke udgives med samme navn som din interne private pakke, så en forkert konfigureret afhængighedsopløser henter angriberens version

Beskyt dig ved at fastlåse et pålideligt internt pakkeregister og bruge private pakker med begrænset rækkevidde eller navnerum.

En legitim og bredt betroet pakke kan blive skadelig, hvis vedligeholderens konto kompromitteres, eller hvis en skadelig bidragyder får ret til at udgive pakker.

Nyere hændelser fra den virkelige verden viser, hvordan angribere lokker vedligeholderes loginoplysninger ud af dem og derefter udgiver en kompromitteret programrettelse, der eksfiltrerer tokens under installationen.

• Kræv 2FA på alle konti, der kan udgive pakker
• Foretræk pakker med udgivelsestokens med begrænset rækkevidde og beskyttede udgivelser
• Hold øje med uventede nye vedligeholdere af kritiske afhængigheder

Mange økosystemer kører kode på installationstidspunktet, før din app overhovedet kører. En npm install kan udføre en postinstall-hook, der stjæler miljøvariabler eller SSH-nøgler.

Deaktivér vilkårlige installationsscripts i CI, og gennemgå alle pakker, der har brug for dem:

Selve byggemiljøet er et mål med høj værdi. Hvis en angriber forgifter en compiler, et CI-kørselafbildning eller et plugin til byggeprocessen, indeholder alle de artefakter, den producerer, en bagdør, selv når din kildekode er ren.

Det klassiske eksempel er en trojaniseret opdateringsmekanisme, der signerer malware med en legitim nøgle til kodesignering, så ofrene accepterer den som ægte.

• Behandl byggeinfrastrukturen som produktion, og hærd den fuldt ud
• Brug midlertidige, reproducerbare kørselssystemer til byggeprocessen
• Adskil signeringsnøgler fra byggeværten

En låsefil fastlåser præcise versioner og indholdshashværdier, så en ny opløsning ikke ubemærket kan udskifte et artefakt med et andet. Commit den altid, og lad CI verificere den i stedet for frit at opløse afhængighederne igen.

Integritetsfeltet gemmer en hashværdi; hvis den hentede tarball ikke stemmer overens, mislykkes installationen.

Kendte sårbare versioner, der registreres som CVE'er, er den mest almindelige svaghed i softwareforsyningskæden. Værktøjer til softwarekompositionsanalyse (SCA) sammenholder dine opløste afhængigheder med sårbarhedsdatabaser.

Kør scanninger i CI, og lad byggeprocesser mislykkes ved kritiske fund:

Flydende versionsintervaller (^1.2.0) lader nye udgivelser komme ind automatisk. Det er praktisk, men udsætter dig for en skadelig programrettelse.

• Fastlås til præcise versioner, og gennemgå opgraderinger bevidst
• Fastlås med en digest for containerafbildninger, ikke med ændrelige mærker som latest
• Indlejr kritiske afhængigheder i dit eget kodelager eller spejl, så en sletning hos den oprindelige leverandør ikke kan ødelægge eller forgifte dig

Sikring af softwareforsyningskæden er en løbende opgave, ikke en scanning, du kun udfører én gang. Du skal vide hvad du leverer, hvor det kommer fra, og hvornår det bliver sårbart.

• Generér en SBOM for hver udgivelse (i næste lektion)
• Dokumentér byggeprocessens oprindelse, så du kan bevise, hvordan et artefakt blev produceret
• Abonnér på sikkerhedsmeddelelser, så en nyoffentliggjort CVE udløser en ny vurdering af byggeprocesser, der allerede er leveret

Kortlæg hvert trin, hvor input, du ikke stoler på, kommer ind: udviklermaskiner, versionsstyring, afhængighedsregistre, byggesystemet, artefaktlageret og opdateringskanalen. Hvert af dem er et muligt injektionspunkt.

Spørg ved hvert trin: hvem kan skrive hertil, hvad ville en kompromittering give dem mulighed for, og hvordan ville jeg opdage det? Det giver en prioriteret liste over sikkerhedsforanstaltninger i stedet for en generisk tjekliste.

Du har lært, hvorfor afhængigheder er angrebsvektorer, og hvordan du kan begrænse denne eksponering.

• Tillidsinversion betyder, at din sikkerhed afhænger af tredjeparter, du ikke har kontrol over
• Vigtige trusler er typosquatting, afhængighedsforveksling, overtagelse af vedligeholderadgang, skadelige installationsscripts og kompromitterede værktøjer til byggeprocessen
• De vigtigste forsvar er låsefiler med integritetshashværdier, SCA-scanning, præcis fastlåsning med digest, 2FA for udgivere og kontinuerlig overvågning

Dernæst registrerer du præcist, hvad din software indeholder, med en SBOM.