Dank voor het plaatsen van de link naar goed leesvoer! Heel herkenbaar, zowel voor een securityman als iemand die eisendocs geschreven heeft, als programmeur (ik heb veel geprogrammeerd, vooral beroepsmatig).

Jammer alleen dat het stuk nauwelijks over security gaat maar vooral over bugs die zich zonder opzet manifesteren. En als dat al een probleem is (en dat is het), dan zijn secuity bugs, die een aanvaller (vaak kosten noch moeite sparend) vindt en uit weet te buiten, een veel groter probleem. En vormen dus een bedreiging voor onze steeds verder digitaliserende samenleving.

Programmeren is gewoon hartstikke leuk. Het is verslavend, net als puzzelen (en dan heb ik het niet over de huidige stackoverflow copy/pasters). Ik voel me een uitvinder als ik programmeer en de code doet wat het moet doen, en helemasl als de code niet doet wat het niet moet doen. Maar beroepsmatig vond ik het vaak niet leuk meer omdat ik er, volgens mijn werkgever, te lang over deed (zorgen dat code niet doet wat niet moet maar niet gedocumenteerd is noemen sommige werkgevers "goldplating", en het woord "perfectionisme" kwam in menige beoordeling voorbij). Dat komt omdat ik van robuuste code houd met fatsoenlijke input validation. Heus niet in elke functie, maar wel uitzoeken waar dat het beste kan en bij elke wijziging (vooral als collega's er tussendoor aangezeten hadden) checken en fixen indien nodig (wat er aan input binnenkomt wijzigt vaker dan je wilt, en dat kan tot diep in je code consequenties hebben). Maar als mijn snellere collega's weer eens bugs geïntroduceerd hadden en de oorzaak niet konden vinden, wisten mijn werkgevers mij weer wel vaak te vinden (ook puzzelen, maar spaghetti ontwarren frustreert wel eens). Ze hadden zich veel geld en boze klanten kunnen besparen.

Requirements schrijven vind ik veel minder leuk dan programmeren (maar is financieel vaak weer wel aantrekkelijker). Gedetacheerd liep ik er ook tegen aan dat projectleiders zo snel mogelijk functionele eisen op papier willen hebben. "Prima als ze niet allemaal/helemaal SMART zijn" (waarbij de S niet voor "secure" staat maar voor "specific" en de rest -uit Wikipedia- voor measurable, achievable, relevant en time-bound). "Zet er maar gewoon in dat het systeem aan OWASP en ISO 27001" (klok en klepel) "moet voldoen en klaar is Kees". Kijk maar eens in tenderdocs voor een willekeurig ICT project en je snapt wat ik bedoel.

En meestal is het zo dat, nadat het systeem met allerlei dependencies naar third party libraries en/of ingebakken third party conponenten geleverd is, er geen afspraken blijken te zijn gemaakt wie lekken en security updates van alle spulleboel (ook third party dus) in de gaten houdt, registreert, updates maakt en test - en vooral en wie dat moet betalen. Daarbij komt dat de leverancier binnen de kortste keren over is op een ander "framework du jour" en eerder betrokken programmeurs van project of werkgever wisselen, waarmee kennis razendsnel verdampt. Als er later, om welke reden dan ook (nieuwe Java versie bijv.), flinke wijzigingen doorgevoerd moeten worden, gebeurt dit vaak door mensen die totaal geen overzicht hebben op alle mogelijk betrokken systeemdelen, laat staan het hele systeem.

Het is een wonder hoeveel er goed gaat (of lijkt te gaan).

Ik had het stuk al via de website van NRC gevonden. Ik heb het nog niet volledig gelezen, maar er staat een hoop herkenbaars in.

Alle code die je op een gegeven ogenblik verkregen hebt, zul je ook weer op een gegeven moment moeten kunnen/willen afvoeren. Omdat het deel uitmaakt van een kwetsbare bibliotheek of omdat het verlaten code betreft, die nooit meer zal worden bijgehouden door de ontwerper(s). Bij jQuery kennen we dat soort problemen. Doe maar eens een scan hier http://retire.insecurity.today/ Voorbeeld - http://retire.insecurity.today/#!/scan/b2e0a4b3c9cda3eb98be1ea563de3aad6b99d7ba558fec0e3e5d7446954f8807
Potentieel gevaarlijk script met syntax error en script injectie. Kijk eens naar de unidentified identifiers.

Dan is het nog van belang in hoeverre die code kwaad kan als de "same origin" regel bijvoorbeeld niet gehandhaafd is
en er geen SRI hashes zijn gehanteerd. Ook speelt hier een JSONStub.stringify error.

Ga er maar aan staan om alles door te moeten spitten en alle configuraties en dependencies na te moeten lopen.
Met veertien jaar ervaring weet je ongeveer in welke richting je zal moeten zoeken, steunend op ervaring met eerder gevonden ellende en staand op de schouders van anderen.

Charlotte Bouwman over deze Longread, op NRC.nl

https://www.nrc.nl/nieuws/2017/09/27/deze-programmeurs-waarschuwen-voor-de-software-apocalyps-a1575023

Interessant en zeer leeswaardig wat je hier schrijft Bitwiper, dank!

Beste Bitwiper, bedankt, en je legt de vinger gelijk op een hele zere plek, namelijk 3rd party code.

Daar gaat het ook het vaakst mis met SRI hashes, juist de Google code, die van buiten af onvoldoende beveiligd wordt geserveerd, nota bene van een Google Safe link.

Natuurlijk is het ingrijpen van code op andere code een van de hoofdproblemen. Ik zelf kom niet verder dan javascript kauwen en herkauwen, mijn website analyse hobby/beperking/blinde vlek...en dan zie ik ook nog genoeg, hoor.

Ik denk echter ook, na zo veel code regels de revue te hebben zien passeren, dat het juist die code is, die om reden van propriety code of vanwege commerciële aspecten hoekjes en bochtjes gaat afsnijden en zich niet aan algemene standaarden wenst te houden, juist om zich daaraan te onttrekken - dat deze code de echte boosdoener is in het verhaal

Aan juist deze vlijt zal de code wereld ten onder gaan. Denk aan het boek "De wereld gaat aan vlijt ten onder". Hoe waar is dat niet telkenmale gebleken?

Maar men doet wel zijn best, zie hier: https://fossies.org/diffs/opennms-source/18.0.2-1_vs_18.0.3-1/opennms-webapp/src/main/webapp/js/backshift.onms.min.js-diff.html

Over de onderliggende en achterliggende grondoorzaken zal een flinke discussie onontbeerlijk zijn....

luntrus

Een computer programma is geen solide ontworpen hangbrug of een robuust uitgevoerde spoorwissel, maar eerder een immer voortdurend overleg. Een overleg dat in duigen kan vallen.

De software ontwikkelaar van vandaag de dag heeft dan ook veel meer gemeen met een bureaucraat of een kantoorpoliticus, dan met een wiskundig en elektrotechnisch onderlegde ingenieur. Het gevolg is dat de werking van computer programmatuur dan ook veelal ten onder gaat aan miscommunicatie, wederzijds onbegrip en allerlei politieke intriges.

In het licht van het aangehaalde NRC en Atlantic artikel wordt dan ook duidelijke waarom lieden zoals Elon Musk zich grote zorgen maken over de ontwikkeling van kunstmatige intelligentie. Die vorm van intelligentie kan wel een veel dommer zijn dan we ons nu kunnen voorstellen. En als we pech hebben zal die zich misschien weinig bekommeren om de mensenrechten.

Goede software schrijven is een kunst. Het wordt vaak onderschat op managementniveau.
Het geld jaagt het stellen van veel te vroege deadlines aan.
Samen goede software schrijven is ook een kwestie van veelvuldige communicatie tussen softwareschrijvers en een overkoepelend teamleader die van wanten weet. Daar horen ook goede onderlinge relaties bij die tegen een stootje kunnen, want het is lastig communiceren met iemand die je eigenlijk niet meer wil horen of zien.
Het probleem is dat mensen wanneer ze wat ouder worden en wat meer kennis krijgen vaak kapsones krijgen.
"Hou jij je mond maar, ik weet wel hoe het moet". Dat is schadelijk voor de samenwerking.
Studenten zijn zo succesvol omdat ze dat nog niet zo hebben, en dus veel meer open staan om van elkaar te leren.

Goede software voor een bepaald gedefinieerd doel hoeft maar één keer voltooid te worden. Maar dat kost tijd, en dus geduld en doorzettingsvermogen. En niet te vergeten modulair denken en doorredeneren hoe deze modules interactie met elkaar kunnen hebben. Daar is soms iemand met een goede "helicopter view" voor nodig, en die zou de teamleader bij voorkeur al moeten hebben. Wij leerden op school Pascal, omdat deze programmeertaal je als het ware al dwingt om in modules te denken. Privé doe ik het meestal in assembler, omdat ik dan het idee heb veel dichter bij de functionaliteit van een microcontroller te staan, en optimaal gebruik kan maken van al zijn functies. het gaat dan om niet te grote projecten.

Wat men overigens ook niet moet onderschatten is de rol van hardware.
Ik heb menigmaal gezien dat "vreemd gedrag" een gevolg was van een slecht contact of een slechte soldering, en soms een defecte component.
Neem nou die harde schijf die in mijn stagetijd begon te falen met bad sectors e.d. als hij warm werd.
Soms na 5 minuten al, soms pas na een uur.
In mijn tijd waren HDD's nog 5 1/4 inch, dus was qua hardware nog wel te behappen. Door logisch nadenken kwam ik op het idee om de aansluiting van de heads bij de flexicable eens heel goed te bekijken. "Hee, het lijk wel...." dus je pakt je
soldeerbout om heel voorzichtig die ene verdachte aansluiting eens opnieuw te solderen. Er was toch niets te verliezen.
En wat denk je? Alles weer in orde en steady!
Dus men moet ook oppassen om niet te snel de software (of hardware-componenten) de schuld te geven.
Betrouwbaarheis is dus ook een kwestie van zo weinig mogelijk kabelverbindingen en de verbindingen die niet zijn te voorkomen betrouwbaar uitvoeren, en altijd nog eens nauwkeurig na te kijken in geval van vreemd gedrag.
Een andere soms voorkomende verklaring van vreemd gedrag is EMC-storing.
Bijvoorbeeld een DECT basisstation op je inktjetplotter zetten vlakbij de gevoelige dropsensor is geen goed idee.
Problemen met bedrading en EMC wordt meestal over het hoofd gezien. Als ik bij een apparaat kwam dat binnen een paar maanden meerdere malen vanwege dezelfde soort problemen al door mijn collega's was bezocht, wist ik alweer hoe laat het was...

Dank je, het is jou dus ook opgevallen. Zelfde ervaring, je kunt het vervolgen met dat het wel in de tenderdocs staat echter dat er daarna geen aandacht meer voor is. Het had er net zo goed niet kunnen staan.