Aanvallers verstoppen infostealer in kwetsbaarhedenscanner Trivy

Kwetsbaarhedenscanner Trivy bevatte informatiestelende malware door een succesvolle hackaanval op ontwikkelaars van deze securitytool. Containerimages en GitHub-releases waren gecompromitteerd, wat ook het automatisch aanroepen van Trivy via GitHub Actions trof.

Het inplanten van een infostealer in deze securityscanner gebeurde via buitgemaakte inloggegevens voor de GitHub-repository van Trivy-maker Aqua Security, meldt Bleeping Computer. Daarmee kreeg de aanvaller, die gelinkt is aan cybercrimegroep TeamPCP, schrijfrechten voor de code van Trivy. Gebruikers van deze tool lopen risico dat inloggegevens voor hun ict-omgevingen zijn gestolen. De mogelijk getroffen omgevingen lopen uiteen van cloudinfrastructuur en containeropstellingen tot softwareontwikkelsystemen.

Aqua Security meldt dat deze aanval 'een voortzetting is van de supplychainaanval die eind februari 2026 begon'. Het bedrijf onthulde die eerdere aanval op 1 maart, waarna het de eigen inlogcredentials ververste. Die verversing gebeurde niet volledig gelijktijdig, maar nam enkele dagen in beslag, legt Aqua uit. Daardoor had de aanvaller mogelijk nog een valide inlogtoken waarmee nieuwe inloggegevens waren te verkrijgen.

Het gevaar van softwaresupplychains

Eind vorig jaar nam de Owasp Foundation gaten in softwaresupplychains op in haar lijst van ict-beveiligingsrisico's. Deze toen nieuwe categorie stond gelijk in de top drie van de vernieuwde Owasp-lijst. Op nummer een staat kapotte toegangscontrole en op nummer twee staan configuratiefouten van securitysystemen.

Bron: Curly_Photo/Moment/Getty Images

Reacties (47)

[Stukfruit]

Dit is dus exact een van de redenen waarom je packages vastzet op één specifieke versie commit én zulke tools alleen binnen een afgeschermde omgeving draait én gevoelige gegevens per definitie afgeschermd houdt én zaken die door Trivy worden gevonden automatisch onbruikbaar maakt door bv. nieuwe keys te genereren.

Het ging hier volgens het artikel trouwens over Trivy v0.69.4, die nu vervangen lijkt te zijn door de .3-release.

[Reactie gewijzigd door Stukfruit op 22 maart 2026 13:31]

[jimmy_dg]

vastzet op één specifieke versie

Je moet juist niet een tag/versie gebruiken maar de sha256 hash. De hash is niet te vervangen maar de tag wel, wat in dit geval is gebeurt.

[R4gnax]

Of een distributiekanaal gebruiken wat het vervangen van een reeds gepubliceerde versie niet toelaat.
Direct een git commit gebruiken is een nogal banale aanpak. Vziw staat Github Actions echter niet anders toe, wat als dat klopt - eigenlijk, grof gezegd, gewoon een infantiel slechte oplossing is die niemand zou moeten gebruiken.

[Reactie gewijzigd door R4gnax op 22 maart 2026 13:50]

[supersnathan94]

Juist een git commit is immutable. Wijzigingen zijn altijd een nieuwe commit hash. Ook als je gaat ammenden en rebasen enzo.

Een git commit is een SHA-1 hash (of 256 als je “—object-format=sha256” gebruikt) die maar 1 keer gebruikt kan worden. Dat staat dus juist het vervangen van een reeds gepubliceerde versie niet toe.

[R4gnax]

Klopt. Ik zeg ook niet dat dat niet zo is. Enkel dat het direct gebruiken van een git commit banaal is. Daar zijn andere redenen voor dan immutability. (Wat een git commit dus inderdaad wel is.)

Als je direct git commits gebruikt ipv een managed package distributiekanaal mis je bijv. security audit alerts die op jouw geinstalleerde versie binnen kunnen komen via dat kanaal. En als je gewezen bent op direct git commits te gebruiken zullen ook build agents etc. toegang tot de desbetreffende git repository moeten hebben, ipv firewalled te kunnen zijn en slechts gelimiteerd en gecontroleerd contact toe te staan met een vooraf vastgesteld domein waar via je package distributie werkt. Als een derde partij dat kanaal beheert, dan worden zij ook een 'first line of defense' - bijv. waar zij al security scanners op nieuwe versies los laten.

