ISGroup Cybersicherheitsberatung

Amazon Q Developer und AWS-Sicherheit: Was vor dem Produktivgang zu prüfen ist

Amazon Q Developer und AWS-Sicherheit: Was vor dem Gang in die Produktion zu prüfen ist

Wer Amazon Q Developer in einer AWS-Umgebung nutzt, bittet nicht nur um Hilfe beim Schreiben von Code: Er arbeitet innerhalb eines Ökosystems, in dem eine einzige Änderung Lambda, API Gateway, IAM, S3, RDS, CloudFormation, Terraform, CDK, CloudWatch, CloudTrail, Pipelines und Cloud-Accounts beeinflussen kann.

Der kritische Punkt ist erreicht, wenn aus einem nützlichen Vorschlag eine angewendete Änderung wird: eine in die Produktion kopierte IAM-Policy, ein ausgeführtes IaC-Template, eine veröffentlichte Lambda-Funktion, ein offener Bucket oder eine Abhängigkeit, die nur hinzugefügt wurde, damit der Build erfolgreich durchläuft. In diesem Moment stellt sich nicht die Frage, ob Amazon Q Developer nützlich ist, sondern ob der Code und die AWS-Konfigurationen, die in das Produkt einfließen, die Prinzipien des “Least Privilege”, der Umgebungstrennung, der Auditierbarkeit und der Anwendungssicherheit einhalten.

Amazon Q Developer kann Entwicklung, Fehlerbehebung, Code-Reviews und die Arbeit an der Infrastruktur beschleunigen. Die Verantwortung für Anwendungslogik, IAM, Geheimnisse (Secrets), IaC, Deployments und Konfigurationen liegt jedoch weiterhin bei dem Team, das diese Änderungen vornimmt. Dieser Artikel dient dazu, festzulegen, was zu prüfen ist, bevor Code oder AWS-Konfigurationen, die mit Amazon Q Developer generiert, vorgeschlagen oder korrigiert wurden, in die Produktion überführt werden.

[Callforaction-WAPT]

Warum Amazon Q Developer den Risikobereich verändert

Bei einem generischen Coding-Assistenten besteht das Hauptrisiko oft darin, dass ein Schnipsel kopiert wird, ohne dessen Kontext zu verstehen. Bei Amazon Q Developer ist der Bereich weitaus größer: Der Assistent lebt in der Nähe der AWS-Umgebung, kennt Cloud-Muster und kann bei Anwendungscode, Infrastruktur, Richtlinien, Sicherheit, CLI und verwalteten Diensten helfen.

Dies ist für ein AWS-Team nützlich, erfordert aber eine andere Art der Überprüfung. Ein Vorschlag kann syntaktisch korrekt sein und dennoch übermäßige Privilegien einführen; eine Konfiguration kann einen Deployment-Fehler beheben und gleichzeitig eine unnötige Angriffsfläche öffnen; ein IaC-Template kann funktionierende, aber zu permissive Ressourcen erstellen. Eine Lambda-Funktion kann beispielsweise ein Secret lesen, Logs schreiben und AWS-Dienste mit einer Ausführungsrolle (Execution Role) aufrufen, die weitreichender ist als nötig.

Das Modell der geteilten Verantwortung muss auch auf die Nutzung von KI-Coding-Assistenten angewendet werden: AWS schützt die Cloud-Infrastruktur und stellt Sicherheitskontrollen bereit, aber Code, Daten, Identitäten, Richtlinien, Konfigurationen und die im Account erstellten Ressourcen bleiben in der Verantwortung des Kunden.

IAM: Der erste Prüfpunkt

In AWS führen viele Anwendungsschwachstellen zu Sicherheitsvorfällen, weil sie auf zu weitreichende Cloud-Privilegien treffen. Amazon Q Developer kann beim Schreiben von IAM-Policies oder bei der Lösung von Autorisierungsfehlern helfen, aber das Ergebnis muss immer auf das Prinzip des “Least Privilege” zurückgeführt werden.

Das riskanteste Muster ist die funktionale Abkürzung: ein Wildcard bei Action oder Resource, eine temporäre Administratorrolle, die in der Produktion verbleibt, eine Policy, die an einen menschlichen Benutzer statt an die korrekte Service-Rolle gebunden ist, nicht dokumentierte Cross-Account-Berechtigungen oder fehlende Bedingungen für Tags, Regionen, Accounts oder spezifische Ressourcen.

