Er gaat meer code doorheen dan iemand nog kan lezen. Een controle die meedraait in de pijplijn vangt de categorie fouten af die zich mechanisch laat herkennen, zodat de aandacht van uw mensen naar de fouten gaat die dat niet doen. Wij richten dat in met afspraken die blijven staan.
DevSecOps betekent in de praktijk iets eenvoudigs: de controles die u anders aan het einde doet of helemaal niet, draaien mee op het moment dat code wordt geschreven en opgeleverd. Geen apart beveiligingsproject naast het ontwikkelen, maar een aantal poorten in de weg die code toch al aflegt. De winst zit niet in het vinden op zich, maar in het moment: een fout die bij het schrijven zichtbaar wordt, is een kort gesprek; dezelfde fout na oplevering is een incident.
Er is een reden waarom dit nu dringender is dan een paar jaar geleden. Het tempo waarin code wordt geproduceerd is sneller gegroeid dan het tempo waarin mensen die kunnen nalezen, en gereedschap dat code genereert is geoptimaliseerd voor werkende code en niet voor veilige code. Dat betekent dat er meer doorheen komt en dat er meer bekende patronen in zitten — precies de categorie die een controle in de pijplijn wel afvangt en een overbelaste reviewer niet.
Wij richten die controles in, maar het werk zit vooral in de afspraken eromheen: wat houdt tegen, wat waarschuwt, en hoe komt er iets doorheen als dat een keer moet. Dat sluit direct aan op uw componentoverzicht en op kwetsbaarhedenbeheer. Draait uw pijplijn bij een externe partij, dan werken we samen met wie dat beheer doet.
Alles tegelijk aanzetten op een bestaand project levert een berg meldingen op waar niemand aan begint. Wij werken daarom in deze volgorde, en pas als de vorige stap rustig is.
Wij beginnen altijd bij geheimen. Dat is de meest voorkomende fout, de best af te vangen, en de enige waar niemand tegen kan zijn: een sleutel of wachtwoord in code heeft geen legitieme uitzondering. Daarna de afhankelijkheden: verouderde onderdelen met een bekend lek, gekoppeld aan uw componentoverzicht. Staat die categorie op nul en blijft hij daar, dan is er vertrouwen om de volgende aan te pakken.
Analyse op de code zelf voor de patronen die zich mechanisch laten herkennen: invoer die ongefilterd in een zoekopdracht belandt, onveilige functies, ontbrekende controles op de plekken waar ze horen. Daarnaast de container- en infrastructuurlaag, waar een groot deel van de gemelde kwetsbaarheden zit en waar een verkeerde instelling iets openzet dat dicht hoorde te zijn. Meldingen wegen we op waar ze zitten, niet alleen op hun score.
Per categorie vastleggen wat tegenhoudt en wat waarschuwt, met een nette uitzonderingsroute die vastlegt wie waarvoor tekent. Daarnaast het beveiligen van de bouwstraat zelf: wie mag wat uitrollen, waar komen de bouwstenen vandaan, en kunt u van een artefact aantonen uit welke code het is voortgekomen. Dat laatste wordt in inkooptrajecten steeds vaker gevraagd.
Werkende controles in uw eigen pijplijn, plus de afspraken die bepalen of ze over een half jaar nog aan staan.
Vier situaties waarin het inrichten van controles in de pijplijn meer oplevert dan het kost. Herkent u er een, dan is er waarschijnlijk snel winst te halen.
Het tempo is gestegen en de code-review is de flessenhals geworden, of hij is stilzwijgend een formaliteit geworden. Een mechanische controle vangt de categorie fouten af die zich laat herkennen, zodat uw mensen naar de rest kunnen kijken.
U laat periodiek testen en er komt telkens een lijst met bekende patronen uit. Dat is duur ontdekken van iets wat de pijplijn had kunnen afvangen, en het maakt de test minder waardevol voor waar hij wel goed in is.
Afnemers vragen in hun vragenlijst of u beveiligingscontroles in uw ontwikkelproces heeft en of u dat kunt aantonen. Rapportage dat de controles hebben gedraaid en wat eruit kwam, is precies wat daar wordt gevraagd.
Er is ooit een scanner aangezet, er staan honderden waarschuwingen open en het kanaal is gedempt. Dat is geen gereedschapsprobleem maar een afsprakenprobleem, en dat is precies waar wij beginnen.
Welke bouwstraat draait er, welke talen, wat staat er al aan, en wat kwam er uit de laatste test of audit. We kijken ook naar de mensen: wie beoordeelt nu bevindingen, en wat gebeurt er als er iets met spoed live moet. Dat laatste bepaalt of poorten standhouden.
We zetten de eerste categorie waarschuwend aan en ruimen op wat eruit komt, samen met uw team. Blokkeren op een berg openstaande bevindingen leidt gegarandeerd tot uitzetten. Pas als de lijst op nul staat, gaat de poort dicht.
Per categorie bepalen wat blokkeert, wat waarschuwt en wat informatie is, en hoe de uitzonderingsroute eruitziet. Wij doen dat met de ontwikkelaars zelf en niet alleen met wie erover beslist; dat is het verschil tussen een proces dat draait en een dat na een maand stilvalt.
Categorie voor categorie, in tweewekelijkse sprints, telkens dezelfde volgorde: waarschuwend aan, opruimen, afspraak maken, dichtzetten. Geheimen, dan afhankelijkheden, dan statische analyse, dan de container- en infrastructuurlaag.
Een rapportage die u kunt meesturen in een inkooptraject, een overdracht aan uw team, en een afspraak over wie de poorten beheert. Als u daarna periodiek wilt laten meekijken kan dat, maar het is geen voorwaarde.
Wat ontwikkelteams, CTO’s en security-officers ons vragen voordat zij hiermee beginnen.
Een kennismaking van een half uur, vrijblijvend. Vertel wat er nu aanstaat en wat er uit de laatste test kwam, dan zeggen we waar wij zouden beginnen en wat kan wachten — ook als we uiteindelijk niet samenwerken.
Appfront gebruikt cookies en vergelijkbare technieken voor een goede werking van de website, voor analyse en voor marketing. Je kiest zelf wat je toestaat. Lees meer in ons privacybeleid.