Al dat verlies je, als je kiest om direct op een git commit te prikken. Het werkt defense in depth en meer-lagendheid tegen.

[Reactie gewijzigd door R4gnax op 23 maart 2026 00:22]

[supersnathan94]

Ah ja, nee er zitten zeker meer ogen en haken aan dan alleen de mutability dat ben ik helemaal met je eens.

Maar GH actions met de standaard actions zitten ook wel meer beveiligingsgaten in hoor. Ik vind het een leuk systeempje om publieke repo's mee te doen, maar ik vertrouw er helemaal niks van voor private CI/CD. worden heel veel stappen overgeslagen en de meeste zaken zijn als een soort van "trusted" gemarkeerd terwijl dat (zoals hier dus blijkt) echt onterecht is.

[Stukfruit]

Goed punt

[gorgi_19]

Ook dat had in dit geval niet altijd geholpen:

quote: https://github.com/aquase...ories/GHSA-69fq-xp46-6x23

SHA pinning to a commit prior to 2025-04-09.

De reden: deze dockerimage is wellicht dan wel safe, maar hij roept ook een andere docker aan, die niet gepinned was:

trivy-action started pinning setup-go with pull request trivy-action#456. If you pinned trivy-action to a commit prior to that PR (merged 2025-04-09), then you would get a safe trivy-action but it would get a malicious setup-trivy, if invoked during the setup-trivy exposure window.

Dat hebben ze nu wel opgelost, maar ten tijde van de aanval was dit niet het geval.
Nu is dit wel enige tijd geleden, maar het laat zien dat je niet zomaar er op mag vertrouwen dat je dan altijd safe zit.

[lenwar]

https://github.com/aquasecurity/trivy/security/advisories/GHSA-69fq-xp46-6x23 Hier hebben ze wat meer gepubliceerd.

Ik vind het een beetje tegenvallen dat ze niets op hun homepage hebben gezet overigens. Dit soort tools zijn 100% afhankelijk van vertrouwen en transparantie. Het is uiteraard open source, en het is maar een paar uur beschikbaar geweest, maar toch. Het zou netjes zijn als ze het even een weekje op de home pagina hadden gezet of zo.

[Stukfruit]

En hier de bijbehorende discussie (met links naar archive.org voor verwijderde discussies):
https://github.com/aquasecurity/trivy/discussions/10425

Maar daar ben ik het wel mee eens ja. Je hebt niet altijd tijd om issues, discussies en dan ook nog eens advisories en andere zaken na te kijken, terwijl het plaatsen van dit soort belangrijke informatie vaak redelijk afwisselend wordt gedaan in één van die drie. Of zelfs alleen maar op een bedrijfswebsite

Dat kan een stuk duidelijker.

[elmuerte]

Vastzetten op een specifieke versie werkt alleen dat de package repository immutable is. Docker Hub is dat niet. Een git repo (voor Github actions, e.d.) is dat ook niet. In die gevallen zou je het met een hash moeten doen. Nadeel van een hash is dat het weer lastig te relateren is aan een versie, dus die moet je als comment er bij zetten.

Ook als je gaat updaten is het updaten naar een versie die nog niet zo oud is ook niet altijd de beste aanpak. Je kan beter wachten op het moment dat een versie al een tijdje oud is, in de hoop dat er dan genoeg validatie over geweest.

[Stukfruit]

Dat laatste sowieso. Ik wilde er nog bij zetten dat een extra "level of indirection" ook verstandig is omdat er meer ogen naar kijken, maar dat is in principe ook een vorm van security by obscurity.

[R4gnax]

Niets mis met security by obscurity.
"Security by obscurity is no security," wordt nog wel eens dom gezegd door personen die aan de context voorbij gaan. Security by obscurity is enkel geen security als je een doelwit bent dat doelbewust met reden aangevallen wordt. In alle andere gevallen treedt kosten-baten in effect en is het een extra barrière waarmee je een minder aantrekkelijk doelwit wordt t.o.v. een andere partij die makkelijker te grazen te nemen is.

[Stukfruit]

Ik zal de eerste opmerking niet persoonlijk opvatten. Ten tweede: security by obscurity was nog acceptabel aan het begin van deze eeuw.

