Forstå CodeQL-resultater

  • 5 minutter

I tidligere enheder oprettede du en database og scannede den udpakkede fil fra din kode. Nu kan du få vist resultaterne og afgøre, om der er sikkerhedsrisici, der skal håndteres.

Fortolkede forespørgselsresultater vises automatisk i kildekoden i CodeQL-udvidelsen til Visual Studio Code. Outputresultater, som CodeQL CLI genererer, kan være i mange formater til brug sammen med forskellige værktøjer.

Du kan styre, hvordan analyseresultater vises i kildekoden, ved at ændre en forespørgsels select-sætning. Du kan gøre resultaterne tydelige og nemme for andre brugere at forstå, mens de udvikler forespørgslen. Når du skriver dine egne forespørgsler i forespørgselskonsollen eller i CodeQL-udvidelsen til Visual Studio Code, er der ingen begrænsninger for, hvad der kan vælges.

Hvis du vil bruge en forespørgsel til at oprette beskeder i GitHub-kodescanning eller generere gyldige analyseresultater ved hjælp af CodeQL-kommandolinjegrænsefladen, skal du gøre rapporten med select-sætningen til det påkrævede format.

Udbedringsarbejdsgange med Copilot Autofix

Når CodeQL har identificeret et problem, er det vigtigste skridt at løse det. GitHub integrerer detektion med afhjælpning ved at lade dig gå direkte fra en advarsel til en foreslået løsning.

Rettelse af advarsler med Copilot Autofix

Når du åbner en CodeQL-advarsel i fanen Sikkerhed, viser GitHub detaljer om problemet, herunder den berørte kode, alvorsgraden og hvordan problemet blev introduceret.

For understøttede advarsler ser du også Copilot Autofix.

Copilot Autofix analyserer advarslen og genererer et foreslået rettelse. Dette omfatter:

  • En kodeændring, der løser problemet
  • En forklaring på, hvorfor problemet opstår
  • Vejledning om, hvordan løsningen løser problemet

I stedet for manuelt at skrive en løsning fra bunden, starter du med en foreslået ændring.

En typisk arbejdsgang ser sådan ud:

  1. CodeQL kører i din arbejdsgang og opretter en advarsel.
  2. Du åbner alarmen og gennemgår den berørte kode.
  3. Copilot Autofix genererer en foreslået løsning.
  4. Du gennemgår forklaringen og de foreslåede ændringer.
  5. Du anvender rettelsen, som skaber en pull request.
  6. Pull requesten kører tjek og gennemgås før sammenlægning.

Denne arbejdsgang forbinder detektion direkte med afhjælpning uden at forlade GitHub-grænsefladen.

Copilot Autofix anvender ikke ændringer automatisk. Du er ansvarlig for at gennemgå og godkende løsningen. Dette sikrer, at:

  • Løsningen passer til din kodebase.
  • Du kan justere implementeringen, hvis det er nødvendigt.
  • Ændringer gennemgår din eksisterende gennemgangsproces.

Autofix er mest effektiv til:

  • Almindelige sårbarhedsmønstre, såsom injektionsrisici eller usikker brug af API'er.
  • Problemer, der kan løses med en klar, lokaliseret kodeændring.

For mere komplekse problemer kan Autofix give vejledning, men du kan være nødt til at ændre løsningen eller implementere en specialløsning.

Foreslåede løsninger i alarmer

Selv når Autofix ikke er tilgængelig, indeholder nogle advarsler foreslåede løsninger.

Disse forslag:

  • Fremhæv den del af koden, der bør ændres.
  • Giv vejledning om, hvordan du løser problemet.

Du kan bruge disse forslag som udgangspunkt, når du skriver din løsning.

Afhjælpning af afhængigheder med Dependabot

Ikke alle sårbarheder kommer fra din kode. Nogle introduceres gennem afhængigheder.

Dependabot hjælper automatisk med at løse disse problemer ved at:

  • Opdagelse af sårbare afhængigheder.
  • Oprettelse af pull requests med opdaterede versioner.
  • Det giver dig mulighed for at gennemgå og sammenflette rettelser.

