Hoe groot is het risico met oude software

[bassiej19]

Goedemiddag,

Als eerste bedankt voor het openen van dit topic. Dit topic is bedoeld als werkelijke vraag maar ook als discussieonderdeel en ondersteuning van mijn mening.

Situatie is als volgt:
- Partij A: Eigenaar van platform
- Partij B: (wij) hosting club
- Partij C: Software leverancier

Wij leveren een infrastructuur voor een mediaplatform welke bedoeld is voor een enorm grote groep mensen voor het bekijken van content. Nu leveren wij volledig managed diensten en willen servers volledig up2date houden.

Nu is het zo dat de software partij de software zoals PHP-FPM, NGINX, APACHE, etc onderhoudt doormiddel van docker containers voor het hosten van de applicatie.

Nu is het probleem dat de applicatie nog gebruikt maakt van een oudere versie van PHP 7.2 en ook verouderde webservers van Nginx en Apache gebruikt.

Nu hebben wij partij A vermeld dat dit een risico is omdat deze versies niet meer ge-update worden en er hierdoor een risico is dat dependencies niet geupdate worden en de server een gemakkelijke prooi van hackers wordt met het risico van honderd-duizenden mensen data te lekken. Ook zijn wij verantwoordelijk voor de stabiliteit van de infrastructuur, waarbij wij hebben aangegeven ons hier niet prettig bij te voelen gezien de situatie.

Partij C is van mening dat ze geen PHP functies gebruiken die in de overzicht met lekken staan, er een WAF (op verouderde nginx) voorhangt en dat er dus nagenoeg geen risico is, en ze pas een keer gaan updaten zodra het volgens hun wel een risico is. (PHP versie is het belangrijkste en oudste in het geheel).
Daarnaast melden ze dat het updaten erg moeilijk is omdat ze achteraf moeten kijken wat er allemaal kapot gaat, en dat dat moeilijk te vinden is.

Partij C definieert zich als een professionele software partij welke zijn zaken op orde heeft.


Nu wil ik een paar punten benoemen en ik hoop dat jullie mij kunnen aangeven of ik overdrijf en me aanstel, of dat wij hier wel degelijk in ons gelijk staan:

- Oude versies (welke niet meer ondersteund worden) draaien is not done. Risico op niet geautoriseerd misbruik is groot
- Als er gegevens op straat komen dan ben je de sjaak omdat er bewust niet ge-update is naar ondersteunde versies. Partij A, zal hier de klappen van ontvangen
- Daarnaast ben ik van mening dat een software partij welke een professionele applicatie bouwt en deze tegen hoge licenties aanbiedt en geen unit / functionele tests heeft om de applicatie na een PHP update te testen zijn zaakjes niet op orde heeft.


Als los onderdeel van deze vraag, gezien ik nu om een publieke opinie vraag is:
Partij A beschikt nu over 1 infrastructuur (ik noem het infrastructuur omdat meerdere servers, CDN, etc) waarop zowel accept/productie draait op dezelfde machines en zelfs dezelfde codebase.

Volgens partij C is dit prima omdat er getest wordt binnen de club welke het ontwikkeld en het daarna gewoon ge-update kan worden.

Ik ben hier ook van mening dat je een acceptatie omgeving moet hebben welke identiek is aan productie (misschien wat minder resources), zodat je updates echt bij de klant (partij A) kan doortesten. Omdat servers bij partij C nooit identiek zijn aan servers van hun klanten. Ook omdat partij A van bepaalde module combinaties gebruik maakt.


Dus bij deze de vraag; Stellen wij ons aan, of heeft partij C de zaakjes echt niet op orde? Partij A heeft beperkte kennis en het wordt een welles/nietes verhaal.

[M2M]

Nodig 3 mensen uit in een fysieke vergadering. Geef bij partij C aan dat het een onaanvaardbaar risico is. Geef bij partij A aan dat de puinhoop op hun bord komt te liggen. Geef zelf aan om onder serviceverlening een testsituatie / acceptatieomgeving te creeren. Als je het goed doet, kun je 10% van A's klanten op de nieuwe omgeving zetten en 90% op de oude.

Als het goed gaat zet je het percentage langzaam hoger tot je helemaal over bent op de nieuwe omgeving en ontmantel je de oude.

Echter is dit probleem niet eenmalig. Elke keer zal een oude versie achtergelaten worden, en zit je met exact hetzelfde probleem. Het probleem nu op deze manier fixen zorgt er automatisch voor dat je over een jaartje of twee met eenzelfde probleem zit. De wereld van IT gaat nu eenmaal veel te snel.