Tegenwoordig is het "insecure design" én wordt het afgeraden omdat het het veilig houden van een omgeving complexer kan maken. Dat maakt het juist onveilig. Tevens heb je in het heden te maken met steeds betere tools (taalmodellen doen hier ook hun ding) waarmee het steeds moeilijker wordt om het zelfs maar als extra beveiligingslaag te accepteren zoals vroeger.

Maar geloof mij niet, geloof OWASP:

https://devguide.owasp.or...s/03-security-principles/

https://cwe.mitre.org/data/definitions/1441.html

[R4gnax]

Ik zal de eerste opmerking niet persoonlijk opvatten.

Was ook niet op de man bedoeld, maar in algemene zin.
Excuses als het wel zo over kwam.

[supersnathan94]

Security by obscurity is gewoon onderdeel van defense in depth hoor. Bepaalde dingen moet je gewoon niet aan de grote klok hangen.

Zo moet je bijvoorbeeld de standaard nginx en apache foutpagina’s vooral niet het versienummer en type laten sturen wat ze by default wel doen bijvoorbeeld. Dat maakt het vinden van kwetsbaarheden een stuk makkelijker.

Valt ook gewoon onder “least privilege” principe. “The public” hoeft niet te weten dat je Apache of NginX draait, laat staan welke versie.

Defense in depth heeft een shitload aan zaken waarbij “obscurity” gewoon onderdeel is van het geheel.

[Stukfruit]

Defense in depth is, zoals je zelf ook opmerkt, alleen wel iets heel anders dan security by obscurity.

Hetzelfde geldt voor least privilege.

Het ene is "beveiliging" op basis van het "verstoppen" van gegevens. Het andere beperkt de mogelijkheden om bij het doorbreken van de beveiliging meer schade aan te kunnen richten.

Dat je bij het eerste als "laag" (ik zou het niet zo durven zien, maar laten we het even aannemen) versienummers uitzet is prima, maar hoeveel denk je dat dat gaat helpen tegen geautomatiseerde tools? Dat is alsof je "wachtwoord123!" met een "4" erbij gaat gebruiken als wachtwoord Ben je zo doorheen.

[Reactie gewijzigd door Stukfruit op 23 maart 2026 10:03]

[supersnathan94]

maar hoeveel denk je dat dat gaat helpen tegen geautomatiseerde tools?

Ja data is dus precies die targeted attack waar @R4gnax het over heeft. In ALLE lagen van DiD is obscurity een onderdeel van de oplossing.

Dat is alsof je "wachtwoord123!" met een "4" erbij gaat gebruiken als wachtwoord Ben je zo doorheen.

Nou, het zou je verbazen hoe effectief het toevoegen van een karakter daadwerkelijk doet bij zulke aanvallen. Als je puur naar entropie gaat kijken dan niet, maar als je gaat kijken naar frequency dan zorgt die 4 er dus voor dat ie vele malen verderop in de tabel pas een keer geprobeerd wordt en als jij goede rate limiting hebt met een goede exponential back-off policy dan helpt dat dus zeer zeker wel.

Dat is wat R4gnax terecht ook opmerkt, je gaat voorbij aan de context waarin iets gebeurd. Obscurity an sich is geen security, maar obscurity, met daarbij gewoon een normale security opzet helpt wel degelijk om je een ingewikkelder target te maken. Óók tegen geautomatiseerde tooling.

[Stukfruit]

Ah, dus nu moet je goede rate limiting hebben om security by obscurity mogelijk te maken?

Zie je waar ik naartoe ga?

Ik ben een beetje gemeen aan het doen, waarvoor mijn excuus, maar het punt is dat tegenwoordig zoiets aanraden niet echt nuttig is omdat er veel betere oplossingen bestaan. Waaronder degene die je zelf aandraagt.

[Stukfruit]

obscurity is je deterrent. Dat is wat we proberen te zeggen

Dan begrijp je het niet, sorry. Dit is ook het punt waar ik stop met de discussie, want de uitspraken die je hier doet komen niet erg volwassen over.

[supersnathan94]

Nee sorry, jij begrijpt het niet. Het halve internet hangt aan elkaar van obscurity als extra laag op beveiliging. Het hele idee van een wachtwoord is obscurity.

quote: https://www.copado.com/re...-it-s-nowhere-near-enough

Defense in Depth is the only scenario where obscurity can be used for effective security. Simply obfuscating your systems and applications isn’t enough to keep bad actors at bay. Protecting your hidden resources with several layers of security policies and mechanisms can create a comprehensive security strategy to defend your business from cyber threats.

