Nachdem wir in den vergangenen Beiträgen dieser Blogserie gezeigt haben, wie man Workflows in GitHub definiert und verwendet, um seine Pipeline effizient zu nutzen, gehen wir in diesem Beitrag auf ein spezifisches und sehr wichtiges Thema ein. Wir widmen uns der automatisierten Analyse von Schwachstellen im Source Code, um die Risiken durch Sicherheitslücken oder Lizenzverstöße zu minimieren.
Dafür müssen wir zunächst einmal definieren, welche Arten von Schwachstellen wir dabei betrachten. In der Regel hat man in der Softwareentwicklung auch externe Abhängigkeiten zu verwalten und es ist üblich, dass dabei auch Open Source Komponenten zum Einsatz kommen. Doch dieser Effizienzvorteil während der Entstehung einer Software, bringt einen gewissen Wartungsaufwand mit sich. Denn in den abhängigen (Open Source) Komponenten können eben auch Sicherheitslücken entdeckt und hoffentlich auch geschlossen werden. Dies manuell zu überwachen und pflegen ist eine große Herausforderung.
Genau hier kann man jedoch auf Automatismen setzen. Für diese sogenannten Vulnerability Checks gibt es unabhängig von GitHub die zwei namhaften Anbieter Synopsis, mit ihrem Produkt Black Duck, und WhiteSource mit gleichnamiger Software. Mit beiden Lösungen, kann man seine Software scannen und auf Lizenzverletzungen und Sicherheitslücken überprüfen.
Als Microsoft Gold Partner mit starker Fokussierung auf Microsoft Azure Technologien verwalten wir viele unserer Projekte in Azure DevOps. Aufgrund der Partnerschaft von Microsoft und WhiteSource, die bereits 2016 eine TFS-Integration beinhaltete, setzen wir in vielen unserer Projekte WhiteSource für solche Scans ein. Seit 2019 hat auch GitHub eine offizielle Partnerschaft mit WhiteSource, weshalb WhiteSource in GitHub bereits stark integriert ist.
Während wir in Azure DevOps diese Prüfungen als Teil der CI/CD-Pipeline integrieren, gibt es bei GitHub einen anderen Weg. Da wir diese gesamte Blogserie vor dem Hintergrund der Migration von Azure DevOps Pipelines nach GitHub Workflow betrachten, sei an dieser Stelle folgendes erwähnt: Der in der Migration natürlich erscheinende Weg wäre, eine Action im Workflow auszuführen, welche die Prüfungen durchführt. Die vorher genannte tiefere Integration von WhiteSource in GitHub sieht jedoch einen anderen Weg vor.
Analog zu den Branch Policies in Azure DevOps gibt es in GitHub sogenannte Branch Protection Rules. Dort lassen sich WhiteSource Security Checks aktivieren (siehe Abbildung 1), die während des Pull Requests ausgeführt werden, nachdem man die WhiteSource Bolt App über den Marketplace installiert hat.
Auf diese Art der Prüfung wird verhindert, dass eine Sicherheitslücke überhaupt erst über einen Merge auf den Master Branch gelangt. Insofern es Beanstandungen dieser Prüfung gibt, erzeugt WhiteSource einen Report (siehe Abbildung 2).
Für diejenigen, die WhiteSource bereits außerhalb von GitHub kennen, erscheint der Klick auf die einzelnen Elemente vertraut, mit denen man Empfehlungen erhält, wie man das Problem beseitigen kann. Außerdem werden automatisch GitHub Issues angelegt, die man sehr gut verwenden kann, um die Bearbeitung der Themen zu planen, in dem man sie beispielsweise einem Milestone oder einem Benutzer zuordnet.
Die kostenfreie Variante WhiteSource Bolt kann über den GitHub Marketplace einfach installiert werden und unterstützt bis zu 5 Scans pro Repository pro Tag. Wer zusätzlich noch eine Lizenzprüfung, mehr Scans oder weitere Features benötigt, kann WhiteSource einkaufen und bekommt dann ein ganzes Dashboard für die Themen Governance und Compliance.
Zusätzlich kann man zu WhiteSource den sogenannten Dependabot verwenden, um im Hintergrund, und unabhängig vom Pull Request, Prüfungen durchzuführen. Dies ist ebenso sinnvoll, da beispielsweise eine verwendete Open Source Komponente zum Zeitpunkt des Pull Requests eine noch nicht entdeckte Sicherheitslücke aufweisen könnte, die zu einem späteren Zeitpunkt jedoch entdeckt und behoben wird. Der Dependabot kann solche Referenzen finden und auch gleich automatisiert einen Pull Request mit der Aktualisierung anlegen (siehe Abbildung 3).
Automatisierte Suche nach Schwachstellen mit GitHub Actions
Wem die Automatismen im Hintergrund zu magisch erscheinen und Analysen stattdessen im Workflow ausführen möchte, für den ist der alternative Ansatz über GitHub Actions eine Möglichkeit. Für die automatisierte Suche nach Schwachstellen innerhalb der eigenen GitHub Action kann z.B. auf Snyk oder GitHub CodeQL zurückgegriffen werden.
Snyk unterstützt verschiedene Ökosysteme, wie z.B. .NET, Node oder Docker, und scannt auf verwendeten Abhängigkeiten mit gemeldeten Sicherheitslücken, wie z.B. NuGet- oder npm-Paketen. Für öffentliche Repositories ist Snyk kostenlos verfügbar, für private Repositories sind 200 Analyseläufe kostenlos mit dabei. Die Action kann direkt über das Snyk GitHub Repository in den eigenen Workflow integriert werden (siehe Codebeispiel 1). Den Token für die Action bekommt man bei der kostenlosen Anmeldung auf der Snyk Homepage.
name: Example workflow using Snyk on: push jobs: security: runs-on: ubuntu-latest steps: - uses: actions/checkout@master - name: Run Snyk to check for vulnerabilities uses: snyk/actions/node@master env: SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
Codebeispiel 1: Integration von Snyk in GitHub Actions
GitHub CodeQL kann für unterschiedliche Programmiersprachen, wie z.B. C#, JavaScript oder Go, eingesetzt werden und ist kostenlos für alle auf GitHub gehosteten Repository verfügbar. Anders als Snyk analysiert CodeQL nicht die Abhängigkeiten, sondern findet Sicherheitslücken direkt im Source Code. Diese können beispielsweise eine Fehlbedienung in der Verwendung von einer Vielzahl an Frameworks sein, wie z.B. mit ASP.NET Core oder Entity Framework Core, die zu Sicherheitsproblemen führen. CodeQL kann direkt in einem GitHub Workflow ausgeführt werden (siehe Codebeispiel 2) und sucht zusätzlich auch noch nach Secrets oder Passwörtern im Source Code, die versehentlich mit hochgeladen wurden.
name: "Code Scanning - Action"
on: push: pull_request: schedule: - cron: '0 0 * * 0' jobs: CodeQL-Build: runs-on: ubuntu-latest steps: - name: Checkout repository uses: actions/checkout@v2 - name: Initialize CodeQL uses: github/codeql-action/init@v1 with: languages: csharp - name: Autobuild uses: github/codeql-action/autobuild@v1 - name: Perform CodeQL Analysis uses: github/codeql-action/analyze@v1
Codebeispiel 2: Integration von CodeQL in GitHub Actions
Lizenzprüfung in GitHub Actions
Ein weiteres wichtiges Thema ist die Prüfung der Open Source Lizenzen von verwendeten Abhängigkeiten. Bei Azure DevOps kann hierfür z.B. WhiteSource Bolt verwendet werden, das eine kompakte Übersicht gibt.
Bei GitHub Actions kann z.B. GitHub Licensed eingesetzt werden, für das es auch eine GitHub Action gibt. Dieses listet für verschiedene Paketmanager, wie z.B. NuGet oder npm, die verwendeten Lizenzen, um so eine Übersicht zu bekommen. So können Abhängigkeiten mit restriktiven Lizenzen wie GPL noch einmal überprüft und ausgetauscht werden, bevor es zu rechtlichen Problemen kommt.
Fazit
Aus Sicht der Analyse von Schwachstellen steht einer Migration von Azure Pipelines nach GitHub Actions nichts im Wege. Zusätzlich zu den Ansätzen, die man bereits aus Azure Pipelines kennt, gibt es noch eine Vielzahl an weiteren Möglichkeiten das Repository abzusichern.
Neben der klassischen Analyse bei CI/CD in GitHub Actions mit Snyk oder CodeQL, können zusätzlich noch Pull Request mit WhiteSource (Bolt) geprüft und über Dependabot in der Zukunft das Repository gesichert werden. Kombiniert man die verschiedenen Anwendungen so ergibt sich eine Absicherung auf allen Ebenen.
Es wird sichergestellt, dass keine Sicherheitslücken über Pull Request ins Repository kommen. Zusätzlich muss nicht aufwändig manuell geprüft werden, ob es bei den verwenden Abhängigkeiten zu Sicherheitslücken kommt, da diese vollautomatisiert als Issue und zusätzlicher Pull Request angelegt werden, bei dem man im besten Fall nur noch auf Merge drücken muss.
Sprechen Sie uns an, wenn Sie Fragen haben oder Unterstützung in Ihrem Softwareentwicklungsprozess benötigen: Von der ersten Idee über die Entwicklung mit einer Build– und Release-Pipeline bis hin zur Inbetriebnahme und Wartung. Wir führen Sie gerne ans Ziel.