Waar een software-audit echt naar kijkt

Mensen vragen een software-audit wanneer iets niet goed voelt en niemand kan zeggen wat. Releases duren langer dan vroeger, één ontwikkelaar is de enige die een bepaalde module nog durft aan te raken, een beveiligingsvraag van een klant wachtte een week op antwoord. De audit moet dat gevoel vervangen door een lijst. Zo ziet die lijst eruit, dit lezen we om ze te schrijven, en dit doen we onderweg niet.

Hoe het rapport eruitziet

Het rapport is korter dan de meeste mensen verwachten. Het heeft vier delen.

• Bevindingen gerangschikt op gevolg. Elke bevinding zegt wat er gebeurt als je niets doet, hoe waarschijnlijk dat is en ongeveer wat het kost om ze te sluiten.
• Wat je met rust laat. Een deel van het rapport benoemt de stukken die goed zijn zoals ze zijn, zodat niemand een kwartaal besteedt aan het moderniseren van iets dat nooit het probleem was.
• Een eerste werkweek. De goedkoopste punten die het meeste risico wegnemen, gegroepeerd zodat een team maandag kan beginnen zonder ons.
• Waar ons aandeel stopt. Het rapport zegt wat wij als volgende stap zouden doen als je het vraagt en wat je eigen team aankan. Een goede audit wordt niet stilletjes een belofte om de uitvoering voor altijd te beheren.

Het staat in gewone taal, het is van jou, en het is geschreven zodat elk team ermee aan de slag kan, ook een team dat niet het onze is.

Wat we lezen

Softwareproblemen zitten zelden op één plek, dus lezen we de code en alles errond. De documentatie vertelt ons wat mensen bedoelden. De repository, de infrastructuur en de echte stroom van het werk vertellen ons wat er gebeurd is.

• Structuur: hoe het systeem opgedeeld is, waar de grenzen liggen en welke daarvan in de code nog gerespecteerd worden.
• Afhankelijkheden: op welke bibliotheken en platformen het steunt, welke daarvan nog beveiligingsupdates krijgen en welke stilletjes gestopt zijn.
• Kortere wegen: de plekken waar iemand onder druk de snelle route nam. Elk systeem heeft ze. De vraag is welke zullen houden en welke nu gewicht dragen waarvoor ze nooit bedoeld waren.
• Beveiliging die bij het echte risico past: de maatregelen die horen bij jouw data, jouw gebruikers en de gevolgen van een lek. Geen beveiligingstheater, en geen lijst controles gekopieerd van een bank terwijl jij een planningstool draait.
• Waarom releases pijn doen: hoe een wijziging van idee naar productie reist, waar ze wacht, wat onderweg breekt en wat uitrollen opnieuw voorspelbaar zou maken.

We praten ook met de mensen die het werk doen voor we iets meten. Hun zorgen kloppen meestal over het symptoom en soms niet over de oorzaak, en de kloof tussen die twee is het nuttigste wat een audit kan vinden.

Twee patronen die we blijven tegenkomen

De details verschillen elke keer. De vormen keren terug, en twee ervan zeggen het meest over waar een audit voor dient.

Het eerste is de module die iedereen wil herschrijven. Het is het oudste deel van het systeem, geschreven in een stijl die vandaag niemand zou kiezen, en het oogt als het voor de hand liggende doelwit. Dan lezen we de wijzigingsgeschiedenis en zien we dat er in jaren amper aan geraakt is, dat het één taak doet en dat het die taak zonder incidenten doet. De aanbeveling is om het met rust te laten: er een laag omheen zetten, het ene ding documenteren dat mensen erover moeten weten en de aandacht besteden waar verandering echt plaatsvindt. Een herschrijving zou maanden kosten en weggooien wat de code al geleerd heeft. Technische schuld meet je aan haar gevolg, niet aan haar leeftijd.

Het tweede is het systeem dat op geluk draait. Back-ups lopen, maar niemand heeft er ooit een teruggezet. De beheerders delen één account, en het wachtwoord heeft twee vertrekken overleefd. Eén persoon weet hoe een release werkt, en die persoon neemt vakantie. Niets hiervan verschijnt als bug. Alles ervan is een week werk om op te lossen: een geteste restore, persoonlijke accounts met tweestapsverificatieEen tweede bewijs van identiteit naast het wachtwoord, zoals een code op een telefoon, zodat een gelekt wachtwoord alleen geen beheerdersaccount opent., één pagina die beschrijft hoe een release verloopt. De audit zet die week boven elke architecturale ambitie in het rapport, omdat ze het ergste risico wegneemt voor het minste geld.

Wat we weigeren

• Mensen beoordelen. We beoordelen het werk. De meeste kortere wegen waren redelijke beslissingen binnen de beperkingen van dat moment, en een rapport dat schuld toewijst is een rapport waar niemand iets mee doet.
• Onszelf standaard aanbevelen. Als vervolgwerk zinvol is, zeggen we dat, en de beslissing is aan jou. Het advies staat op zichzelf en kan best besluiten dat je niets van ons nodig hebt.
• Resultaten beloven. Onze algemene voorwaarden zeggen dat advies een inspanningsverbintenisEen engagement om vakkundig en zorgvuldig te werken met de middelen die de opdracht vraagt, zonder een bepaald resultaat te garanderen. Onze algemene voorwaarden gebruiken het voor consultancy, advies en ontwikkeling. is: we werken zorgvuldig en zetten in wat de opdracht vraagt, en we garanderen geen uitkomst. Een audit die pijnloze releases tegen de lente belooft, verkoopt iets anders dan een audit.

Voor je er een vraagt

Wil je eerst zelf een lezing, dan stelt onze software health check twintig vragen over één systeem in productie en eindigt hij met een telling waar je mee verder kan. Verrast de telling je, of zijn de vragen die je niet kan beantwoorden net die over wie de kennis in handen heeft, dan is dat het moment waarop een audit zijn plaats verdient. Vermijden dat de bevindingen terugkomen is een aparte gewoonte, en we schreven al hoe die routine eruitziet.