Het intro van dit artikel klinkt bijna als "developers, developers, developers", het mantra van Steve Ballmer, wat je hier op Youtube nog kunt bekijken: link.
Ik zou vandaag mijn 2e samenvatting van Build 2023 delen, maar ik heb "nog maar" 2 van de 3 sessies van 24 mei bekeken (en ook de vooraf opgenomen sessies nog niet gezien). Andere dingen te doen, maar... de tweede sessie die ik gisteren bekeken heb, die vond ik "los-artikel-waardig" voor LinkedIn.
Het gaat namelijk over de sessie van Adrian Diglio en Jasmine Wang over het Secure Supply Chain Consumption Framework.
Hoe zat het ook alweer?
"Vroeger" zette je via FTP een website online. Wat bestanden vervangen en klaar.
Vaak haalt je website data uit een database. En kun je daar ook op zoeken.
En ja, daar kun je misbruik van maken. Dus toen kwamen er scans van "hoe veilig jouw website is".
Voldoe je aan security headers, geen SQL injection, geen XSS zwakheden.
Ik kwam van de opleiding Hogere Informatica, had daar C++ Builder en Delphi gedaan, had bij mijn afstuderen en werk kennis gemaakt met ASP (wat we inmiddels classic ASP noemen), bij eigen projecten met PHP bezig en nooit les gehad over security-zaken. Dus toen er een rapport met scans kwam van sites, waarbij gezegd werd dat er XSS uitgevoerd kon worden, dat zei me niet zoveel. Een javascript:alert('test'), hoe erg kan dat zijn? Nou... als dat met het uitlezen van cookiewaardes ook kan, of zaken door-posten naar een ander domein, dat is écht een groot probleem!
Later kwam er een professionaliseringsslag. Je code werd netjes in source-control gezet, zodat je terug kon naar een eerdere versie als er "in de nieuwe versie" iets niet goed ging. En via FTP gaan we niet meer websites live zetten, daarvoor hebben we nu een build-straat. Oh ja, we maken natuurlijk ook niet "alles" meer zelf, er zijn miljarden code-bibliotheken online die je gratis kunt gebruiken, dus zaken met JSON, XML, loggen van fouten, daar kun je externe tools voor gebruiken die je in je eigen code koppelt.
En daar ging deze sessie over van Microsoft. Adrian en Jasmine zijn onderdeel van een groep die in 2019 gestart is met het specificeren van wat je met open source moet doen.
Waarom zou je als hacker een site proberen aan te vallen, als je ook een open source onderdeel kunt hacken, welke in miljarden websites gebruikt wordt? Waren websites altijd het doel om binnen te komen, de focus verschuift nu richting de developer.
De vraag is, wat doe je daarmee? Als developer zit je niet elke keer te denken "als ik dit nu bouw, zou daar misbruik van gemaakt kunnen worden?"... terwijl dat misschien wel zou moeten.
Als ontwikkelaar ben je "lekker bezig" om je code te kloppen en te zorgen dat alle openstaande punten afgevinkt kunnen worden. En als je geluk hebt, is er iemand die je code reviewt en met een scherpe blik kijkt: hier wordt input niet of onvolledig gevalideerd, dus hier zou iemand misbruik van kunnen maken.
Maar vaak wordt er even snel gekeken of het "oké eruit ziet" en is het maximale dat je code uitgecheckt wordt en geprobeerd wordt om de boel te builden. Vraag is dan natuurlijk wel wat "een code review nog toevoegt"...
Eigenlijk het enige wat ik kan bedenken is dat er iemand binnen jouw bedrijf wordt aangenomen die "security" doet, een losse rol.
Iemand die zich volledig op security kan richten. Want als ik de OWASP top 10 van 2023 erbij pak, dan zie ik daar geen SQL-injection en XSS-zaken meer, maar eigenlijk alleen maar zaken die in API's optreden. Dat komt natuurlijk omdat we met zijn allen steeds meer de front-end en de back-end van websites los trekken en via API's met elkaar gaan communiceren (waarbij we dat in het verleden alleen gebruikten om data beschikbaar te stellen voor externe partijen).
In 2015 ben ik bij de Holland Webweek in Groningen geweest en daar kwam OWASP al ter sprake: link.
Toen dacht ik al: hier moet ik / moeten wij wat meer mee doen. Maar... wanneer check ik de site van OWASP? Nu voor dit artikel, en de laatste keer is misschien 3 jaar geleden?
Die persoon, die security op zich neemt (of misschien ben jij dit binnen jouw bedrijf), die zou deze sessie van Adrian en Jasmine zeker moeten zien. Dat kan hier op de Build Site van Microsoft: link.
Want dit Framework heeft Microsoft aangeleverd bij OpenSSF: link.
Het artikel daarover is hier na te lezen: link.
En daar zie je ook de link naar de Github repo: link.
In die PDF zie je ook het "maturity-level" van jouw organisatie.
Als een developer een ZIP-bestand van een Github-locatie download en in zijn/haar project toevoegt, dan is er "geen link" naar de repository. Als er een bevinding is in die versie, krijg je niet een melding dat je code/de referentie moet bijwerken.
Zoals tijdens deze presentatie al gezegd wordt is level 4 misschien "te hoog gegrepen", want dan ga je ook alle source-code binnen halen en zelf de builds doen, bij bepaalde kritische zaken / afhankelijk van het type project is dat iets wat gedaan moet worden (Adrian is dit bij klanten tegen gekomen).
Maar het bijhouden van wijzigingen in dit framework, wat er mogelijk is met OpenSSF, welke zaken volgens OWASP de meeste aandacht moeten krijgen, het uitwerken van protocollen als er zaken fout gaat, het automatiseren van bepaalde controles, mogelijk toch zelf ook nog handmatige scans uitvoeren binnen de repositories van jouw organisatie, het lijkt een op een dagtaak en daarom volgens mij op een "losse functie binnen jouw bedrijf".
Hoewel ik nog heel veel dingen op mijn eigen planning heb staan, wil ik toch nog wel eens kijken of ik hier zelf ook nog wat aan kan doen. Want in Visual Studio kun je met Resharper van JetBrains zorgen dat tijdens het bouwen van je code er tips/voorstellen komen om je code beter te maken. Deed je vroeger in LINQ-statements altijd recordset.Where(rec => rec.Id > 100).First(), Resharper geeft aan dat die Where wel weg kan en je die lambda-expressie "gewoon" in de First(...) kunt uitvoeren. Eigenlijk zou je ook een soort plug-in in Visual Studio moeten hebben die jouw code kan beoordelen en tips kan geven die betrekking hebben op security.
Maar misschien hoef ik daar zelf al niet zoveel meer aan te doen. Want de hoofdmoot van deze Build-editie van Microsoft was Co-pilot, code / AI die jou tips kan geven en zaken voor je kan uitvoeren. Omdat Microsoft veel aandacht besteedt aan het veiliger maken van code en het ook voor hun zelf van belang is om hun eigen code veilig te houden en dat handmatig of met teams niet te doen is, zou het perfect zijn dat Co-pilot dat voor je kan doen.
Ja, we hebben het druk. Ja, we kunnen niet alles doen. Maar zorg wel dat je jouw prioriteiten goed stelt. Die ene feature die klaar zou moeten zijn is toch echt minder belangrijk dan die kritische CVE-bevinding in een codebibliotheek die jij gebruikt. Want als dat na 3 dagen nog niet gefixt is, dan zijn er online allang bot-netjes bezig om sites/projecten/omgevingen te scannen op dat zwaktepunt in code. En als daardoor al jouw sites offline gehaald kunnen worden, dan is er straks geen site meer waar je jouw feature kunt of hoeft te implementeren, want je klant is zijn/haar vertrouwen kwijt en zoekt wel een andere partij.