Een vereiste acceptatie en test-omgeving is derhalve noodzaak voor A. Voor A is het risico, derhalve dient A te zorgen voor een veilige omgeving om softwareupdates te testen voordat er live gegaan wordt.

[Johnny]

bassiej19 schreef op donderdag 1 april 2021 @ 11:46:
Partij C is van mening dat ze geen PHP functies gebruiken die in de overzicht met lekken staan, er een WAF (op verouderde nginx) voorhangt en dat er dus nagenoeg geen risico is, en ze pas een keer gaan updaten zodra het volgens hun wel een risico is. (PHP versie is het belangrijkste en oudste in het geheel).
Daarnaast melden ze dat het updaten erg moeilijk is omdat ze achteraf moeten kijken wat er allemaal kapot gaat, en dat dat moeilijk te vinden is.

Hier zitten wat tegenstrijdigheden in. Er zal ooit moeten worden overgestapt naar een nieuwe versie. Hoe meer versies je achterloopt hoe moeilijker het wordt. Als men wacht tot er een concreet risico is dan moet het zo snel mogelijk gebeuren, maar omdat het moeilijk is zal dat veel tijd kosten, dus kun je er maar beter eerder mee beginnen.

Tenzij ze bezig zijn met een nieuwe versie van de software en geen onderhoud meer willen doen aan de oude en hopen dat ze kunnen overschakelen voordat de oude versie een exploit heeft is het geen logisch verhaal.

Het minste wat je zou mogen verwachten is een planning voor de upgrades, en anders moet jij een plan gaan maken om weg te gaan bij deze leverancier want als de software niet meer wordt bijgewerkt dan is dat uiteindelijk een groot probleem.

[bwerg]

Het enige relevante lijkt mij: als er iets misgaat, ligt het probleem dan bij jullie of bij A en/of C? Als het bij jullie ligt (inbreker die via crappy software bij jullie schade aan gaat richten) dan kun je zelf eisen stellen, maar daarvoor zou het wel leuk zijn als daarvoor contractuele afspraken zijn. Maar als jullie e.e.a. dichtgetimmerd hebben, goed monitoren en bij misbruik de boel van C gewoon kunnen afsluiten, dan ligt het probleem volledig tussen A en C. Melden, heel duidelijk maken wat de risico's en de mogelijke gevolgen zijn, en dan is het aan A om C zover te krijgen dat ze er iets aan doen, of om de gevolgen te accepteren.

[Oon]

Ik denk dat je risico-inventarisatie enigszins overdreven is; PHP 7.2 is niet bepaald lek, en ook Apache en Nginx zelf vallen wel mee mits de versie niet ouder dan een jaar of twee is.

Het belangrijke is de onderliggende libraries; zolang een recente versie van de SSL library e.d. gebruikt wordt is het risico al beperkt. Ook moet de onderliggende infrastructuur (docker en alles op de host) up to date zijn, maar als de containers goed ingericht zijn volgens de principes van docker (single service met alleen de libraries en andere tools die écht nodig zijn om die ene service te draaien) zit daar niet superveel risico in.

Ik zou wel zwart op wit willen dat de inhoud en inrichting van die containers niet jullie verantwoordelijkheid is, zodat je altijd nog kan wijzen op verouderde software buiten jullie controle. Daarmee dekken jullie je aansprakelijkheid af.

Ik zou ook de eindklant op de hoogte stellen van de situatie. Je kan ze gewoon een mailtje sturen met een overzicht van softwareversies, wanneer die versie uitkwam, meest recente versie + datum, en wanneer de huidige versie EOL was. Daarbij stuur je dan het verzoek aan de eindklant om deze te (laten) updaten. De eindklant zal daarmee naar de softwareleverancier gaan, en hoe het verder afgehandeld wordt is tussen die twee.

[downtime]

bassiej19 schreef op donderdag 1 april 2021 @ 11:46:
Als eerste bedankt voor het openen van dit topic. Dit topic is bedoeld als werkelijke vraag maar ook als discussieonderdeel en ondersteuning van mijn mening.

Lastig en veelomvattend onderwerp om iets over te zeggen met veel "it depends", het hangt ervan af hoe het in detail is geregeld op het niveau van afspraken/contracten en op technisch niveau. Om te beginnen constateer ik dat je op achterstand begint omdat het een bestaand platform is en het lastig is om afspraken te veranderen zolang het goed blijft gaan. Vooral als die nieuwe afspraken geld kosten.

