Die quelloffene GitHub-Alternative für Entwickler li

Die quelloffene GitHub-Alternative für Entwickler li

GitLab hat den 9. Global DevSecOps-Report: The State of AI in Software Development veröffentlicht. Weltweit wurden dafür mehr als 1000 Führungskräfte aus der IT-Branche, Entwickler sowie Sicherheits- und Operations-Fachkräfte befragt.

Laut dem GitLab Global DevSecOps Report wenden Entwickler nur 25 Prozent ihrer Arbeitszeit für die Code-Erstellung auf. Um das volle Potenzial von KI auszuschöpfen, müsse sie in den gesamten Lebenszyklus der Softwareentwicklung eingebettet werden, sagt David DeSanto, Chief Product Officer bei GitLab.

Zu den wichtigsten Ergebnissen des Berichts zählt, dass der Schutz der Privatsphäre und des geistigen Eigentums gewahrt bleiben müssen. 95 Prozent der Führungskräfte in der IT-Branche räumen bei der Auswahl eines KI-Tools dem Schutz der Privatsphäre und des geistigen Eigentums Priorität ein.

32 Prozent der Befragten machen sich „große“ oder „sehr große“ Sorgen, wenn es darum geht die KI in den Softwareentwicklungszyklus einzuführen. Von diesen Befragten sind 39 Prozent besorgt, dass KI-generierter Code Sicherheitslücken aufweisen könnte, und 48 Prozent  sind besorgt, dass KI-generierter Code nicht demselben Urheberrechtsschutz unterliegt wie von Menschen erstellter Code.

Sicherheitsexperten befürchten, dass KI-generierter Code zu mehr Sicherheitsschwachstellen führen könnte – und damit zu Mehrarbeit für sie, heißt es im Report. Denn nur 7 Prozent ihrer Zeit verwenden Entwickler dafür, Sicherheitslücken zu identifizieren und zu beheben, 11 Prozent für das Testen von Programmcode.

48 Prozent der Entwickler sehen mit deutlich höherer Wahrscheinlichkeit schnellere Entwicklungszyklen als Vorteil von KI an, verglichen mit 38 Prozent der Sicherheitsexperten. 51 Prozent aller Befragten sehen Produktivitätssteigerungen bereits als einen Hauptvorteil von KI-Implementierungen.

Der Report kann bei GitLab gegen Registrierung gelesen werden.

Der Beitrag GitLab-Report: The State of AI in Software Development erschien zuerst auf Linux-Magazin.

Gitlab hat seine sechste DevSecOps-Umfrage veröffentlicht, bei der rund 5000 Teilnehmer befragt wurden. Ein Ergebnis: Softwareentwicklungs-Teams sind bestrebt, sicheren und konformen Code in dem für die Geschäftsabläufe erforderlichen Tempo zu liefern.

An der Umfrage hätten Entwickler, Sicherheits- und Operations-Experten sowie Unternehmensleiter teilgenommen, berichtet Gitlab. Dass Sicherheit für Unternehmen die höchste Priorität bei Investitionen darstellt, sei ein weiteres Ergebnis. 69 Prozent der Befragten gaben an, dass sie ihre Toolchains konsolidieren möchten. Nahezu drei Viertel der Befragten haben eine DevOps-Plattform eingeführt oder planen die Einführung im Laufe des Jahres. Damit soll die steigenden Erwartungen der Branche in Bezug auf Sicherheit, Compliance, Toolchain-Konsolidierung und schnellere Softwarebereitstellung erfüllt werden, heißt es.

Allerdings zeigen sich bei den Befragten große Bedenken hinsichtlich der Komplexität der Toolchain-Verwaltung und der damit verbundenen Observability-Aufgaben. Und 60 Prozent der befragten Entwickler gaben an, ihren Code zwar schneller freizugeben als früher. Allerdings bremse der Wildwuchs an Toolchains ihre Geschwindigkeit und Produktivität und raube wertvolle Zeit.

Rund 40 Prozent der Entwickler verbringe zwischen einem Viertel und der Hälfte ihrer Zeit mit der Pflege oder Integration komplexer Toolchains, hat die Umfrage ergeben. Zudem hätten sich die Compliance-Verantwortlichkeiten auf die Bereiche Entwicklung, Betrieb und Sicherheit ausgeweitet: 71 Prozent der Operations-Experten verbrächten ein Viertel oder mehr ihrer Zeit mit Audits und Compliance. Fast drei von zehn (28 %) Sicherheitsexperten konzentrierten sich auf diese Aufgaben, heißt es im Bericht.

Der GitLabs DevSecOps Bericht 2022 steht zum Download bereit, allerdings ist dafür eine Angabe persönlicher Daten nötig.

