TeamPCP iski PyPI:n LiteLLM:ään: syvällinen katsaus tunnistetietoja varastavaan haittaohjelmakampanjaan

Viimeisin päivitys: 03/25/2026
Kirjoittaja: C SourceTrail
  • LiteLLM PyPI -pakettiin tehtiin takaportti versioissa 1.82.7 ja 1.82.8 TeamPCP:hen linkitetty monivaiheinen tunnistetietojen varastamisen hyötykuorma.
  • Haittaohjelma keräsi salaisuuksia pilvi-, CI/CD-, Kubernetes- ja paikallisjärjestelmistä ja vuodatti salattuja tietoja hyökkääjien hallitsemille verkkotunnuksille.
  • Hyökkääjät todennäköisesti siirtyivät Trivyn toimitusketjun murron kautta väärinkäyttäen varastettua PyPI-tokenia pyörän rakennus- ja julkaisuprosessin aikana.
  • Puolustajia kehotetaan käsittelemään tartunnan saaneita ympäristöjä vaarantuneina, kierrättämään kaikkia tunnistetietoja, etsimään pysyvyyden aiheuttavia esineitä ja kiinnittämään LiteLLM turvalliseen versioon.

LiteLLM-haittaohjelmatapaus PyPI:ssä

Muutaman tunnin ajan 24. maaliskuuta 2026 erittäin suosittu Python-paketti muuttui hiljaisesti voimakkaaksi tunnistetietojen varastajaksi. Kaksi myrkytettyä julkaisua LiteLLM:stä, kirjastosta, jota käytetään laajalti... yhtenäinen käyttöliittymä suuriin kielimalleihin (LLM), ladattiin PyPI:hin, mikä altisti hetkellisesti valtavan määrän järjestelmiä hienostuneelle toimitusketjuhyökkäykselle.

Haitalliset versiot, 1.82.7 ja 1.82.8, niputti monivaiheisen hyötykuorman, joka pystyy imemään salaisuuksia kehittäjäkoneista, CI/CD-ajojärjestelmistä, pilvi-infrastruktuurista ja Kubernetes-klustereista ja sitten siirtämään ne hyökkääjien hallitsemille palvelimille. Kampanja on ollut sidoksissa TeamPCP-uhkaryhmään, joka on ollut kuukausia kestäneessä rynnäkkökierroksessa Trivyssä, Checkmarx-työkaluissa ja Docker-levykuvissa, hyökkäykset npm-toimitusketjua vastaan ja nyt PyPI-ekosysteemi.

Mikä on LiteLLM ja miksi se oli niin ensisijainen kohde?

LiteLLM-pakkauksen toimitusketjun riski

LiteLLM on avoimen lähdekoodin Python-kirjasto ja välityspalvelin joka toimii eräänlaisena universaalina sovittimena LLM-rajapinnoille. Sen avulla sovellukset voivat kommunikoida yli sadan eri mallin kanssa – palveluntarjoajilta, kuten OpenAI, Anthropic, Google, AWS Bedrock, Vertex AI ja muut – yhden OpenAI-tyyppisen rajapinnan kautta.

Tämän roolin ansiosta projekti on juurtunut syvälle tekoälyekosysteemiin. Useiden tietoturvatoimittajien raportit osoittavat, että LiteLLM näkee suunnilleen 3–3.4 miljoonaa latausta päivässä, ja joidenkin telemetriatietojen perusteella sitä on läsnä noin 36 % valvotuista pilviympäristöistäHyökkääjille paketin vaarantaminen tuolla jalanjäljellä tarjoaa harvinaisen tilaisuuden päästä käsiksi valtavaan määrään arkaluonteisia tietoja ja tunnistetietoja yhdellä iskulla.

Suunnittelunsa vuoksi LiteLLM sijaitsee usein suoraan välissä sovelluksia ja useita tekoälypalveluntarjoajiaTämä asema tarkoittaa, että se käsittelee rutiininomaisesti API-avaimia, ympäristömuuttujia, määritystiedostoja ja muita salaisuuksia, joita tarvitaan ulkoisten LLM-päätepisteiden saavuttamiseksi. Tällaisessa riippuvuudessa oleva takaovi voi hiljaa siepata ja vuotaa nämä arvot ilman, että vaaditaan suoraa murtoa itse ylävirran alustoille.