Disse pull requests følger samme arbejdsgang som Autofix:

  1. Der foreslås en ændring.
  2. Checks bliver kørt.
  3. Opdateringen bliver gennemgået og sammenflettet.

Dette gør afhængighedsudbedring i overensstemmelse med, hvordan du løser applikationskodeproblemer.

Automatisering af udbedringsarbejdsgange

Du kan bruge GitHub Actions til at automatisere, hvordan rettelser håndteres.

For eksempel kan arbejdsgange:

  • Kør tests på Autofix eller Dependabot pull requests.
  • Påfør mærkater baseret på sværhedsgraden.
  • Krav godkendelser for højrisikoændringer.
  • Sammenlæg automatisk lavrisikoopdateringer.

Disse arbejdsgange sikrer, at udbedringen sker:

  • Konsekvent på tværs af teamet.
  • Valideret før sammenlægning.
  • Integreret i din udviklingsproces.

Fra detektion til opløsning

I en komplet arbejdsgang:

  1. CodeQL opdager en sårbarhed.
  2. Copilot Autofix foreslår en løsning.
  3. En pull request oprettes.
  4. GitHub Actions validerer ændringen.
  5. Rettelsen bliver gennemgået og flettet sammen.

Ved at kombinere CodeQL-analyse med Copilot Autofix, Dependabot og workflow-automatisering skaber du et system, der ikke kun finder problemer, men også hjælper med at løse dem effektivt.

Handle på kodescanningsadvarsler

Du kan konfigurere kodescanning for at kontrollere koden i et lager. Du kan bruge standard-CodeQL-analysen, en ikke-Microsoft-analyse eller andre typer analyser. De resulterende beskeder vises side om side i lageret.

GitHubs standard CodeQL-analyse kan omfatte flere egenskaber for beskeder end resultater fra ikke-Microsoft-værktøjer eller fra brugerdefinerede forespørgsler. I en standardarbejdsproces analyserer kodescanning jævnligt din kode på standardgrenen og under pullanmodninger.

Hver besked indeholder følgende oplysninger:

  • Problemet med koden og navnet på det værktøj, der identificerede den.
  • Den kodelinje, der udløste beskeden.
  • Egenskaberne for beskeden, f.eks. alvorsgraden.
  • Sikkerhedens alvorsgrad.
  • Det punkt, hvor problemet blev indført.
  • Problemets art.

Oplysningerne omfatter også, hvordan du løser problemet, når CodeQL-analyse identificerer en besked. Derudover kan kodescanning via CodeQL registrere dataflowproblemer i din kode.

Skærmbillede af CodeQL-analyseadvarsler i GHAS.

Ud over manuelt at rette sårbarheder kan du automatisere afhængighedsudbedring ved hjælp af Dependabot-sikkerhedsopdateringer.

Når Dependabot opdager en sårbar afhængighed, opretter den en pull request for at opdatere afhængigheden. Disse pull requests kan integreres i automatiserede arbejdsgange for at effektivisere udbedringen.

Automatisering af afhængighedsafhjælpning med Dependabot

En typisk automatiseringsarbejdsgang følger dette mønster:

  1. Dependabot opretter en pull request for at opdatere en sårbar afhængighed.
  2. En GitHub Actions-arbejdsgang udløses på begivenhedenpull_request.
  3. Workflowet tjekker, om pull requesten er oprettet af dependabot[bot].
  4. Metadata om opdateringen (såsom afhængighedstype eller versionsændring) kan bruges til at bestemme den næste handling.
  5. Arbejdsgangen kører valideringskontroller, anvender etiketter eller aktiverer automatisk sammenfletning for lavrisikoopdateringer.

Følgende eksempel viser en simpel GitHub Actions-arbejdsgang, der kun kører for Dependabot pull requests. Den validerer opdateringen og kan aktivere auto-merge efter at tjekkene er bestået.

name: Dependabot remediation

on:
  pull_request:
    branches:
      - main

permissions:
  pull-requests: write

jobs:
  dependabot:
    if: github.event.pull_request.user.login == 'dependabot[bot]'
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Run tests
        run: npm test

      - name: Enable auto-merge for approved updates
        if: ${{ success() }}
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          PR_URL: ${{ github.event.pull_request.html_url }}
        run: gh pr merge --auto --merge "$PR_URL"