Der Beitrag GitLabs DevSecOps Bericht 2022 veröffentlicht. erschien zuerst auf Linux-Magazin.

Mit Updates der Versionsverwaltung Gitlab auf die Versionen 15.0.1, 14.10.4 und 14.9.5 schließen die Entwickler Sicherheitslücken in der Community Edition (CE) und der Enterprise Edition (EE).

Bei den insgesamt acht Sicherheitsproblemen, die mit den Updates behoben werden, ist das Risiko einer Lücke mit kritisch bewertet. Über sie ist es unter Umständen möglich, eine Kontoübernahme durch eine SCIM-E-Mail-Änderung zu schaffen. Wenn SAML SSO für Gruppen konfiguriert sei, könne die SCIM-Funktion (System for Cross-domain Identity Management), die nur bei Premium+-Abonnements verfügbar sei, es Besitzern einer Premium-Gruppe ermöglichen, beliebige Benutzer über ihren Benutzernamen und ihre E-Mail-Adresse einzuladen. Es sei dann möglich, die E-Mail-Adressen dieser Benutzer über SCIM in eine von einem Angreifer kontrollierte E-Mail-Adresse zu ändern und so – bei fehlender Zweifaktor-Authentifizierung, diese Konten zu übernehmen.

Bei den weiteren Sicherheitslücken sind zwei mit hohem Risiko behaftet, vier mit mittlerem und eine mit niedrigem Risiko. Gitlab fordert die Nutzer auf, die gepatchten Versionen einzuspielen.

Der Beitrag Gitlab schließt Sicherheitslücken erschien zuerst auf Linux-Magazin.

Mit der neuen Version 15 bringt die Versionsverwaltung Gitlab die Funktion Container Scanning in alle verfügbaren Versionen und damit auch in die freie.

Container Scanning hilft Entwicklern, bekannte Sicherheitslücken in Abhängigkeiten zu finden, die in ihren Container-Images installiert sind. Michael Friedrich, Senior Developer Evangelist bei GitLab sagte bei der KubeCon und CloudNativeCon in Valencia, dass die Aufnahme des Scannings in die freie Version ein Highlight darstellt. Es gehöre zum Ansatz von Gitlab, die freie Version mit allen Grundfunktionen auszustatten, die für einen sicheren und reibungslosen Betrieb nötig sind. Container Scanning helfe dabei, die Entwicklung sicherer zu machen.

Neu ist auch die einfachere Orgainsation der Issue-BNeschreibungen. Die Issue Descriptions werden verwendet, um verschiedene Arten von Informationen zu erfassen, etwa Checklisten und Implementierungsdetails. Die Listenelemente einer Beschreibung lassen sich nun durch drag & drop umorganisieren, ohne die vollständige Beschreibung bearbeiten und speichern zu müssen.

Internal Notes in Gitlab 15. Quelle: Gitlab

Mit den ebenfalls neuen internal Notes lassen sich Diskussionen, die nur für bestimmte Benutzer sichtbar sein sollen, unkenntlich machen, während die wichtigsten Details zu einem Problem öffentlich bleiben. Die interne Notizen in Issues oder Epics sind dann nur für den Autor des Issues, den Zuweiser und Gruppen- oder Projektmitglieder mit mindestens der Rolle Reporter sichtbar.

In der Ankündigung sind weitere Features genannt.

Der Beitrag Gitlab 15 bringt Container Scanning und mehr erschien zuerst auf Linux-Magazin.

GitLab hat das E-Book „A guide to getting started in DevOps“ veröffentlicht. Der Leitfaden soll erklären, was DevOps ist sowie Technologien und Begriffe erläutern.

Das E-Book beinhaltet zudem Praxisbeispiele, eine Liste an Ressourcen und ein Quiz, um das gelernte Wissen zu testen. Laut der Studie „2021 Upskilling Enterprise DevOps Skills Report des DevOps Institute“ gaben 24 Prozent der mehr als 2000 befragten DevOps-Experten an, dass sie seit weniger als einem Jahr in ihrem DevOps-Team arbeiten. Weitere 30 Prozent hatten zwischen einem und zwei Jahren Erfahrung angegeben. Um dieser großen Gruppe der DevOps-Neulingen den Einstieg zu erleichtern, hat GitLab das E-Book veröffentlicht, teilt das Unternehmen mit.

Das E-Book steht kostenfrei zum Download bereit, eine Registrierung ist erforderlich.

Der Beitrag Kostenloses E-Book: A guide to getting started in DevOps erschien zuerst auf Linux-Magazin.

Kurz angemerkt: beim Update eines GitLab-Servers per APT trat folgende Fehlermeldung auf:

