IaC-skanning

IaC-skanning er en egen sjekk, fremforge/iac-scan, med egne innstillinger og en egen fane for funn. På hver pull request, og ved hver push til standardbranchen eller en beskyttet release-branch, kjører fremforge trivy config over repositoryet med alle Trivys innebygde sjekker for feilkonfigurasjon:

• Dockerfiler og Containerfiler
• Docker Compose-filer
• Kubernetes-manifester
• Helm-charts
• Terraform og OpenTofu, både .tf- og .tofu-filer, der også eksterne moduler sjekkes: moduler fra organisasjonen din på frem.sh og fra fremforges speil, og registermoduler og kilder på github.com eller gitlab.com med en tag eller en commit gjennom modulbufferen. Andre eksterne kilder hentes ikke, og listes som det
• AWS CloudFormation-maler, YAML og JSON
• Azure Resource Manager-maler (ARM), JSON
• Bicep-filer, kompilert til ARM først; se Bicep
• Ansible-playbooks og -tasks, for skyressursene modulene deres oppretter (for eksempel amazon.aws.s3_bucket); ikke alle moduler dekkes

Hvert av disse ble bevist 19. oktober 2026 med en pull request som la til en kjent feilkonfigurasjon (den feilet sjekken), og en med den sikre versjonen (den besto).

Fram til 17. oktober 2026 kjørte disse sjekkene inne i image-skanningen, og funnene var image-funn. Image-sjekken, fremforge/image-scan, har dem ikke lenger.

Pull request-sjekken

fremforge/iac-scan feiler når pull requesten legger til en feilkonfigurasjon på eller over terskelen din. En feilkonfigurasjon som branchen den merges inn i allerede har, blokkerer den ikke: sjekken sammenligner med den siste skanningen av den branchen, standardbranchen eller en beskyttet release-branch. Et funn er det samme funnet når det er samme sjekk i samme fil; en ny forekomst av en sjekk i en fil er ny.

Når det ikke finnes noen skanning av den branchen ennå, blokkerer alle funn på eller over terskelen, og en skanning av branchen bestilles, slik at neste kjøring av sjekken blir sammenlignet.

Statusen sier hva den fant, for eksempel 1 new high/critical misconfiguration(s); merge blocked; 2 already on main, og lenker til Sikkerhet › Funn › IaC.

Når den er en påkrevd sjekk

fremforge/iac-scan rapporterer på hver pull request. Om en feil blokkerer merge, avhenger av om den er en påkrevd sjekk i branchbeskyttelsen i organisasjonen din:

• Organisasjoner opprettet 19. oktober 2026 eller senere har den som påkrevd sjekk fra sitt første repository.
• Eldre organisasjoner får den organisasjon for organisasjon, slik at ingen pull request som ble åpnet før sjekken fantes, venter på den. Fram til da viser den resultatet uten å blokkere merge på egen hånd.
• Modus Off fjerner den fra de påkrevde sjekkene; Logg beholder den som påkrevd, men feiler aldri.

Sikkerhet › Policyer › Skannere › IaC sier hva som gjelder for organisasjonen din: A required check in this organisation eller Not yet a required check in this organisation. Du kan selv legge den til i de påkrevde sjekkene når som helst; se Branchbeskyttelse.

Innstillinger

Under Sikkerhet › Policyer › Skannere › IaC:

De samme innstillingene er oppføringen iac_scan i organisasjonens skannepolicy, så du kan sette dem gjennom API-et og per repository:

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

En verdi per repository går foran organisasjonens:

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

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

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

Eksterne Terraform-moduler

Sjekken leser modulene konfigurasjonen din kaller, slik at en feilkonfigurasjon inne i en modul også blir funnet:

• Gjennom modulbufferen. En registermodul (terraform-aws-modules/vpc/aws, med eller uten version) og en kilde på github.com eller gitlab.com med en tag eller en commit leses gjennom avhengighetsproxyens modulbuffer: den nyeste versjonen som passer version-begrensningen din, låst ved første henting. Bare modulens .tf- og .tf.json-filer, og de lokale modulene de kaller, sjekkes; eksemplene og testene sjekkes ikke. Repositoryet ditt endres aldri: skanneren arbeider på en privat kopi.

• Fra frem.sh. Moduler i din egen organisasjon, og i fremforges speil av offentlige repositoryer, leses fra frem.sh.

