Op 22 maart ging versie 11.9 van GitLab live. In deze versie kom je er sneller achter of geheime gegevens gelekt zijn en het geeft je de mogelijkheid om meerdere goedkeuringsregels toe te voegen voor merge requests. Én de populaire functionaliteit ChatOps is nu open source, zodat we er met z’n allen aan mee kunnen bouwen.
Snel ontdekken of geheime gegevens gelekt zijn
De eerste en belangrijkste update uit deze release: je kunt nu snel ontdekken of geheime gegevens zijn gelekt. Het per ongeluk delen van inloggegevens in een gedeelde repository kan namelijk gebeuren. Een fout die gemakkelijk gemaakt wordt en behoorlijke consequenties kan hebben. Stel je voor dat een hacker hierdoor je wachtwoord of API-sleutel te pakken krijgt: ze nemen je account over, sluiten je uit van het systeem en kunnen zelfs je geld uitgeven. Het kan zelfs leiden tot een domino-effect, waarbij toegang tot het ene account ook toegang geeft tot het andere. Scenario’s waar niemand blij van wordt.
Daarom heeft GitLab gewerkt aan een oplossing om er snel achter te komen of er geheime gegevens gelekt zijn. Op het moment dat je een nieuwe update commit, wordt deze door GitLab automatisch gescand om te checken of er geen geheime gegevens in staan. Als dat zo is, dan wordt de developer daarvan in zijn merge request op de hoogte gesteld. Op die manier weet hij meteen dat hij zijn huidige inloggegevens moet updaten.
Mogelijkheid tot complexer review proces
Wanneer een organisatie groeit, wordt een goede afstemming over verschillende afdelingen vaak een stuk moeilijker. Tegelijkertijd worden de gevolgen van het implementeren van verkeerde of onveilige code steeds groter, omdat de applicatie groeit in het aantal gebruikers en meer omzet genereert. Veel organisaties hebben daarom als afspraak dat er altijd een gedegen reviewproces voorafgaat aan het mergen van nieuwe code.
GitLab heeft er met deze release voor gezorgd dat dit belangrijke proces beter te controleren en overzien is. Eerder was het namelijk zo dat individuele of groepen merge requests voorgedragen konden worden ter goedkeuring. Nu is het zo dat je meerdere goedkeuringsregels kunt toevoegen. Je kunt bijvoorbeeld aangeven dat een merge request voorgelegd moet worden aan specifieke individuele ‘goedkeurders’, of aan een aantal goedkeurders die in een bepaalde groep zitten.
Dat betekent dus dat je als organisatie nu ook meer complexe ‘goedkeuringsstromen’ kunt implementeren om de kwaliteit van de code nog beter te waarborgen.
De ChatOps-functie is nu open source
Veel developers werken in chatprogramma’s als Slack en Mattermost. De ChatOps-functie in GitLab zorgde er al voor dat je rechtstreeks vanuit het chatprogramma een actie kunt uitvoeren in GitLab en de status van de actie kunt bekijken.
GitLab heeft aangegeven dat ze open source software-ontwikkeling als een van de pijlers binnen hun bedrijf zien. Vandaar dat er in deze release voor is gekozen om de ChatOps functie open source te maken. Enerzijds zodat iedereen van de functionaliteit gebruik kan maken, anderzijds zodat ChatOps zelf kan profiteren van suggesties voor verbeteringen van slimme developers buiten GitLab.
Overige updates
Dit waren de 3 belangrijkste updates van deze release. Maar er zijn ook nog een aantal kleinere updates die het leven van een GitLab developer een stuk gemakkelijker gaan maken.
Wijzigingen in feature flags worden bijgehouden
De feature flags-functionaliteit maakte het al mogelijk om een project in verschillende ‘smaken’ te lanceren, door bepaalde functionaliteiten dynamisch aan- of uit te schakelen. In versie 11.9 van GitLab worden wijzigingen aan deze feature flags bijgehouden.
Dat betekent dat er een zogenaamde audit log is, waar je kunt zien wat er is veranderd en wanneer. Dat is nuttig, omdat de ontwikkelaar in het geval van incidenten nu kan zien welke feature flag recentelijk gewijzigd is en of dit de oorzaak zou kunnen zijn van het incident.
Gemakkelijker software opschonen
Het saneren of opschonen (remediation) van software zou een simpel proces moeten zijn om snel kwetsbaarheden in je code te ontdekken. Hiervoor worden beveiligingspatches gebruikt: kleine stukjes software die fouten opspoort en oplost. Eerder moest de ontwikkelaar daarvoor een patch file downloaden en lokaal toepassen, om deze vervolgens in de repository op afstand te verwerken.
In GitLab 11.9 wordt dit proces geautomatiseerd. Dat houdt in dat een developer de code nu kan opschonen zonder dat hij of zij de interface van GitLab hoeft te verlaten.
Mogelijke kwetsbaarheden in één overzicht
GitLab heeft al een dashboard groepsbeveiliging. Dit dashboard geeft ontwikkelaars inzicht in alle mogelijke kwetsbaarheden in hun app, en welke daarvan op dit moment de hoogste prioriteit hebben. Eerder waren alle mogelijke kwetsbaarheden niet op één plek te vinden, maar daar heeft GitLab 11.9 verandering in gebracht. Developers hebben nu het complete overzicht op één pagina, ongeacht de oorzaak van het probleem.
Templates voor veiligheidsfunctionaliteiten
GitLab’s veiligheidsfunctionaliteiten ontwikkelen zich ontzettend snel, omdat ze er constant aan werken om ze up-to-date te houden. Ze moeten effectief zijn en de code goed kunnen beschermen. Dat betekent echter ook dat de namen van deze functies relatief vaak wijzigen. Voor een developer kan het een uitdaging zijn om deze te wijzigen, vooral als diegene meerdere projecten beheert.
In GitLab 11.9 zijn daarom templates ingebouwd voor deze zogenaamde security jobs. Dat betekent dat de veiligheidsfunctionaliteiten elke keer als een ontwikkelaar upgradet naar een nieuwe GitLab-versie worden geüpdatet in het systeem.
GitLab 11.9: veiliger en overzichtelijker
Tot zover de belangrijke wijzigingen in de nieuwste GitLab versie 11.9. De volgende release vindt eind april plaats, en ook dan duiken we weer de release notes in.
