SonarQube zur Analyse und Verbesserung der Codesicherheit

SonarQube ist ein unverzichtbares Tool zur Analyse der Qualität und Sicherheit von Quellcode.

Kernpunkte:

• SonarQube führt eine statische Codeanalyse durch, um Fehler, Sicherheitslücken und schlechte Programmierpraktiken zu erkennen.
• Das Tool lässt sich problemlos in CI/CD-Pipelines integrieren und ermöglicht so eine kontinuierliche Überwachung.
• Die Sicherheits vorschriften und die Quality Gates lassen sich an die Anforderungen des jeweiligen Projekts anpassen.

Was ist SonarQube?

Definition und Rolle

SonarQube ist eine Plattform zur statischen Codeanalyse (SAST), die Entwicklungsteams dabei unterstützt, Schwachstellen, Fehler und Qualitätsprobleme vor der Produktivschaltung zu erkennen.

➡️ So funktioniert es: SonarQube untersucht den Quellcode direkt, um Sicherheitsrisiken wie SQL-Injektionen, XSS-Schwachstellen oder andere Entwicklungsfehler zu identifizieren, die von einem Angreifer ausgenutzt werden könnten.

Über die Erkennung von Schwachstellen hinaus bündelt die Lösung die Analyseergebnisse in einer einzigen Benutzeroberfläche. Die Teams können:

• suivre les anomalies,
• les prioriser selon leur niveau de criticité,
• sie den Entwicklern zuweisen
• deren Korrektur zeitlich zu steuern.

➡️ Konkrete Vorteile: Durch die Integration in CI/CD-Pipelines und DevSecOps-Verfahren ermöglicht SonarQube die Behebung von Sicherheitsproblemen bereits in den ersten Phasen der Entwicklung und trägt so zur Verbesserung der Codequalität bei.

Unterstützt SonarQube SAST, SCA und DAST?

SonarQube ist in erster Linie eine SAST-Plattform. Ihre Aufgabe besteht darin, den Quellcode zu analysieren. Andere Ansätze dienen der Lösung ergänzender Probleme:

• Die SCA (Software Composition Analysis) befasst sich mit den Abhängigkeiten und den von der Anwendung verwendeten Open-Source-Komponenten, um bekannte Sicherheitslücken (CVE) zu identifizieren.
• Beim DAST (Dynamic Application Security Testing) wird eine laufende Anwendung getestet, um ausnutzbare Schwachstellen in ihrem tatsächlichen Verhalten aufzudecken.

Diese Ansätze ergänzen sich: SAST analysiert den von den Teams entwickelten Code, SCA überprüft Bibliotheken von Drittanbietern und DAST bewertet die Anwendung nach ihrer Bereitstellung.

Um diesem Bedarf gerecht zu werden, hat SonarSource „SonarQube Advanced Security“ eingeführt, das die Funktionen der Plattform um Software-Composition-Analysis (SCA) und erweiterte Sicherheitsanalysen erweitert.

Was ist SonarQube Advanced Security?

SonarQube Advanced Security ist eine Erweiterung der integrierten SonarQube-Plattform für Unternehmen.

In einer Anwendung geht ein erheblicher Teil des Risikos auch auf Open-Source-Abhängigkeiten und die Interaktion mit Bibliotheken von Drittanbietern zurück. Genau dieses Problem möchte SonarQube Advanced Security mit zwei wesentlichen Funktionen lösen:

• die Software-Composition-Analyse (SCA) zur Identifizierung bekannter Sicherheitslücken (CVE), bösartiger Pakete und bestimmter Risiken im Zusammenhang mit Open-Source-Lizenzen;
• Advanced SAST, um die Sicherheitsanalyse weiter voranzutreiben, indem die Datenflüsse über den reinen Geschäftslogik-Code hinaus verfolgt werden.

Konkret ist SonarQube zudem in der Lage,die Risiken zu bewerten, die durch die von der Anwendung verwendeten Bibliotheken und Komponenten von Drittanbietern entstehen.