De meeste dingen moet je gewoon niet aan de grote klok hangen. Dat maakt het vinden van kwetsbaarheden alleen maar makkelijker. Daarom wil je ook niet in Shodan terechtkomen met je infra. Als je daar eenmaal in staat dan ben je gewoon by default de lul.

Obscurity houdt attackers weg omdat het meer moeite kost om de "ui te pellen" als je niet weet waar en welke lagen er op welke manier zijn geïmplementeerd.

Security by obscurity only is een probleem. Obscurity in combinatie met andere zaken is noodzakelijk.

[Stukfruit]

Volgens mij werd uit mijn reacties redelijk duidelijk dat de aangedragen voorbeelden op zichzelf weinig met obscurity te maken hebben.

Het verschil tussen jou en mij is dat ik zeg dat je zou moeten optimaliseren voor de slechtst mogelijke situatie, terwijl jij blijkbaar je tijd deels besteedt aan verstoppen met een spaghetti aan oplossingen die met de dag minder goed werken.

Een wachtwoord als voorbeeld dat obscurity werkt? Een marketingblog? "Het internet" met al zijn prutswerk gebruiken als bewijs? Kom op, ben je hier serieus?

[supersnathan94]

dat ik zeg dat je zou moeten optimaliseren voor de slechtst mogelijke situatie

Dat is echt voor het eerst dat je dit zegt.

terwijl jij je tijd deels besteedt aan verstoppen met een spaghetti aan oplossingen die met de dag minder goed werken.

Ik weet niet waar jij vandaan haalt dat het een "spaghetti" aan oplossingen is die met de dag minder goed werken? Het is onderdeel van Defense in depth dat je gewoon dingen niet aan de grote klok hangt. Dat is obscurity.

Notabene je eigen bronnen spreken je hier op tegen:

quote: https://cwe.mitre.org/data/definitions/656.html

Note that obscurity can be one small part of defense in depth, since it can create more work for an attacker;

Het is gewoon onderdeel van DiD, dat is wat @R4gnax zei en waar je de hele discussie over ging.

Obscurity is geen security control, maar wel een nuttige laag binnen attack surface reduction en defense in depth.

In alle andere gevallen treedt kosten-baten in effect en is het een extra barrière waarmee je een minder aantrekkelijk doelwit wordt t.o.v. een andere partij die makkelijker te grazen te nemen is.

Dit is algemeen aanvaard in de securitywereld als waar.

Volgens mij loop je nu vast op het "security by obscurity" als losstaande beveiliging, maar dat is het niet.

Obscurity is een kostenverhogende frictielaag binnen defense in depth. Onderdeel van een context.

[Stukfruit]

Volgens mij loop je nu vast op het "security by obscurity" als losstaande beveiliging, maar dat is het niet

Voor iemand die het over context blijft hebben krijg je er weinig van mee. Kijk even naar de reactie waarmee dit verhaal begon.

Obscurity is geen security control

Aha, het verhaal wordt nogmaals aangepast.

[supersnathan94]

Voor iemand die het over context blijft hebben krijg je er weinig van mee. Kijk even naar de reactie waarmee dit verhaal begon.

Ja dus ik snap niet zo goed waarom je er zo hard tegenin aan het gaan bent dat je eigen suggestie prima is.

Aha, het verhaal wordt nogmaals aangepast.

Nee helemaal niet. Dat is vanaf het eerste moment wat er gezegd werd door @R4gnax. Leer ff lezen aub.

[CAPSLOCK2000]

Security by obscurity is gewoon onderdeel van defense in depth hoor. Bepaalde dingen moet je gewoon niet aan de grote klok hangen.

Ik haak hier even aan want volgens mij hebben jullie last van een spraakverwarring.
Je hebt gelijk dat obscurity deel is van security, maar het is onhandig om dat "security by obscurityy" te noemen. De woorden "security by obscurity" hebben namelijk een heel specifieke context, namelijk het Wikipedia: Principe van Kerckhoffs . In de wereld van cryptografie betekent dit dat de veiligheid van encryptie niet mag afhangen van het geheim houden van het algoritme. Het wachtwoord moet je wel geheim houden maar het algoritme zelf niet. Alle grote encryptie-algoritmes zijn publiek beschikbaar zodat ze onderzocht en getest kunnen worden.
"Security by obscurity" betekent in de security-wereld dat je wiskundig onveilige algoritmes gebruikt of fouten niet oplost in de hoop dat niemand ze vindt. Dat is op termijn uiteraard geen goed idee. Het betekent niet dat je geen geheimen moet hebben of zo iets, daar gaat het niet over. Het zoveel mogelijk afschermen van alle informatie waar een aanvaller iets aan zou kunnen hebben is gewoon een goed idee. Je moet dat alleen geen "security by obscurity" noemen want dan denken mensen aan iets anders.