Tapaus korostaa myös sitä, kuinka kietoutunut moderni kehitys on: paikalliset työasemat, CI/CD-putket, Kubernetes-klusterit ja pilvitilit ovat kaikki sidoksissa toisiinsa jaettujen salaisuuksien ja automaation kautta. Yksi vaarantunut riippuvuus kyseisessä graafissa voi paljastaa tunnistetietoja organisaation useilla eri tasoilla, mikä vahvistaa vaikutusta paljon yhden isännän ulkopuolelle.

Kuinka haitalliset LiteLLM-versiot levisivät

LiteLLM-versiot PyPI:ssä takaportilla

Myrkytetyt päästöt LiteLLM 1.82.7 ja 1.82.8 siirrettiin PyPI:hin 24. maaliskuuta 2026 aamulla, noin 08: 30 UTCNe pysyivät saatavilla lähes kaksi tuntia ennen kuin PyPI-tietoturvatiimi eristi ne ja kolmannen osapuolen puolustusjärjestelmät estivät niiden käytön. Ne on poistettu noin 11: 25 UTC.

Tämän tapauksen tekee merkillepantavaksi se, että takaovea ei näkynyt vastaavassa GitHub-lähdekoodissaEndor Labs ja muut tutkijat havaitsivat, että haitallinen logiikka oli ruiskutettu PyPI:ssä jaettuun rakennettuun wheeliin, ei julkiseen arkistoon, mikä viittaa siihen, että tietomurto tapahtui rakennus-/julkaisuprosessin aikana tai sen jälkeen eikä näkyvän koodin commitin kautta.

Analyytikot havaitsivat erityisesti, että tiedosto litellm/proxy/proxy_server.py sisälsi upotetun base64-koodatun hyötykuorman, joka oli puuttuu samasta tiedostosta GitHub-commitissaMuuten laillisten koodilohkojen väliin (esimerkiksi lähelle määritelmää) lisättiin noin tusina riviä. REALTIME_REQUEST_SCOPE_TEMPLATE ja showwarning funktio). Nuo ylimääräiset rivit dekoodattiin ja suoritettiin hiljaisesti piilotettu komentosarja aina, kun moduuli tuotiin.

Versiossa 1.82.8hyökkääjät menivät askeleen pidemmälle pudottamalla .pth tiedosto nimeltä litellm_init.pth Python-ympäristöön. Koska Python käsittelee kaikki .pth tiedostot tulkin käynnistyksen yhteydessä, tämä varmisti hyötykuorman suorittamisen jokaisella Python-kutsun yhteydessä, vaikka sovellus ei olisi koskaan tuonut itse LiteLLM:ää.

Tämä eskaloituminen teki 1.82.8 huomattavasti vaarallisempiMikä tahansa Python-skripti, testiajuri, koontityökalu tai automaatio, joka käynnistetään ympäristössä, jossa vaarantunut paketti on asennettu, käynnistää hiljaisesti tunnistetietojen varastamisen logiikan taustalla.

Yhteys laajempaan TeamPCP-kampanjaan

TeamPCP:n toimitusketjukampanja

LiteLLM-kompromissi ei tapahtunut eristyksissä. Sonatypen, Wizin, Endor Labsin ja muiden tutkimukset yhdistävät sen johonkin TeamPCP:n käynnissä oleva toimitusketjukampanja, ryhmä, joka herätti huomiota vuoden 2025 lopulla ja on sittemmin kohdistanut toimintansa useisiin avoimen lähdekoodin projekteihin ja kehittäjäekosysteemeihin.

Aiemmin maaliskuussa samat toimijat olivat sidoksissa salamurhaan Aqua Securityn Trivy haavoittuvuuksien skanneriin ja siihen liittyviin GitHub-toimintoihin sekä Checkmarx-työkalujen haitallisiin muunnelmiin, mukaan lukien KICS, GitHub Actions ja OpenVSX-laajennukset. Kampanja on koskenut myös npm-paketteja, Docker Hub -kuvia ja Kubernetes-ympäristöjä, usein uudelleenkäyttäen infrastruktuuria, salausmenetelmiä ja pysyvyysartefakteja.

Jäljittäessään LiteLLM-tapausta ylläpitäjät paljastivat, että PyPI-julkaisutunnus LiteLLM:n GitHub-arkistoon ympäristömuuttujana tallennettu arvo vuoti vaarantuneen Trivy-työnkulun kautta. Tätä tunnusta käytettiin sitten väärin julkaise saastuneita PyPI-julkaisuja, joiden avulla hyökkääjät voivat ohittaa käyttäjätilien kaksivaiheiset suojaukset ja lisätä haitallisia kiekkoja muuttamatta julkista lähdekoodia.