Wenn ein Vorschlag von Amazon Q IAM betrifft, muss die Überprüfung konkrete Fragen beantworten: Welche Identität verwendet diese Policy? Wird sie in der Produktion wirklich benötigt? Ist die Ressource eingeschränkt? Ist die Rolle dediziert oder geteilt? Erlaubt die Policy nur die notwendigen Aktionen oder deckt sie ganze Dienstfamilien ab? Gibt es für jede verbleibende Wildcard eine dokumentierte Begründung?

Automatisierte Tools helfen, ersetzen aber nicht die Prüfung der Zielsetzung: Eine Policy kann syntaktische Prüfungen bestehen und dennoch das Betriebsmodell des Unternehmens verletzen. Deshalb sollte IAM wie kritischer Code behandelt werden – mit kleinen Diffs, manueller Überprüfung, separater Genehmigung und Tests in einer Nicht-Produktionsumgebung.

Lambda, API Gateway und Serverless: Code und Privilegien zusammen

Amazon Q Developer ist nützlich für Lambda, API Gateway und Serverless-Code, da es Handler generieren, Fehler korrigieren, AWS-SDKs vorschlagen und bei der Erstellung von Integrationen helfen kann. Das Risiko besteht darin, Code und Privilegien gemeinsam zu akzeptieren, ohne zu unterscheiden, was wirklich benötigt wird. Eine Lambda-Funktion, die ein S3-Objekt lesen muss, sollte keine weitreichenden Berechtigungen für den gesamten Bucket, alle Secrets oder nicht zusammenhängende Dienste erhalten. Ebenso sollte eine Funktion, die E-Mails versendet, keine administrativen Tabellen lesen können, und ein Handler, der Webhooks verarbeitet, sollte keine sensiblen Payloads protokollieren oder Umgebungsvariablen mit ungeschützten Secrets verwenden.

Auch API Gateway erfordert spezifische Kontrollen: Routen müssen konsistente Authorizer, begrenztes CORS, Throttling, Logging, Stages und sorgfältig konfigurierte benutzerdefinierte Domains haben. Ein für Tests erstellter Endpunkt, eine Route ohne Authorizer oder eine Antwort mit internen Details können einen schnellen Fix in eine offene Angriffsfläche verwandeln.

Vor dem Deployment sollte jede Lambda-Funktion, die mit Amazon Q generiert oder geändert wurde, zusammen mit ihrer Execution Role, den Umgebungsvariablen, den aufgerufenen Ressourcen und den auslösenden Ereignissen überprüft werden. Jede API-Route muss auf ihr exponiertes Verhalten getestet werden: anonymer Zugriff, abgelaufene Tokens, verschiedene Rollen, manipulierte Eingaben, Fehler und Rate Limits.

S3, RDS und Daten: Konfigurationen, die funktionieren, aber exponieren

S3 und RDS sind zwei Bereiche, in denen ein KI-Vorschlag harmlos erscheinen kann, weil er ein praktisches Problem löst: eine Datei lesbar machen, ein Asset hochladen, eine Datenbank verbinden, eine Verbindung öffnen. Die Sicherheitsprüfung muss jedoch über die unmittelbare Funktionalität hinausgehen.

Für S3 sind die relevanten Fragen: Muss der Bucket öffentlich sein? Handelt es sich bei den Objekten um öffentliche Assets oder vertrauliche Daten? Existiert “Block Public Access”? Verwendet die Bucket-Policy Principal: *? Haben Presigned URLs eine konsistente Dauer und einen konsistenten Umfang? Validieren Uploads Typ, Größe und Eigentümerschaft? Bei RDS zählen hingegen Netzwerkkonfiguration, Anmeldedaten, Backups, Verschlüsselung, Security Groups und Anwendungszugriff. Eine öffentlich erreichbare Datenbank kann für einen Test nützlich sein, aber eine Security Group, die für 0.0.0.0/0 offen ist, ein Passwort in einer Umgebungsvariablen, eine unverschlüsselte Verbindung oder ein zugängliches Backup sind Probleme, die korrigiert werden müssen, bevor echte Daten hineingelangen.