Voor mijn eigen gemak zal ik niet over A, B of C spreken maar gewoon over Opdrachtgever, Hosting en Developer. Anders zit ik continu heen en weer te scrollen om te kijken wie er met A, B of C wordt bedoeld.

Wat betreft de aparte Test- en Acceptatieomgeving is het moeilijk om iets te zeggen. Normaal gesproken wil je die zeker hebben maar dat hoeft niet persé in de vorm van een gescheiden Hosting infrastructuur.
Maar als er echt helemaal geen manier is om een vorm van Acceptatie testen te doen in een Productie-like omgeving dan zou de Opdrachtgever dat een probleem moeten vinden, niet de Hosting.
Hetzelfde geldt voor de Test omgeving. Als de Developer meent dat hun eigen omgeving voldoende representatief is om technisch te testen dan is dat hun verantwoordelijkheid, niet van de Hosting.

Nu wil ik een paar punten benoemen en ik hoop dat jullie mij kunnen aangeven of ik overdrijf en me aanstel, of dat wij hier wel degelijk in ons gelijk staan:

• Oude versies (welke niet meer ondersteund worden) draaien is not done. Risico op niet geautoriseerd misbruik is groot

Oude versies draaien is inderdaad not done. De Developer kiest er blijkbaar voor om niet te upgraden tenzij... En dan kunnen ze misschien niet meer (snel) upgraden omdat er dan teveel andere dingen ook moeten veranderen.

Mijn vuistregels zijn simpel:

• Unsupported software hoort helemaal niet gebruikt te worden.
• Niet-kritieke issues in libraries/tools fix je bij de volgende reguliere release. Dit is gewoon technical debt die niet genegeerd moet worden.
• Kritieke issues fix je meteen in een extra release. Worst case scenario is dat op de dag van release van een fix.

• Als er gegevens op straat komen dan ben je de sjaak omdat er bewust niet ge-update is naar ondersteunde versies. Partij A, zal hier de klappen van ontvangen

Zeker. Maar ik mag hopen dat de Opdrachtgever dat snapt. Ik zie te vaak bedrijven naar een onderaannemer (bv hun Developer) wijzen als het fout gaat. Misschien werkt dat voor veel mensen maar ik vind het niet interessant om te weten of Bedrijf X mijn gegevens zelf heeft gelekt of dat ze iemand hebben aangenomen om die gegevens te lekken. Ik kijk Bedrijf X er toch op aan.

• Daarnaast ben ik van mening dat een software partij welke een professionele applicatie bouwt en deze tegen hoge licenties aanbiedt en geen unit / functionele tests heeft om de applicatie na een PHP update te testen zijn zaakjes niet op orde heeft.

Dus bij deze de vraag; Stellen wij ons aan, of heeft partij C de zaakjes echt niet op orde? Partij A heeft beperkte kennis en het wordt een welles/nietes verhaal.

Dat is vast waar maar het is niet jouw probleem. Focus je op de gewenste uitkomst en niet op de vraag of de Developer zijn geld waard is. Dat leidt alleen maar tot moddergooien.

[Rukapul]

Oon schreef op donderdag 1 april 2021 @ 12:08:
Ik denk dat je risico-inventarisatie enigszins overdreven is; PHP 7.2 is niet bepaald lek,

Wie gaat dat voor je bijhouden?

Het punt van unsupported software is namelijk dat degene aan de top van de piramide (de leverancier) het niet meer doet.

Het is geen vraag of maar wanneer het mis gaat. Een aanvaller heeft het ook nog eens makkelijk, want die kan simpelweg de nieuwere versies monitoren op security fixes.

Bij elk groot project zie je dat deze methods actief gebruikt worden met Windows als grootste voorbeeld voorop.

Als software of diensten leverancier moet je gewoon je software lifecycle management op orde hebben.

[Oon]

Rukapul schreef op vrijdag 2 april 2021 @ 17:33:
[...]

Wie gaat dat voor je bijhouden?

Het punt van unsupported software is namelijk dat degene aan de top van de piramide (de leverancier) het niet meer doet.

Het is geen vraag of maar wanneer het mis gaat. Een aanvaller heeft het ook nog eens makkelijk, want die kan simpelweg de nieuwere versies monitoren op security fixes.

Bij elk groot project zie je dat deze methods actief gebruikt worden met Windows als grootste voorbeeld voorop.

Als software of diensten leverancier moet je gewoon je software lifecycle management op orde hebben.