[Reactie gewijzigd door CAPSLOCK2000 op 24 maart 2026 16:30]

[supersnathan94]

Mja dat ben ik wel met je eens. Het ding is alleen dat Stukfruit hier zelf wel binnen die andere context start door een "extra level of indirection" als een vorm van "security by obscurity" te noemen. Dan is het heel terecht dat R4gnax in 'Aanvallers verstoppen infostealer in kwetsbaarhedenscanner Trivy' dat dan duid naar een verhaal wat hij nogmaals onderstreept in R4gnax in 'Aanvallers verstoppen infostealer in kwetsbaarhedenscanner Trivy'. Volgens mij is dat het verhaal, niks meer niks minder.

Binnen DiD raad iedereen aan om gewoon zoveel mogelijk nuttige informatie af te schermen cq "te obscuren". Zijn eigen bronnen onderstrepen dat ook.

[R4gnax]

Het is 'kant noch wal' - en dat mag je even uitleggen.
Stukfruit relativeert het eigen argument dat extra indirectie toevoegen enkel een vorm 'security by obscurity' is. Daarbij plaats ik de kanttekening dat 'enkel' security by obscurity helemaal niet afbreuk doet aan het toevoegen van die indirectie, aangezien het in algemene zin drempels opwerpt in de zin van extra te spenderen moeite, extra risico, etc. om ergens in te breken - en dat de leus "security by obscurity is no security," gezien moet worden in de context van het direct een vooraf vastgesteld doelwit zijn. Waarbij men sowieso al bereidt is die moeite te spenderen en dat risico te nemen, ipv naar een ander potentieel doelwit uit te wijken.

[Reactie gewijzigd door R4gnax op 22 maart 2026 17:07]

[Ed Vertijsment]

“Woordensalade”, leuk woord. Echter denk ik dat @R4gnax wel degelijk een punt heeft. Security is een een ui met laagjes, iedere laag voegt iets toe. In zekere is een wachtwoord trouwens ook security trough obscurity.

[supersnathan94]

Iemand met een kwart miljoen karma punten?

Misschien even kijken naar de context. @R4gnax heeft gewoon gelijk hoor.

[Sebastian1313]

Mooi punt. Maar zelfs met een kwart miljoen punten blijft het dus moeilijk om iets duidelijk op papier te zetten. Maar dat is helemaal niet erg hoor. Iedereen heeft zijn kwaliteiten

[supersnathan94]

Mwah. Het staat er vrij duidelijk hoor. T mist misschien wat context,

maar om dat Ai of Bot te roepen. Beetje raar

[Sebastian1313]

Ja zal het de volgende keer anders proberen te formuleren.

[ZinloosGeweldig]

In een professioneel ecosysteem heb je natuurlijk een eigen repository (bijv. Harbor of JFrog Artifactory) er tussen staan waar je tags immutable gemaakt hebt.

[djwice]

Je kunt ook automatisch de delta met de vorige release checken als additionele validatie. Dingen die expliciet verdwijnen of bestaande code die door totaal andere functies vervangen worden.

Dit doe ik sinds 10 jaar op alle OWASP tools, configuraties en check sets.

Tegenwoordig kan een taalmodel buiten standaard statische diff checks, helpen interpreteren wat de verschillen zijn.

[Lagonas]

Wel jammer dat Trivy deze kwetsbaarheid niet direct heeft kunnen vinden / stoppen

Iets serieuzer; Het valt me op dat de laatste tijd meerdere security pakketten aangevallen worden en geïnfecteerd. Volgens mij is het al het tweede artikel deze week op Tweakers. Dat is toch wel een zorgwekkende trend.

Ik werk in een enterprise omgeving en we investeren jaarlijks miljoenen in onze security tools en vertrouwen er op dat ze hun werk op een goede manier doen, en dan is de ontwikkelaar zelf getroffen..

[kodak]