Denne tilgang hjælper teams med at reducere manuelt arbejde, samtidig med at afhængighedsopdateringer bliver valideret, før de bliver slået sammen.

I produktionsscenarier er auto-merge typisk begrænset til lavrisikoopdateringer, såsom patch-udgivelser, og kombineres med branch-beskyttelsesregler, påkrævede statuskontroller og gennemgangspolitikker.

Underretning af teams om oprydningsaktiviteter

For at forbedre synligheden i afhængighedsopdateringer integrerer teams ofte Dependabot med eksterne notifikationssystemer.

Ud over GitHub-notifikationer kan du bruge:

  • Slack- eller Microsoft Teams-integrationer for teambevidsthed.
  • GitHub webhooks til brugerdefinerede integrationer og automatiseringspipelines.

For eksempel kan en arbejdsgang eller webhook give besked til et team, når:

  • En Dependabot pull request åbnes.
  • Valideringstjek fejler.
  • En sikkerhedsopdatering er flettet.

Disse notifikationer hjælper teams med hurtigt at reagere, når udbedring kræver opmærksomhed.

Dataflowbeskeder

Dataflowanalyse finder potentielle sikkerhedsproblemer i kode, herunder:

  • Brug af data på en måde, der kompromitterer sikkerheden.
  • Overførsel af farlige argumenter til funktioner.
  • Lækker følsomme oplysninger.

GitHub viser dig, hvordan data bevæger sig gennem koden, når kodescanning rapporterer dataflowbeskeder. Du kan bruge disse dataflowbeskeder til at identificere de områder af din kode, der lækker følsomme oplysninger. Denne viden kan hjælpe dig med at identificere indgangspunktet for angreb fra ondsindede brugere.

Alvorsgradsniveauer

Alle kodescanningsresultater med en sværhedsgrad af fejl forårsager som standard kontrolfejl.

Alarmens sværhedsgrad er:

  • Fejl
  • Advarsel!
  • Bemærkning

Du kan angive det alvorlighedsniveau, hvor pull requests, der udløser kodescanningsalarmer, skal fejle.

Niveauer for sikkerheds alvorsgrad

Sikkerhedsforespørgsler, som kodescanning genererer, viser niveauer for sikkerheds alvorsgrad for beskeder.

Sikkerhedsniveauerne er:

  • Alvorlig
  • Høj
  • Mellem
  • Lav

GitHub bruger CVSS-data (Common Vulnerability Scoring System) til at beregne en beskeds sikkerheds alvorsgrad.

Enhver kodescanningsresultat, der har en sikkerhedsstyrke på Kritisk eller Høj, forårsager som standard en kontrolfejl. Du kan angive, hvilket sikkerhedsniveau der skal forårsage en kontrolfejl for kodescanningsresultater.

Luk en kodescanningsadvarsel

Du har to måder at lukke en besked på:

  • Løs problemet i koden.
  • Afvis eller slet beskeden.

Afvis en kodescanningsadvarsel

Hvis du afviser en besked, kan du lukke en besked, som du ikke mener skal rettes. Du kan f.eks. afvise en besked om en fejl i kode, der kun bruges til test. Du kan også afvise en besked, hvis den indsats, der kræves for at rette fejlen, er større end den potentielle fordel ved at forbedre koden.

Du kan afvise advarsler fra kodescanningsannoteringer i koden eller fra oversigtslisten under fanen Sikkerhed . For at afvise en advarsel fra listen, vælg menuen Afvis advarsel , vælg en grund til afvisning, og vælg derefter knappen Afvis advarsel .

Animation, der viser rullemenuen og knappen til at afvise en kodescanningsadvarsel.

Når du afviser en besked:

  • Beskeden afvises i alle forgreninger.
  • Beskeden fjernes fra antallet af aktuelle beskeder for projektet.
  • Beskeden flyttes til listen Lukket i oversigten over beskeder. Du kan åbne den derfra, hvis det er nødvendigt.
  • Årsagen til, at du har lukket beskeden, registreres.
  • Næste gang kodescanning køres, genererer den samme kode ikke en besked.