Amazon Q kann beim Schreiben des Zugriffscodes für S3 oder RDS helfen, kennt aber nicht die geschäftlichen Grenzen: Welche Daten sind personenbezogen, welche Dateien müssen privat sein, welche Benutzer gehören zu welchem Mandanten, welche Umgebungen dürfen Produktionsdaten sehen? Diese Entscheidungen müssen vor dem Go-Live explizit getroffen und dokumentiert werden.

Mit KI generiertes oder korrigiertes IaC

CloudFormation, Terraform und CDK machen Infrastruktur wiederholbar. Wenn jedoch ein mit Amazon Q generiertes oder korrigiertes Template ohne Überprüfung angewendet wird, wird eine Fehlkonfiguration zusammen mit allem anderen wiederholbar. Zu den häufigsten Risiken gehören zu weite Security Groups, öffentliche Buckets, geteilte IAM-Rollen, Outputs, die sensible Werte preisgeben, permissive Standardwerte, Ressourcen, die im falschen Account oder in der falschen Region erstellt wurden, zu ähnliche oder zu unterschiedliche Dev/Staging/Prod-Umgebungen, fehlendes Tagging und das Fehlen eines Rollback-Plans.

Die IaC-Überprüfung muss den Diff wie eine Produktionsänderung betrachten, nicht wie eine unterstützende Datei. Vor dem apply, deploy oder Merge in die Pipeline sind Plan-Diffs, IaC-Scanner, manuelle Kontrolle der Vertrauensgrenzen (Trust Boundaries), Überprüfung der Secrets, Genehmigung für kritische Ressourcen und Umgebungstrennung erforderlich.

Wenn Amazon Q eine IaC-Änderung vorschlägt, um das Deployment zum Laufen zu bringen, muss sich das Team fragen, was sich im Risikomodell geändert hat: Welche Ressourcen werden öffentlich, welche Identitäten erhalten Berechtigungen, welche Logs werden erstellt, welche Daten werden kopiert, welche Endpunkte werden erreichbar?

Secret Exposure: Code, Prompts, Logs und Artefakte

Amazon Q Developer kann helfen, Secrets im Code zu identifizieren, aber das Vorhandensein eines Scans beseitigt das Problem nicht an der Wurzel. Secrets können in Repositories, Prompts, Testdateien, Beispiele, CI/CD-Artefakte, CloudWatch-Logs, Stack Traces, CLI-Outputs oder IaC-Templates gelangen. Für AWS-Zugangsdaten und Drittanbieter-Schlüssel gilt eine einfache Regel: Wenn sie in einem nicht vorgesehenen Kontext offengelegt wurden, müssen sie rotiert werden. Den String aus dem Code zu entfernen reicht nicht aus, wenn die Historie, die Logs oder die Artefakte zugänglich bleiben.

Für AWS-Apps erfolgt die korrekte Verwaltung über den Secrets Manager, den SSM Parameter Store oder gleichwertige Mechanismen, mit minimalen Berechtigungen zum Lesen der Werte und Audits für sensible Lesezugriffe. Lambda-Funktionen dürfen keine Secrets ausgeben, Pipelines dürfen keine Umgebungsvariablen in Logs anzeigen und Tests sollten keine echten Zugangsdaten verwenden, wenn fiktive Werte ausreichen.

Integrierte Scans: nützlich, aber nicht ausreichend

Amazon Q Developer kann Code-Reviews unterstützen und Kategorien von Problemen wie Schwachstellen im Code, Secrets, IaC-Fehlkonfigurationen und anfällige Abhängigkeiten erkennen. Das ist nützlich, da es Sicherheitskontrollen früher in den Entwicklungszyklus bringt. Ein Scanner sieht jedoch Muster, nicht immer Absichten: Er kann eine bekannte Schwachstelle melden, ohne einen Missbrauch der Geschäftslogik zu verstehen; ein Secret im Klartext finden, ohne zu wissen, ob eine IAM-Rolle im Vergleich zum Geschäftsprozess zu weitreichend ist; eine IaC-Fehlkonfiguration erkennen, ohne eine architektonische Überprüfung zu Vertrauensgrenzen, sensiblen Daten, Account-Strategie und Umgebungstrennung zu ersetzen.

Die korrekte Praxis besteht darin, Scans als Input für die Überprüfung zu verwenden, nicht als Endpunkt. Die Ergebnisse müssen triagiert, korrigiert und erneut getestet werden. Bereiche mit hoher Auswirkung – Auth, IAM, öffentliche APIs, RDS, S3, Lambda und Pipelines – erfordern eine manuelle Überprüfung, auch wenn die Scanner keine Probleme melden.

