SundAITal med os ↗
Menu
Alle artikler

DevSecOps

AI-genereret kode: sikkerhedsgennemgang før idriftsættelse

En praktisk DevSecOps-tjekliste til AI-genereret kode: adgangskontrol, afhængigheder, CI/CD-rettigheder, hemmeligheder og dokumentation før release.

Til: Udviklingsansvarlige, der leverer AI-assisteret kode eller no-code-prototyper

I denne guide

Det korte svar

Gennemgå AI-genereret kode som anden produktionskode: placer ansvar, test adgangsgrænser, undersøg afhængigheder og kontroller leveranceprocessen. En fungerende demo og en ren scanningsrapport er nyttige input. Ingen af dem viser alene, at applikationen håndhæver de forretningsregler, kunderne er afhængige af.

Start med ændringer, der giver adgang eller beføjelser

Prioriter autentifikation, autorisation, betalinger, uploads, dataeksport og administration. Bed en reviewer forklare følsomme ændringer, og hvorfor den kaldende bruger må udføre handlingen. Hvis ingen kan forklare kontrollen, bør ændringen vente på en tilstrækkelig gennemgang.

Vores forslag til et reviewnotat angiver commit, funktion, berørte data, reviewer og accepttest. Medtag genererede databasemigreringer og infrastruktur. En lille ændring i brugerfladen kan dække over en større ændring af databaseadgang eller deploy-rettigheder.

Test forretningsgrænsen og de afviste handlinger

Lav parrede test: En bruger med rettighed kan udføre handlingen; en bruger uden rettighed kan ikke. Medtag en anden kunde, en udløbet session og en forespørgsel uden om brugerfladen. Ved RAG bør tjenesten udelukke dokumenter uden for brugerens adgang, før de kommer ind i modellens kontekst.

Microsofts Azure AI Search-dokumentation skelner mellem roller på tjenesteniveau og adgangskontrol på dokumentniveau. Ret til at søge i en tjeneste er ikke automatisk ret til alle dokumenter. [1] Den præcise opsætning og tilgængelige funktioner afhænger af den valgte implementering.

Beskyt vejen fra pull request til deployment

GitHubs vejledning anbefaler minimale workflow-rettigheder og advarer mod ikke-betroet input og kode i privilegerede workflows. Den beskriver også OIDC til cloud-autentifikation, hvor det understøttes. [2] Undersøg både pipeline og cloudens tillidspolitik; en mekanisme validerer ikke sin egen konfiguration.

Giv afhængighedsopdateringer, fund af hemmeligheder og buildfejl en ansvarlig. Fastlås versioner efter projektets opdateringspolitik, undersøg pakkernes oprindelse og gennemgå nye installationsscripts. Lad ikke et genereret workflow få brede rettigheder alene for at få en fejlet build til at lykkes.

Tre grænser, der kræver dokumentation

GrænseDokumentation
Bruger- og kundeadgangParrede tilladte og afviste API-test, også direkte forespørgsler.
Build-identitetWorkflow-rettigheder og cloudens tillidsbetingelser gennemgået samlet.
GenopretningAftalt tilbageførsel og ansvar for åbne fund.

Efterlad dokumentation til næste udvikler

Vores foreslåede overdragelse omfatter gennemgået commit, testresultater, ændrede afhængigheder, kendte begrænsninger og tilbageførsel. Noter begrundelse og udløb for accepterede undtagelser. Et scannerfund skal vurderes; at ignorere det er ikke en risikovurdering.

Efter release kontrolleres både den tilsigtede funktion og de fejlforløb, der betyder noget for kunderne. Afklar, hvem der reagerer på alarmer, og om den tidligere version kan gendannes uden tab af nødvendige data. Nye privilegerede integrationer, datastrømme og større afhængighedsændringer bør udløse en ny gennemgang.

Praktisk tjekliste før release

  1. En navngiven udvikler kan forklare følsomme kode- og infrastrukturændringer.
  2. Autentifikation og autorisation kontrolleres på serveren.
  3. Afhængigheder, installationsscripts og hemmeligheder er gennemgået.
  4. Ikke-betroede pull requests kan ikke overtage deploy-beføjelser.
  5. Test dækker afvisninger, ikke kun vellykkede demonstrationer.
  6. Leverancen har en ansvarlig, kendte begrænsninger og en genopretningsplan.

Spørgsmål fra købere

Kan en scanner erstatte manuel gennemgang?

En scanner finder bestemte problemtyper inden for sin dækning. Den kan ikke alene afgøre, om applikationen håndhæver jeres forretningsrettigheder, eller om en undtagelse er acceptabel.

Bør vi forbyde AI-kodeværktøjer?

Et forbud er et politikvalg, ikke en erstatning for leverancekontroller. Definer godkendte værktøjer og dataanvendelse, og kræv ansvarlig gennemgang uanset kodens oprindelse.

Prototypen virker. Er leveranceprocessen klar?

Vi kan gennemgå den aftalte vej fra repository til release og gøre sikkerhedskontroller gentagelige.

Se sikre leverancepipelines

Læs videre

Kilder og redaktionel metode

  1. Microsoft: Document-level access control in Azure AI Search
  2. GitHub: Secure use reference

Redaktionel vejledning fra SundAI, udarbejdet med AI-assistance. Kildebaserede udsagn har henvisninger; arbejdsark og scenarier er vores forslag til planlægning, ikke dokumenterede kunderesultater. Artiklen er ikke en certificering eller juridisk vurdering. Kilder kontrolleret 16. oktober 2026.