IaC-Scanning

IaC-Scanning ist ein eigener Check, fremforge/iac-scan, mit eigenen Einstellungen und einem eigenen Befund-Tab. Bei jedem Pull Request und bei jedem Push auf den Standard-Branch oder einen geschützten Release-Branch führt fremforge trivy config über das Repository aus, mit allen eingebauten Fehlkonfigurations-Checks von Trivy:

• Dockerfiles und Containerfiles
• Docker-Compose-Dateien
• Kubernetes-Manifeste
• Helm-Charts
• Terraform und OpenTofu, .tf- wie .tofu-Dateien, wobei auch ihre Remote-Module geprüft werden: Module deiner Organisation auf frem.sh und aus den Mirrors von fremforge sowie Registry-Module und Quellen auf github.com oder gitlab.com an einem Tag oder Commit über den Modul-Cache. Jede andere Remote-Quelle wird nicht abgerufen und als solche aufgeführt
• AWS-CloudFormation-Templates, YAML und JSON
• Azure-Resource-Manager-Templates (ARM), JSON
• Bicep-Dateien, zuerst zu ARM kompiliert; siehe Bicep
• Ansible-Playbooks und -Tasks, für die Cloud-Ressourcen, die ihre Module anlegen (zum Beispiel amazon.aws.s3_bucket); nicht jedes Modul ist abgedeckt

Jeder dieser Punkte wurde am 19. Oktober 2026 mit einem Pull Request nachgewiesen, der eine bekannte Fehlkonfiguration hinzufügt (er ist am Check gescheitert), und mit einem, der die sichere Variante enthält (er hat bestanden).

Bis zum 17. Oktober 2026 liefen diese Checks innerhalb des Image-Scans, und ihre Befunde waren Image-Befunde. Der Image-Check, fremforge/image-scan, enthält sie nicht mehr.

Der Pull-Request-Check

fremforge/iac-scan scheitert, wenn der Pull Request eine Fehlkonfiguration auf oder über deinem Schwellenwert hinzufügt. Eine Fehlkonfiguration, die der Branch, in den er gemergt wird, bereits hat, blockiert ihn nicht: Der Check vergleicht mit dem neuesten Scan dieses Branches, dem Standard-Branch oder einem geschützten Release-Branch. Ein Befund ist derselbe Befund, wenn es derselbe Check in derselben Datei ist; ein zweites Vorkommen eines Checks in einer Datei ist neu.

Gibt es noch keinen Scan dieses Branches, blockiert jeder Befund auf oder über dem Schwellenwert, und ein Scan des Branches wird angefordert, sodass beim nächsten Lauf des Checks verglichen wird.

Der Status sagt, was er gefunden hat, zum Beispiel 1 new high/critical misconfiguration(s); merge blocked; 2 already on main, und verlinkt auf Sicherheit › Befunde › IaC.

Wann er ein erforderlicher Check ist

fremforge/iac-scan meldet sich bei jedem Pull Request. Ob ein Fehlschlag den Merge blockiert, hängt davon ab, ob er in deiner Organisation ein erforderlicher Branch-Schutz-Check ist:

• Organisationen, die am oder nach dem 19. Oktober 2026 angelegt wurden, haben ihn ab ihrem ersten Repository als erforderlichen Check.
• Ältere Organisationen bekommen ihn Organisation für Organisation, damit kein Pull Request, der vor der Einführung des Checks geöffnet wurde, auf ihn wartet. Bis dahin zeigt er das Ergebnis, ohne den Merge selbst zu blockieren.
• Modus Aus entfernt ihn aus den erforderlichen Checks; Audit lässt ihn erforderlich, aber er scheitert nie.

Sicherheit › Richtlinien › Scanner › IaC sagt, was für deine Organisation gilt: Eine erforderliche Prüfung in dieser Organisation oder Noch keine erforderliche Prüfung in dieser Organisation. Du kannst ihn jederzeit selbst zu deinen erforderlichen Checks hinzufügen; siehe Branch-Schutz.

Einstellungen

Unter Sicherheit › Richtlinien › Scanner › IaC:

Dieselben Einstellungen sind der Eintrag iac_scan der Scan-Richtlinie der Organisation, sodass du sie über die API und pro Repository setzen kannst:

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

Ein Wert pro Repository hat Vorrang vor dem der Organisation:

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

Mit Terraform oder OpenTofu verwendest du fremforge_scan_policy mit scanner = "iac_scan" (Provider 0.4.0 und neuer):

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

Remote-Terraform-Module

Der Check liest die Module, die deine Konfiguration aufruft, sodass auch eine Fehlkonfiguration innerhalb eines Moduls gefunden wird:

• Über den Modul-Cache. Ein Registry-Modul (terraform-aws-modules/vpc/aws, mit oder ohne version) und eine Quelle auf github.com oder gitlab.com an einem Tag oder Commit werden über den Modul-Cache des Dependency-Proxys gelesen: die neueste Version, die zu deiner version-Einschränkung passt, festgelegt beim ersten Abruf. Geprüft werden nur die .tf- und .tf.json-Dateien des Moduls und die lokalen Module, die sie aufrufen, nicht seine Beispiele und Tests. Dein Repository wird nie verändert: Der Scanner arbeitet auf einer privaten Kopie.

• Von frem.sh. Module in deiner eigenen Organisation und in den Mirrors öffentlicher Repositorys von fremforge werden von frem.sh gelesen.