💡 Einer der interessantesten Vorteile liegt in der Erkennung sogenannter grenzüberschreitender Schwachstellen. Bestimmte Schwachstellen treten weder in Ihrem Code noch in einer einzelnen Bibliothek auf, sondern in der Interaktion zwischen beiden. Dank einer fortschrittlichen Flussanalyse kann SonarQube Advanced Security solche komplexen Szenarien aufdecken, die mit herkömmlichen Ansätzen oft nur schwer zu erkennen sind.

Wie analysiert SonarQube die Sicherheit des Codes?

Wie funktioniert die statische Sicherheitsanalyse?

Schritt 1: Analyse des Quellcodes. Wenn eine Analyse gestartet wird, durchläuft SonarQube den Quellcode des Projekts und wendet eine Reihe von Sicherheitsregeln an, die auf die jeweilige Programmiersprache (Java, C#, JavaScript, Python usw.) zugeschnitten sind.

Schritt 2: Erkennung risikobehafteter Muster. Die Analyse-Engine sucht nach Codemustern, von denen bekannt ist, dass sie mit Sicherheitslücken oder gefährlichen Praktiken in Verbindung stehen.

Schritt 3: Zuweisung eines Schweregrads . Chaque problème détecté est qualifié selon sa nature et sa criticité afin d’aider les équipes à prioriser les corrections.

Schritt 4: Darstellung der Ergebnisse. Die Ergebnisse werden anschließend in der SonarQube-Oberfläche zentralisiert, wo die Entwickler die Warnmeldungen analysieren, deren Ursache ermitteln und deren Behebung verfolgen können.

💡Lesen Sie gerne unseren Artikel zum Thema „Clean Code“. Auch unser Artikel zur digitalen Souveränität könnte für Sie von Interesse sein.

Beispiele für von SonarQube erkannte Sicherheitslücken

Zu den wichtigsten Sicherheitsproblemen, die SonarQube aufdecken kann, gehören:

• Injektionen (SQL, OS, LDAP usw.): Vom Benutzer bereitgestellte Daten werden ohne ausreichende Validierung oder Schutzmaßnahmen verwendet, was Befehls- oder Abfrageinjektionen Tür und Tor öffnet.
• Cross-Site-Scripting-Schwachstellen (XSS): Situationen, in denen nicht geprüfte Daten ohne angemessenen Schutzmechanismus an einen Browser zurückgesendet werden, wodurch das Risiko von XSS-Angriffen steigt.
• Die Offenlegung sensibler Daten: fest eingebettete Passwörter, API-Schlüssel, im Code eingebettete Anmeldedaten oder veraltete kryptografische Verfahren.
• Risikobehaftete Authentifizierungsverfahren, wie beispielsweise die Verwendung von Passwörtern, die direkt im Code gespeichert sind.
• Die gefährliche Verwendung bestimmter APIs oder Entwicklungsmechanismen, insbesondere im Zusammenhang mit der Deserialisierung oder der Bearbeitung unzuverlässiger Daten.

💡 SonarQube unterscheidet zwei Arten von Sicherheitsmeldungen:

1. „Vulnerabilities“ sind im Code identifizierte Sicherheitslücken, die behoben werden müssen, da sie ein nachweisbares Risiko darstellen.
2. Die „Security Hotspots“ weisen auf sensible Codeabschnitte hin, die einer manuellen Überprüfung bedürfen, um festzustellen, ob tatsächlich ein Risiko besteht.

Die Sicherheitsregeln von SonarQube

Die Security Rules bilden die Grundlage für die Erkennung durch SonarQube. Sie ermöglichen es dem Tool, Schwachstellen, risikobehaftete Verhaltensweisen und Entwicklungspraktiken, die nicht den Sicherheitsstandards entsprechen, automatisch zu identifizieren.

Diese Regeln beziehen sich in der Regel auf anerkannte Standards wie :

• OWASP Top 10,
• CWE Top 25,
• OWASP ASVS,
• PCI DSS,
• CERT Secure Coding…

Diese Zuordnung ermöglicht es, die erkannten Schwachstellen mit branchenweit gängigen Risikokategorien zu verknüpfen. Folgende wichtige Referenzrahmen werden dabei berücksichtigt:

• OWASP Top 10 (Open Web Application Security Project) ist eine internationale Open-Source-Community, die sich der Verbesserung der Sicherheit von Webanwendungen verschrieben hat. Sie veröffentlicht eine Rangliste, in der die zehn größten Sicherheitsrisiken im Web aufgeführt sind.

SonarQube enthält zahlreiche Sicherheitsregeln, die sich auf die in den OWASP Top 10 beschriebenen Risiken beziehen, insbesondere in Bezug auf Injektionen, den Umgang mit sensiblen Daten sowie Authentifizierungsmechanismen.

• CWE Top 25 (Common Weakness Enumeration), un catalogue standardisé des faiblesses logicielles (bugs, erreurs de conception) qui peuvent mener à des vulnérabilités exploitables.

Es listet gängige Sicherheitsschwachstellen auf, und in seiner jährlichen „Top 25“-Liste werden die kritischsten davon hervorgehoben. SonarQube verknüpft seine Regeln mit diesen CWEs.

Jede Regel gibt häufig den Bezug zu einem Referenzrahmen an und hilft den Entwicklern so, die Tragweite der Sicherheitslücke zu erfassen und sie gleichzeitig für bewährte Praktiken zu sensibilisieren.

SonarQube für IDE

Diese kostenlose Erweiterung fungiert als Sicherheitsnetz in Echtzeit.

Sein wahrer Nutzen zeigt sich im Connected Mode: Die IDE ist mit dem SonarQube-Server oder der SonarQube-Cloud verbunden und wendet dieselben Regeln an wie das Projekt: Qualitätsprofil, Ausschlüsse, Analyseparameter sowie den Status bereits akzeptierter oder als Fehlalarme markierter Issues. Der Entwickler arbeitet mit denselben Anforderungen, die auch bei der zentralisierten Analyse zum Einsatz kommen.

💡 Nicht alle Sicherheitslücken lassen sich allein durch eine lokale Analyse in der IDE erkennen. Komplexere Sicherheitslücken erfordern eine umfassende Analyse auf dem SonarQube-Server oder in der SonarQube-Cloud.

Kurz gesagt: SonarQube for IDE ersetzt die zentralisierte Analyse nicht, sondern bringt sie näher an den Entwickler heran.

Bewährte Sicherheitspraktiken mit Sonarqube

„Shift Left“-Sicherheit

„Shift Left Security“ bezeichnet den Ansatz, Sicherheitskontrollen so früh wie möglich in den Entwicklungszyklus zu verlagern. Anstatt Schwachstellen erst am Ende (im Rahmen eines Audits, eines Penetrationstests oder kurz vor der Inbetriebnahme) aufzudecken, versucht man, diese bereits beim Schreiben des Codes und anschließend in jeder Phase der Bereitstellung zu identifizieren.

In diesem Zusammenhang ist SonarQube auf mehreren Ebenen tätig:

• In der IDE mit SonarQube for IDE: Der Entwickler erhält bereits während des Schreibens seines Codes Warnmeldungen. Dies ist die frühestmögliche Phase: Das Problem wird bereits vor dem Commit erkannt.
• Im Pull-Anfrage oder Merge-Anfrage : SonarQube kann den geänderten Code vor der Integration analysieren. Das Team kann dann eine Sicherheitslücke blockieren oder beheben, bevor sie in den Hauptzweig gelangt.
• In der CI/CD-Pipeline wird die Analyse zu einer automatisierten Prüfung. Quality Gates können die Bereitstellung von Code verhindern, der die festgelegten Kriterien nicht erfüllt, beispielsweise wenn neue kritische Sicherheitslücken vorliegen.
• Im Rahmen der Projektüberwachung: SonarQube fasst die Issues, die Sicherheits-Hotspots, die Schweregrade, die akzeptierten Fehlalarme sowie die Entwicklung der technischen oder sicherheitsrelevanten Schulden im Zeitverlauf zusammen.

Anpassen der Quality Gates und Quality Profile

Es muss festgelegt werden, welche Regeln anzuwenden sind und ab welchem Schwellenwert ein Code als inakzeptabel gilt. Genau dies ist die Aufgabe der Qualitätsprofile und der Qualitätskontrollpunkte.

Das Qualitätsprofil legt die Regeln fest, die während der Analyse angewendet werden. Jede Programmiersprache verfügt über ein Standardprofil, wie beispielsweise „Sonar Way“, doch dieses Profil kann an den jeweiligen Projektkontext angepasst werden. Im Hinblick auf die Sicherheit sollte ein gutes Profil das tatsächliche Risikoniveau des Projekts widerspiegeln. Die Regeln bezüglich Injektionen, der Offenlegung vertraulicher Informationen, schwacher kryptografischer Verfahren oder Sicherheits-Hotspots müssen sorgfältig ausgewählt und dokumentiert werden, wenn eine Ausnahme beschlossen wird.

Das Quality Gate hingegen erfüllt eine andere Funktion: Es wandelt diese Analysen in eine Entscheidung um. Der Code wird gemäß vorab festgelegten Bedingungen entweder akzeptiert oder abgelehnt.

Beispiel: Eine Organisation kann beschließen, dass keine neuen kritischen Schwachstellen eingeführt werden dürfen, dass alle neuen Sicherheitsrisikobereiche überprüft werden müssen oder dass der Grad der Testduplizierung und der Testabdeckung innerhalb der akzeptierten Grenzwerte bleiben muss.

Es hat sich bewährt, zunächst mit dem neuen Code zu beginnen. Anstatt zu versuchen, die gesamte historische Code-Schuldenlast auf einen Schlag zu beheben, wird zunächst verhindert, dass neue Schwachstellen entstehen. Anschließend können die Teams die bestehenden Probleme schrittweise angehen, ohne das gesamte Projekt abrupt zum Stillstand zu bringen.

Schließlich müssen Fehlalarme und akzeptierte Risiken unter Kontrolle bleiben. Ein Alarm kann nach einer Überprüfung verworfen werden, doch diese Entscheidung muss dokumentiert werden. Auf diese Weise lässt sich ein gesundes Gleichgewicht wahren: streng genug, um Auswüchse zu vermeiden, und pragmatisch genug, um mit der Realität der Projekte vereinbar zu bleiben.

Automatisierung der Analyse in einer CI/CD-Pipeline

Pour une meilleure intégration dans les processus, SonarQube peut être intégré dans les pipelines CI/CD.

Das Ziel besteht darin, die Codeanalyse in den Pipelines zu automatisieren. Hier sind einige Beispiele für die Integration:

Integration mit GitLab CI

Mit GitLab CI lassen sich Analyse-Jobs orchestrieren. Sie müssen lediglich einen Job in die Datei „.gitlab-ci.yml“ einfügen, um die Analyse mit dem SonarScanner zu starten. Dieser Job nutzt die Variablen des GitLab-Projekts, um auf den Sonar-Server zuzugreifen (URL, Token).

Ein Konfigurationsbeispiel:

"sonar_scan: 

  stage: analysis 

  image: sonarsource/sonar-scanner-cli:latest 

  script:  

- sonar-scanner -Dsonar.projectKey=myproj -Dsonar.host.url=https://sonar.exemple.com -Dsonar.login=$SONAR_TOKEN 

  only: 

- merge_requests 

- main 

"

Ergebnis: Jeder Merge-Request oder jedes Commit im Hauptzweig löst einen Scan aus. GitLab kann die Pipeline zudem anhalten, wenn das Quality Gate nicht bestanden wurde.

Integration mit Jenkins

Jenkins verfügt über ein SonarQube-Plugin, das die Ausführung des Scanners vereinfacht. In Jenkins konfigurieren Sie zunächst die Sonar-Serverdaten (in der globalen Konfiguration) und fügen anschließend in der Pipeline (Jenkinsfile-Pipeline oder Freestyle-Job) einen Sonar-Schritt hinzu.

Ein Beispiel für ein deklaratives Skript:

"stage('SonarQube Analysis') { 
  steps { 
withSonarQubeEnv('My Sonar') { 
  sh 'sonar-scanner -Dsonar.projectKey=myproj -Dsonar.sources=src/ -Dsonar.host.url=https://sonar.exemple.com -Dsonar.login=${SONAR_TOKEN}' 
} 
  } 
}"

