-
Continue reading →: Der Agent committet allein: lokale Git-Hooks vor dem Push
Ein Agent zögert nicht vor dem Push: Warum lokale Git-Hooks ein Secret stoppen, bevor serverseitige Kontrollen überhaupt greifen.
-
Continue reading →: Was ein Postmortem enthalten muss, damit es beim nächsten Mal hilft
Der Vorfall ist vorbei, der Dienst läuft wieder, und irgendwo liegt ein Dokument mit dem Titel Postmortem. Ob es beim nächsten Vorfall hilft oder nur ablegt, was ohnehin alle wussten, entscheidet sich am Inhalt, nicht an der Existenz. Die meisten Postmortems scheitern nicht daran, dass niemand sie schreibt. Sie scheitern…
-
Continue reading →: Rollback ist kein Plan B: warum jede Pipeline einen geübten Rückweg braucht
Ein Deployment geht schief. Die Frage ist dann nicht, ob es einen Rückweg gibt, sondern ob ihn jemand kennt und ob er unter Druck funktioniert. In vielen Teams ist die Antwort auf beides unklar, und das fällt genau in dem Moment auf, in dem es teuer wird. Der Rückweg steht…
-
Continue reading →: Deploy Keys oder GitHub Apps: welcher Maschinenzugang wofür
Jedes Repository, das automatisch gebaut, getestet oder ausgerollt wird, braucht einen Zugang, hinter dem kein Mensch sitzt. Zwei Mechanismen tauchen dabei in fast jeder GitHub-Umgebung auf: der Deploy Key und die GitHub App. Oft wird der eine oder der andere aus Gewohnheit gewählt, nicht weil er zur Aufgabe passt. Das…
-
Continue reading →: Service-Accounts und Bot-Tokens in GitHub: die stillen Dauer-Zugänge
Wenn ein Mensch das Unternehmen verlässt, wird sein Zugang entzogen. Das ist Routine. Es gibt aber Zugänge, die niemandem gehören und trotzdem alles dürfen: Service-Accounts und Bot-Tokens. Sie deployen, öffnen Pull Requests, schreiben in Repositories und laufen oft seit Jahren durch. Kein Offboarding erfasst sie, kein Passwortwechsel betrifft sie. Genau…
-
Continue reading →: Technische Schulden in der Pipeline: wie man sie sichtbar macht
Technische Schulden kennt jedes Team aus dem Anwendungscode. In Build, Test und Deployment entstehen sie genauso. Nur fallen sie dort seltener auf, weil niemand auf die Pipeline schaut, solange sie grün ist. Das Problem zeigt sich erst, wenn ein Build bricht, ein Deployment hängt oder ein Prüfer nach Nachweisen fragt.…
-
Continue reading →: Warum Sicherheitswerkzeuge scheitern, wenn niemand für die Befunde zuständig ist
Ein neuer Scanner ist schnell eingeführt. Ein Klick in der Pipeline, ein Report erscheint, und plötzlich stehen dreihundert Befunde auf einer Liste. Das fühlt sich nach Fortschritt an. Sechs Wochen später ist die Liste auf achthundert gewachsen, niemand hat sie gelesen, und die Sicherheit ist keinen Schritt besser. Das Werkzeug…
-
Continue reading →: Was hinter „Stand der Technik“ im Kundenvertrag steckt
Immer mehr Softwareverträge enthalten eine Klausel, die verlangt, dass der Anbieter seine Systeme nach dem „Stand der Technik“ absichert. Der Satz klingt harmlos und wird oft überlesen. Er verschiebt aber die Beweislast: Wer unterschreibt, verpflichtet sich zu einem Sicherheitsniveau, das nicht der Vertrag definiert, sondern die Fachwelt. Und der bewegt…
-
Continue reading →: Von der Excel-Liste zum SBOM: der pragmatische Einstieg für kleine Teams
Fast jedes kleine Softwareteam hat eine Liste seiner Abhängigkeiten. Sie steht in einer Excel-Tabelle, in einer README oder im Kopf des Entwicklers, der am längsten dabei ist. Diese Liste ist der Anfang einer Software-Stückliste. Der Schritt zum echten SBOM ist kleiner, als die Abkürzung vermuten lässt. Er lohnt sich, sobald…
-
Abonnieren
Abonniert
Have a WordPress.com account? Log in now.
