IaC-skanning

IaC-skanning är en egen kontroll, fremforge/iac-scan, med egna inställningar och en egen flik för fynd. På varje pull request, och vid varje push till standardbranchen eller en skyddad release-branch, kör fremforge trivy config över repot med alla Trivys inbyggda kontroller av felkonfiguration:

• Dockerfiles och Containerfiles
• Docker Compose-filer
• Kubernetes-manifest
• Helm-charts
• Terraform och OpenTofu, både .tf- och .tofu-filer, där även deras fjärrmoduler kontrolleras: moduler från din organisation på frem.sh och från fremforges speglar, samt registrymoduler och källor på github.com eller gitlab.com vid en tagg eller en commit via modulcachen. Andra fjärrkällor hämtas inte, och listas som sådana
• AWS CloudFormation-mallar, YAML och JSON
• Azure Resource Manager-mallar (ARM), JSON
• Bicep-filer, som först kompileras till ARM; se Bicep
• Ansible-playbooks och tasks, för de molnresurser som deras moduler skapar (till exempel amazon.aws.s3_bucket); alla moduler täcks inte

Var och en av dessa bevisades den 19 oktober 2026 med en pull request som lägger till en känd felkonfiguration (den fällde kontrollen) och en med den säkra versionen (den gick igenom).

Fram till 17 oktober 2026 kördes de här kontrollerna i image-skanningen och deras fynd var image-fynd. Image-kontrollen, fremforge/image-scan, innehåller dem inte längre.

Pull request-kontrollen

fremforge/iac-scan fallerar när pull requesten lägger till en felkonfiguration på eller över din tröskel. En felkonfiguration som den branch den mergas in i redan har blockerar den inte: kontrollen jämför med den senaste skanningen av den branchen, standardbranchen eller en skyddad release-branch. Ett fynd är samma fynd när det är samma kontroll i samma fil; en andra förekomst av en kontroll i en fil är ny.

När det ännu inte finns någon skanning av den branchen blockerar varje fynd på eller över tröskeln, och en skanning av branchen begärs, så att nästa körning av kontrollen jämförs.

Statusen anger vad den hittade, till exempel 1 new high/critical misconfiguration(s); merge blocked; 2 already on main, och länkar till Säkerhet › Fynd › IaC.

När den är en obligatorisk kontroll

fremforge/iac-scan rapporterar på varje pull request. Om ett fel blockerar mergen beror på om den är en obligatorisk branch-skyddskontroll i din organisation:

• Organisationer som skapats den 19 oktober 2026 eller senare har den som obligatorisk kontroll från sitt första repo.
• Äldre organisationer får den organisation för organisation, så att ingen pull request som öppnades innan kontrollen fanns väntar på den. Fram till dess visar den resultatet utan att blockera mergen på egen hand.
• Läget Av tar bort den från de obligatoriska kontrollerna; Granska behåller den som obligatorisk men fallerar aldrig.

Säkerhet › Policyer › Skannrar › IaC visar vilket som gäller för din organisation: En obligatorisk kontroll i den här organisationen, eller Ännu ingen obligatorisk kontroll i den här organisationen. Du kan själv lägga till den bland dina obligatoriska kontroller när som helst; se Branch-skydd.

Inställningar

Under Säkerhet › Policyer › Skannrar › IaC:

Samma inställningar är posten iac_scan i organisationens skanningspolicy, så du kan ställa in dem via API:t och per repo:

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

Ett värde per repo har företräde framför organisationens:

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

Med Terraform eller OpenTofu använder du fremforge_scan_policy med scanner = "iac_scan" (provider 0.4.0 och senare):

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

Terraform-fjärrmoduler

Kontrollen läser de moduler som din konfiguration anropar, så att även en felkonfiguration inuti en modul hittas:

• Via modulcachen. En registrymodul (terraform-aws-modules/vpc/aws, med eller utan version) och en källa på github.com eller gitlab.com vid en tagg eller en commit läses via beroendeproxyns modulcache: den senaste versionen som matchar ditt version-villkor, låst vid första hämtningen. Bara modulens .tf- och .tf.json-filer, och de lokala moduler de anropar, kontrolleras; dess exempel och tester gör det inte. Ditt repo ändras aldrig: skannern arbetar på en privat kopia.