Das Jenkins-Sonar-Plugin bietet zudem einen Schritt zum Abwarten des Qualitäts-Gate-Vergleichs (waitForQualityGate), um die Pipeline anzuhalten, falls die Kriterien nicht erfüllt sind.

Integration mit GitHub Actions

Auf GitHub kann man entweder die offizielle Aktion „SonarSource/sonarcloud-github-action“ (vor allem für SonarCloud) verwenden oder den Scanner direkt in einem Job aufrufen.

Ein Beispiel für einen Arbeitsablauf:

"- name: SonarQube Scan 
  uses: sonarsource/sonarqube-scan-action@v1.2 
  with: 
host_url: ${{ secrets.SONAR_HOST_URL }} 
login: ${{ secrets.SONAR_TOKEN }} 
projectBaseDir: "./" 
" 

Weitere CI/CD-Tools

SonarQube lässt sich in andere Systeme wie Azure DevOps (mit Erweiterung), Bitbucket Pipelines, CircleCI usw. integrieren. Im Rahmen eines DevSecOps-Ansatzes fungiert die Pipeline als Sicherheitsmechanismus: Der Übergang in die Produktionsumgebung wird blockiert, wenn die Sicherheitskriterien nicht erfüllt sind.

IDE-Integration (SonarLint)

