Kode og sikkerhed
Sikkerhedsscanning af kode: fang fejl før de bliver sat i drift
En app kan bygge, bestå almindelige tests og stadig indeholde et lækket token, en kendt sårbar pakke eller en usikker vej fra brugerinput til database eller browser. Automatiske scanninger kan opdage en del af det tidligt, hvis hver alarm får en ejer, bliver vurderet i appens sammenhæng og ikke forveksles med et sikkerhedsstempel.
Udgivet 4. oktober 2026 · Ca. 10 minutters læsetid
Det korte svar
Start med at scanne den eksisterende kode og historik, så gamle fund ikke blandes med nye ændringer. Beskyt derefter pull requests med kontroller, der passer til projektets sprog og risiko: scanning efter secrets, vurdering af nye dependencies og statisk analyse af kode. Aftal hvem der vurderer fund, hvad der skal blokere en release, og hvordan en undtagelse dokumenteres og genbesøges.
Brug forskellige kontroller til forskellige fejl
“Security scan” er ikke én kontrol. Afgræns problemet, og vælg de mekanismer, som passer til repositoryet og den valgte platform.
| Kontrol | Kan blandt andet finde | Finder ikke automatisk |
|---|---|---|
| Secret scanning | Kendte token- og nøglemønstre i kode og historik | Alle interne credentials eller om et fund allerede er misbrugt |
| Dependency review | Nye eller ændrede pakker med kendte sårbarheder | Ukendte fejl eller om den ramte kodevej bruges i produktion |
| Statisk kodeanalyse | Mistænkelige dataflow og kendte fejlmønstre i understøttet kode | Hele runtimekonfigurationen eller appens forretningslogik |
| Tests og manuel review | Forkerte rettigheder, regler, integrationer og konkret adfærd | Alle mønstre på tværs af en stor kodebase uden målrettet hjælp |
NIST anbefaler at vælge analyse og test efter softwaretype, livscyklus og risiko samt at registrere, prioritere og følge fund i udviklingsteamets normale arbejdsgang.
Tag et kontrolleret udgangspunkt
Kør først de valgte scanninger på den nuværende stabile branch. Hvis hundredvis af gamle fund straks bliver gjort til et samlet mergekrav, bliver resultatet ofte enten stilstand eller ukritisk masseafvisning.
- 1. Bekræft omfanget. Notér sprog, projektmapper, genereret kode, testkode, buildartefakter og om værktøjet faktisk analyserer dem.
- 2. Kør en baseline. Registrér eksisterende fund uden automatisk at kalde dem alle reelle eller ufarlige.
- 3. Fjern støj ved kilden. Udeluk kun dokumenteret genereret eller irrelevant kode; skjul ikke brede mapper for at få et grønt resultat.
- 4. Prioritér efter vej og konsekvens. Se på om input er angriberstyret, om koden kan nå produktion, og hvilke data eller handlinger der påvirkes.
- 5. Beskyt nye ændringer. Lad pull requests vise nye fund, mens den eksisterende restliste får ejer og realistisk plan.
Behandl et lækket secret som en hændelse
Secret scanning kan gennemgå Git-historik for kendte credentialmønstre, mens push protection kan stoppe understøttede secrets, før de bliver skubbet til repositoryet. Dækning og tilgængelighed afhænger af repository, organisation og GitHub-produkt, så kontrollér de aktuelle indstillinger i den konkrete konto.
- Tilbagekald eller rotér først. At slette teksten fra seneste commit gør ikke credentialet ugyldigt.
- Afgræns eksponeringen. Find hvor nøglen fandtes, hvilke rettigheder den havde, og om logs eller leverandørspor viser usædvanlig brug.
- Flyt den rigtige værdi. Læg erstatningen i den valgte platforms secret-løsning eller brug identitetsbaseret adgang, når stacken understøtter det.
- Vurdér historikken bagefter. Omskrivning af Git-historik kan være relevant, men den erstatter ikke tilbagekaldelse og kan påvirke kloner og åbne branches.
Læs kodealarmen som en mulig datarejse
Statisk analyse undersøger kode uden at køre hele appens virkelige brugerflow. GitHubs CodeQL kan med standardopsætning vælge understøttede sprog og køre ved relevante pushes og pull requests. Avanceret opsætning kan være nødvendig ved særlige builds eller analysebehov. Vælg ikke den mest komplekse opsætning, før den enkle er afprøvet på projektets faktiske kode.
- Kilde: Hvor kommer den ubetroede værdi fra – formular, URL, fil, webhook eller eksternt API?
- Vej: Hvilken validering, transformation og adgangskontrol passerer den?
- Mål: Ender den i SQL, HTML, kommandokørsel, filsti, redirect eller et følsomt API-kald?
- Kontekst: Kan den kodevej rammes i produktion, og hvilke bruger- eller systemrettigheder har den?
- Bevis: Ret koden og tilføj en test, eller dokumentér præcist hvorfor fundet ikke kan udnyttes.
GitHub registrerer årsag og valgfri kommentar, når en code scanning-alarm afvises. Brug det som en teknisk beslutning med kontekst – ikke som en oprydningsknap.
Gør kontrollen stabil, før den blokerer
En kontrol, der ofte fejler på grund af opsætning eller manglende dækning, skaber genveje. Kør den derfor synligt på rigtige pull requests, ret konfigurationsfejl, og gør først derefter det stabile resultat til et krævet check på den branch, der kan udgives.
- Kør hurtige, relevante kontroller på pull requests og fuldere scanninger på en passende tidsplan.
- Giv workflowet mindst mulige rettigheder, og giv ikke analysejobbet produktionscredentials.
- Fastlå og vedligehold tredjeparts-actions efter samme regler som resten af deploymentkæden.
- Brug dependency review til nye pakkeændringer og behold en separat proces for allerede kendte sårbarheder.
- Aftal hvad der sker, hvis scanningstjenesten er nede: vent, brug en dokumenteret manuel kontrol eller stop releasen efter risiko.
Typiske fejl
- Scanneren installeres, men ingen ejer alarmerne: Dashboardet vokser, mens releases fortsætter uændret.
- Alle gamle fund blokerer straks: Teamet lærer at omgå kontrollen i stedet for at prioritere risikoen.
- Et lækket token slettes kun fra koden: Credentialet virker fortsat fra historik, logs eller en eksisterende kopi.
- Severity bliver hele vurderingen: En generisk score erstatter spørgsmålet om kodevej, eksponering, data og forretningskonsekvens.
- AI-rettelsen flettes uden review: Alarmen forsvinder, men adfærd, adgang eller fejlhåndtering ændres ubemærket.
- Scannerens mapper er ukendte: Backend, funktioner eller et underprojekt bliver aldrig analyseret.
- Grønt resultat kaldes godkendt sikkerhed: Rettigheder, tenantgrænser og kritiske forretningsregler bliver ikke testet.
Tjekliste før scanning bliver en releasekontrol
- ☐ Repositoryets sprog, projektmapper, genererede filer og stabile branch er kortlagt.
- ☐ Secret scanning, dependency review og kodeanalyse har hver et tydeligt formål og kendt dækning.
- ☐ Eksisterende fund er baselinet, prioriteret og tildelt en ejer uden at skjule nye fund.
- ☐ Et lækket credential bliver tilbagekaldt eller roteret før eventuel oprydning i Git-historik.
- ☐ Pull requests viser nye fund, før koden kan nå den branch, som udgives.
- ☐ Analysejobbet har ingen unødvendige secrets eller produktionsrettigheder.
- ☐ En alarm vurderes ud fra kilde, vej, mål, produktionsbrug og mulig konsekvens.
- ☐ Rettelser gennemgås og testes som kodeændringer – også når et værktøj eller AI foreslår dem.
- ☐ Afviste eller udsatte fund har konkret begrundelse, ansvarlig og dato for ny vurdering.
- ☐ Kontrollen har vist stabil dækning på rigtige pull requests, før den bliver et krævet check.
- ☐ Planen ved scannerfejl eller utilgængelig tjeneste er dokumenteret efter release-risiko.
- ☐ Trusselsmodel, adgangstests og relevante runtime-tests supplerer den automatiske scanning.
Relaterede guides
Officielle kilder
Understøttede sprog, scanningstyper og adgang til GitHubs sikkerhedsfunktioner kan ændre sig og afhænge af repository og organisation. Rådene er kontrolleret mod aktuelle officielle kilder; kontrollér altid funktionerne i den konkrete konto og dokumentationen til projektets valgte analyseværktøj.