• Från frem.sh. Moduler i din egen organisation, och i fremforges speglar av publika repon, läses från frem.sh.

• Från din egen git-värd, med din inloggningsuppgift. En modul på en annan git-värd över 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 skrivskyddad inloggningsuppgift av typen kind: git för exakt den värden. En ägare sparar den under Säkerhet › Åtkomst › Registerinloggningar och väljer Git-modulvärd, eller via API:t för registerinloggningar; funktionen är avstängd tills en ägare slår på den. Skanningen hämtar modulen via beroendeproxyn, som lägger till din inloggningsuppgift:

  • endast läsning: en git fetch, aldrig en push;
  • din inloggningsuppgift går till den värden och ingen annanstans, och en omdirigering nekas;
  • ingenting cachas, så att ta bort inloggningsuppgiften lämnar ingen kopia kvar.

  En värd som du inte har någon inloggningsuppgift för hämtas inte, som tidigare.

• Allt annat hämtas inte. En annan värd utan inloggningsuppgift, en källa på github.com eller gitlab.com utan tagg (en branch), en arkiv-URL eller en SSH-källa hämtas aldrig av skannern. Den listas under Inte kontrollerat på Säkerhet › Fynd › IaC, med sin källa, och kontrollens status anger hur många moduler som inte hämtades; resurserna den definierar kontrolleras inte.

Fynd inuti en modul listas för sig, under I moduler, grupperade per modul med den version som skanningen läste och var den anropas från. De blockerar aldrig en pull request, har inget åtgärdsdatum och skickar inget larm, eftersom fixen ligger i ditt anrop (en indata, eller en modulversion som åtgärdar det), inte i dina filer. Ett avfärdande behålls mellan modulversioner: det är kopplat till modulen, filen i den och kontrollen, inte till versionen.

Bicep

Trivy har inga Bicep-kontroller, men kontrollerar ARM. Därför kompilerar fremforge varje .bicep-fil i repot till ARM med Bicep CLI och kontrollerar resultatet med samma kontroller, tröskel och avfärdanden som resten av repot. Ett fynd visas på .bicep-filen, på raden för den flaggade egenskapen där den kan hittas, annars på resursdeklarationen, och anger att raden mappats från den kompilerade ARM-mallen.

• Offline. Bicep körs utan nätverksåtkomst och utan att återställa moduler. En modul från ett registry (br:) eller en template spec (ts:) kan inte hämtas, så en fil som använder en sådan kompileras inte och listas som sådan. Lokala moduler (module x './y.bicep') fungerar.
• Varje fil för sig. Varje .bicep-fil, moduler inräknade, kompileras och kontrolleras för sig, så en resurs i en modul kontrolleras i modulens fil.
• Din bicepconfig.json läses inte. Modulalias, tillägg, experimentella funktioner och analysinställningar i den påverkar inte skanningen. En fil som behöver en experimentell funktion för att kompilera listas som inte kompilerad.
• Aldrig ett tyst godkännande. En fil som inte kunde kompileras (ett fel, en registrymodul, mer än 60 sekunder, eller över gränsen på 200 filer eller 2 MiB per repo) blockerar inte mergen, eftersom det inte är en felkonfiguration, men kontrollens status anger hur många som inte kontrollerades, och Säkerhet › Fynd › IaC listar dem under Inte kontrollerat med orsaken.

Dina egna kontroller

En organisation kan lägga till egna kontroller, skrivna i Rego som anpassade Trivy-kontroller. fremforge/iac-scan kör dem tillsammans med de inbyggda kontrollerna på varje repo i organisationen, med samma läge och tröskel, och bara det som en pull request lägger till blockerar den.

Lägg till dem under Säkerhet › Policyer › IaC-kontroller, eller via API:t (nedan). En kontroll måste:

• ligga i ett paket under custom., till exempel package custom.acme.no_root;
• ha ett # METADATA-block med en title, ett custom.id (dess fynd visas som custom/<id>) och en custom.severity (LOW, MEDIUM, HIGH eller CRITICAL); custom.input.selector anger vilka filtyper den läser, som i Trivy;
• bara läsa den skannade filen (input): ingen import data och ingen referens till data;
• inte använda några inbyggda funktioner för nätverk eller körmiljö: http.send, net.lookup_ip_addr, opa.runtime, rego.parse_module, trace, numbers.range och numbers.range_step nekas.

