IaC-scanning

IaC-scanning er et selvstændigt tjek, fremforge/iac-scan, med egne indstillinger og sin egen fane med fund. På hver pull request og ved hvert push til standardbranchen eller en beskyttet release-branch kører fremforge trivy config over repositoriet med alle Trivys indbyggede tjek for fejlkonfigurationer:

• Dockerfiles og Containerfiles
• Docker Compose-filer
• Kubernetes-manifester
• Helm-charts
• Terraform og OpenTofu, både .tf- og .tofu-filer, hvor fjernmodulerne også tjekkes: moduler fra din organisation på frem.sh og fra fremforges mirrors samt registry-moduler og kilder på github.com eller gitlab.com ved et tag eller et commit gennem modul-cachen. Andre fjernkilder hentes ikke og vises som sådan
• AWS CloudFormation-skabeloner, YAML og JSON
• Azure Resource Manager-skabeloner (ARM), JSON
• Bicep-filer, som først kompileres til ARM; se Bicep
• Ansible-playbooks og -tasks, for de cloudressourcer, deres moduler opretter (for eksempel amazon.aws.s3_bucket); ikke alle moduler er dækket

Hver af disse blev bevist den 19. oktober 2026 med en pull request, der tilføjede en kendt fejlkonfiguration (den fik tjekket til at fejle), og en med den sikre version (den bestod).

Indtil 17. oktober 2026 kørte disse tjek som en del af image-scanningen, og deres fund var image-fund. Image-tjekket, fremforge/image-scan, indeholder dem ikke længere.

Pull request-tjekket

fremforge/iac-scan fejler, når pull requesten tilføjer en fejlkonfiguration på eller over din tærskel. En fejlkonfiguration, som den branch, der merges ind i, allerede har, blokerer ikke: tjekket sammenligner med den seneste scanning af den branch, standardbranchen eller en beskyttet release-branch. Et fund er det samme fund, når det er det samme tjek i den samme fil; en ekstra forekomst af et tjek i en fil er ny.

Findes der endnu ingen scanning af den branch, blokerer alle fund på eller over tærsklen, og der bestilles en scanning af branchen, så næste kørsel af tjekket bliver sammenlignet.

Statussen siger, hvad den fandt, for eksempel 1 new high/critical misconfiguration(s); merge blocked; 2 already on main, og linker til Sikkerhed › Fund › IaC.

Når det er et påkrævet tjek

fremforge/iac-scan rapporterer på hver pull request. Om en fejl blokerer merge, afhænger af, om det er et påkrævet tjek i branch-beskyttelsen i din organisation:

• Organisationer oprettet den 19. oktober 2026 eller senere har det som påkrævet tjek fra deres første repository.
• Ældre organisationer får det organisation for organisation, så ingen pull request, der blev åbnet før tjekket fandtes, venter på det. Indtil da viser det resultatet uden selv at blokere merge.
• Tilstanden Fra fjerner det fra de påkrævede tjek; Audit beholder det som påkrævet, men det fejler aldrig.

Sikkerhed › Politikker › Scannere › IaC viser, hvad der gælder for din organisation: Et påkrævet tjek i denne organisation eller Endnu ikke et påkrævet tjek i denne organisation. Du kan selv til enhver tid tilføje det til dine påkrævede tjek; se Branch-beskyttelse.

Indstillinger

Under Sikkerhed › Politikker › Scannere › IaC:

De samme indstillinger er iac_scan-posten i organisationens scanningspolitik, så du kan sætte dem via API’et og pr. repository:

PUT /_app/api/v1/orgs/{org}/policy
{ "scan_policy": { "iac_scan": { "mode": "enforce", "block_severity": "critical" } } }

En værdi for et repository går forud for organisationens:

PUT /_app/api/v1/orgs/{org}/repos/{repo}/policy
{ "scan_policy": { "iac_scan": { "mode": "audit" } } }

Med Terraform eller OpenTofu bruger du fremforge_scan_policy med scanner = "iac_scan" (provider 0.4.0 og nyere):

resource "fremforge_scan_policy" "iac" {
  org            = "acme"
  scanner        = "iac_scan"
  mode           = "enforce"
  block_severity = "high"
}

Terraform-fjernmoduler

Tjekket læser de moduler, din konfiguration kalder, så en fejlkonfiguration inde i et modul også bliver fundet:

• Gennem modul-cachen. Et registry-modul (terraform-aws-modules/vpc/aws, med eller uden version) og en kilde på github.com eller gitlab.com ved et tag eller et commit læses gennem afhængighedsproxyens modul-cache: den nyeste version, der matcher din version-begrænsning, fastlåst ved første hentning. Kun modulets .tf- og .tf.json-filer og de lokale moduler, de kalder, tjekkes; dets eksempler og tests gør ikke. Dit repository ændres aldrig: scanneren arbejder på en privat kopi.