CloudTrail, CloudWatch und Rückverfolgbarkeit

Wenn Amazon Q Developer in den AWS-Workflow einfließt, wird die Rückverfolgbarkeit Teil der Sicherheit. Das Team muss in der Lage sein, zu rekonstruieren, welche Änderungen angewendet wurden, von wem, mit welcher Identität, in welchem Account und welcher Region sowie mit welchen Auswirkungen auf Ressourcen und Berechtigungen.

CloudTrail und CloudWatch dienen nicht nur nach einem Vorfall, sondern auch davor, um sensible Änderungen sichtbar zu machen: Erstellung oder Änderung von IAM-Policies, Änderungen an S3-Buckets, offene Security Groups, Lambda-Deployments, API Gateway-Updates, Änderungen an Secrets, Variationen im Logging, Cross-Account-Ereignisse. Wenn die von der KI generierten oder vorgeschlagenen Änderungen über Pipelines, Issues, PRs oder Tickets laufen, sollte die Überprüfung Prompt, Diff, Genehmigung und Deployment verknüpfen. Ohne diese Kette kann ein Team vor geänderten AWS-Ressourcen stehen, ohne zu wissen, ob die Wahl beabsichtigt, temporär oder notwendig war.

VPC-Endpunkte und privater Zugriff auf Amazon Q Developer

In Unternehmenskontexten kann es relevant sein, Interface-VPC-Endpunkte und AWS PrivateLink zu verwenden, um eine private Verbindung zu Amazon Q Developer herzustellen. Dies ist eine Maßnahme zur Governance und Verkehrskontrolle, die nützlich ist, wenn die Organisation strenge Anforderungen an Netzwerkpfade, Logging und den Zugriff auf AWS-Dienste hat.

Diese Kontrolle macht die generierte oder geänderte Anwendung nicht automatisch sicher: Sie reduziert einen Teil des operativen Risikos im Zusammenhang mit dem Zugriff auf den Dienst, validiert aber nicht IAM, Lambda, S3, RDS, API, IaC oder Geschäftslogik. Sie sollte daher auf der richtigen Ebene angesiedelt werden: Governance des Tools und des Zugriffs, nicht Zertifizierung des Produkts.

Checkliste vor dem Deployment

IAM und Identitäten

  • Überprüfen Sie jede generierte oder vorgeschlagene Policy und entfernen Sie unnötige Wildcards bei Action und Resource
  • Trennen Sie menschliche Benutzer, Pipeline-Rollen, Service-Rollen und Execution Roles
  • Überprüfen Sie Bedingungen für Accounts, Regionen, Tags und Ressourcen
  • Stellen Sie sicher, dass Berechtigungen mit der korrekten Identität verknüpft sind und nicht mit einer aus Bequemlichkeit verwendeten Administratorrolle

Lambda, API und Anwendungscode

  • Lesen Sie Handler, Execution Role, Umgebungsvariablen, Secrets, Ereignisse und aufgerufene Ressourcen gemeinsam
  • Testen Sie API Gateway mit anonymem Zugriff, verschiedenen Rollen, abgelaufenen Tokens und manipulierten Eingaben
  • Kontrollieren Sie Authorizer, CORS, Throttling, Stages, Fehlerbehandlung, Logging und benutzerdefinierte Domains

S3, RDS und Datenspeicherung

  • Überprüfen Sie Block Public Access, Bucket-Policies, Presigned URLs, Uploads, Verschlüsselung und die Trennung zwischen öffentlichen und privaten Daten
  • Kontrollieren Sie bei RDS öffentliche Erreichbarkeit, Subnetze, Security Groups, Anmeldedaten, Backups, Verschlüsselung und Audit-Logs
  • Keine echten Daten sollten eingegeben werden, bevor Eigentümerschaft, Aufbewahrung und Zugriff geklärt sind

IaC, Pipelines und Umgebungen

  • Führen Sie vor dem Apply eine Überprüfung von CloudFormation, Terraform, CDK und Pipeline-Dateien durch
  • Kontrollieren Sie Plan-Diffs, IaC-Scanner, Tagging, sensible Outputs, Account/Region und die Trennung von Dev/Staging/Prod
  • Planen Sie das Rollback: Eine mit KI generierte IaC-Änderung muss wie eine Cloud-Änderung behandelt werden, nicht wie ein einfacher Vorschlag

