Har skrevet en afgrænsningsregel efter et læk
Har skrevet en afgrænsningsregel ind i repositoryet, efter at en omstrukturering havde ført en anden virksomheds inventar, firewalltilladelser og tekst med ind i det — og holdt de karantænesatte rester under hemmelighedsscanneren i stedet for at udelukke dem.
Arbejdet udført: september 2026

Foto: MabelAmber / Pixabay 
Foto: dankeck / Pixabay
en afgrænsningsregel, efter at en anden virksomheds it‑landskab dukkede op
Situation. Arbejde, der var udført for en anden virksomhed, kom med gennem en omstrukturering af repositoryet og blev liggende. Det, der fulgte med, var ikke abstrakt: en kladdelog med gyldige adgangsoplysninger i klartekst, som lå i træet uden om alle kontroller gennem det meste af repositoryets historie; en forældet inventarliste, der nævnte den virksomheds vært; og en opgavefil til firewallen, der åbnede porte til seksten af dens kunders netværk. Intet af det kørte. Det er netop derfor, det overlevede — noget, der ikke kører nogen steder, bliver aldrig gennemgået igen.
Opgave. Grænsen skulle gøres til en regel med en tilhørende test i stedet for en hensigt, og resterne skulle håndteres på en måde, der ikke blot skjulte dem.
Handling. Reglen er nu det første afsnit i repositoryets instruktionssæt: dette repository styrer én virksomheds infrastruktur og kun den, og en anden parts vært, inventarliste, firewallåbning, DNS‑zone eller adgangsoplysninger hører ikke hjemme i det — heller ikke deaktiveret, udkommenteret eller parkeret i en fil, som ingen playbook importerer. Den praktiske test står lige ved siden af: om denne virksomhed stadig ville være ansvarlig for det, hvis samarbejdet ophørte. Resterne blev sat i karantæne i en mappe med et tydeligt navn i stedet for at blive slettet, så historikken stadig kan læses, og karantænen er bevidst delvis — de to strukturelle lintere springer den over, mens hemmelighedsscanneren, vault‑kontrollen og emoji‑tjekket bevidst stadig læser den, for det er de tre, der ville fange det, der slap ind. Selve lækket førte til en ny linterregel: et brugerdefineret mønster, der markerer adgangsoplysninger, som sendes som et kommandolinjeflag — netop den form, de lækkede oplysninger havde, og som standardregelsættet ikke fangede.
Resultat. Omfangsgrænsen er en nedskrevet regel med en angivet test, resterne er synlige i stedet for begravet, og netop den form for adgangsoplysninger, der slap igennem, får nu et commit til at fejle. Læren, der er noteret ved siden af, er den generelle: det farlige artefakt er ikke det, der kører, men det, der ikke gør, for det er det, ingen læser igen.
Se tilbage på Har verificeret firewallregler efter position. Læs videre: Har adskilt alle driftshemmeligheder pr. vært. Eller tag et kig på hele porteføljen.
Ét stykke af en længere fortegnelse — og det hele ligger her på sitet.
Hver post er skrevet på samme måde: situationen, opgaven, hvad vi gjorde, og hvad der ændrede sig.