Ik werk in een enterprise omgeving en we investeren jaarlijks miljoenen in onze security tools en vertrouwen er op dat ze hun werk op een goede manier doen, en dan is de ontwikkelaar zelf getroffen..

Geld uitgeven alsof je daarmee maar vertrouwen kan hebben is eerder het afschuiven van verantwoordelijkheid dan werkelijk onacceptabele risico's willen verminderen. Het is nooit verstandig geweest om andermans diensten of software te vertrouwen omdat je een betaling doet of een overeenkomst hebt. Omdat je in de praktijk, niet slechts in theorie, zelf verantwoordelijk bent naar je klanten, leveranciers en eigen bedrijf. En de praktijk is dat een betaling en overeenkomst geen wangedrag, nalatigheid en fouten voorkomen. En dat is precies waarom je niet zomaar nieuwe versies van software maar moet vertrouwen als even goed of beter dan de gestelde eisen.

We lezen hier nergens dat blijkt dat de ontwikkelaars hun beveiliging werkelijk op orde hadden. Eerder dat er een behoorlijk gebrek aan transparantie is over wat ze allemaal nalaten om werkelijk betrouwbaar te ontwikkelen en software te leveren. Zelfs het erkennen van dit enorme probleem lijkt ze niet belangrijk om duidelijk te vermelden. En dat is ook wat je kan verwachten als je zelf nalatig bent dit soort ontwikkelaars behoorlijk te controleren.

[Lagonas]

Ik zeg nergens dat we geld uitgeven om niks meer te hoeven doen, of alle verantwoordelijkheid bij de tools kunnen leggen. Absoluut niet. We kopen software / hardware om onze specialisten tools te geven om hun werk goed uit te kunnen voeren, en je hoopt dat je daar wat vertrouwen mag neerleggen dat deze dan ook goed werken zoals vooraf is vastgesteld. Daar zijn dan ook erg lange POC trajecten aan vooraf gegaan, zodat we zelf kunnen ondervinden dat deze tools goed werken voor onze doelstellingen.

[kodak]

Je stelt niet waar jullie grens van vertrouwen dan werkelijk ligt. Want het feit dat er vooraf poc-trajecten zijn in de hoop risico's weg te nemen voorkomt niet dat er nadien bij dit soort ontwikkelaars wangedrag, nalatigheid en fouten gebeuren. Het geeft zelfs niet zomaar inzicht of men wel behoorlijk incident kan en wil voorkomen. En dat is waar dit nieuws en probleem om gaat. Men blijkt en blijft niet spontaan maar betrouwbaar en behoorlijk om hun software en diensten te gebruiken.

[downtime]

En wat is de oplossing volgens jou? Want het ligt voor de hand dat security tools een aanvalsvector zijn. Maar hoe mitigeer je dat risico? Je zit in een spagaat. Je wilt nieuwe versies van zulke tools zo snel mogelijk deployen om te voorkomen dat je de zoveelste wordt die gehackt worden omdat ie verouderde software draaide. Maar grondig testen kost tijd en zal eventuele problemen in een nieuwe versie ook niet altijd aan het licht brengen.

[Ryunoru]

Dat is geen nieuws onder de horizon. Veiligheidssoftware is al decennia een van de meest getroffen vector van aanvallers.

[dasiro]

het gevaarlijke aan open-source tools zoals dit is dat mensen/bedrijven forks ervan maken voor eigen gebruik. Als ze op dat moment er een gemaakt hadden, dan zat de infostealer daar dus ook in en kunnen van daar uit ook credentials gestolen worden.

Door iets publiekelijk beschikbaar te maken (net zoals bij freeware) heb je geen relatie met je onbekende gebruikers die je niet rechtstreeks kan verwittigen, simpelweg omdat je niet weet wie het ooit allemaal heeft gedownload.

De vraag is hoe het dan zit met liability voor de getroffenen, want dat zijn nu net mensen/bedrijven die zulke tools binnen hun omgeving opzettelijk los laten, waar andere malware vanuit onvertrouwde sources niet bij zou kunnen.

[Chromoris]

Hmmm, ik gebruikte trivy binnen Dockhand voor hey analyseren van nieuwe docker images. Vraag me af hoeveel risico ik nu loop.

[MSalters]

Inmiddels geëscaleerd. LiteLLM gebruikte Trivy en daardoor zijn er twee malafide releases geweest. LiteLLM werd veel gebruikt door andere libraries zoals DSPy dus de consequenties zijn behoorlijk.