• Fra din egen Git-vert, med din legitimasjon. En modul på en annen Git-vert over https (git::https://git.example.com/infra/modules.git?ref=v1.2.0 eller https://git.example.com/infra/modules.git) leses når organisasjonen din har en skrivebeskyttet legitimasjon av typen kind: git for akkurat den verten. En eier lagrer den under Sikkerhet › Tilgang › Registerlegitimasjon ved å velge Git-vert for moduler, eller gjennom API-et for registerlegitimasjon; funksjonen er av til en eier slår den på. Skanningen henter modulen gjennom avhengighetsproxyen, som legger til legitimasjonen din:

  • bare lesing: en git fetch, aldri en push;
  • legitimasjonen din sendes til den verten og ingen andre steder, og en omdirigering avvises;
  • ingenting bufres, så når du sletter legitimasjonen, ligger det ingen kopi igjen.

  En vert du ikke har legitimasjon for, hentes ikke, som før.

• Alt annet hentes ikke. En annen vert uten legitimasjon, en kilde på github.com eller gitlab.com uten tag (en branch), en arkiv-URL eller en SSH-kilde hentes aldri av skanneren. Den listes under Ikke sjekket på Sikkerhet › Funn › IaC, med kilden, og statusen til sjekken sier hvor mange moduler som ikke ble hentet; ressursene modulen definerer, sjekkes ikke.

Funn inne i en modul listes for seg, under In modules, gruppert per modul med versjonen skanningen leste og hvor den kalles fra. De blokkerer aldri en pull request, har ingen frist for utbedring og sender ingen varsler, fordi rettingen ligger i kallet ditt (en inndata, eller en modulversjon som retter det), ikke i filene dine. En avvisning beholdes på tvers av modulversjoner: den er knyttet til modulen, filen i den og sjekken, ikke versjonen.

Bicep

Trivy har ingen Bicep-sjekker, men sjekker ARM. Derfor kompilerer fremforge hver .bicep-fil i repositoryet til ARM med Bicep CLI og sjekker resultatet med de samme sjekkene, terskelen og avvisningene som resten av repositoryet. Et funn vises på .bicep-filen, på linjen med den flaggede egenskapen der den kan finnes, ellers på ressursdeklarasjonen, og sier at linjen er kartlagt fra den kompilerte ARM-malen.

• Frakoblet. Bicep kjører uten nettverkstilgang og uten å gjenopprette moduler. En modul fra et register (br:) eller en template spec (ts:) kan ikke hentes, så en fil som bruker en slik, kompileres ikke og listes som det. Lokale moduler (module x './y.bicep') fungerer.
• Hver fil for seg. Hver .bicep-fil, moduler inkludert, kompileres og sjekkes for seg selv, så en ressurs i en modul sjekkes i modulens fil.
• bicepconfig.json leses ikke. Modulaliaser, utvidelser, eksperimentelle funksjoner og analysatorinnstillinger i den har ingen virkning på skanningen. En fil som trenger en eksperimentell funksjon for å kompilere, listes som ikke kompilert.
• Aldri en stille godkjenning. En fil som ikke kunne kompileres (en feil, en registermodul, mer enn 60 sekunder, eller over grensen på 200 filer eller 2 MiB per repository), blokkerer ikke merge, fordi det ikke er en feilkonfigurasjon, men statusen til sjekken sier hvor mange som ikke ble sjekket, og Sikkerhet › Funn › IaC lister dem under Ikke sjekket med årsaken.

Dine egne sjekker

En organisasjon kan legge til egne sjekker, skrevet i Rego som egendefinerte Trivy-sjekker. fremforge/iac-scan kjører dem sammen med de innebygde sjekkene på hvert repository i organisasjonen, med samme modus og terskel, og bare det en pull request legger til, blokkerer den.

Legg dem til under Sikkerhet › Policyer › IaC-sjekker eller gjennom API-et (nedenfor). En sjekk må:

• ligge i en pakke under custom., for eksempel package custom.acme.no_root;
• ha en # METADATA-blokk med title, custom.id (funnene vises som custom/<id>) og custom.severity (LOW, MEDIUM, HIGH eller CRITICAL); custom.input.selector angir filtypene den leser, som i Trivy;
• bare lese den skannede filen (input): ingen import data og ingen referanse til data;
• ikke bruke innebygde funksjoner for nettverk eller kjøretid: http.send, net.lookup_ip_addr, opa.runtime, rego.parse_module, trace, numbers.range og numbers.range_step avvises.

Høyst 25 sjekker per organisasjon, 32 KiB hver. Konsollen tilbyr et ferdig eksempel å starte fra.

En lagret sjekk står som Kontrolleres til skanneren har verifisert den med OPA, i det samme avgrensede miljøet som kjører pull request-skanningene dine, og deretter som Aktiv eller Avvist, med årsaken. Bare en aktiv sjekk som ikke er slått av, kjører. Når du redigerer kildekoden til en sjekk, verifiseres den på nytt; fram til da gjelder ikke den forrige vurderingen lenger, og sjekken kjører ikke. Du kan slå av en sjekk uten å slette den.

Funn fra sjekkene dine vises sammen med de innebygde, i pull request-sjekken og under Sikkerhet › Funn › IaC, merket Tilpasset med navnet på sjekken.

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 hver sjekk en fremforge_iac_custom_check (provider 0.4.0 og senere): name, source og enabled, med status, status_reason, check_id, title og severity lest tilbake fra skannerens vurdering.

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

Listing krever findings:read eller policy:read; endringer krever policy:write. En ny eller endret sjekk kommer tilbake med status pending; skannerens vurdering setter den til valid eller invalid, med status_reason. En sjekk API-et kan avvise før skanneren ser den (for stor, ingen custom.-pakke, ingen METADATA), besvares med 400 og årsaken; sjekk nummer 26 besvares med 409. Hver endring står i revisjonsloggen.

Funn

Sikkerhet › Funn › IaC lister de åpne feilkonfigurasjonene: sjekken (for eksempel KSV-0014), tittelen, repositoryet og filen, med alvorlighetsgrad og frist for utbedring. Filtrer på alvorlighetsgrad, åpne filen ved den skannede commiten, og avvis ett eller flere med en begrunnelse, som på de andre funnfanene. En avvisning beholdes for samme sjekk i samme fil på tvers av skanninger.

For noen få sjekker der én egenskap har én enkelt sikker verdi, som S3 public access block og Azure Storage sine innstillinger for bare HTTPS og minste TLS-versjon, åpner Open fix PR i kolonnen Fix en pull request som setter den, uten AI. Se Regelbaserte rettelser.

De vises også på Sikkerhet › Funn › Alle som typen IaC, som en egen rad på sikkerhetsoversikten, i samsvarsrapporten og gjennom findings-API-et (type=iac).

Benchmarks og NIS2

Samsvarsrapporten grupperer de åpne IaC-funnene etter benchmark-kontrollene sjekkene tester (CIS Docker, CIS Kubernetes, RKE2 og EKS, NSAs veiledning for herding av Kubernetes, Pod Security Standards, CIS AWS), ut fra compliance-koblingene Trivy publiserer, og etter område i NIS2 artikkel 21(2). NIS2-grupperingen er fremforges egen; den er ikke en offisiell kobling og sier ingenting om etterlevelse av noe tiltak.

For å ignorere en sjekk i et repository bruker du en Trivy-ignorefil; se Trivy-ignorefiler.

Ikke dekket

Disse sjekkene finner feilkonfigurasjoner. De matcher ikke versjoner mot sårbarhetsvarsler:

• Terraform-moduler sjekkes ikke for sårbare versjoner. Terraform- og OpenTofu-providere gjør det, av avhengighetsskanningen; se Terraform- og OpenTofu-providere.
• Helm-charts sjekkes ikke for sårbare chartversjoner. Containerimagene et chart ruller ut, sjekkes av image-skanningen; se Imager som Helm-chartene dine ruller ut.
• Pulumi og AWS CDK skannes ikke: ressursene deres finnes først når programmet ditt kjører, og fremforge kjører ikke koden din.
• Dekningen innenfor et format er Trivys. For eksempel evalueres ikke regler for nettverkssikkerhetsgrupper i ARM-maler (og dermed i Bicep), og en Ansible-task sjekkes bare når Trivy kjenner modulen: i vårt bevis ble en amazon.aws.s3_bucket-task sjekket og en amazon.aws.ec2_security_group-task ikke.
• Versjoner av CI-actions sjekkes, av avhengighetsskanningen og ikke av denne sjekken: en action med en kjent sårbarhet er et avhengighetsfunn; se Versjoner av CI-actions. Om de er låst til en commit, sjekkes separat; se Låsing i workflower.

Se Støttede økosystemer.