The following signatures were invalid: EXPKEYSIG 3F01618A51312F3F GitLab B.V. (package repository signing key) <packages@gitlab.com>

Der Hintergrund ist recht einfach und wird auch auf der entsprechenden Hilfeseite erklärt:

This key’s expiration was extended from 2022-03-02 to 2024-03-01. If you encounter a complaint of expiration on 2022-03-02, perform the steps in Update keys after expiry extension to incorporate the updated public key content.

So lief tatsächlich der Repository Key in der Mitte der Woche regulär aus und muss nun erneuert bzw. aktualisiert werden, da seine Laufzeit erweitert wurde. Die Anleitung, wie man den Key aktualisieren kann, wird auf besagter Hilfeseite ebenfalls zur Verfügung gestellt. Danach verläuft das Upgrade wieder wie gehabt.

[GitLab.com Issue]

Mit der neuen Version 14.7 bringt die Versionsverwaltung Gitlab rund 25 Neuerungen mit. Darunter sind Streaming Audit Events zum streamen von Audit-Ereignissen an ein frei wählbares Ziel.

Damit ließen sich dann etwa Gitlab-Prüfungsereignisse mit anderen Datenströmen korrelieren, eine Sicherungskopie der Prüfungsereignisse erstellen oder eine eigene Automatisierung entwickeln, um dann Maßnahmen zu ergreifen, wenn ein bestimmtes Prüfungsereignis eintritt, heißt es in der Ankündigung. Dieses Feature ist allerdings nur Nutzern der Ultimate-Edition zugänglich.

Neu sind auch Group Access Tokens, mit denen sich mit einem einzigen Token Aktionen für Gruppen durchführen lassen, die Projekte innerhalb der Gruppe verwalten und sich in Gitlab 14.2 und höher über HTTPS bei Git authentifizieren. Bisher seien die Group Access Tokens auf selbstverwaltete Instanzen beschränkt gewesen und hätten sich nur über die Rails-Konsole erstellen lassen. Jetzt sie sich über die Benutzeroberfläche und die API erstellen. Dabei können der Name des Tokens, das Ablaufdatum und der Geltungsbereich festgelegt werden. Zudem ließe sich ein bestehendes Gruppenzugriffstoken widerrufen.

Mit Verbesserungen im Gitlab User Interface zeigt die Benutzeroberfläche Administratoren jetzt gesperrte Benutzer an, was hilfreich ist, um diese Sperren zu bestätigen. In älteren Versionen hätten Admins nicht sehen können, dass ein Benutzer gesperrt sei. Group Access Tokens und die Locked-User-Funktion sind auch in den freien Versionen von Gitlab enthalten.

Der Beitrag Gitlab 14.7 bringt Streaming Audit Events erschien zuerst auf Linux-Magazin.

Container sind nach wie vor in alle Munde. Wer, der Einfachheit halber, mit Docker hantiert, der sollte regelmäßig die Aktualität der verwendeten Images prüfen. Nicht erst seit Log4j verbergen sich unerwünschte Sicherheitslücken in veralteten Images.

Trivy

Das Open-Source-Tool Trivy bietet die Möglichkeit lokale Images, direkt im Filesystem oder entfernte Repositorys nach Lücken zu scannen. Das Programm scannt unter anderen Base Images wie Alpine, Debian, Ubuntu, CentOS, SUSE, Photon OS, Paketmanager und andere Abhängigkeiten mithilfe der eigenen Schwachstellendatenbank ab.

Die Trivy Datenbank basiert auf NVD und diverser Security Meldungen einzelner Programmiersprachen (siehe).

Installation Trivy Security Scanner Debian/Ubuntu

sudo apt-get install wget apt-transport-https gnupg lsb-release
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo apt-key add -
echo deb https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main | sudo tee -a /etc/apt/sources.list.d/trivy.list
sudo apt-get update
sudo apt-get install trivy

Einen Scan mit Trivy anstoßen

Um die Übersicht der Scanergebnisse zu behalten, empfiehlt es sich, die Ausgabe auf kritische Lücken zu beschränken

trivy image --severity HIGH,CRITICAL IMAGENAME

Das Tool erlaubt es ebenfalls einen HTML Report zu veröffentlichen

trivy image --format template --template "@contrib/html.tpl" -o report.html golang:1.12-alpine

Trivy kann auch das Filesystem untersuchen.

trivy fs /path/to/project

Schlussendlich kann auch direkt via GitHub gescannt werden.

trivy repo https://github.com/knqyf263/trivy-ci-test

Fazit

