Volgens Burr Sutter van Red Hat zijn er twee belangrijke uitdagingen op het gebied van softwareontwikkeling: het opzetten van een robuuste software supply chain en het verbeteren van de onboarding-ervaring.
Burr Sutter werkt al jaren bij Red Hat als developer advocate. Bij het open-sourcebedrijf houdt hij de industrie nauwlettend in de gaten om de nieuwste trends in softwareontwikkeling te identificeren. Tijdens zijn recente bezoek aan Nederland hebben we met hem gesproken om te onderzoeken wat er op dit moment speelt op het gebied van development. Volgens Sutter hebben bedrijven de meeste problemen door een gebrek aan visibility en onboardingprocessen.
Waar bevinden softwarecomponenten zich in de infrastructuur?
Sutter verwijst naar een van de belangrijkste securityrisico’s van de afgelopen jaren om de zwakke software supply chain te verklaren. In december 2021 hoorde de wereld over de Log4Shell kwetsbaarheid in het open-source framework Log4j. Zelfs na bijna 2,5 jaar hebben veel ondernemingen nog steeds last van Log4Shell. Het is nog steeds in productie. “Het probleem is dat ze het niet kunnen vinden. Ze weten dat ze een probleem hebben, maar ze weten niet hoe ze het moeten aanpakken. Ze moeten het lokaliseren. Waar zit Log4J in de infrastructuur? Bedrijven weten het waarschijnlijk niet”, merkt Sutter op.
Toen we voor het laatst een groot stuk schreven over Log4Shell, ontdekten we inderdaad dat de kwetsbaarheid volgens data van securitybedrijven bovenaan veel hitlijsten staat. Nieuwere gegevens laten ook zien dat Log4Shell nog steeds veel bedrijven achtervolgt.
Sutter erkent dat het een uitdaging is om de aanwezigheid van softwarecomponenten en dependencies zoals Log4j in je omgeving volledig te voorkomen. “Het zijn in wezen ontwikkelaars die gratis open-source materiaal downloaden van het internet. Log4Shell was interessant omdat het acht jaar eerder was geïmplementeerd in Log4j. De ontdekking werd in 2021 gedaan door een ingenieur van Alibaba, die ontdekte dat de functie een backdoor opent. Als deze op een bepaalde manier wordt misbruikt, krijg je toegang tot de machine. Maar acht jaar lang wist niemand dit. Daarom is het zo alomtegenwoordig. Mensen hebben het jarenlang gebruikt zonder te weten waar het zat.”
Het verbieden van open-source in een infrastructuur is de enige manier om een gebeurtenis als Log4Shell te voorkomen. Sutter zou zo’n drastische stap echter niet aanraden om innovatieredenen. Het kan raadzaam zijn in specifieke situaties, zoals militaire technologie, maar open-source is overal aanwezig waar innovatie nodig is. Volgens Sutter is ongeveer 86 procent van de code open-source.
De software en de auto
Volgens de visie van Red Hat is de weg vooruit het gebruik van open-source en het verbeteren van de zichtbaarheid. Daarom heeft Red Hat de Red Hat Trusted Software Supply Chain gebouwd, een productfamilie met verschillende oplossingen om de levenscyclus van softwareontwikkeling (SDLC) te verbeteren. De oplossingen omvatten de Trusted Application Pipeline, Trusted Profile Analyzer, Trusted Artifact Signer, Advanced Cluster Security en Quay. Bedrijven kunnen één, meerdere of alle oplossingen aanschaffen, afhankelijk van hun behoeften. Ze zijn nauw geïntegreerd om samen te werken.
Sutter legt Red Hat Trusted Software Supply Chain uit door het te vergelijken met hoe autodealers te werk gaan als er een fout is met bepaalde onderdelen. Wanneer iemand een nieuwe auto koopt bij een dealer, registreert de dealer de naam, het adres en het telefoonnummer. Als er een terugroepactie is om een onderdeel te repareren nadat de koper de auto heeft ontvangen, weet de dealer welk model op een specifieke datum is gebouwd met het probleem. “Hoe wisten ze dat jij die auto had en dat onderdeel dat gerepareerd moet worden? Dat is de echte supply chain”, legt Sutter uit. “Ze weten dat in dat model dat op een specifieke datum is gebouwd, het probleem zit. Het was niet de auto zelf, maar het remblokje van een andere fabrikant. Er is een fout. Ze kennen de hele supply chain, de hele lijn van alle onderdelen die in de auto zitten die je hebt gekocht. Als dat remblokje het begeeft en de klant overlijdt, zal de klant de autofabrikant aanklagen. Breng de auto terug en we repareren hem.”
Tip: Wat is het nieuwe AI-project Red Hat InstructLab?
Kopiëren-plakken
Red Hat Trusted Software Supply Chain streeft naar hetzelfde controleniveau voor software. In het geval van nog een Log4Shell-incident is er de zichtbaarheid om een fout te identificeren, waardoor alle componenten die bijdragen aan het eindproduct traceerbaar zijn. Burr Sutter legt uit: “Als je kijkt naar de end-to-end supply chain binnen die software development life cycle, is er een moment waarop ontwikkelaars hun originele code schrijven. Ze gaan ook naar een registry en downloaden dependencies, kopiëren en plakken. Ontwikkelaars kopiëren en plakken graag, maar het probleem is dat ze misschien iets plakken met een fout. We hebben een plugin die dat moment van kopiëren en plakken probeert op te vangen. Het waarschuwt ontwikkelaars als ze een potentiële kwetsbaarheid hebben geïntroduceerd via de vastgelegde dependencies. Het waarschuwt hen en een ontwikkelaar kan ervoor kiezen om het te negeren.”
De ontwikkelaar kan nog steeds committen en de code naar de broncode repository sturen. In dat geval voert de pipeline-oplossing van Red Hat een controle uit. De oplossing meldt dat er nog steeds een probleem kan zijn. Sutter voegt toe: “Als je die code commit, teken je voor de code. We weten wie de commit heeft gedaan en wie de code heeft gewijzigd. De slechte dependencies – er is een bevestiging van wie het heeft geïntroduceerd. Er is traceerbaarheid, waardoor een bedrijf de ontwikkelaar kan vragen om te stoppen met het introduceren van kwetsbaarheden in de codebase.”
Nadat de ontwikkelaar de commit vanuit de repository heeft geverifieerd, ondersteunt Red Hat de Trusted Software Supply Chain door zich te richten op de containerafbeelding. Sutter legt uit: “Wanneer je die container image bouwt met de applicatiecode, inclusief mogelijke slechte dependencies en je bedrijfslogica, bouwen we ook een veilige omgeving. Het ondertekent, test en controleert de software bill of material (SBOM) daarvan. De handtekening laat zien dat het in een specifieke omgeving is gebouwd, op een specifieke laptop. Die bestemming is ook het merkteken dat alle attributen weergeeft waarin het is gebouwd. Het geeft metadata over hoe de gebouwde omgeving er op die dag uitzag. Dit helpt je te begrijpen of de ontwikkelomgeving op dat moment veilig was.”
De ingrediëntenlijst
Sutter benadrukt het nut van de software bill of materials. Het is nu op veel plaatsen verplicht om SBOM’s te gebruiken. De documentatie van de Software Supply Chain zorgt voor meer kennis van verantwoordelijkheden. Met de SBOM weet een bedrijf of het product goed is gebouwd, op de juiste locatie, op de juiste manier en wat erin is gegaan. Zelfs als het een slechte dependency heeft, geeft de SBOM de aanwezigheid ervan aan.
Om de SBOM te ondersteunen, biedt Red Hat twee aanvullende oplossingen binnen de Trusted Software Supply Chain. De eerste is de Quay repository, een containerregistry voor software-artefacten. Deze artefacten zijn zichtbaar, waardoor het bedrijf hun locatie kan traceren en bestanden van plaats naar plaats kan overbrengen. Op deze manier is het mogelijk om de SBOM en de handtekening te verzenden. Daarnaast biedt Red Hat de tool Trusted Profile Analyzer, die de SBOM opneemt en opslaat. Door het opslaan van de SBOM kunnen bedrijven weten wanneer er ingrediënten aan de software worden toegevoegd. Met Trusted Profile Analyzer kunnen gebruikers de ingrediëntenlijst doorzoeken, waarbij SBOM’s proactief worden bewaakt om potentiële problemen zoals Log4Shell te identificeren. Het waarschuwt gebruikers wanneer dergelijke incidenten zich voordoen en geeft inzicht in hoe vaak het voorkomt in de infrastructuur.
Sutter concludeert dat deze manier van werken een aanzienlijke verbetering is ten opzichte van de traditionele methode. “Normaal gesproken zou je scanners gebruiken en reverse-engineeren van de binary voor wat ze denken dat erin zit. Dat is niet zo effectief omdat sommige dependencies verborgen kunnen zijn. SBOM maakt het meer zichtbaar en menselijk leesbaar, waardoor mensen kunnen redeneren over het bestand.”
De developer’s developer
Een andere belangrijke uitdaging die Sutter benadrukt, is het ontbreken van een effectief onboardingproces voor ontwikkelaars. Hij deelt inzichten uit een klantgesprek met een grote bank in het Verenigd Koninkrijk, die te maken had met onboarding-uitdagingen. “Ze ontdekten dat wanneer ze iemand nieuw in dienst namen, de nieuwe persoon een laptop, VPN-toegang, e-mailadres en een deursleutel kreeg – alles wat nodig was om een werknemer te zijn. Het probleem was echter dat de nieuwe medewerker minstens 60 dagen lang niet productief was in het schrijven van code”, legt Sutter uit. Ondanks het feit dat de ontwikkelaar over de vaardigheden beschikte om code te schrijven, werd hij geconfronteerd met uitdagingen omdat de software development life cycle op de nieuwe werkplek aanzienlijk verschilde van zijn vorige ervaring. “Elke SDLC is uniek per bedrijf, en in sommige gevallen zijn er meerdere SDLC’s binnen een bedrijf, met teams die hun eigen geïndividualiseerde SDLC’s hebben. Daarom moet een nieuwe medewerker leren hoe het bedrijf software bouwt.”
Om dit probleem aan te pakken, heeft Red Hat Red Hat Developer Hub ontwikkeld. Sutter beschrijft het als de “developer’s developer”, een hulpmiddel voor het opzetten van de onboarding-omgeving. De portal biedt alles wat een ontwikkelaar nodig heeft, inclusief alle documentatie en context, zoals de locatie van git repositories. Gebruikers kunnen de SDLC ervaren via dat sjabloon, doorklikken en de unieke pijplijn van het bedrijf zien”, merkt Sutter op.
Volgens Sutter kan het gebruik van Red Hat Developer Hub de tijd die een nieuwe ontwikkelaar nodig heeft om te beginnen met het schrijven van code na indiensttreding aanzienlijk verkorten van 60 dagen tot 6 minuten. Dit minimaliseert tijdverlies en zorgt ervoor dat innovatie door kan gaan omdat ontwikkelaars direct aan de slag kunnen, waardoor onnodig salarisverlies tijdens de eerste 60 dagen wordt voorkomen. Sutter wijst er ook op dat in bedrijven waar een onboarding van 60 dagen de norm is, ontwikkelaars zelfs binnen die tijd kunnen vertrekken naar een concurrent die een betere onboarding-ervaring biedt.
Het verkorten van de onboarding-tijd en het verbeteren van de software supply chain, verbeteren het werk van een ontwikkelaar aanzienlijk. Deze twee onderwerpen verdienen zonder twijfel aandacht in een tijdperk waarin software industrieën verandert.
Tip: Red Hat maakt van OpenShift de hybride AI en cloud-pion