Tutkijat viittaavat myös epäilyttäviin commit-tiedostoihin ja työnkulkuihin, jotka on luotu noin 23. maaliskuuta LiteLLM:ään liittyvissä arkistoissa, mukaan lukien lyhytikäinen haara ja GitHub Actions -työnkulku, joka sisältää tutun RSA-julkisen avaimen, jota on nähty muissa TeamPCP-hyötykuormissa. Työnkulkujen suoritusten telemetria viittaa siihen, että näiden CI-suorittimien saatavilla olevia salaisuuksia on saatettu päästä käsiksi ja vuotaa.

Tapausten välillä ryhmä on osoittanut johdonmukaista kaavaa: varastaa tunnistetiedot yhdessä ympäristössä ja siirtyä sitten seuraavaan ekosysteemiinTässä tapauksessa Trivyn GitHub Actionsin virheellinen määritys mahdollisti etuoikeutetun tokenin varastamisen; kyseinen token johti haitallisiin Trivy-julkaisuihin ja Docker-levykuviin; nämä puolestaan ​​mahdollistivat Checkmarx-työkalujen ja lopulta LiteLLM PyPI -paketin vaarantumisen.

Näin LiteLLM-haittaohjelma toimii

Useiden toimittajien analyysit kuvaavat LiteLLM-takaovea monivaiheinen, base64-obfuskoitu Python-hyötykuorma suunniteltu olemaan huomaamaton, joustava ja vikasietoinen. Logiikka on järjestetty karkeasti kolmeen kerrokseen, joista jokainen käsittelee hyökkäyksen eri vaihetta.

Ensimmäisessä kerroksessa injektoitu koodi proxy_server.py tai litellm_init.pth tiedosto dekoodaa ja käynnistää piilotetun orkestroijanSen sijaan, että käytettäisiin helposti merkittäviä funktioita, kuten exec(), komentosarja nojaa aliprosessikutsuihin ja kirjaston vakiotoimintoihin dekoodatun hyötykuorman suorittamiseen ja sen tulosteen tallentamiseen, mikä auttaa sitä sulautumaan normaaliin sovelluksen toimintaan.

Käynnistyttyään tämä orkestroija kerää seuraavan vaiheen tuotoksen, salaa kerätyt tiedot AES-256-CBC-salaustekniikalla ja sitten salaa itse AES-istuntoavaimen käyttämällä koodiin sisäänrakennettua kovakoodattua RSA-julkista avainta. Salattu blob ja avain niputetaan arkistoon nimeltä tpcp.tar.gz, toistaen muita TeamPCP:n operaatioita ja valmistautui karkotukseen.

Toinen kerros on vastuussa aggressiivinen järjestelmän tiedustelu ja tunnistetietojen keruuSe luettelee isäntänimet, käyttäjä- ja verkkotiedot sekä ympäristömuuttujat ja skannaa sitten pitkän luettelon poluista ja asetustiedostoista arkaluonteisen materiaalin varalta. Kohteisiin kuuluvat:

  • SSH-avaimet ja asetustiedostot (asiakas ja palvelin)
  • Pilvitunnistetiedot AWS:lle, GCP:lle ja Azurelle, mukaan lukien metadatasta johdetut tokenit
  • Kubernetes-kubeconfig-tiedostot, palvelutilin tunnukset ja klusterisalaisuudet
  • Ympäristötiedostot kuten .env variantteja, joita usein käytetään API-avainten tallentamiseen
  • CI/CD-kokoonpano, salaisuudet ja käyttöoikeustunnukset
  • Terraform, Helm ja muut IaC- tai käyttöönottoartefaktit
  • Tietokannan yhteysmerkkijonot ja määritystiedostot
  • TLS/SSL-yksityiset avaimet ja todennusmateriaalia
  • Kryptovaluuttalompakot ja siihen liittyvät tiedot

Joissakin ympäristöissä varastaja ei pysähdy keräämiseen. Se yrittää käytä aktiivisesti löydettyjä tunnistetietojaesimerkiksi kyselemällä pilvipalveluntarjoajien API-rajapintoja, hakemalla Kubernetes-salaisuuksia tai tutkimalla saavutettavia resursseja, mikä lisää sivuttaissiirtymisen ja sitä seuraavan tietomurron riskiä.