Wer Docker im Einsatz hat, sollte die verwendeten Images regelmäßig auf Sicherheitslücken und Abhängigkeiten prüfen. Der Profi baut seine Images sicher selbst und weiß, was er tut, allerdings übersieht ein DevOp auch dort mal Abhängigkeiten. Auch hier schafft Trivy praktische Abhilfe, denn es lässt ich schnell in CI Workflows, beispielsweise von Gitlab integrieren.

Die Versionsverwaltung Gitlab bringt mit der Version 14.6 als letztes Release im Jahr 2021 einige Verbesserungen mit. Dazu zählt eine vereinfachte Geo-Konfiguration, die global verteilten Teams hilft, die nächstgelegene Geo-Site zu nutzen.

Vor GitLab 14.6 konnten Sysadmins Geo mit einer einheitlichen URL für alle Git-Vorgänge einrichten. Die Geo-Replikate hatten jedoch jeweils eine eigene URL für die Web-UI und den API-Zugriff, sodass die Benutzer die URL zu den spezifischen Geo-Replikaten kennen mussten. Mit GitLab 14.6 würden sekundäre Geo-Sites Schreibanforderungen transparent an die primäre Site weiterleiten und die meisten Leseanforderungen beschleunigen. Systemadministratoren können nun allen GitLab-Benutzern eine einzige URL zur Verfügung stellen, die automatisch die nächstgelegene Geo-Site verwendet, teilt Gitlab mit.

GitLab bringt zudem eine Aktivitätsliste für den GitLab-Agenten mit. In dieser Aktivitätsliste werden Ereignisse in Echtzeit protokolliert. Im ersten Schritt der Implementierung protokolliert die Liste den Verbindungs- und Token-Status. In kommenden Versionen sollen weitere Ereignisse für die Protokollierung folgen.

Aktivity-Liste im Gitlab-Agenten. Quelle: Gitlab

Ein neuer Rich-Markdown-Editor soll zudem das Bearbeiten von Wiki-Seiten erleichtern, unabhängig davon, wie gut der Anwender die Markdown-Syntax kennt. In früheren Versionen sei es nötig gewesen, Änderungen zu speichern, um zwischen dem Markdown-Editor und dem Markdown-Quelltext wechseln zu können. In GitLab 14.6 könne der Nutzer zwischen den beiden Editoren wechseln, ohne Änderungen zu speichern. Damit lasse sich schnell der Editor wählen, der gerade erwünscht sei, etwa um im Markdown zu schreiben und in die WYSIWYG-Oberfläche für komplexere oder langwierige Formatierungsaufgaben zu wechseln.

Der Beitrag Gitlab 14.6 bringt Verbesserungen erschien zuerst auf Linux-Magazin.

Gitlab hat den Open-Source-Experten Opstrace übernommen, der eine integrierte Open-Source-Observability-Lösung anbietet. Die Integration der Opstrace Observability-Lösung in die GitLab DevOps-Plattform soll dort Überwachungs- und Beobachtungsfunktionen bereitstellen.

Unternehmen sollen mit der Integration der konfigurationsfreien Beobachtungslösung die Inzidenz-Rate senken können und die Produktivität von Entwicklern erhöhen, teilen die Unternehmen mit. GitLab sieht sich als erstes Unternehmen das eine integrierte Open-Source-Observability-Lösung innerhalb einer einzigen Anwendung anbietet. Opstrace greift auf unabhängige Open-Source-Überwachungstools wie Prometheus, Cortex und Grafana zurück.

Organisationen sollten auf eine eine einsatzbereite, getestete, integrierte Observability-Plattform zurückgreifen können, die in der GitLab DevOps Plattform eingesetzt werde, statt sich zwischen einem teuren SaaS-Service und einer Do-it-yourself-Observability-Lösung entscheiden zu müssen.

Zu den Funktionen zähle dann die geführte Instrumentierung von Codes, Einblicke in jüngste Leistungseinbußen bei gleichzeitiger Durchführung von Performanceverbesserungen, Leistungsfeedback aus Prüfumgebungen in Merge-Requests, automatisches Rollback von Deployments und eine schnellere Untersuchung und Behebung von Incidents.

Basierend auf der DevSecOps-Umfrage 2021 von GitLab gaben fast 50 Prozent der Teilnehmer an, dass ihre Teams zwischen zwei und fünf Überwachungstools verwenden. GitLab will die Technologie von Opstrace in die GitLab Monitor-Phase integrieren und standardmäßig aktivieren. Sie soll für GitLab SaaS als auch für selbstverwaltende Nutzer zur Verfügung stehen. Weitere Details zum Integrationsprozess finden sich hier bei GitLab.

Der Beitrag Gitlab übernimmt Observability-Lösung Opstrace erschien zuerst auf Linux-Magazin.