Nouja, PHP gebruikt grotendeels systeemlibraries, en PHP zelf doet weinig (tenzij je FPM van buitenaf bereikbaar hebt, wat me niet lijkt in een docker setup). De software die geschreven is in PHP moet gewoon netjes geschreven zijn, en de libraries onder PHP up to date.

Hoe dan ook ben ik het er compleet mee eens dat het een risico is en dat het geüpdatet moet wroden. Het is een risico dat blijft groeien naarmate PHP 7.2 langer EOL is, maar als het de nieuwste 7.2 is en alle inputs en outputs netjes gecontroleerd worden dan is het risico puur op dat stuk en op dit moment relatief klein.

Uiteindelijk is de vraag over wie verantwoordelijk is als/wanneer het fout gaat belangrijker, en TS moet gewoon de eindklant duidelijk maken dat zij (de eindklant) dat zijn, en dat het daarmee hun verantwoordelijkheid is om de softwareleverancier een update uit te laten voeren.

[vso]

Ooit een boek gepakt over hacking oid ? (iets wat je bv niet moet vergeten is dat een goeie hacker zijn "bom" plant en gewoon maanden op zijn handen zit .. (dan zit het in alle backups)

supported/unsupported software maakt weinig uit .. het is de "oppervlakte" waar je schade aan toe kan doen.. als ik remote een omgeving binnen kan dringen, de backup kan wissen en data gijzelen/copieren oid dan hang je aan alle kanten..

om je "attack surface" te verminderen en dus waarom compartimentaliseerd en je software up to date houd.
Als hoster voorkom je dus dat men naar andere klanten/machines kan springen .. (onderlinge firewalls etc.) maar als men deze "bewust" open zet houd jou verantwoording op.. dan kan je alleen assisteren met de gevolgschade (downtime) te minimaliseren .. door backups/snapshots terug te zetten.

Als leverancier/klant ben je zelf verantwoordelijk om je software up to date te houden ..

over vergaderen met "klant"
Als mijn hosting partij zich "druk" maakt over mijn update policy omdat ik wel vertrouwen heb in hun backup/firewalling /ddos bescherming .. dan zou ik me op mijn beurt zorgen maken over de eerder genoemde beveiliging !!! uitgaande dat ze nog meer klanten (behalve mijzelf) bedienen.

een mailtje krijgen
heel erg dubbel maar dat gezegd hebbende vind ik het wel fijn als mijn hoster mij attendeert dat ik een enorm risico loop omdat ze merken dat ik 3 versies achterloop ..of dat ze tijdens reguliere scans die wekelijks oid "automagisch" een mailtje sturen met de resultaten die voor mij relevant zijn..

de leverancier
tja als mijn klant alleen betaalt voor het werk wat alleen door een opdracht vanuit hun gebeurt zou ik niet veel moeite steken in "updaten", wil niet zeggen dat ik helemaal niet attendeer maar zolang de klant niet een "het mailtje" van de hoster doorstuurt zoals ik hierboven beschrijf .. kost het me meer tijd/geld en het levert niks op immers de klant betaald er niet voor ..

[naitsoezn]

bwerg schreef op donderdag 1 april 2021 @ 12:02:
Het enige relevante lijkt mij: als er iets misgaat, ligt het probleem dan bij jullie of bij A en/of C? Als het bij jullie ligt (inbreker die via crappy software bij jullie schade aan gaat richten) dan kun je zelf eisen stellen, maar daarvoor zou het wel leuk zijn als daarvoor contractuele afspraken zijn. Maar als jullie e.e.a. dichtgetimmerd hebben, goed monitoren en bij misbruik de boel van C gewoon kunnen afsluiten, dan ligt het probleem volledig tussen A en C. Melden, heel duidelijk maken wat de risico's en de mogelijke gevolgen zijn, en dan is het aan A om C zover te krijgen dat ze er iets aan doen, of om de gevolgen te accepteren.

Volgens mij is dit het enige juiste antwoord.

Aan het updaten van de software hangt een kostenplaatje, ik neem niet aan dat partij B de kosten van partij A gaat vergoeden om die software te updaten?

Partij B levert een dienst, de hosting. Als het niet jullie verantwoording is, moet je niet op de stoel van de softwareboer gaan zitten. Als het wel jullie verantwoording is, dan hoef je de discussie met de softwareboer niet te winnen maar doe je gewoon wat juist is.

[bassiej19]

Bedankt voor jullie reacties! Ik ga er later verder op in.

Wel wil ik aanvullen dat de reden dat wij ons er zorgen om maken wij de 24/7 support leveren en wij ook helpen met communicatie tussen development club en opdrachtgever. Wij adviseren hier in, en wij zijn erbij gehaald toen de opdrachtgever zich zorgen maakte over de software. Enkel werd het zo dat de development partij aangeeft dat deze adviezen op security niet kloppen en er geen risico’s zijn.

En dan kom je in een welles/nietes verhaal.

[eric.1]

bassiej19 schreef op vrijdag 2 april 2021 @ 20:27:

Wel wil ik aanvullen dat de reden dat wij ons er zorgen om maken wij de 24/7 support leveren en wij ook helpen met communicatie tussen development club en opdrachtgever.

Wat heb je afgesproken over die 24/7 support? Ik neem aan dat dit zwart op wit staat. Als partij C de containers levert, dan valt daar weinig support over te verlenen als partij B zijnde (buiten wat basale acties). Wanneer het mis gaat is het een kwestie van mitigeren, de server isoleren en wachten op een bijgewerkte docker container van partij C - lijkt me?

Dit lijkt me geen risico wat partij A wilt lopen, downtime van een onbepaalde tijd. Partij A moet gewoon harde eisen stellen lijkt me.

[DJMaze]

In de php 7.2 core zitten geheugenproblemen die in specifieke situaties flink uit te buiten zijn.
Het is dan mogelijk dat loginnamen/wachtwoorden vrolijk in de logs of op je browser zichtbaar zijn.

Deze bugs zitten ook in een aantal 7.3 en 7.4 versies en zijn wel opgelost.

Als softwarebedrijf niet kan updaten dan is de code blijkbaar te oud/beroerd geschreven.
Anders was het binnen een dag wel redelijk goed in kaart te brengen.

Ondanks dat het oud is, hoeft er natuurlijk niks mis mee te zijn. Banken en vezekeringsmaatschappijen gebruiken immers ook nog COBOL.

De enige juiste optie is een extern rapport van een php goeroe die in kaart kan brengen hoe degelijk het product is.

[burnedhardware]

Het gaat staan of vallen met afspraken rond aansprakelijkheid.

Die software gaat een keer gehacked worden waarna

1. de gegevens van de users uit de database op straat komen te liggen (GDPR?)
2. de auteursrechtelijk beschermde werken (content) onrechtmatig zijn herpubliceerd
3. andere klanten omdat hun docker containers ook gecompromitteerd werden

Wie gaat betalen? In het geval van GDPR kan je gedeeltelijk aansprakelijk worden

[ Voor 9% gewijzigd door burnedhardware op 02-04-2021 22:18 ]

[thlst]

Beveiligings updates worden gebackport

Bijv Ubuntu 18 LTS heeft PHP 7.2 en nog jaren support.

[418O2]

bassiej19 schreef op vrijdag 2 april 2021 @ 20:27:
Bedankt voor jullie reacties! Ik ga er later verder op in.

Wel wil ik aanvullen dat de reden dat wij ons er zorgen om maken wij de 24/7 support leveren en wij ook helpen met communicatie tussen development club en opdrachtgever. Wij adviseren hier in, en wij zijn erbij gehaald toen de opdrachtgever zich zorgen maakte over de software. Enkel werd het zo dat de development partij aangeeft dat deze adviezen op security niet kloppen en er geen risico’s zijn.

En dan kom je in een welles/nietes verhaal.

Dit moet je hoe dan ook niet doen. Je support is die bak in de lucht houden. Dit is zo'n klus die tot in het eind der tijden hoofdpijn en welles nietes gaat worden.

Als developer zou ik ook niet blij zijn als een hoster inhoudelijk dingen zou gaan roepen. En met alle respect, helemaal niet als die het doet met 'van horen zeggen'-kennis van Tweakers

Jullie moeten zorgen voor de hosting en dat er niet via die server in het netwerk kan worden gehackt

[ Voor 15% gewijzigd door 418O2 op 03-04-2021 00:03 ]

[downtime]

DJMaze schreef op vrijdag 2 april 2021 @ 22:01:
Ondanks dat het oud is, hoeft er natuurlijk niks mis mee te zijn. Banken en vezekeringsmaatschappijen gebruiken immers ook nog COBOL.

Volgens mij zijn er nog steeds meerdere leveranciers die COBOL compilers verkopen en supporten. Fujitsu verkoopt bijvoorbeeld NetCOBOL, een versie van COBOL die op .NET draait, en blijkbaar is er ook een versie van NetCOBOL die in Azure draait.

[Voutloos]

418O2 schreef op vrijdag 2 april 2021 @ 23:59:
[...]

Dit moet je hoe dan ook niet doen.

...

Jullie moeten zorgen voor de hosting en dat er niet via die server in het netwerk kan worden gehackt

Check. Schoenmaker blijf bij je leest. Je hebt dit topic nodig voor 2 redenen: Zowel de inhoud als mening peilen of je je druk moet maken. Allebei prima redenen om je er niet in te mengen.

[Hydra]

418O2 schreef op vrijdag 2 april 2021 @ 23:59:
Als developer zou ik ook niet blij zijn als een hoster inhoudelijk dingen zou gaan roepen.

Dat vind ik wel wat kort door de bocht. Ik zou als developer heel blij zijn als een hoster ons op security holes wijst die wij zelf niet gezien hebben. Ik vind je daarover op je pik getrapt voelen eigenlijk nogal onprofessioneel.

Die software club klinkt als een vrij typische low-cost web development club die eigenlijk altijd het absolute minimum wil doen. En als het dan eenmaal te laat is, begint het vinger wijzen. Dan krijg je dus een situatie dat een DB weg is, en dan wijst dat software bedrijf natuurlijk eerst naar het hosting bedrijf.

Volkomen terecht dat je dit soort situaties voor wil zijn.

[thlst]

Hydra schreef op zaterdag 3 april 2021 @ 08:40:
Dat vind ik wel wat kort door de bocht. Ik zou als developer heel blij zijn als een hoster ons op security holes wijst die wij zelf niet gezien hebben. Ik vind je daarover op je pik getrapt voelen eigenlijk nogal onprofessioneel.

Eens, maar in veel gevallen heeft een hoster daar maar beperkt zicht op . Simpelweg zeggen : oude versie, dus onveilig is ook te kort door de bocht

[418O2]

Hydra schreef op zaterdag 3 april 2021 @ 08:40:
[...]


Dat vind ik wel wat kort door de bocht. Ik zou als developer heel blij zijn als een hoster ons op security holes wijst die wij zelf niet gezien hebben. Ik vind je daarover op je pik getrapt voelen eigenlijk nogal onprofessioneel.

Die software club klinkt als een vrij typische low-cost web development club die eigenlijk altijd het absolute minimum wil doen. En als het dan eenmaal te laat is, begint het vinger wijzen. Dan krijg je dus een situatie dat een DB weg is, en dan wijst dat software bedrijf natuurlijk eerst naar het hosting bedrijf.

Volkomen terecht dat je dit soort situaties voor wil zijn.

Het is een stretch van 'wijzen op risico's' naar op Tweakers vragen maar in inhoudelijk commentaar op de gebruikte stack en daarnaast ook nog tussen de communicatie te gaan zitten.

En de vragen die hier gesteld worden doen mij denken dat er het hele proces niet echt professioneel is

[ Voor 5% gewijzigd door 418O2 op 03-04-2021 10:39 ]

[RagingPenguin]

thlst schreef op zaterdag 3 april 2021 @ 10:12:
[...]


Eens, maar in veel gevallen heeft een hoster daar maar beperkt zicht op . Simpelweg zeggen : oude versie, dus onveilig is ook te kort door de bocht

Eens, maar dan zou je alsnog de development partij op de verouderde versies kunnen wijzen. 'Verouderde versies zijn onveilig' zou de default moeten zijn, niet de andersom. En het is ook een beetje risico's indekken, als jij als hoster aantoonbaar moeite gedaan hebt om te waarschuwen over een mogelijk issue dat is het veel makkelijker om als het dan mis gaat te zeggen dat het niet jouw verantwoordelijkheid is.

[OverloadOfRed]

bwerg schreef op donderdag 1 april 2021 @ 12:02:
Het enige relevante lijkt mij: als er iets misgaat, ligt het probleem dan bij jullie of bij A en/of C?

Dit.
Wat zijn de voorwaarden van je contract met de andere partij(en) wat betreft de support?
Je geeft aan volledig managed, dan lijkt me dat je daar iets van een richtlijn in hebt wat er wel en niet onder valt.

Bij een vorige werkgever hadden we een policy op volledig managed servers dat je managementcontract verliep (uiteraard in overleg) als je zelf aan de settings van het panel ging kloten of andere versies nginx/apache installeerde.

Ik kan me goed voorstellen dat je op je eigen servers geen oude troep wil laten draaien, maar de hamvraag blijft zoals @bwerg zei wie opdraait als het tóch gehackt wordt.