3 Belangrijkste ingrediënten voor Continuous Compliance

Andreas Prins

Het is al weer even geleden dat ik 5 redenen voor Continuous Compliance deelde, en de introductie gaf op dit onderwerp. Het jaar is inmiddels 8 maanden verder en zo ook de visie en inrichting van dit onderwerp.

In dit blog delen we met veel plezier de 3 belangrijkste ingrediënten voor Continuous Compliance.

  1. Maak gebruik van Build Breakers in de pipeline
  2. Zorg voor een goede segregatie van rechten
  3. Zet monitoring bovenop je pipeline

Een eerlijke onthulling

Persoonlijk ben ik het met nummer 1 volledig eens, nummer 2 en 3 vindt ik wat over de top. Ben je echter werkzaam binnen een omgeving waar Sox, audits en compliancy behoren tot de woordenschat van je bedrijf dan zul je er niet aan ontkomen om ze op te zetten. Als je dat doet, doe het dan goed en zo veel als mogelijk geautomatiseerd. Het ultieme doel is dat je er nauwelijks het omkijken naar hebt.

Maak gebruik van Build Breakers in de pipeline

Dit is echt een van de belangrijkste componenten om een veilige pipeline te hebben. Maar niet alleen veilige maar ook een pipeline die kwalitatief hoogwaardige software moet opleveren. Build Breakers zijn punten in je pipeline die ervoor zorgen dat de software niet wordt neergezet op omgevingen (Test en Acceptatie) verder in je pipeline als je niet voldoet aan bepaalde kwaliteitscriteria.

Door op deze manier te werken is er een garantie dat alles wat naar productie gaat ook daadwerkelijk de testen heeft doorstaan. Voor de auditors is dit echt een cruciaal punt. Deze manier van werken heeft twee grote bijkomende voordelen, de beslissing of iets naar productie kan gaan is in verre mate te automatiseren en het levert enorm snelle feedback cycles op voor iedereen in het proces.

4 Voorbeelden van build breakers:

  • Elke rode of oranje bevinding uit je static secure code analysis (op te zetten met Fortify SCA)
  • Een code coverage onder bijvoorbeeld 85% (op te zetten met SonarQube)
  • Een (API) regressie test die faalt (op te zetten met bijvoorbeeld Concordian)
  • Een performance daling van een stuk functionaliteit (op te zetten in Gatling)

Zorg voor een goede segregatie van rechten in je pipeline

Dit deel is eenvoudig en vanzelfsprekend. Een goede segregatie van rechten is een een hoog gereguleerde omgeving van cruciaal belang. Het komt er kortweg op neer dat je pipeline moet kunnen aantonen dat de persoon die de code maakt of aanpast niet de persoon is die de release naar productie kan aanzetten.

Wij hebben dit opgezet door de engineer alle rechten te geven om code aan te passen en te creëren. Deze belanden uiteindelijk in bijvoorbeeld Gitlab en Artifactory voordat ze naar productie worden gepompt door de pipeline. De ontwikkelaar heeft ook alle rechten om alle pipelines aan te passen en te verbeteren behalve de pipeline die de software naar de productie omgeving brengt.

De Product Owner, Asset Owner en IT Custodian hebben vervolgens het recht om een release aan te zetten en de software naar productie te brengen. Deze drie rollen, in ons geval ook 3 personen, hebben niet de rechten om in Gitlab en Artifactory aan de code te komen.

In mijn team hebben we de segregatie van rechten opgezet op het niveau van de pipeline die we hebben ingericht in XL-Release.

Zet monitoring bovenop je pipeline

Ik ben echt van auditors gaan houden, hun gedachten zijn soms meer dan vreemd maar daarmee niet minder prikkelend. In mijn post De IT Audit als ultieme les voor omdenken, schreef ik al hoe er allerlei zaken gevonden werden. De meeste zou ik nooit bedacht hebben en dus ook niet gevonden hebben. Iemand stelde tijdens de audit zelfs de vraag of we criminelen zijn dat dit soort scenario’s bedacht worden.

Om een lang verhaal kort te maken, auditors hebben eigenlijk altijd wel gelijk, zei het soms zuiver hypothetisch. Dat heeft ons er wel toe gebracht om monitoring op de pipeline te zetten. Want hoe weet je anders zeker dat de ontwikkelaar via een enorme omweg toch niet de pipeline heeft aangepast en stiekum allerlei testactiviteiten heeft uitgeschakeld.

Met goede monitoring op de pipeline weet je precies wanneer de pipeline wordt aangepast. We hebben dit inzichtelijk gemaakt met ELK (Elastic, Logstash en Kibana) en dit staat continue aan op de werkvloer. Daarnaast krijgt het hele team inclusief de drie personen die de release naar productie kunnen aanzetten altijd een email als er een release wordt aangezet.

Deze drie zijn voor ons de belangrijkste ingrediënten omdat we hiermee het proces om de software naar productie te brengen weer een stukje veiliger hebben gemaakt.

Wat voor maatregelen neem jij om zonder al te veel inspanning toch redelijk zeker te zijn van de code die er in productie staat de juiste code is?

whatsapp meWil je een WhatsApp bericht ontvangen bij een nieuwe blog?
Stuur dan even een berichtje naar +31645112490