• Von deinem eigenen Git-Host, mit deinen Zugangsdaten. Ein Modul auf einem anderen Git-Host über https (git::https://git.example.com/infra/modules.git?ref=v1.2.0 oder https://git.example.com/infra/modules.git) wird gelesen, wenn deine Organisation schreibgeschützte Zugangsdaten vom Typ kind: git für genau diesen Host hinterlegt hat. Ein Owner speichert sie unter Sicherheit › Zugriff › Registry-Zugangsdaten mit der Auswahl Git-Modul-Host oder über die API für Registry-Zugangsdaten; die Funktion ist aus, bis ein Owner sie einschaltet. Der Scan ruft das Modul über den Dependency-Proxy ab, der deine Zugangsdaten hinzufügt:

  • nur lesend: ein Git-Fetch, nie ein Push;
  • deine Zugangsdaten gehen an diesen Host und nirgendwo sonst hin, und eine Weiterleitung wird abgewiesen;
  • nichts wird zwischengespeichert, sodass nach dem Löschen der Zugangsdaten keine Kopie zurückbleibt.

  Ein Host, für den du keine Zugangsdaten hinterlegt hast, wird wie bisher nicht abgerufen.

• Alles andere wird nicht abgerufen. Ein anderer Host ohne Zugangsdaten, eine Quelle auf github.com oder gitlab.com ohne Tag (ein Branch), eine Archiv-URL oder eine SSH-Quelle wird vom Scanner nie abgerufen. Sie wird unter Nicht geprüft auf Sicherheit › Befunde › IaC mit ihrer Quelle aufgeführt, und der Status des Checks nennt, wie viele Module nicht abgerufen wurden; die Ressourcen, die es definiert, werden nicht geprüft.

Befunde innerhalb eines Moduls werden getrennt unter In Modulen aufgeführt, gruppiert nach Modul, mit der Version, die der Scan gelesen hat, und der Stelle, von der aus es aufgerufen wird. Sie blockieren nie einen Pull Request, haben keine Behebungsfrist und lösen keine Benachrichtigung aus, denn die Korrektur liegt in deinem Aufruf (ein Input oder eine Modulversion, die es behebt), nicht in deinen Dateien. Eine Verwerfung bleibt über Modulversionen hinweg erhalten: Sie ist an das Modul, die Datei darin und den Check gebunden, nicht an die Version.

Bicep

Trivy hat keine Bicep-Checks, prüft aber ARM. Deshalb kompiliert fremforge jede .bicep-Datei im Repository mit der Bicep CLI zu ARM und prüft das Ergebnis mit denselben Checks, demselben Schwellenwert und denselben Verwerfungen wie den Rest des Repositorys. Ein Befund wird an der .bicep-Datei angezeigt, auf der Zeile der beanstandeten Eigenschaft, sofern sie sich finden lässt, sonst an der Ressourcendeklaration, und er weist darauf hin, dass die Zeile aus dem kompilierten ARM zugeordnet wurde.

• Offline. Bicep läuft ohne Netzwerkzugriff und ohne Module wiederherzustellen. Ein Modul aus einer Registry (br:) oder einer Template Spec (ts:) kann nicht abgerufen werden, sodass eine Datei, die eines verwendet, nicht kompiliert und als solche aufgeführt wird. Lokale Module (module x './y.bicep') funktionieren.
• Jede Datei für sich. Jede .bicep-Datei, Module eingeschlossen, wird einzeln kompiliert und geprüft, sodass eine Ressource in einem Modul in der Datei des Moduls geprüft wird.
• Deine bicepconfig.json wird nicht gelesen. Modul-Aliasse, Extensions, experimentelle Funktionen und Analyzer-Einstellungen darin haben keine Wirkung auf den Scan. Eine Datei, die zum Kompilieren eine experimentelle Funktion braucht, wird als nicht kompiliert aufgeführt.
• Nie ein stilles Bestehen. Eine Datei, die nicht kompiliert werden konnte (ein Fehler, ein Registry-Modul, mehr als 60 Sekunden oder über der Grenze von 200 Dateien oder 2 MiB pro Repository), blockiert den Merge nicht, weil sie keine Fehlkonfiguration ist, aber der Status des Checks nennt, wie viele nicht geprüft wurden, und Sicherheit › Befunde › IaC führt sie unter Nicht geprüft mit dem Grund auf.

Deine eigenen Checks

Eine Organisation kann eigene Checks hinzufügen, in Rego geschrieben als benutzerdefinierte Trivy-Checks. fremforge/iac-scan führt sie zusammen mit den eingebauten Checks auf jedem Repository der Organisation aus, mit demselben Modus und Schwellenwert, und nur was ein Pull Request hinzufügt, blockiert ihn.

Füge sie unter Sicherheit › Richtlinien › IaC-Prüfungen oder über die API (unten) hinzu. Ein Check muss:

• in einem Paket unter custom. liegen, zum Beispiel package custom.acme.no_root;
• einen # METADATA-Block mit title, custom.id (seine Befunde werden als custom/<id> angezeigt) und custom.severity (LOW, MEDIUM, HIGH oder CRITICAL) tragen; custom.input.selector nennt die Dateitypen, die er liest, wie in Trivy;
• nur die gescannte Datei (input) lesen: kein import data und keine Referenz auf data;
• keine Netzwerk- oder Laufzeit-Built-ins verwenden: http.send, net.lookup_ip_addr, opa.runtime, rego.parse_module, trace, numbers.range und numbers.range_step werden abgewiesen.

Höchstens 25 Checks pro Organisation, je 32 KiB. Die Konsole bietet ein ausgearbeitetes Beispiel als Ausgangspunkt.

Ein gespeicherter Check steht auf Wird geprüft, bis der Scanner ihn mit OPA verifiziert hat, in derselben abgeschotteten Umgebung, in der deine Pull-Request-Scans laufen, und dann auf Aktiv oder Abgelehnt, mit dem Grund. Nur ein aktiver Check, der nicht ausgeschaltet ist, läuft. Wird der Quelltext eines Checks bearbeitet, wird er erneut verifiziert; bis dahin gilt das vorherige Ergebnis nicht mehr, und er läuft nicht. Du kannst einen Check ausschalten, ohne ihn zu löschen.

Befunde deiner Checks erscheinen zusammen mit den eingebauten, im Pull-Request-Check und unter Sicherheit › Befunde › IaC, markiert als Benutzerdefiniert mit dem Namen des Checks.

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}

Mit Terraform oder OpenTofu ist jeder Check eine Ressource fremforge_iac_custom_check (Provider 0.4.0 und neuer): name, source und enabled, wobei status, status_reason, check_id, title und severity aus dem Ergebnis des Scanners zurückgelesen werden.

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

