Linux goeroe: Ontwikkelaars niet verantwoordelijk voor code
Linux goeroe en kernel ontwikkelaar Alan Cox heeft het Engelse House of Lords laten weten dat zowel open als closed source ontwikkelaars niet verantwoordelijk zijn voor de veiligheid van hun code. Volgens de Red Hat medewerker hebben ontwikkelaars de "ethische taak" om hun code zo veilig mogelijk te maken. "Microsoft mensen hebben de morele taak om ervoor te zorgen dat hun besturingssysteem gezond genoeg is om gebruikt te worden".
Cox voegde eraan toe dat het algemeen geaccepteerd is dat niemand weet hoe je een veilig besturingssysteem bouwt, maar dat uiteindelijk iemand dit zal ontdekken en hier erg rijk van zal worden. De Linux goeroe is van mening dat closed-source aanbieders niet voor hun code verantwoordelijk zijn, vanwege de gevolgen die dit zou hebben voor de relatie met third-party vendors. Ook open source ontwikkelaars kun je niet voor hun code aansprakelijk houden, vanwege de aard van open source software ontwikkeling en de manier waarop de code gebruikt wordt.
Microsoft was ook op de hoorzitting aanwezig. Technology Officer Jerry Fishenden liet weten dat degene die inbreken hiervoor verantwoordelijk zijn. "Wij maken onze software zo veilig als mogelijk. Mensen, de verantwoordelijkheid voor inbraak ligt niet bij de slotenmakers, die ligt bij de inbrekers".
Dit heeft de consequentie dat bedrijven niet kunnen bouwen op
opensource software. Als ze de stekker eruit halen kunnen ze dat zonder
consequentie doen.
Willen ze geen patch uitbrengen dan kunnen ze dat ook doen.
Enige waar bedrijven op kunnen bouwen is: hoe het in het verleden
verlopen is, en dat is niet voldoende.
Jammer maar waar.
Wat je hier als argumenten tegen open source aandraagt gelden net zo goed voor closed source. Lees de EULA maar eens een keertje goed door.
En dat is het probleem van opensource. Niemand is
verantwoordelijk.
Dit heeft de consequentie dat bedrijven niet kunnen bouwen op
opensource software. Als ze de stekker eruit halen kunnen ze
dat zonder
consequentie doen.
Willen ze geen patch uitbrengen dan kunnen ze dat ook doen.
Enige waar bedrijven op kunnen bouwen is: hoe het in het
verleden
verlopen is, en dat is niet voldoende.
Jammer maar waar.
Het voordeel van Open Source is dan weer dat je eventueel
zelf een oplossing kan maken (of laten maken), terwijl het
bij closed source ophoud als de leverancier/fabrikant niet
meer wil
En dat is het probleem van opensource. Niemand is
verantwoordelijk.
Dit heeft de consequentie dat bedrijven niet kunnen bouwen op
opensource software. Als ze de stekker eruit halen kunnen ze dat
zonder consequentie doen.
Willen ze geen patch uitbrengen dan kunnen ze dat ook doen.
En dat kan ook met closed source. Als jij met een
software-bedrijf een SLA afspreekt en netjes een contract
opstelt, hebben ze zich daar aan te houden. Dat staat verder
los van het feit of de source open is of niet.
Zoals een andere Anoniem al aangaf: als de maker van de
software de stekker er uit trekt ben je met closed source
een stuk slechter af dan met open source.
Closedsource: Een aantal weten hoe de sleutel er uit ziet en
hebben eventueel het recht om deze te vervangen
Vraag is echter, wat is nou beter/veiliger/etc? Je eigen OS
schrijven lijkt me de enige oplossing in deze omdat allebei
de situaties eigenlijk niet wenselijk zijn.
Opensource: Iedereen kan de sleutel maken en het slot vervangen
Closedsource: Een aantal weten hoe de sleutel er uit ziet en
hebben eventueel het recht om deze te vervangen
Vraag is echter, wat is nou beter/veiliger/etc? Je eigen OS
schrijven lijkt me de enige oplossing in deze omdat allebei
de situaties eigenlijk niet wenselijk zijn.
Leuke analogie, die sloten. Want je hebt lockpickers die het
voor de uitdaging doen en zij die het voor het gewin doen...
De vraag wat er beter/veiliger is? Iedereen die zegt dat
hij/zij dat weet liegt dat hij/zij barst. We weten niet hoe
we wel veilige code moeten schrijven, we weten alleen uit
ervaring wat er in het verleden niet gewerkt heeft.
Open source is hardstikke leuk spul hoor, maar dom om te gebruiken voor
productie doeleinden als je de kennis niet in huis hebt om problemen op
te lossen.
Closed source daarentegen is hardstikke leuk spul, maar werkt verdomde
frustrerend als je iets moet aanvragen en dergelijke, wat je zelf in een
uurtje kunt aanpassen / verbeteren als je WEL de kennis in huis hebt.
Maar dit is compleet niet waar het topic over gaat...
Jammer maar waar: hier zit Alan Cox er toch helemaal naast.
Het grote probleem van de software-industrie is juist dat
software-ontwikkelaars (met name bedrijven) niet
verantwoordelijk zijn voor de kwaliteit van hun rommel. Dat
betekent dat niet zij opdraaien voor de kosten van fouten,
maar dat anderen dat doen, en dat zorgt er voor dat de
bedrijven niet economisch zijn gemotiveerd om goed voor de
veiligheid van hun produkten te zorgen, zowel tijdens de
bouw als in de onderhoudsfase
Dat zegt ie toch?
Open source is hardstikke leuk spul hoor, maar dom om te
gebruiken voor
productie doeleinden als je de kennis niet in huis hebt om
problemen op
te lossen.
zou ook geen cisco spul voor productie inzetten als ik de
kennis niet heb om 't spul te onderhouden en problemen op te
lossen.
@Jos Visser:
Voor software makende bedrijven is het misschien wel te doen
om die verantwoordelijkheid te nemen, maar als ik als hobby
programmeur iets op het net zet kan ik dat niet. Ik denk ook
dat Alan Cox daarop doelt. Als ik het goed heb staat in de
GPL zelfs dat de software geleveld word "as-is" zonder
garanties. Garanties die (naar mijn mening) de distributeur
weer wel kan geven voor betalende klanten, die kunnen
daardoor immers mensen in dienst nemen om zoiets te fixen
als de originele auteur dat niet (meer) kan.
en een gedegen ontwerp volgens bijvoorbeeld het Object
Capability Model.
Ik zou zeggen dat de ontwikkelaar niet verantwoordelijk is
voor de code, maar wel voor het ontwerp. En dat geneuzel dat
niemand weet hoe je een veilig
besturingssysteem maakt, of veilige software maakt. Even
googelen op Object Capability Mode en Principle Of Least
Authority en je vind de decenia oude basis beginselen die
door MS en Linux blijkbaar nog steeds niet begrepen worden.
Gelukkig zijn we met o.a. de e-language nu op een punt
beland dat we niet meer van het OS afhankelijk zijn om
veilige software te maken.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