Logging, Monitoring und Sanierung

  • Überprüfen Sie CloudTrail, CloudWatch, Anwendungs-Logs und Alarme bei sensiblen Änderungen
  • Stellen Sie sicher, dass Genehmigungen nachverfolgt und mit den Diffs verknüpft sind
  • Sanierungsmaßnahmen müssen vor dem Go-Live Eigentümer, Priorität und einen erneuten Test haben
  • Schwachstellen bei IAM, Secrets, Daten, öffentlichen Buckets, exponierten Datenbanken und APIs ohne Auth müssen vor der Veröffentlichung behoben werden

Wann reicht die interne Überprüfung und wann ist eine unabhängige Prüfung erforderlich?

Eine interne Überprüfung kann für isolierte Vorschläge, nicht exponierten Code, Prototypen ohne echte Daten und Änderungen, die IAM, IaC, AWS-Accounts, öffentliche APIs oder kritische Cloud-Ressourcen nicht berühren, ausreichen.

Eine unabhängige Prüfung ist erforderlich, wenn Amazon Q IAM-Policies, Lambda, API Gateway, S3, RDS, CloudFormation, Terraform, CDK, Pipelines, Security Groups, Secrets oder Produktions-Deployments beeinflusst hat. Sie ist auch erforderlich, wenn die App echte Daten, Zahlungen, externe Benutzer, Unternehmensintegrationen oder Multi-Account-Umgebungen verwaltet. Es geht nicht darum, Amazon Q Developer zu verlangsamen, sondern darum, das zu trennen, was beschleunigt werden kann, von dem, was überprüft werden muss: Code, Privilegien, Daten, Netzwerk, Speicher, Audit und Infrastruktur.

Wie ISGroup mit Amazon Q generierten AWS-Code und -Konfigurationen überprüfen kann

Die Kontrolle ändert sich je nachdem, was Amazon Q Developer generiert oder geändert hat. Wenn das Risiko im Anwendungscode, in Lambda-Funktionen, Middleware, Eingabevalidierung, der Verwendung von Secrets oder in Abhängigkeiten liegt, hilft die Code Review dabei, Schwachstellen und Regressionen vor dem Merge zu identifizieren. Wenn das Risiko AWS-Accounts, IAM, S3, RDS, Lambda, API Gateway, CloudTrail, CloudWatch, VPC oder Security Groups betrifft, überprüft das Cloud Security Assessment Konfigurationen und Privilegien im realen Kontext.

Wenn Amazon Q Developer berührt hat… Hauptrisiko Empfohlene Kontrolle
Anwendungscode, Lambda-Handler, Validierung, Fehlerbehandlung, Abhängigkeiten Schwachstellen oder Regressionen im Code Code Review
IAM, S3, RDS, API Gateway, Lambda Execution Role, CloudTrail, CloudWatch, Security Groups Cloud-Fehlkonfiguration oder übermäßige Privilegien Cloud Security Assessment
Serverless-Architektur, Vertrauensgrenzen, Multi-Account, sensible Daten, Integrationen Schwache architektonische Annahmen Secure Architecture Review
Web-Apps oder öffentliche APIs, die auf AWS bereitgestellt wurden Von außen ausnutzbares Verhalten Web Application Penetration Testing
Kontinuierliche Nutzung von Amazon Q im Entwicklungs- und Release-Zyklus Nicht wiederholbare Kontrollen bei Releases und Pipelines Software Assurance Lifecycle

Die Wahl der Kontrolle hängt davon ab, was sich tatsächlich geändert hat: Code, AWS-Privilegien, Infrastruktur, exponiertes Verhalten oder Entwicklungsprozess. Vor dem Go-Live ist es ratsam, diesen Bereich einzugrenzen und das tatsächliche Risiko für die Anwendung und den Cloud-Account zu überprüfen.

Haben Sie Amazon Q Developer verwendet, um Code, IAM-Policies oder AWS-Konfigurationen zu generieren, die kurz vor der Produktion stehen? ISGroup kann Ihnen helfen, Code, Privilegien, APIs, Infrastruktur, Geheimnisse, Logging und exponierte Oberflächen zu überprüfen, bevor eine nützliche Änderung zu einem operativen Risiko wird.

Vor der Überprüfung vorzubereitende Nachweise

Bevor ein externes Team einbezogen wird, ist es ratsam, Repositories, Diffs, CloudFormation/Terraform/CDK-Templates, eine Liste der betroffenen AWS-Dienste, beteiligte Accounts und Regionen, IAM-Rollen, neue oder geänderte Policies, Lambda-Funktionen, API Gateways, S3-Buckets, RDS-Datenbanken, Security Groups, Pipelines und verfügbare Logs zu sammeln.

Ebenfalls erforderlich sind Angaben dazu, welche Teile mit Amazon Q Developer generiert oder korrigiert wurden, welche automatischen Ergebnisse akzeptiert oder ignoriert wurden, welche Secrets rotiert wurden, welche Umgebungen echte Daten enthalten und welche Sanierungsmaßnahmen bereits geplant sind. Diese Nachweise reduzieren Mehrdeutigkeiten und ermöglichen es, Code-Probleme von Cloud-Fehlkonfigurationen sowie unmittelbare Risiken von Prozessverbesserungen zu unterscheiden.

Die Frage, die man sich vor der Veröffentlichung stellen sollte

Die Entscheidung sollte nicht abstrakt lauten: “Wenden wir den Vorschlag an oder nicht?”, sondern vielmehr: Welche Privilegien ändert er, welche Daten legt er offen, welche Ressourcen erstellt er, welche Endpunkte veröffentlicht er, welche Logs erzeugt er und welches Restrisiko bleibt nach der Sanierung bestehen?

Amazon Q Developer kann die Arbeit an AWS stark beschleunigen. Sicherheit dient dazu, zu verhindern, dass diese Geschwindigkeit zu weitreichende Policies, öffentliche Buckets, exponierte Datenbanken, Lambda-Funktionen mit übermäßigen Privilegien, APIs ohne Autorisierung oder nicht überprüfte IaC in die Produktion bringt. Der von Amazon Q vorgeschlagene Code und die AWS-Konfigurationen müssen als Teil des Cloud-Produkts überprüft werden, nicht nur akzeptiert, weil sie einen Fehler behoben haben. Wenn der Risikobereich nicht klar ist, besteht der nächste Schritt nicht darin, die Entwicklung zu verlangsamen, sondern dieses Risiko einzugrenzen, bevor echte Daten, Cloud-Privilegien und exponierte Oberflächen in die Produktion gelangen.

FAQ

  • Macht Amazon Q Developer den Code, den es vorschlägt, sicher?
  • Nein. Amazon Q Developer kann mit Vorschlägen und Kontrollen helfen, aber das Team muss Anwendungslogik, IAM, Secrets, Abhängigkeiten, IaC und das tatsächliche Verhalten vor der Produktion überprüfen.
  • Reichen die Scans von Amazon Q für ein AWS-Release aus?
  • Nein. Sie sind ein hervorragendes erstes Signal, ersetzen aber keine Code Review, kein Cloud Security Assessment oder Web Application Penetration Testing, wenn der Code exponiert ist, echte Daten verarbeitet oder kritische AWS-Ressourcen ändert.
  • Was ist das spezifischste Risiko auf AWS?
  • Das Akzeptieren von Konfigurationen, die funktionieren, aber die Privilegien erweitern: IAM-Wildcards, zu weitreichende Lambda Execution Roles, öffentliche S3-Buckets, exponierte RDS-Datenbanken, weite Security Groups, API Gateways ohne konsistenten Authorizer oder IaC, die ohne Überprüfung angewendet wurde.
  • Wann ist ein Cloud Security Assessment erforderlich?
  • Wenn Amazon Q AWS-Konfigurationen, IAM-Policies, S3, RDS, Lambda, API Gateway, CloudTrail, CloudWatch, VPC, Security Groups, Account-Strategie oder für die Produktion bestimmte IaC beeinflusst hat.
  • Wann ist eine Code Review erforderlich?
  • Wenn Amazon Q Anwendungscode, Lambda-Handler, Middleware, Eingabevalidierung, Fehlerbehandlung, Abhängigkeiten, die Verwendung von Secrets oder Autorisierungslogik generiert oder geändert hat.

[Callforaction-WAPT-Footer]

Quellen und nützliche Referenzen

In

, , ,

Leave a Reply

Your email address will not be published. Required fields are marked *