Et passord, en nøkkel eller et token som sniker seg inn i en commit, blir fanget opp før det når repositoriet ditt. Historikken din holder seg ren. Ingen i teamet ditt må slippe alt de har i hendene for å bytte ut en tilgangsopplysning.
Hva du får
En repository-historikk uten tilgangsopplysninger i seg, og ingen krise å rydde opp etter.
De fleste utviklingsteam kjenner øyeblikket. Noen oppdager en tilgangsnøkkel i en commit fra forrige uke. Fra da av er det et kappløp: finn ut hva nøkkelen åpner, lag en ny, bytt den inn overalt der den gamle ble brukt, og håp at ingen fant den først. Et repository husker alt det får, så å fjerne nøkkelen fra historikken er en krevende jobb i seg selv.
Det kappløpet koster selv når ingenting galt kommer ut av det. Det trekker de beste folkene dine bort fra planlagt arbeid i en dag. Det etterlater også et spørsmål som er vanskelig å svare sikkert på: så noen andre den?
Arbeidet havner i ditt eget kode-repository. Passord, nøkler og tokens blir fanget opp før de når det. Tre ting følger av det for deg.
Historikk som holder seg ren. Det som kommer inn i repositoriet ditt, er arbeidet, ikke en tilgangsopplysning som ble med ved et uhell.
Ingen utskifting i all hast. En nøkkel som aldri nådde repositoriet ditt, er ikke en nøkkel du må bytte ut i kveld.
Ett funn mindre å jage. En tilgangsopplysning i kildehistorikken er noe av det første en grundig sikkerhetsgjennomgang ser etter. Her blir den fanget opp før den kan bli et funn.
Slik ser det ut i praksis
Tenk deg en vanlig uke. Endringer kommer inn i repositoriet ditt: en rettelse i registreringsskjemaet, en ny rapport, en oppgradering av et bibliotek. Teamet ditt leser dem, og du bestemmer hva som lanseres. Ingenting når brukerne dine uten at du har godkjent det.
Det du ikke får den uken, er en melding som begynner med «vi må bytte ut». Repositoriet teamet ditt kloner, deler med en nyansatt eller gir til en revisor, inneholder arbeidet, ikke en hemmelighet som lekket ut sammen med det.
For en teknisk leder betyr det færre kvelder brukt på å spore hvor en nøkkel tok veien. For en produktleder er det en uke som ikke går tapt til en hasteopprydding. Og for den som svarer på sikkerhetsspørreskjemaet, er det en enkel linje å skrive.
To sider av samme grense
Dette hører sammen med arbeid innenfor tilgangen du gir. Den siden handler om hva vi kan nå i systemene dine: vi arbeider innenfor tilgangen du gir, og ikke mer. Denne handler om det som kommer tilbake den andre veien. Endringene som kommer tilbake til repositoriet ditt, bringer med seg arbeidet, og passordene, nøklene og tokenene blir fanget opp før de kommer dit.
Hva det ikke er
Det er ikke en sikkerhetsrevisjon, og det erstatter ikke din egen praksis for håndtering av tilgangsopplysninger. Det vokter mot én vanlig og kostbar feil: at en hemmelighet forsvinner ut i en commit.
Begynn med ett lite stykke arbeid, og se på historikken det etterlater i repositoriet ditt.