Um SonarLint noch früher in den Entwicklungszyklus zu integrieren, können Sie es in Ihrer IDE nutzen. SonarLint ist ein Plugin (verfügbar für IntelliJ, VS Code, Eclipse usw.), das den Code während des Schreibens analysiert und die Entwickler bereits während der Entwicklung auf Schwachstellen hinweist, sodass diese die Schwachstellen noch vor dem Commit beheben können.

Durch die Automatisierung von SonarQube im CI/CD-Prozess wird die Sicherheit fest im Entwicklungsprozess verankert. Die Teams erhalten schnelles Feedback, beheben Fehler und machen die Sicherheit zu einem unverzichtbaren Kriterium jeder Release-Phase.

Berichte richtig interpretieren

Sicherheitswarnungen über SonarQube zu erhalten, ist nützlich; sie zu interpretieren und darauf zu reagieren, ist jedoch noch wichtiger.

Das Tool bietet einen Gesamtüberblick sowie genaue Details, um diese Aufgabe zu erleichtern. Das Dashboard zeigt einen Sicherheits-Score (A bis E), die Anzahl der offenen Sicherheitslücken sowie zu überprüfende„Sicherheits-Hotspots“ an.

Ein „E“ weist auf schwerwiegende Probleme hin. Diese Schnellübersicht vermittelt einen ersten Eindruck vom allgemeinen Stand des Projekts.