Kolmas kerros tarjoaa pysyvyys ja etäohjausSe kirjoittaa Python-skriptin levylle (yleisesti havaittu nimellä sysmon.py) ja rekisteröi sen pitkäkestoiseksi palveluksi, joka usein naamioidaan joksikin hyvänlaatuiseksi, kuten "järjestelmän telemetriapalveluksi". Tämä palvelu ottaa säännöllisesti yhteyttä hyökkääjän infrastruktuuriin, tyypillisesti 50 minuutin välein, hakeakseen lisäkomentoja tai hyötykuormia.

Tutkijat huomaavat tässä jonkin verran omituista toimintaa: kun tietyt tietoturvatoimittajat yrittivät saada hyötykuorman komento- ja ohjauspäätepisteestä, palvelin vastasi linkillä kappaleen "Bad Apple!!" remasteroidulle versiolle, ilmeisesti automaattista analyysia vastaan ​​​​suunnattu harhautustaktiikkaTartunnan saaneissa järjestelmissä sama mekanismi voi kuitenkin ajan myötä hiljaa toimittaa uusia toimintoja.

Soluttautumiskanavat ja hyökkääjän infrastruktuuri

LiteLLM-tapausten aikana analyytikot havaitsivat viestintää ainakin kahden hyökkääjän hallitseman pääalueen kanssa: modelslitellmcloud ja checkmarxzoneNämä ovat linjassa aiemmassa TeamPCP-toiminnassa käytetyn infrastruktuurin kanssa ja niillä on erillisiä rooleja.

Salattu arkisto tpcp.tar.gz on tyypillisesti ladattu models.litellmcloud-sivustolle, jonka avulla operaattorit voivat hakea varastettuja tunnistetietoja tuhansista alavirran ympäristöistä. Joissakin muunnelmissa eri alipolut checkmarxzone (esimerkiksi, checkmarxzone/raw or .../vsx) käytetään pysyvyysskriptien tai lisävaiheiden toimittamiseen.

Vaarantuneissa järjestelmissä puolustajat ovat raportoineet toistuvista ongelmista kompromissin indikaattorit (IoC:t) liittyy LiteLLM-haittaohjelmaan:

  • Arkiston läsnäolo tpcp.tar.gz väliaikaisissa tai työhakemistoissa
  • Väliaikaiset tiedostot, kuten /tmp/pglog ja /tmp/.pg_state
  • Python-skripti ja siihen liittyvät määrityspolut sysmon.py ja vastaava palvelutiedosto (usein käyttäjän tai systemd:n ​​asetushakemistoissa)
  • Odottamaton litellm_init.pth tiedostot Python-sivustopaketeissa versiolle 1.82.8
  • Lähtevä liikenne tai DNS-haut osoittavat kohteeseen modelslitellmcloud or checkmarxzone

Haitallista logiikkaa jäljitettiin tiedostoihin, mukaan lukien proxy_server.py (LiteLLM 1.82.7 ja 1.82.8) ja litellm_init.pth (1.82.8). Tietoturvatoimittajat ovat luetteloineet tiivisteitä ja muita IoC-arvoja ja päivittävät jatkuvasti tiedotteitaan sitä mukaa, kun uusia rikosteknisiä tietoja tulee esiin.

Vaikutus tekoäly-, pilvi- ja CI/CD-ympäristöihin

Koska LiteLLM:ää käytetään paljon Tekoälypohjaiset sovellukset ja palvelutTämän kompromissin käytännön vaikutusalue ulottuu yksinkertaisten pakettien käyttäjien ulkopuolelle. Pilviympäristöissä, joissa LiteLLM toimi porttina LLM-palveluntarjoajille, on todennäköisesti samassa suoritusympäristössä tai konfiguraatiotilassa olevia salaisuuksia.

Wiz ja muut tarkkailijat arvioivat, että LiteLLM esiintyy noin kolmannes havaituista pilviympäristöistämikä korostaa potentiaalista ulottuvuutta. Jotkut BleepingComputerin mainitsemat lähteet ovat esittäneet, että tietovuotojen määrä voi nousta satoihin tuhansiin, vaikka tarkkojen lukujen riippumaton vahvistus on vielä odotettavissa.

