Meer van de code in je repository wordt door een agent geschreven dan een jaar geleden, en dat aandeel groeit alleen maar. Agents zijn goed in het laten werken van iets. Ze zijn goed in het ontblokkeren van zichzelf. Wat ze niet weten, is welke compliance frameworks je bedrijf moet naleven, omdat die informatie in een beleidsdocument staat dat ver buiten hun contextvenster ligt.
Het resultaat is een nieuwe en groeiende bron van compliance risico: code die correct is, gemerged, en stilletjes in strijd met een control waar de agent nooit van heeft gehoord.
De handige wildcard
Een agent koppelt een nieuwe interne service en een cross-origin verzoek mislukt. De snelste manier om het verzoek te ontblokkeren is om elke oorsprong toe te staan. De agent doet dat, het verzoek slaagt, de taak wordt als voltooid gemarkeerd. Het is een redelijke zet voor iemand wiens taak het is om de code werkend te krijgen.
app.use(cors({- origin: ["https://app.example.com"],+ origin: true, // reflect any origin credentials: true,}))Het reflecteren van elke oorsprong met referenties vergroot wie toegang kan krijgen tot een geauthenticeerd oppervlak, wat precies is waar CC6.1 (logische toegang) over gaat: toegang beperkt tot wat is geautoriseerd. De code is correct en het verzoek werkt. De beveiliging is zwakker dan voor de agent eraan begon.
Waarom dit de nieuwe grens is
Door mensen geschreven controleafwijkingen gebeuren één onzorgvuldige PR tegelijk. Door agenten geschreven controleafwijkingen gebeuren met de snelheid en omvang waarop agenten werken, en zonder de impliciete beoordeling die een ervaren engineer meebrengt ('moet ik dit echt voor iedereen openstellen?'). De agent optimaliseert voor de taak die voor hem ligt, en 'voldoen aan SOC 2 CC6.1' is niet de taak die voor hem ligt.
Naarmate het aandeel door agenten geschreven code toeneemt, neemt ook het aandeel wijzigingen toe die niet zorgvuldig door een mens op compliance zijn beoordeeld. Dat is de afwijking, en die neemt toe.
De pull request is de enige controlepost
Je kunt het beleids-PDF niet in de context van elke agent plaatsen en erop vertrouwen dat het wordt nageleefd. Maar het werk van de agent komt nog steeds als een pull request binnen, en de pull request is de enige plek in de workflow waar een wijziging kan worden gecontroleerd voordat deze wordt geïmplementeerd, of het nu door een persoon of een agent is geschreven.
heygrc is gebouwd om elke PR te lezen tegenover je frameworks en de controle aan te geven die een wijziging raakt, of deze nu door een agent of niet is geschreven, zodat de handige wildcard wordt genoemd als een CC6.1-probleem in de diff.