Zum Auflisten genügt findings:read oder policy:read; Änderungen erfordern policy:write. Ein neuer oder geänderter Check kommt mit status pending zurück; das Ergebnis des Scanners setzt ihn auf valid oder invalid, mit status_reason. Einen Check, den die API abweisen kann, bevor der Scanner ihn sieht (zu groß, kein custom.-Paket, keine METADATA), beantwortet sie mit 400 und dem Grund; der 26. Check wird mit 409 beantwortet. Jede Änderung steht im Audit-Log.

Befunde

Sicherheit › Befunde › IaC listet die offenen Fehlkonfigurationen auf: den Check (zum Beispiel KSV-0014), seinen Titel, das Repository und die Datei, mit Schweregrad und Behebungsfrist. Filtere nach Schweregrad, öffne die Datei am gescannten Commit und verwirf einen oder mehrere Befunde mit Begründung, wie in den anderen Befund-Tabs. Eine Verwerfung bleibt für denselben Check in derselben Datei über Scans hinweg erhalten.

Für einige Checks, bei denen eine Eigenschaft genau einen sicheren Wert hat, etwa der S3 Public Access Block und die Einstellungen von Azure Storage zu HTTPS-only und minimaler TLS-Version, öffnet Korrektur-PR öffnen in der Spalte Fix einen Pull Request, der ihn setzt, ohne KI. Siehe Regelbasierte Korrekturen.

Sie erscheinen außerdem unter Sicherheit › Befunde › Alle als Typ IaC, in der Sicherheitsübersicht als eigene Zeile, im Compliance-Bericht und über die Befund-API (type=iac).

Benchmarks und NIS2

Der Compliance-Bericht gruppiert die offenen IaC-Befunde nach den Benchmark-Kontrollen, die ihre Checks prüfen (CIS Docker, CIS Kubernetes, RKE2 und EKS, der Kubernetes-Härtungsleitfaden der NSA, Pod Security Standards, CIS AWS), anhand der Compliance-Zuordnungen, die Trivy veröffentlicht, und nach Bereichen von Artikel 21 Absatz 2 der NIS2. Die NIS2-Gruppierung stammt von fremforge selbst; sie ist keine offizielle Zuordnung und sagt nichts über die Einhaltung einer Maßnahme aus.

Um einen Check in einem Repository zu ignorieren, verwende eine Trivy-Ignore-Datei; siehe Trivy-Ignore-Dateien.

Nicht abgedeckt

Diese Checks finden Fehlkonfigurationen. Sie gleichen keine Versionen mit Schwachstellen-Advisories ab:

• Terraform-Module werden nicht auf verwundbare Versionen geprüft. Terraform- und OpenTofu-Provider schon, durch den Abhängigkeits-Scan; siehe Terraform- und OpenTofu-Provider.
• Helm-Charts werden nicht auf verwundbare Chart-Versionen geprüft. Die Container-Images, die ein Chart ausrollt, schon, durch den Image-Scan; siehe Images, die deine Helm-Charts ausrollen.
• Pulumi und das AWS CDK werden nicht gescannt: Ihre Ressourcen existieren erst, wenn dein Programm läuft, und fremforge führt deinen Code nicht aus.
• Die Abdeckung innerhalb eines Formats ist die von Trivy. Zum Beispiel werden Regeln von Network Security Groups in ARM-Templates (und damit in Bicep) nicht ausgewertet, und ein Ansible-Task wird nur geprüft, wenn Trivy sein Modul kennt: In unserem Nachweis wurde ein Task amazon.aws.s3_bucket geprüft und ein Task amazon.aws.ec2_security_group nicht.
• Versionen von CI-Actions werden geprüft, aber durch den Abhängigkeits-Scan statt durch diesen Check: Eine Action mit einer bekannten Schwachstelle ist ein Abhängigkeitsbefund; siehe Versionen von CI-Actions. Ob sie auf einen Commit festgelegt sind, wird getrennt geprüft; siehe Workflow-Pinning.

Siehe Unterstützte Ökosysteme.