Erityisesti haittaohjelma korostaa Kubernetes-tietoinen toimintaMonissa analyyseissä hyötykuorma yrittää ottaa käyttöön etuoikeutettuja podeja kaikissa klusterin solmuissa ja käyttää sitten näitä podeja salaisuuksien ja määritysobjektien käyttämiseen. Erillisissä mutta toisiinsa liittyvissä TeamPCP-operaatioissa tutkijat ovat nähneet Kubernetes-klustereita, joihin on kohdistettu skriptejä, jotka tyhjentävät solmut, kun ympäristö näyttää sijaitsevan Iranissa, samalla kun ne asentavat takaportteja (kuten niin kutsuttu CanisterWorm) muualle.

CI/CD-työkaluihin keskittyminen on samalla tavalla selkeää. Vaarantamalla Trivy GitHub Actionsin, Checkmarx VS Code -laajennukset ja GitHub Actionsin sekä nyt myös LiteLLM:n hyökkääjät saavat sisäänpääsypisteitä, joissa automaatiolla on jo laajat käyttöoikeudet tietovarastojen kautta, rakentaa artefakteja ja käyttöönottotunnistetietoja. Tämä lähestymistapa muuttaa muuten tietoturvapainotteiset työkalut askelmiksi kohti laajempaa tietomurtoa.

FBI:n virkamiehet ja alan tutkijat ovat varoittaneet, että suuri määrä varastettuja valtakirjoja hallussaanon kohtuullista odottaa lisää tietomurtoilmoituksia, toissijaisia ​​tunkeutumisia ja kiristysyrityksiä LiteLLM:n alkuperäisen paljastuksen jälkeisinä viikkoina ja kuukausina.

Havaitsemis-, eristämis- ja korjaavat toimenpiteet

Organisaatioille, jotka ovat saattaneet vetää tai ottaa käyttöön LiteLLM-versioita 1.82.7 tai 1.82.8 PyPI:n osalta tietoturvatoimittajien ja PyPI-ylläpitäjien ohjeet ovat tylyjä: käsittele vaurioituneita järjestelmiä vaarantuneinaPaketin pelkkä asennuksen poistaminen ei poista pysyvyysmekanismeja tai kumoa jo tapahtunutta tunnistetietojen varastamista.

Suositeltavia välittömiä toimia ovat:

  • Tunnista mahdolliset asennukset LiteLLM 1.82.7:n tai 1.82.8:n käyttöön kehittäjäkoneissa, CI/CD-ajokoneissa, konteissa ja tuotantoympäristöissä.
  • Poista haitalliset versiot ja kiinnitä LiteLLM tunnettuun toimivaan julkaisuun (jossa versiota 1.82.6 pidetään laajalti viimeisimpänä puhtaana versiona raportointihetkellä).
  • Kierrätä kaikki tunnistetiedot joihin on pääsy kyseisistä ympäristöistä: SSH-avaimet, pilvipalveluntarjoajan avaimet ja tunnukset, Kubernetes-salaisuudet, CI/CD-salaisuudet, tietokannan tunnistetiedot, TLS-avaimet ja kaikki lompakot tai maksuihin liittyvät salaisuudet.
  • Etsi pysyvyysartefakteja, Kuten sysmon.py, epäilyttävät systemd-palvelumääritelmät ja epätavalliset tiedostot kohdassa ~/.config tai väliaikaisia ​​hakemistoja, kuten /tmp/pglog ja /tmp/.pg_state.
  • Kubernetes-klusterien tarkastaminen odottamattomille etuoikeutetuille podeille, erityisesti nimiavaruuksissa, kuten kube-systemja epätavallisille palvelutileille tai roolisidonnaisuuksille.
  • Lähtevien yhteyksien valvonta ja DNS-kyselyt tunnetuille hyökkääjäverkkotunnuksille, kuten models.litellmcloud ja checkmarxzone.

Ympäristöissä, joissa takaovi on saattanut toimia merkittävän ajan, monet asiantuntijat ehdottavat, että täydellinen uudelleenrakennus luotettavasta lähtökohdasta voi olla turvallisin vaihtoehto, erityisesti kriittiselle infrastruktuurille. Haittaohjelman luonteen vuoksi hienovaraista manipulointia tai lisähyötykuormia ei voida sulkea pois pelkästään poistamalla LiteLLM-paketti.

Organisaatioita kannustetaan myös omaksumaan tehokkaampia riippuvuuksien hallinta ja toimitusketjun puolustus: kiinnittäminen tiettyihin, vahvistettuihin versioihin, työkalujen käyttöönotto, jotka estävät tai merkitsevät tunnettuja haitallisia paketteja niiden lataamisen yhteydessä, ja automaattisen käyttäytymisanalyysin sisällyttäminen, joka voi havaita odottamatonta verkko- tai tiedostojärjestelmätoimintaa koontiversioiden ja testien aikana.