• Fra frem.sh. Moduler i din egen organisation og i fremforges mirrors af offentlige repositorier læses fra frem.sh.

• Fra din egen git-vært med din legitimation. Et modul på en anden git-vært over https (git::https://git.example.com/infra/modules.git?ref=v1.2.0 eller https://git.example.com/infra/modules.git) læses, når din organisation har en skrivebeskyttet kind: git-legitimation til netop den vært. En ejer gemmer den under Sikkerhed › Adgang › Registerlegitimationer ved at vælge Git-modulvært eller via API’et til registerlegitimationer; funktionen er slået fra, indtil en ejer slår den til. Scanningen henter modulet gennem afhængighedsproxyen, som tilføjer din legitimation:

  • kun læsning: en git fetch, aldrig et push;
  • din legitimation sendes til den vært og ingen andre steder, og en omdirigering afvises;
  • intet caches, så når legitimationen slettes, efterlades ingen kopi.

  En vært, du ikke har en legitimation til, hentes ikke, som hidtil.

• Alt andet hentes ikke. En anden vært uden legitimation, en kilde på github.com eller gitlab.com uden et tag (en branch), en arkiv-URL eller en SSH-kilde hentes aldrig af scanneren. Den vises under Ikke tjekket på Sikkerhed › Fund › IaC med sin kilde, og tjekkets status siger, hvor mange moduler der ikke blev hentet; de ressourcer, modulet definerer, tjekkes ikke.

Fund inde i et modul vises for sig under I moduler, grupperet efter modul med den version, scanningen læste, og hvor modulet kaldes fra. De blokerer aldrig en pull request, har ingen frist for rettelse og sender ingen alarm, fordi rettelsen ligger i dit kald (et input eller en modulversion, der retter det), ikke i dine filer. En afvisning bevares på tværs af modulversioner: den er knyttet til modulet, filen i det og tjekket, ikke versionen.

Bicep

Trivy har ingen Bicep-tjek, men tjekker ARM. Derfor kompilerer fremforge hver .bicep-fil i repositoriet til ARM med Bicep CLI og tjekker resultatet med de samme tjek, den samme tærskel og de samme afvisninger som resten af repositoriet. Et fund vises på .bicep-filen, på linjen med den markerede egenskab, hvis den kan findes, ellers på ressourceerklæringen, og angiver, at linjen er afledt af den kompilerede ARM.

• Offline. Bicep kører uden netværksadgang og uden at gendanne moduler. Et modul fra et registry (br:) eller en template spec (ts:) kan ikke hentes, så en fil, der bruger et sådant, kompileres ikke og vises som sådan. Lokale moduler (module x './y.bicep') virker.
• Hver fil for sig. Hver .bicep-fil, også moduler, kompileres og tjekkes for sig, så en ressource i et modul tjekkes i modulets fil.
• Din bicepconfig.json læses ikke. Modulaliasser, extensions, eksperimentelle funktioner og analyzer-indstillinger i den har ingen effekt på scanningen. En fil, der kræver en eksperimentel funktion for at kompilere, vises som ikke kompileret.
• Aldrig et stille bestået. En fil, der ikke kunne kompileres (en fejl, et registry-modul, mere end 60 sekunder eller ud over grænsen på 200 filer eller 2 MiB pr. repository), blokerer ikke merge, fordi det ikke er en fejlkonfiguration, men tjekkets status siger, hvor mange der ikke blev tjekket, og Sikkerhed › Fund › IaC viser dem under Ikke tjekket med årsagen.

Dine egne tjek

En organisation kan tilføje sine egne tjek, skrevet i Rego som Trivy custom checks. fremforge/iac-scan kører dem sammen med de indbyggede tjek på hvert repository i organisationen med samme tilstand og tærskel, og kun det, en pull request tilføjer, blokerer den.

Tilføj dem under Sikkerhed › Politikker › IaC-tjek eller via API’et (nedenfor). Et tjek skal:

• ligge i en pakke under custom., for eksempel package custom.acme.no_root;
• have en # METADATA-blok med en title, et custom.id (dets fund vises som custom/<id>) og en custom.severity (LOW, MEDIUM, HIGH eller CRITICAL); custom.input.selector angiver de filtyper, det læser, som i Trivy;
• kun læse den scannede fil (input): ingen import data og ingen reference til data;
• ikke bruge netværks- eller runtime-built-ins: http.send, net.lookup_ip_addr, opa.runtime, rego.parse_module, trace, numbers.range og numbers.range_step afvises.

Højst 25 tjek pr. organisation, hver på højst 32 KiB. Konsollen tilbyder et gennemarbejdet eksempel at tage udgangspunkt i.

Et gemt tjek står som Kontrolleres, indtil scanneren har verificeret det med OPA i det samme afskærmede miljø, som kører dine pull request-scanninger, og derefter som Aktiv eller Afvist med årsagen. Kun et aktivt tjek, der ikke er slået fra, kører. Redigerer du et tjeks kilde, verificeres det igen; indtil da gælder den tidligere dom ikke længere, og tjekket kører ikke. Du kan slå et tjek fra uden at slette det.

Fund fra dine tjek vises sammen med de indbyggede i pull request-tjekket og under Sikkerhed › Fund › IaC, markeret Tilpasset med tjekkets navn.

API

GET    /_app/api/v1/orgs/{org}/code-security/iac/policies
POST   /_app/api/v1/orgs/{org}/code-security/iac/policies          { "name": "No root", "source": "<rego>", "enabled": true }
PUT    /_app/api/v1/orgs/{org}/code-security/iac/policies/{id}
DELETE /_app/api/v1/orgs/{org}/code-security/iac/policies/{id}

Med Terraform eller OpenTofu er hvert tjek en fremforge_iac_custom_check (provider 0.4.0 og nyere): name, source og enabled, hvor status, status_reason, check_id, title og severity læses tilbage fra scannerens dom.

resource "fremforge_iac_custom_check" "no_root" {
  org    = "acme"
  name   = "No root"
  source = file("checks/no_root.rego")
}

At vise tjek kræver findings:read eller policy:read; ændringer kræver policy:write. Et nyt eller ændret tjek kommer tilbage med status pending; scannerens dom sætter det til valid eller invalid med status_reason. Et tjek, som API’et kan afvise, før scanneren ser det (for stort, ingen custom.-pakke, ingen METADATA), besvares med 400 og årsagen; det 26. tjek besvares med 409. Alle ændringer står i revisionsloggen.

Fund

Sikkerhed › Fund › IaC viser de åbne fejlkonfigurationer: tjekket (for eksempel KSV-0014), dets titel, repositoriet og filen med alvorlighed og frist for rettelse. Filtrér efter alvorlighed, åbn filen ved det scannede commit, og afvis ét eller flere fund med en begrundelse, som på de andre faner med fund. En afvisning bevares for det samme tjek i den samme fil på tværs af scanninger.

For nogle få tjek, hvor én egenskab har en enkelt sikker værdi, såsom S3’s blokering af offentlig adgang og Azure Storages indstillinger for kun HTTPS og minimum-TLS, åbner Åbn rettelses-PR i kolonnen Rettelse en pull request, der sætter den, uden AI. Se Regelbaserede rettelser.

De vises også på Sikkerhed › Fund › Alle som typen IaC, som deres egen række på sikkerhedsoversigten, i compliance-rapporten og gennem findings-API’et (type=iac).

Benchmarks og NIS2

Compliance-rapporten grupperer de åbne IaC-fund efter de benchmark-kontroller, deres tjek tester (CIS Docker, CIS Kubernetes, RKE2 og EKS, NSA’s vejledning i hærdning af Kubernetes, Pod Security Standards, CIS AWS), ud fra de compliance-mappinger, Trivy udgiver, og efter område i NIS2 artikel 21, stk. 2. NIS2-grupperingen er fremforges egen; den er ikke en officiel mapping og udtaler sig ikke om overholdelse af nogen foranstaltning.

For at ignorere et tjek i et repository bruger du en Trivy-ignorefil; se Trivy-ignorefiler.

Ikke dækket

Disse tjek finder fejlkonfigurationer. De matcher ikke versioner mod sårbarhedsadvisories:

• Terraform-moduler tjekkes ikke for sårbare versioner. Terraform- og OpenTofu-providers gør, af afhængighedsscanningen; se Terraform- og OpenTofu-providers.
• Helm-charts tjekkes ikke for sårbare chart-versioner. De container-images, et chart udruller, gør, af image-scanningen; se Images, dine Helm-charts udruller.
• Pulumi og AWS CDK scannes ikke: deres ressourcer findes først, når dit program kører, og fremforge kører ikke din kode.
• Dækningen inden for et format er Trivys. For eksempel evalueres regler for netværkssikkerhedsgrupper i ARM-skabeloner (og dermed i Bicep) ikke, og en Ansible-task tjekkes kun, når Trivy kender dens modul: i vores bevis blev en amazon.aws.s3_bucket-task tjekket, mens en amazon.aws.ec2_security_group-task ikke blev.
• Versioner af CI-actions tjekkes, af afhængighedsscanningen i stedet for dette tjek: en action med en kendt sårbarhed er et afhængighedsfund; se Versioner af CI-actions. Om de er fastlåst til et commit, tjekkes separat; se Fastlåsning i workflows.

Se Understøttede økosystemer.