In der Liste der Issues finden sich die für die Analyse und Behebung erforderlichen Details: Titel, Schweregrad, verletzte Regel sowie deren Fundstelle im Quellcode.

Zudem wird das Risiko erläutert und eine Lösung aufgezeigt. Diese Hinweise werden häufig durch bewährte Vorgehensweisen oder Dokumentationen ergänzt.

Anschließend muss der Aktionsplan festgelegt werden: Kritische Schwachstellen sind umgehend zu beheben, die Behebung der weniger schwerwiegenden Schwachstellen ist zu planen, ohne dass sich diese im Laufe der Zeit anhäufen.

Was die „Security Hotspots“ betrifft, ist ein Überprüfungsschritt erforderlich: Die Überprüfung muss dem Team zugewiesen werden, und anschließend muss entschieden werden, ob sie behoben werden müssen oder nicht (falscher Alarm oder akzeptiertes Risiko).

Zusammenfassend lässt sich sagen, dass der sinnvolle Einsatz von SonarQube Security darin besteht, diese Berichte in den Arbeitsalltag und das gesamte Projektmanagement zu integrieren.

Das Tool in einen DevSecOps-Ansatz integrieren

Um die Effizienz von SonarQube zu maximieren, sollte man es nicht als isoliertes Tool betrachten, sondern als einen Baustein der „DevSecOps“-Kultur. Hier einige Tipps:

• SonarQube bereits in den ersten Phasen der Entwicklung in die Prozesse integrieren. Indem man es zu einem Abnahmekriterium macht, wird die Sicherheit als Qualitätskriterium verankert.
• Das Team sensibilisieren: Ein Entwickler, der versteht, warum eine Sicherheitslücke ein Problem darstellt, wird von sich aus sicherer programmieren.
• SonarQube in Arbeitsabläufe integrieren: durch die Automatisierung von Analysen in CI/CD-Pipelines, die Einbindung der Berichtsresultate in das Projektmanagement und die Verwaltung von Sicherheitslücken über Tickets.
• Ergänzen Sie dies durch weitere Tools: Wenn Sie mehr über DevSecOps-Tools erfahren möchten, finden Sie dazu einen eigenen Artikel.

Einschränkungen von SonarQube hinsichtlich der Anwendungssicherheit

SonarQube allein deckt nicht den gesamten Bereich der Anwendungssicherheit ab.

Seine erste Einschränkung ergibt sich aus seinem statischen Ansatz. Er kann somit zwar sichtbare Schwachstellen im Code identifizieren, testet jedoch nicht das tatsächliche Verhalten der Anwendung im laufenden Betrieb.

Zweite Einschränkung: Die Analyse hängt von den verfügbaren, aktivierten und an die verwendete Sprache angepassten Regeln ab. Sie kann nicht garantieren, dass keine Schwachstellen vorhanden sind. Wie jedes SAST-Tool kann es Fehlalarme erzeugen, aber auch bestimmte komplexere Fälle oder solche, die zu stark vom Anwendungskontext abhängen, übersehen.

Dritte Einschränkung: SonarQube analysiert nicht die gesamte Sicherheitsfläche eines Systems. Es ersetzt weder ein DAST-Tool zum Testen einer bereitgestellten Anwendung noch ein SCA-Tool zur Analyse von Abhängigkeiten noch Sicherheitslösungen für Infrastruktur, Cloud, Container oder Server. Es ersetzt auch keine Architekturprüfung oder keinen Penetrationstest, wenn das Risikoniveau dies erfordert.

Vergleich mit anderen Sicherheitstools

Es gibt verschiedene Tools, die ähnliche Anforderungen erfüllen wie SonarQube, wobei jedes seine eigenen Besonderheiten aufweist:

Checkmarx

Checkmarx bietet mehr Funktionen als SonarQube. Die Plattform umfasst SAST, DAST, SCA sowie Container- und IaC-Sicherheit.

Veracode

Veracode bietet SAST, DAST und eine Abhängigkeitsanalyse an. Man übermittelt dem Tool den Code, und es liefert einen detaillierten Bericht über Sicherheitslücken zurück – ideal für Compliance-Zwecke und Audits.

Snyk

Snyk ist ein vielseitiges Tool für SAST, SCA, Containersicherheit und IaC.

Wie unterstützt Sie Qim info bei der Umsetzung von Sicherheitsmaßnahmen mit SonarQube?

Bei Qim info begleiten wir Sie in jeder Phase der Integration von SonarQube Security, um die Anwendungssicherheit zu einem Leistungshebel zu machen. Dank unseres maßgeschneiderten Ansatzes schulen wir Sie in Sicherheitsfragen, im Umgang mit dem Tool und in dessen reibungsloser Integration in Ihre CI/CD-Pipelines. Darüber hinaus bieten wir Ihnen eine regelmäßige Betreuung, um Sie bei der Auswertung der Berichte, der Anpassung der Regeln und der Anbindung von SonarQube an andere Sicherheitslösungen zu unterstützen.

Unsere Unterstützung gliedert sich in drei Bereiche:

• Beratung und Schulung: Bedarfsanalyse und praktische Einweisung in die Nutzung des Tools.
• Technische Umsetzung: Bereitstellung des Servers oder von SonarCloud, Konfiguration der Profile und Quality Gates, Integration in Ihre CI/CD-Pipelines.
• Überwachung und Fortschritte: Unterstützung bei der Auswertung von Berichten, kontinuierliche Anpassungen sowie Synergien mit anderen Sicherheitstools, einschließlich Container-Bildscannern.

Mit unserem Know-how in den Bereichen DevOps und Sicherheit unterstützen wir Sie dabei, SonarQube nachhaltig in Ihre Arbeitsabläufe zu integrieren. Das Ergebnis: eigenständigere Teams, robusterer Code und besser geschützte Projekte.