Högst 25 kontroller per organisation, 32 KiB var. Konsolen erbjuder ett genomarbetat exempel att utgå från.

En sparad kontroll har statusen Granskas tills skannern har verifierat den med OPA, i samma avgränsade miljö som kör dina pull request-skanningar, och därefter Aktiv eller Avvisat, med orsaken. Bara en aktiv kontroll som inte är avstängd körs. Om du redigerar en kontrolls källkod verifieras den igen; fram till dess gäller det tidigare utlåtandet inte längre och den körs inte. Du kan stänga av en kontroll utan att ta bort den.

Fynd från dina kontroller visas tillsammans med de inbyggda, i pull request-kontrollen och under Säkerhet › Fynd › IaC, märkta Egen med kontrollens namn.

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 är varje kontroll en fremforge_iac_custom_check (provider 0.4.0 och senare): name, source och enabled, där status, status_reason, check_id, title och severity läses tillbaka från skannerns utlåtande.

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

Listning kräver findings:read eller policy:read; ändringar kräver policy:write. En ny eller ändrad kontroll kommer tillbaka med status pending; skannerns utlåtande sätter den till valid eller invalid, med status_reason. En kontroll som API:t kan neka innan skannern ser den (för stor, inget custom.-paket, ingen METADATA) besvaras med 400 och orsaken; den 26:e kontrollen besvaras med 409. Varje ändring finns i granskningsloggen.

Fynd

Säkerhet › Fynd › IaC listar de öppna felkonfigurationerna: kontrollen (till exempel KSV-0014), dess titel, repot och filen, med allvarlighetsgrad och åtgärdsdatum. Filtrera på allvarlighetsgrad, öppna filen vid den skannade commiten och avfärda ett eller flera med en motivering, som på de andra flikarna för fynd. Ett avfärdande behålls för samma kontroll i samma fil mellan skanningar.

För några kontroller där en egenskap har ett enda säkert värde, som S3 public access block och Azure storages inställningar för endast HTTPS och lägsta TLS-version, öppnar Öppna fix-PR i kolumnen Åtgärd en pull request som sätter det, utan AI. Se Regelbaserade fixar.

De visas också under Säkerhet › Fynd › Alla som typen IaC, i säkerhetsöversikten som en egen rad, i compliancerapporten och via Findings API (type=iac).

Benchmarks och NIS2

Compliancerapporten grupperar de öppna IaC-fynden efter de benchmark-kontroller som deras kontroller testar (CIS Docker, CIS Kubernetes, RKE2 och EKS, NSA:s guide för härdning av Kubernetes, Pod Security Standards, CIS AWS), utifrån de compliance-mappningar som Trivy publicerar, och efter område i NIS2 artikel 21.2. NIS2-grupperingen är fremforges egen; den är inte en officiell mappning och anger inte efterlevnad av någon åtgärd.

För att ignorera en kontroll i ett repo använder du en Trivy-ignore-fil; se Trivy-ignore-filer.

Omfattas inte

De här kontrollerna hittar felkonfigurationer. De matchar inte versioner mot säkerhetsmeddelanden om sårbarheter:

• Terraform-moduler kontrolleras inte för sårbara versioner. Terraform- och OpenTofu-providers gör det, genom beroendeskanningen; se Terraform- och OpenTofu-providers.
• Helm-charts kontrolleras inte för sårbara chart-versioner. De container-images som en chart driftsätter gör det, genom image-skanningen; se Images som dina Helm-charts driftsätter.
• Pulumi och AWS CDK skannas inte: deras resurser finns bara när ditt program körs, och fremforge kör inte din kod.
• Täckningen inom ett format är Trivys. Till exempel utvärderas inte regler för nätverkssäkerhetsgrupper i ARM-mallar (och därmed i Bicep), och en Ansible-task kontrolleras bara när Trivy känner till dess modul: i vårt bevis kontrollerades en amazon.aws.s3_bucket-task men inte en amazon.aws.ec2_security_group-task.
• Versioner av CI-actions kontrolleras, av beroendeskanningen snarare än av den här kontrollen: en action med en känd sårbarhet är ett beroendefynd; se Versioner av CI-actions. Om de är låsta till en commit kontrolleras separat; se Låsning av arbetsflöden.

Se Ekosystem som stöds.