Mitä LiteLLM:n tapaus kertoo tekoälyohjelmistojen toimitusketjuista

LiteLLM-tapaus korostaa laajempaa trendiä, joka on rakentunut viime vuosina: tekoälyn ja pilvipalveluiden korkean vipuvaikutuksen komponenteista on tulossa ensisijaisia ​​kohteita toimitusketjun hyökkääjille. Sen sijaan, että uhkatoimijat hyökkäisivät suoraan loppukäyttäjien sovelluksiin, he etsivät yhä enemmän työkaluketjun kohtia, joissa yhden kirjaston tai laajennuksen vaarantaminen antaa pääsyn useille alavirran organisaatioille.

Paketit, kuten LiteLLM, sijaitsevat käytännössä samassa paikassa. salaisuuksien kurkkukipuNe välittävät puheluita tekoälypalveluntarjoajille, koskettavat CI/CD- ja infrastruktuurin automaatiojärjestelmiä ja toimivat usein laajennetuilla käyttöoikeuksilla. Kun yhä useammat yritykset kiirehtivät integroimaan LLM-ominaisuuksia avoimen lähdekoodin työkalujen avulla, tällaisten komponenttien arvo – ja kannustin niiden takaportin käyttöön – vain kasvaa.

Samaan aikaan hyökkäys havainnollistaa rakennus- ja julkaisuputkien puolustamisen haasteita. Tässä tapauksessa hyökkääjät väittivät hyödyntäneensä Trivy-työnkulun virheellistä konfiguraatiota varastaakseen tokenin ja käyttäneensä sitten kyseistä tokenia saastuneiden pakettien lähettämiseen PyPI:hin, samalla jättäen julkisen lähdekoodipuun näennäisesti puhtaaksi. Versiotunnisteet ja koontivaiheet tulivat osaksi hyökkäyspintaa, hyödyntäen sitä tosiasiaa, että monet putkistot perustuvat tunnisteisiin kiinnitettyjen committien sijaan ja saattavat implisiittisesti luottaa tutuilta ylläpitäjiltä tuleviin artefakteihin.

Myyjät, kuten Sonatype, Wiz ja Endor Labs, korostavat automatisoidut, reaaliaikaiset suojaustoimet ...joka pystyy havaitsemaan poikkeavaa toimintaa – kuten aiemmin näkymättömiä verkkokohteita tai salatun vuotamisen – vaikka pakettien metatiedot ja tietovaraston historia näyttäisivät laillisilta. Tietovarastojen palomuurit, uhkatiedusteluun perustuvat skannerit ja riippuvuuksien kontekstuaalinen analyysi nähdään yhä useammin välttämättöminä tasoina, ei valinnaisina lisäominaisuuksina.

Sekä ylläpitäjille että organisaatioille LiteLLM-kompromissi muistuttaa siitä, että salaisuuksien käsittely, CI/CD-kovettaminen ja tunnistetietojen kierrätys ovat toimitusketjun turvallisuuden perusta. Epätäydellinen tai ei-atomitason tunnistetietojen kierrätys aiemmissa tapauksissa jätti aukkoja, joita TeamPCP pystyi käyttämään uudelleen viikkoja myöhemmin. Tämä osoittaa, kuinka yksi ainoa virhe tapahtuman reagoinnissa voi levitä useiden ekosysteemien läpi.

LiteLLM:n valloittanut kampanja alkoi näennäisesti rajoitetusta työnkulkuongelmasta ja on sittemmin kattanut GitHub Actionsin, Docker Hubin, Shai-Hulud npm -tapaus, OpenVSX ja PyPI. Kun laajalti luotettavissa työkaluissa ja tekoälyliittimissä piilee takaportteja ja hyökkääjäinfrastruktuuriin virtaa varastettuja tunnistetietoja, jakso korostaa sitä, kuinka nopeasti ohjelmistojen toimitusketjusta voi tulla houkutteleva ja erittäin tehokas hyökkäyspinta.

ataque Shai-Hulud a la cadena de suministro de npm
Aiheeseen liittyvä artikkeli:
Shai-Hulud: el ataque que sacude la cadena de suministro de npm
Related viestiä: