De spanning zit niet in security, maar in afwijkingen
De meeste softwareorganisaties denken dat security centraal is geregeld. Er is een policy, er zijn standaarden, er is een dashboard. Klaar.
Een actueel bericht over Enforce GitHub Advanced Security configurations is hier de context. Het nieuws is niet het punt; het maakt de operationele beslisdruk zichtbaar.
Tot je kijkt waar de afwijkingen zitten. Niet in het beleid zelf, maar in de plekken waar een org-admin of repo-admin toch nog even iets anders kan zetten. Dáár ontstaat de echte frictie: niet tussen ‘veilig’ en ‘onveilig’, maar tussen centrale bedoeling en lokale praktijk.
GitHub heeft daar nu een concrete stap in gezet. Enterprise administrators kunnen GitHub Advanced Security-configuraties afdwingen op enterprise-niveau, en org- en repository-admins kunnen die instellingen niet meer overrulen. Technisch klinkt dat klein. Bestuurlijk is het precies het punt.
Standaardisatie wint het van lokale autonomie
Dit soort wijzigingen zijn interessant omdat ze iets blootleggen wat veel teams liever impliciet houden: securitybeleid is vaak minder centraal dan het lijkt.
Op slide-niveau is alles netjes geordend. Enterprise bepaalt de norm, teams voeren uit. In de praktijk is er bijna altijd een laag van lokale vrijheid. Een repository die een uitzondering kreeg omdat de release al in gang was. Een team dat een instelling tijdelijk anders zette “tot de volgende sprint”. Een beheerder die dacht dat het wel logisch was om één setting aan te passen voor zijn eigen domein.
Dat is niet per se onkunde. Vaak is het juist productiviteit. Lokale admins lossen echte problemen op, snel en zonder vergadercircuits.
Maar zodra je security serieus op enterprise-niveau wilt organiseren, wordt die lokale vrijheid een bestuursvraag. Niet: kunnen mensen iets aanpassen? Maar: mogen ze afwijken van een norm die je als organisatie al hebt vastgesteld?
GitHub kiest hier duidelijk voor minder onderhandelingsruimte. Enterprise admins kunnen Advanced Security-configuraties afdwingen en daarmee voorkomen dat org- of repo-admins het beleid terugdraaien. Dat is geen extra knop voor de securityafdeling. Het is een verschuiving in macht.
Schijnconsistentie is duurder dan een duidelijke uitzondering
De grootste fout die ik in dit soort omgevingen zie, is niet dat teams te weinig regels hebben. Het is dat ze denken dat regels al werken, terwijl de uitzonderingen nooit hard zijn gemaakt.
Dan krijg je schijnconsistentie. De policy staat aan. De rapportage oogt netjes. De presentatie voor leadership ziet er volwassen uit. Maar onder water zijn er repositories, orgs of teams die nét even anders zijn ingericht. Niet omdat iemand de boel saboteert, maar omdat niemand scherp heeft vastgelegd wie nog mag afwijken.
Dat wordt pas echt duur op het moment dat je iets moet uitleggen. Waarom stond deze controle hier uit? Wie heeft dat besloten? Was dit een tijdelijke uitzondering of een structurele keuze? En bovenal: waarom wist niemand dat dit nog afweek?
Daar zit de consequentie van deze GitHub-wijziging. Minder override-mogelijkheden betekent minder configuratieversnippering, maar ook minder ruimte om onduidelijke eigenaarschap te verstoppen achter lokale autonomie.
En dat is ongemakkelijk, want veel organisaties gebruiken lokale vrijheid als smeerolie. Tot die vrijheid een mistlaag wordt waar niemand meer doorheen kijkt.
Volwassen security begint bij eigenaarschap, niet bij meer tooling
Fourlab kijkt hier niet naar als een securityfeature, maar als een governance-signaal.
Als je al weet welke Advanced Security-instellingen echt enterprise-breed moeten gelden, is afdwingen nuttig. Dan hoort die norm niet thuis in een losse repositorybeslissing of in de voorkeur van een individuele admin.
Maar als je dit inzet terwijl nog onduidelijk is wie uitzonderingen mag goedkeuren, dan maskeer je het echte probleem. Dan heb je wel een hardere policy, maar nog geen helder besluitmodel.
En precies daar gaat het vaak mis bij softwareleiderschap. Teams investeren in tooling, terwijl de vraag eigenlijk organisatorisch is: waar ligt de grens tussen standaard en uitzondering? Wie mag die grens verleggen? En hoe lang blijft zo’n uitzondering geldig?
Zonder antwoord daarop wordt afdwingbaarheid een schijnoplossing. Niet omdat het technisch niet werkt, maar omdat de organisatie nog steeds niet weet wie waarvoor aan de lat staat.
Wat deze wijziging echt zichtbaar maakt
De waarde van deze GitHub-aanpassing zit niet in het feit dat er weer een instelling bijgekomen is. De waarde zit in wat het dwingt te erkennen: securitybeleid is pas echt beleid als afwijkingen expliciet zijn gemaakt.
Dat klinkt eenvoudig, maar in veel softwarebedrijven is het precies omgekeerd gegroeid. Eerst waren er teams, dan repositories, dan org-structuren, en daarna pas enterprise-afspraken. De praktijk heeft dan al jaren geleerd om om beleid heen te bewegen.
Daarom is een enterprise-level override niet alleen een technische beperking. Het is een signaal dat volwassen security minder draait om nog meer controles en meer om het vastleggen van beslissingsrechten.
Niet alles hoeft centraal. Maar wat centraal hoort, moet ook echt centraal kunnen zijn.
En als een organisatie daar geen helder antwoord op heeft, dan is het probleem niet dat iemand een configuratie kan aanpassen. Het probleem is dat niemand precies weet waarom dat ooit mocht.