ellievsbear
let's talk about Bridgerton tea, my ask is open
Lint Roller? I Barely Know Her
Cosmic Funnies
Mike Driver
RMH
tumblr dot com
almost home
$LAYYYTER
will byers stan first human second
No title available
KIROKAZE
Product Placement
Monterey Bay Aquarium
PUT YOUR BEARD IN MY MOUTH
🪼
occasionally subtle
wallacepolsom
Jules of Nature
Game of Thrones Daily
seen from TĂĽrkiye
seen from Germany
seen from Malaysia
seen from India
seen from Canada
seen from Switzerland
seen from Malaysia
seen from South Korea
seen from Bangladesh
seen from Austria
seen from Greece
seen from Spain
seen from United Kingdom
seen from Canada
seen from United States
seen from Canada
seen from Malaysia
seen from Greece
seen from Germany
seen from Malaysia
@muellermh
Build-Caches als Angriffsfläche: warum ein vergifteter Cache alle Builds betrifft
Build-Caches sind ein Standardwerkzeug, um Pipelines schneller zu machen. Statt Abhängigkeiten, kompilierte Zwischenstände oder Docker-Layer bei jedem Lauf neu zu erzeugen, werden sie gespeichert und wiederverwendet. Das spart Minuten pro Build und bei vielen Läufen am Tag summiert sich das. Der Preis dafür wird selten benannt: Ein Cache ist geteilter, wiederverwendeter Zustand. Wer ihn…
Secret Scanning und Push Protection: Tokens stoppen, bevor sie in die Historie kommen
Ein Token, das einmal committet wurde, ist nicht weg, wenn du es im nächsten Commit löschst. Es steht in der Historie, und die kann jeder auslesen, der Zugriff auf das Repo hat oder bekommt. Wie schnell ein Angreifer genau das findet, haben wir aus der Außensicht beschrieben. Dieser Beitrag dreht den Blick um. Es geht um die Werkzeuge, die verhindern, dass ein Secret überhaupt erst in die…
Was ein Angreifer in 20 Minuten aus einer offenen GitHub-Organisation liest
Die meisten Sicherheitsdiskussionen drehen sich um Zugriff. Wer darf was, wer kommt rein, wer wurde vergessen. Das ist die halbe Frage. Die andere Hälfte ist, was jemand über eine Organisation erfährt, ohne überhaupt Zugriff zu brauchen. Öffentliche Repos, öffentliche Profile, öffentliche Metadaten. Kein Login, kein Exploit, keine Lücke. Nur lesen. Zwanzig Minuten reichen dafür erstaunlich weit.…
Deploy-Umgebungen trennen: warum Staging und Prod nicht dieselben Credentials teilen dĂĽrfen
In vielen Pipelines gibt es genau einen Satz Zugangsdaten. Ein Deploy-Key, ein Cloud-Account, ein Datenbank-Passwort. Damit läuft der Build nach Staging, und damit läuft er nach Produktion. Das ist bequem, spart Einrichtung und funktioniert jahrelang problemlos. Bis zu dem Tag, an dem jemand Zugriff auf Staging bekommt und feststellt, dass Staging der Generalschlüssel für alles ist. Staging ist…
Effektive vs. nominale Rechte in GitHub: warum Team-Vererbung ĂĽberrascht
In der GitHub-Oberfläche steht neben jedem Team eine Rolle: Read, Write, Admin. Das ist die nominale Zuweisung, also das, was jemand laut Konfiguration bekommen soll. Was eine einzelne Person am Ende tatsächlich darf, steht dort nicht. Effektive Rechte entstehen aus mehreren Quellen gleichzeitig, und bei Konflikten gewinnt immer die höchste. Wer nur auf die Team-Liste schaut, sieht die Absicht,…
Pipeline-Secrets rotieren: warum statische Deploy-Keys ein Ablaufdatum brauchen
In den meisten Pipelines liegt irgendwo ein Deploy-Key oder ein Access-Token, das seit Jahren unverändert ist. Es funktioniert, also fasst es niemand an. Genau das ist das Problem. Ein statisches Secret, das nie rotiert wird, sammelt über die Zeit stillschweigend Risiko an, ohne dass jemand es merkt. Dieser Beitrag zeigt, warum Rotation kein Sicherheits-Luxus ist, sondern eine Grundhygiene, und…
Lockfiles richtig nutzen: Reproduzierbarkeit gegen Sicherheit
Ein Lockfile ist die stille Instanz in fast jedem Projekt. Es entscheidet, welche Version jeder Abhängigkeit wirklich installiert wird, und trotzdem schaut kaum jemand hinein. Dabei liegt genau hier der Punkt, an dem Reproduzierbarkeit und Sicherheit sich treffen und manchmal gegeneinander ziehen. Wer den Umgang mit package-lock.json, yarn.lock, poetry.lock oder Cargo.lock versteht, hat einen der…
Artifact Registries absichern: von Docker Hub bis internem Nexus
Jede Pipeline endet an derselben Stelle: einem Artefakt, das irgendwo abgelegt wird. Container-Images, npm-Pakete, JAR-Dateien, Helm-Charts. Der Ort, an dem sie liegen, heißt Artifact Registry. In vielen Teams ist genau dieser Ort der am schlechtesten kontrollierte Teil der gesamten Lieferkette. Wer in die Registry schreiben kann, entscheidet, was in Produktion läuft. Wer daraus liest, vertraut…
Berechtigungs-Reviews in GitHub-Organisationen: wer darf eigentlich noch was
In den meisten GitHub-Organisationen kennt niemand mehr die vollständige Antwort auf eine einfache Frage: Wer hat gerade Zugriff worauf, und warum. Rechte werden vergeben, wenn jemand sie braucht. Zurückgenommen werden sie fast nie. Das Ergebnis ist ein stiller Rechte-Berg, der mit jedem Onboarding, jedem Projekt und jedem externen Dienstleister weiter wächst. Rechte wachsen, aber niemand nimmt…
Third-Party Actions pinnen: warum SHA statt Tag und was eine Allowlist bringt
Fast jeder GitHub-Actions-Workflow zieht fremden Code. actions/checkout@v4, docker/build-push-action@v6, dazu ein Dutzend kleinerer Helfer aus dem Marketplace. Bequem, aber jede dieser Zeilen ist eine Vertrauensentscheidung. Wer @v4 schreibt, sagt damit: ich fuehre aus, was hinter diesem Tag heute steht, und auch das, was morgen dahinter steht. Genau das ist das Problem. Ein Tag ist kein…
Runner-Sicherheit: Warum Self-hosted Runner ein eigenes Risiko sind
Wer GitHub Actions oder GitLab CI intensiv nutzt, stößt irgendwann auf die Grenze der gehosteten Runner: zu langsam, zu teuer bei hohem Volumen, kein Zugriff auf interne Systeme. Die Antwort heißt dann Self-hosted Runner. Was viele Teams dabei übersehen: Ein selbst betriebener Runner ist kein Werkzeug wie jedes andere. Er ist eine Maschine, auf der fremder Code mit euren Rechten läuft. Was ein…
Merkle-Trees und Transparenz-Logs: Wie Sigstore Vertrauen ohne zentrale Instanz schafft
Signaturen sollen beweisen, dass ein Artefakt von einer bestimmten Stelle stammt und seitdem nicht verändert wurde. In der Praxis scheitert das selten an der Kryptografie und fast immer am Drumherum: Schlüssel liegen jahrelang auf Build-Servern, niemand weiß, wer wann was signiert hat, und ein geleakter Key fällt erst auf, wenn es zu spät ist. Sigstore geht das Problem anders an. Statt Vertrauen…
Software Composition Analysis: Abhängigkeiten kennen, bevor es der Angreifer tut
Der Code, den Ihr Team selbst schreibt, ist in den meisten Projekten die Minderheit. 70 bis 90 Prozent einer typischen Anwendung bestehen aus Open-Source-Abhängigkeiten. Wer diese Abhängigkeiten nicht kennt, kennt seine Angriffsfläche nicht. Genau hier setzt Software Composition Analysis an, kurz SCA. Was SCA konkret macht SCA-Werkzeuge inventarisieren alle Bibliotheken und Pakete, die in einem…
Dependabot und Renovate: automatische Updates richtig einsetzen
Veraltete Abhängigkeiten sind der häufigste Weg, über den Schwachstellen in Software gelangen. Nicht der eigene Code, sondern die 300 Pakete darunter. Automatische Update-Tools wie Dependabot und Renovate lösen genau dieses Problem. Trotzdem scheitert die Einführung in vielen Teams. Nicht am Tool, sondern an der fehlenden Strategie dahinter. Was beide Tools tun Dependabot und Renovate…
Monorepo vs Polyrepo aus Sicherheitssicht
Die Frage Monorepo oder Polyrepo wird meist als Organisations- und Tooling-Frage diskutiert. Aus Sicherheitssicht ist sie mindestens genauso relevant. Wer alle Projekte in einem Repository hält, trifft andere Risikoentscheidungen als jemand, der hundert kleine Repositories betreibt. Beide Modelle haben blinde Flecken, und die meisten Teams kennen ihre eigenen nicht. Zugriffsrechte: alles oder…
Was ein Audit-fähiger Freigabeprozess in der Pipeline braucht
Jede Softwareorganisation hat einen Freigabeprozess. Irgendjemand entscheidet, dass ein Stand in Produktion geht. Die Frage im Audit lautet aber nicht, ob es diesen Prozess gibt. Sie lautet: Kannst du für ein beliebiges Release vom letzten Jahr zeigen, wer freigegeben hat, auf welcher Grundlage und ob die Regel technisch erzwungen war? Genau daran scheitern viele Teams, obwohl sie fachlich sauber…
Provenance und Attestation: woher ein Artefakt wirklich stammt
Ein fertiges Build-Artefakt sieht immer gleich aus: eine Datei, ein Container-Image, ein Paket. Was man ihm nicht ansieht, ist die Frage, die im Ernstfall zählt. Aus welchem Commit ist es entstanden, welche Pipeline hat es gebaut, mit welchen Abhängigkeiten. Provenance und Attestation beantworten genau das. Sie machen die Herkunft eines Artefakts nachvollziehbar und beweisbar, statt sie zu…