Unsere Teams im Kompetenzzentrum verfügen über eine gemeinsame Wissensbasis. Sie profitieren von einem bereichsübergreifenden Kompetenzaustausch, wodurch sichergestellt wird, dass sie mit allen Entwicklungen Schritt halten können. Entscheiden Sie sich für kollektive Exzellenz , um Ihre IT-Umgebung sicher zu gestalten, zu optimieren und vertrauensvoll weiterzuentwickeln.

FAQ

Lässt sich SonarQube in ein DAST- oder IAST-Tool integrieren?

SonarQube lässt sich problemlos mit einem DAST oder IAST kombinieren:

• Parallele Ausführung in der CI: Eine dynamische Analyse kann ebenfalls innerhalb der Pipeline gestartet werden. Sollte eine der beiden Methoden eine kritische Schwachstelle erkennen, kann die Pipeline blockiert werden.
• Konsolidierung und Zentralisierung der Berichte: Um einen Gesamtüberblick zu erhalten, ermöglichen Drittanbieter-Tools wie „DefectDojo“ den Import der Ergebnisse von SonarQube und eines DAST-Tools und bieten so eine übersichtliche Zusammenfassung. Auch Code-Hosting-Plattformen wie GitLab oder GitHub bieten Sicherheits-Dashboards an.
• Synergie : SonarQube und DAST/IAST stehen nicht im Widerspruch zueinander, sondern ergänzen sich: Durch ihre Kombination wird die Erkennung von Schwachstellen verbessert.

Kurz gesagt: Die Kombination von SonarQube mit Tools zur dynamischen Analyse erweitert den Sicherheitsumfang. Die Koordination erfolgt über die Prozesse – Pipeline, einheitliche Berichte – und nicht allein über SonarQube.

Wie installiert und konfiguriert man Sonarqube?

• Schritt 1: Überprüfen Sie die Server-Voraussetzungen: Java, RAM, Festplattenspeicher, Datenbank und Systemeinstellungen, insbesondere unter Linux; laden Sie hier die für Ihre Anforderungen geeignete Version herunter.
• Schritt 2: SonarQube kann über den SonarQube Server selbst gehostet werden. Teams, die den Betrieb der Infrastruktur auf ein Minimum beschränken möchten, können sich auch für SonarQube Cloud entscheiden, das SaaS-Angebot von SonarSource.
• Schritt 3: Erstellen Sie ein Projekt, das dem zu analysierenden Code entspricht, und generieren Sie anschließend ein Analyse -Token.
• Schritt 4: Starten Sie die Analyse mit SonarScanner, der die Ergebnisse an den SonarQube-Server übermittelt, wo sie in Form von Issues, Security Hotspots, Qualitätsindikatoren und Dashboards eingesehen werden können.

Was ist eine Sicherheitslücke in SonarQube?

Es handelt sich um eine Sicherheitslücke, die im Quellcode durch eine Analyseregel identifiziert wurde. Sie weist darauf hin, dass ein bestimmtes Verhalten des Codes die Anwendung einem Risiko aussetzen kann.

Jede Sicherheitslücke wird als „Issue“ gemeldet, mit

• eine Stelle im Code,
• eine Beschreibung des Problems,
• ein Schweregrad
• Empfehlungen als Orientierungshilfe für die Korrektur.

Es ist jedoch zwischen „Vulnerabilities“ und „Security Hotspots“ zu unterscheiden. Eine „Vulnerability“ bezeichnet ein Problem, das SonarQube als zu behebende Schwachstelle einstuft. Ein „Security Hotspot“ hingegen weist auf einen sensiblen Codeabschnitt hin, der manuell überprüft werden muss, bevor festgestellt werden kann, ob tatsächlich ein Risiko besteht.

Welche Hauptprodukte bietet SonarSource an, und inwiefern entsprechen diese den Anforderungen eines kleinen Entwicklungsteams?

SonarSource bietet derzeit im Wesentlichen drei Varianten von SonarQube an:

• SonarQube für IDE,
• SonarQube Cloud,
• SonarQube Server.

Für ein kleines Entwicklungsteam ist die Kombination aus SonarQube for IDE und SonarQube Cloud besonders sinnvoll: Probleme werden bereits beim Schreiben des Codes erkannt und anschließend vor dem Merge automatisch überprüft.