Mit GitLab Duo Pro ist bei GitLab ab Februar ein KI-Add-on verfügbar, das über alle GitLab-Bereitstellungsoptionen, einschließlich SaaS, Self-Managed und Dedicated für 19 US-Dollar pro Nutzer und…
Mit den Versionen 16.7.2, 16.6.4, 16.5.6 für die Gitlab Community Edition (CE) und die Enterprise Edition (EE) schließt der Anbieter von Diensten zur Softwareentwicklung und Versionsverwaltung…
Mit den Versionen 16.6.1, 16.5.3 und 16.4.3 für die
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.
In diesem Artikel möchte ich euch das Förderprogramm Media Tech Lab des Media Lab Bayern vorstellen.
Wie dem Titel bereits zu entnehmen ist, werden Open Source Projekte mit bis zu 50.000 EUR pro Projekt gefördert. Das Geld dafür kommt aus der Bayerischen Staatskanzlei. Doch der Reihe nach.
Vor einiger Zeit schrieb mich Jessica vom Media Lab Bayern an, um mich auf das Programm aufmerksam zu machen. Sie fragte, ob ich nicht Interesse habe, mich mit ihr und Erkan Kasap (CTO) über das Programm zu unterhalten, um ggf. darüber zu berichten und so dessen Bekanntheitsgrad zu steigern. Der Zufall sorgte dafür, dass Erkan und ich uns auf der FrOSCon 2022 an der Hochschule Bonn-Rhein-Sieg in Sankt Augustin begegnet sind, wo wir uns gemeinsam mit Dirk über das Programm ausgetauscht haben. Erkan strahlte dabei eine Leidenschaft und ein Commitment aus, welche mir den Eindruck vermittelten, dass er für dieses Projekt brennt.
Das Programm sucht innovative Projektideen zu Themen aus den Bereichen:
Ihr arbeitet bereits an entsprechenden Projekten oder strebt dies an? Ihr seid dabei auf eine Anschubfinanzierung angewiesen oder braucht Unterstützung bei der Projektplanung? Dann könnt ihr euch mit eurer Idee hier bewerben.
Ihr habt noch keine konkrete Idee, würdet aber gern mal an einem Open Source Proejekt arbeiten, welches das Potenzial hat, die Medienbranche zu verändern? Dann schaut in die Projektideen und lasst euch inspirieren.
Erkan ist auf der Suche nach:
die Lust auf ein cooles Forschungs- und Entwicklungsprojekt in und für die Medienbranche haben. Wichtig dabei ist, dass nur Einzelpersonen oder Teams aus Einzelpersonen gefördert werden können, jedoch keine Unternehmen.
Seid ihr z.B. Entwickler, die über ein Sabbatical nachdenken, um mal an einem richtig coolen Projekt zu arbeiten, aber in dieser Zeit auch Einkommen erzielen müssen, dann ist dieses Programm für euch.
Ihr seid jung, sprudelt vor innovativen Ideen, die ihr unbedingt umsetzen wollt? Doch es fehlt das Geld und ein wenig Unterstützung darin, wie man ein Projekt erfolgreich durchführt? Dann nehmt Kontakt zu Erkan auf. Vielleicht ist euer Projekt dann schon bald dabei und wird Realität.
Euer Projekt muss innovativ sein. Nicht innovativ sind z.B.:
Halt alles was es prinzipiell schon gibt. Damit sind jedoch nicht bereits existierende Projekte gemeint, denen es vielleicht noch an Funktionalität fehlt, um produktiv eingesetzt zu werden.
TL;DR: Wenn ihr alten Wein in neuen Schläuchen verkaufen wollt, seid ihr bei Erkan an der falschen Adresse.
Wenn dein/euer Projekt angenommen wird, arbeitet ihr bis zu sechs Monate an eurem Projekt. Dies geht remote oder beim Media Lab im Open Space in München. Der Arbeit am Projekt wird dabei die größte Zeit des Tages eingeräumt. Der Verwaltungs-Overhead wird auf ein Minimum reduziert. Die Messung und Kontrolle des Fortschritts gehört jedoch zu jedem ordentlichen Projekt dazu. So gibt es selbstverständlich auch hier Check-ins mit dem Media Lab Team, Tech-Experten auf CTO/Senior Level und Produkt Experten (Medienexperten). Mit diesen könnt ihr Fragen zum Tech-Setup diskutieren, die Nutzerperspektive kennenlernen und erhaltet Feedback zu eurem Projekt.
Ihr erhaltet alle zwei Monate ab Beginn des Projekts eine Auszahlung. An das Projektteam (nicht jedes Projektmitglied) werden so max. 45.000 EUR ausbezahlt, die ihr frei einsetzen könnt. Weitere 5.000 EUR sind zweckgebunden und können für Coaching und Mentoring eingesetzt werden. So könnt ihr euch bspw. Experten-Rat zu Themen wie Community-Management oder wie verwalte ich Contributer für mein Projekt einkaufen.
Auf der FrOSCon kam unser Gespräch darauf, was mit den Projekten passiert, wenn sie fertig und abgenommen sind. Stichwort: Maintenance.
Dieser Punkt ist noch nicht abschließend geklärt. Erkan äußerte die Idee, dass Medienhäuser, die ein Open Source Projekt einsetzen und zu einem Bestandteil ihrer Geschäftsprozesse machen, als Paten auftreten können, um die Pflege und Wartung des Codes zu finanzieren. Dem Gemeinschaftsgedanken folgend, können sich mehrere Unternehmen auf diesem Weg die Kosten für die Software-Pflege teilen.
Eine interessante Idee, bei der allerdings noch offen ist, ob und in welchem Umfang sich Medienhäuser darauf einlassen.
Ich persönlich finde es schon bemerkenswert, dass in Deutschland ein Förderprogramm aufgelegt wird, welches die Entwicklung von Open Source Projekten in diesem Umfang fördert. Etwas Vergleichbares war mir bis dato nicht bekannt.
Erkan hat auf mich den Eindruck hinterlassen, mit viel Herzblut und bis in die Bartspitzen motiviert hinter diesen Programm zu stehen.
In meinen Augen bietet das Programm eine gute Chance, um Open Source Projekten zu einem erfolgreichen Verlauf zu verhelfen. Auch wenn die Finanzierung der Maintenance-Phase nach Projektende noch nicht geklärt ist.
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.
In diesem Artikel stelle ich euch meine Ansible-Rolle vsphere_provision_lab vor. Mit dieser ist es möglich, vordefinierte Labor-Umgebungen, bestehend aus virtuellen Maschinen (VMs), in einem VMware vSphere Cluster zu provisionieren.
Um dem Text folgen zu können, ist es hilfreich zu wissen, was eine Ansible-Rolle (engl.) ist und worum es sich bei VMware vSphere handelt.
Zum Test von Ansible-Modulen, -Playbooks und -Rollen sowie neuer Shell-Skripte und Konfigurationsparameter benötige ich wiederholt Test- bzw. Labor-Umgebungen. Diese bestehen aus VMs, welche im Vergleich zum Provisionierungszeitpunkt möglichst wenig Änderungen aufweisen sollten.
Da die Konfiguration der Gast-Betriebssysteme durch einen Testlauf verändert wird, soll eine solche Labor-Umgebung nach einem Test möglichst schnell dekommissioniert und neu-provisioniert werden können.
Der Vorgang der Provisionierung und Dekommissionierung soll automatisiert erfolgen.
Um die Ansible-Rolle vsphere_provision_lab nutzen zu können, benötigt man:
Die Ansible-Rolle verwendet die Module vmware_guest und vmware_guest_disk aus der Collection community.vmware. Um diese nutzen zu können, muss auf dem Ansible Control Node Python in einer Version >= 2.6 und PyVmomi installiert sein.
Da die Rolle neue VMs aus Templates erstellt, müssen entsprechende vSphere Templates vorhanden sein.
In diesem Abschnitt werden die Variablen dokumentiert, welche mit Werten zu belegen sind. Diese sind in defaults/main.yml definiert und können entsprechend der Variablen-Präzedenz überschrieben werden.
Anmeldenvsphere_provision_lab_vc_hostname – Der FQDN für die vCenter Server Appliance.vsphere_provision_lab_vc_username – Ein Benutzeraccount mit der Berechtigung, neue VMs zu erstellen.vsphere_provision_lab_vc_password – Spezifiziert das Benutzer-Passwort.vsphere_provision_lab_vc_datacenter – Name des vSphere Datacenter in der Bestandsliste, das verwendet werden soll.vsphere_provision_lab_vc_cluster – Der zu verwendende vSphere Cluster aus der Bestandsliste.vsphere_provision_lab_vc_datastore – Name des Datenspeichers, in dem die VMDK-Datei(n) erstellt wird/werden.vsphere_provision_lab_vc_folder – Der vSphere Folder Name, in dem die VM erstellt wird. Der Wert kann zuvor mit dem Playbook find_vmware_guest_folder.yml ermittelt werden.Ich empfehle, sensible Informationen wie z.B. Benutzername und Passwort in einer verschlüsselten Ansible-Vault-Datei zu speichern.
Namen und Parameter der zu erstellenden VMs werden in einem YAML-Dictionary gespeichert. Der folgende Code-Block zeigt ein Beispiel für ein solches Dictionary mit einem Eintrag:
vm1:
vm_template: rhel8-en
vm_ram_mb: 1024
vm_vcpu: 2
vm_net: VLAN123
vm_ip: 192.168.0.5
vm_netmask: 255.255.255.0
vm_gateway: 192.168.0.254
vm_domain: sub.example.com
vm_hostname: host2
vm_dns_servers:
- 192.168.0.2
- 192.168.0.3
vm_dns_suffix:
- sub.example.com
- sub2.example.com
- sub3.example.com
vm_second_hdd: true
vm_second_hdd_size_gb: "10"
vm_second_hdd_type: "thin"
vm_second_hdd_datastore: "DS1"
vm_scsi_controller: "1"
vm_unit_number: "1"
vm_scsi_type: 'paravirtual'Aus dem obigen Dictionary wird eine VM mit den folgenden Parametern erstellt:
Diesen Block kann man nun für weitere VMs wiederholen. Wird keine zweite HDD benötigt, setzt man vm_second_hdd auf false.
---
- hosts: localhost
connection: local
gather_facts: no
vars_files:
- /path/to/vault-with-vcenter-creds.vars
- roles/vsphere_provision_lab/vars/rhel-lab.yml
roles:
- vsphere_provision_labIn diesem Beispiel werden die Variablen aus zwei Dateien geladen.
Die Rolle steht unter der Lizenz GPLv2-or-later und kann aus dem GitLab-Repo vsphere_provision_lab heruntergeladen bzw. das Repo geklont werden. Sie ist im Role Path der Ansible-Installation zu speichern. Anschließend kann man sich an folgendem Ablaufplan orientieren:
Die Ansible-Rolle vsphere_provision_lab ermöglicht es, Labor-Umgebungen, bestehend aus VMs, als YAML-Dictionary zu definieren und auf einem VMware vSphere Cluster zu provisionieren.
Damit eignet sie sich, um wiederholt eine Umgebung mit gleichen Ausgangsbedingungen zu schaffen. Gleichzeitig wird die Zeit für die Provisionierung verkürzt, da manuelle Schritte entfallen.
So richtig idempotent arbeitet das Modul vmware_guest allerdings nicht. Führe ich das Playbook ein zweites Mal aus, wird der Status „Changed“ zurückgegeben, obwohl die VMs bereits existieren. Die VMs selbst überstehen den zweiten Lauf auch unbeschadet, jedoch zeigt der vSphere Client, dass sie rekonfiguriert wurden. Das könnte ich mir noch genauer ansehen, um der Ursache auf die Schliche zu kommen.
Was haltet ihr davon? Findet ihr diese Role nützlich, oder bevorzugt ihr andere Wege zur Provisionierung eurer VMs auf vSphere?
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.
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.
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).
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
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
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.
