In dit artikel legt Will Dollman uit waarom het team van Amp bewust heeft gekozen om pull requests over te slaan en direct naar de main branch te pushen. Hij ontkracht de misvatting dat dit in strijd is met SOC 2-compliance. Volgens de auteur en hun auditors draait SOC 2 niet om specifieke tools, maar om het beheersen van risico's door middel van geautoriseerde, geteste en geregistreerde wijzigingen.
Om dit te waarborgen hanteert Amp de volgende controles:
- Beperkte push-toegang: Alleen geautoriseerde engineers kunnen pushen.
- Ondertekende commits: Verificatie van de auteur via GitHub.
- Geautomatiseerde CI: Een strikte validatiepijplijn die foutieve wijzigingen blokkeert.
- Audit-trail: Commits zijn gekoppeld aan discussie-threads, waardoor het proces transparant blijft.
Dollman concludeert dat een rigide proces voor een klein team een bottleneck vormt en pleit ervoor dat bedrijven risico's per systeem moeten evalueren in plaats van een standaardproces voor alle software te hanteren.
“Dat is niet SOC 2-compliant”
We hebben meer gedeeld over hoe we werken: het bouwen van Amp met Amp, orbs, het schrappen van functies en het niet gebruiken van pull requests. De meest voorkomende reactie gaat niet over de AI-workflows of welk type loop graph engineering die week in trek is. Het is dit:
"Wacht, jullie gebruiken geen pull requests? Jullie pushen direct naar main? Hoe? Dat is niet SOC 2-compliant."
Maar dat is het wel.
Het overslaan van pull requests was een bewuste keuze vanaf de eerste commit. Het is een essentieel onderdeel van hoe we bouwen en waarom we continu kunnen releasen. Toen we begonnen met het traject richting SOC 2, stelden we die vraag rechtstreeks aan onze auditors: “Je hebt daar PR's voor nodig... toch?”
Controles
SOC 2 vereist geen pull requests. Het vereist dat je nadenkt over je risico's.
Dat is het werkelijke antwoord dat we kregen. Auditors, en SOC 2 zelf, zijn flexibeler dan je zou aannemen. Onze auditors vroegen niet om pull requests; ze vroegen wat ons wijzigingsproces was en werkten met ons samen aan een set controles die daarbij pasten.
De Trust Services Criteria noemen nooit git of pull requests. Wat ze vereisen is dat wijzigingen worden geautoriseerd, getest, goedgekeurd en geregistreerd — en pull requests zijn slechts één manier om dat te doen.
Dit zijn de controles waar we op uit zijn gekomen:
- Beperkte push-toegang: Toegang tot main volgt de bedrijfsfunctie: elke engineer bij Amp kan pushen, en het grootste deel van Amp bestaat uit engineers. Het percentage mensen met toegang is minder belangrijk dan het kunnen uitleggen van wie precies toegang heeft en waarom.
- Ondertekende commits: Pushen vereist al authenticatie, maar het auteurschap van een commit is slechts metadata. GitHub dwingt geverifieerde handtekeningen af op main, waardoor de auteur van elke commit verifieerbaar is.
- Geautomatiseerde CI: Elke wijziging doorloopt de volledige validatiepijplijn: tests, infrastructuurcontroles en beveiligingscontroles. Foutieve wijzigingen blokkeren main.
- Een audit-trail die net zo goed is als die van een PR: Commits zijn gekoppeld aan de Amp-threads die ze hebben voortgebracht. Het verslag is dus niet alleen een diff, maar alles wat daaraan voorafging. Vanuit daar registreert CI/CD het pad van commit naar implementatie.
Niets hiervan is exotisch. Maar het is ook niet het standaardproces waar simpelweg een stap uit is verwijderd. Het is een systeem dat bewust is ontworpen, en het biedt een auditor hetzelfde als een PR-workflow.
En nee, code review staat niet op de lijst. De criteria schrijven niet voor dat een tweede mens naar een diff moet staren.
Schaalt dit?
We zijn met 20 personen, voornamelijk engineers, en iedereen staat dicht bij de code. Klein zijn en een hoge mate van vertrouwen is ons voordeel, en we gaan dat niet opgeven voor een proces dat we niet nodig hebben. Wanneer het schrijven van code snel gaat, wordt een traag proces de werkelijke bottleneck.
We gaan echter niet doen alsof een bedrijf van 2.000 personen iedereen naar main moet laten pushen.
Wat wel schaalt, is nadenken over je risico's, want risico is binnen een bedrijf ook niet uniform. Amp is productie-software die direct klantgericht is, en we releasen dit op deze manier. Ondertussen is er bij grotere bedrijven genoeg code die minder risico draagt dan dat, maar waar elke wijziging via hetzelfde proces gaat, gekalibreerd op het meest angstaanjagende systeem dat het bedrijf beheert.
Je hoeft niet het hele bedrijf om te gooien om dat op te lossen. Kies één systeem en vraag: “Welke risico's beheersen onze pull requests hier eigenlijk?” Vraag vervolgens hoe je die risico's op een andere manier zou kunnen beheren.
Het antwoord hoeft niet per definitie pull requests te zijn.
“Dat is niet SOC 2-compliant”
We hebben meer gedeeld over hoe we werken: het bouwen van Amp met Amp, orbs, het schrappen van functies en het niet gebruiken van pull requests. De meest voorkomende reactie gaat niet over de AI-workflows of welk type loop graph engineering die week in trek is. Het is dit:
"Wacht, jullie gebruiken geen pull requests? Jullie pushen direct naar main? Hoe? Dat is niet SOC 2-compliant."
Maar dat is het wel.
Het overslaan van pull requests was een bewuste keuze vanaf de eerste commit. Het is een essentieel onderdeel van hoe we bouwen en waarom we continu kunnen releasen. Toen we begonnen met het traject richting SOC 2, stelden we die vraag rechtstreeks aan onze auditors: “Je hebt daar PR's voor nodig... toch?”
Controles
SOC 2 vereist geen pull requests. Het vereist dat je nadenkt over je risico's.
Dat is het werkelijke antwoord dat we kregen. Auditors, en SOC 2 zelf, zijn flexibeler dan je zou aannemen. Onze auditors vroegen niet om pull requests; ze vroegen wat ons wijzigingsproces was en werkten met ons samen aan een set controles die daarbij pasten.
De Trust Services Criteria noemen nooit git of pull requests. Wat ze vereisen is dat wijzigingen worden geautoriseerd, getest, goedgekeurd en geregistreerd — en pull requests zijn slechts één manier om dat te doen.
Dit zijn de controles waar we op uit zijn gekomen:
- Beperkte push-toegang: Toegang tot main volgt de bedrijfsfunctie: elke engineer bij Amp kan pushen, en het grootste deel van Amp bestaat uit engineers. Het percentage mensen met toegang is minder belangrijk dan het kunnen uitleggen van wie precies toegang heeft en waarom.
- Ondertekende commits: Pushen vereist al authenticatie, maar het auteurschap van een commit is slechts metadata. GitHub dwingt geverifieerde handtekeningen af op main, waardoor de auteur van elke commit verifieerbaar is.
- Geautomatiseerde CI: Elke wijziging doorloopt de volledige validatiepijplijn: tests, infrastructuurcontroles en beveiligingscontroles. Foutieve wijzigingen blokkeren main.
- Een audit-trail die net zo goed is als die van een PR: Commits zijn gekoppeld aan de Amp-threads die ze hebben voortgebracht. Het verslag is dus niet alleen een diff, maar alles wat daaraan voorafging. Vanuit daar registreert CI/CD het pad van commit naar implementatie.
Niets hiervan is exotisch. Maar het is ook niet het standaardproces waar simpelweg een stap uit is verwijderd. Het is een systeem dat bewust is ontworpen, en het biedt een auditor hetzelfde als een PR-workflow.
En nee, code review staat niet op de lijst. De criteria schrijven niet voor dat een tweede mens naar een diff moet staren.
Schaalt dit?
We zijn met 20 personen, voornamelijk engineers, en iedereen staat dicht bij de code. Klein zijn en een hoge mate van vertrouwen is ons voordeel, en we gaan dat niet opgeven voor een proces dat we niet nodig hebben. Wanneer het schrijven van code snel gaat, wordt een traag proces de werkelijke bottleneck.
We gaan echter niet doen alsof een bedrijf van 2.000 personen iedereen naar main moet laten pushen.
Wat wel schaalt, is nadenken over je risico's, want risico is binnen een bedrijf ook niet uniform. Amp is productie-software die direct klantgericht is, en we releasen dit op deze manier. Ondertussen is er bij grotere bedrijven genoeg code die minder risico draagt dan dat, maar waar elke wijziging via hetzelfde proces gaat, gekalibreerd op het meest angstaanjagende systeem dat het bedrijf beheert.
Je hoeft niet het hele bedrijf om te gooien om dat op te lossen. Kies één systeem en vraag: “Welke risico's beheersen onze pull requests hier eigenlijk?” Vraag vervolgens hoe je die risico's op een andere manier zou kunnen beheren.
Het antwoord hoeft niet per definitie pull requests te zijn.
Groetjes,