Thema: security
-
Ablauf von TLS-Zertifikaten auf jedem Endpunkt überwachen, nicht nur auf der Hauptwebsite
Ein abgelaufenes Zertifikat ist ein Ausfall mit exakt vorhersagbarem Zeitpunkt; das notAfter-Datum jedes tatsächlich ausgelieferten Zertifikats (Web, API, Mail, interne Panels, Load Balancer) von aussen abfragen, mit ausreichendem Vorlauf für eine manuelle Erneuerung alarmieren und sowohl die Zwischenzertifikate als auch das Endzertifikat prüfen.
-
Prüfen, ob eine TLS-Verbindung tatsächlich X25519MLKEM768 ausgehandelt hat
Mit Browserdetails, OpenSSL, curl und serverseitigen Nachweisen unterscheiden, ob Post-Quanten-Verfahren lediglich verfügbar sind oder die entsprechende Gruppe auf einer tatsächlichen TLS-Verbindung ausgewählt wurde.
-
Audit-Logs: was aufgezeichnet wird, wie sie unversehrt bleiben und wer sie lesen darf
Ein Audit-Log beantwortet, wer was an welchem Objekt getan hat, wann und mit welchem Ergebnis; es wird von der Anwendung für jede sicherheitsrelevante Aktion geschrieben, getrennt von Debug-Logs gehalten, durch zügiges Verschieben in einen Append-only- oder Write-once-Speicher gegen Veränderung geschützt und nur unter protokolliertem, eingeschränktem Zugriff gelesen.
-
Linux-Kernel: jede KEV-Schwachstelle anhand des Distributionspakets und des laufenden Kernels überprüfen
Fünf ausgenutzte Kernel-Schwachstellen getrennt nachverfolgen. Distributionsspezifische Paketkorrekturen verwenden und entweder den gestarteten Kernel oder die ausdrückliche Livepatch-Abdeckung bestätigen; eine Schutzmassnahme für ein Subsystem behebt nicht die übrigen Schwachstellen.
-
Ein Secret wurde committet: warum Löschen der Datei nicht reicht und wie die Reihenfolge der Reaktion aussieht
Zugangsdaten, die in ein Git-Repository gepusht wurden, bleiben in Historie, Forks, Klonen, Caches und CI-Protokollen erhalten. Das Umschreiben der Historie verringert künftige Exposition, kann bereits erstellte Kopien aber nicht zurückholen; deshalb steht zuerst der Widerruf und die Erneuerung der Zugangsdaten an, danach das Bereinigen der Historie, danach die Prüfung auf Verwendung.
-
Unix-Dateiberechtigungen und die umask
Jede Datei besitzt Berechtigungsbits für Eigentümer, Gruppe und Andere zum Lesen, Schreiben und Ausführen, dazu setuid-, setgid- und Sticky-Bit; neue Dateien erhalten ihre Berechtigungen von der umask des Prozesses. Geheimnisse gehören in Dateien mit 0600, Verzeichnisse benötigen Ausführen, um durchquert zu werden, und Dienste sollten unter einem dedizierten Benutzer laufen.
-
System Integrity Protection und Signed System Volume: was sie schützen und warum man sie nicht deaktivieren sollte
SIP verhindert, dass selbst root geschützte Systempfade oder geschützte Prozesse verändert; das Signed System Volume versiegelt das gesamte Systemvolume kryptografisch und prüft es bei jedem Start. Zusammen erklären sie, warum /usr/local beschreibbar ist, /usr aber nicht, und weshalb das Deaktivieren von SIP keine legitime Lösung für einen Berechtigungsfehler ist.
-
Rate-Limits gestalten, die den Dienst schützen und den Client informieren
Nach der verifizierbaren Identität begrenzen (Konto, Netzwerkpräfix), atomare Zähler in festen oder gleitenden Fenstern verwenden, mit 429 und Retry-After antworten, getrennte Budgets für Lese-, Schreib- und Registrierungsvorgänge führen und die geltenden Limits veröffentlichen.
-
Sudo-Richtlinien als Drop-in-Dateien in /etc/sudoers.d, geprüft mit visudo -c
Eine eng gefasste Regel als eigene Datei unter /etc/sudoers.d anzulegen und vor der Aktivierung mit visudo zu validieren, hält die sudo-Richtlinie nachvollziehbar und verhindert, dass ein Syntaxfehler alle aussperrt. Die Methodik behandelt zudem das Risiko breiter NOPASSWD-Regeln und zeigt, wo sudo seine Entscheidungen protokolliert.
-
Veröffentlichungsidentitäten bei npm und PyPI an freigegebene Release-Artefakte binden
Trusted Publishing mit OIDC beseitigt gespeicherte Veröffentlichungs-Tokens, seine Sicherheit hängt aber weiterhin vom autorisierten Workflow ab. Build und Veröffentlichung trennen, Freigaben schützen und die Identität des Artefakts prüfen, ohne einen Herkunftsnachweis als Urteil über Schadsoftware zu behandeln.
-
Durchgang durch einen Datei-Upload-Dienst: Tickets direkt zum Speicher, asynchrones Scannen und Kontingente
Ein Design-Durchgang für Uploads, die an den Anwendungsservern vorbeigehen: ein Ticket, das Kontingent reserviert und eine signierte Upload-URL zurückgibt, ein Abschlussschritt, der das gespeicherte Objekt verifiziert, ein Scan-Worker, der es freigibt oder löscht, Lebenszyklusregeln für abgebrochene Uploads sowie ein Statusmodell, das jedes gespeicherte Objekt erklärt.
-
Cross-Site-Scripting durch Ausgabe-Encoding verhindern
Daten passend zum jeweiligen Einfügekontext escapen (HTML-Text, Attribut, JavaScript, URL, CSS), ein Templating verwenden, das standardmässig escaped, HTML nie durch String-Konkatenation zusammenbauen und das Ganze mit einer strikten CSP absichern.
-
Cisco Secure Email Gateway und SD-WAN Manager: Fehlerbehebungen prüfen und Beweise für eine Kompromittierung sichern
Für den E-Mail-Scanner und SD-WAN Manager separate Behebungsnachweise führen. Tatsächlich installierte Fehlerbehebungen prüfen, Beweise vor eingreifenden Wiederherstellungsmassnahmen sichern und dem produktspezifischen Untersuchungsverfahren folgen.
-
Kurzlink-Dienste mit fortlaufenden Kennungen erhalten mehr Enumerationsanfragen als Dienste mit zufälligen Kennungen
Hypothese: Ein URL-Verkürzer, dessen Schlüssel ein in Base62 codierter Zähler sind, erlaubt es jedem, sämtliche Links der Reihe nach durchzugehen, während zufällige Schlüssel fester Länge die meisten Rateversuche ins Leere laufen lassen; die These lautet, dass Dienste mit fortlaufenden Schlüsseln einen höheren Anteil an Anfragen für bestehende Schlüssel von Clients sehen, die den Link nie erhalten haben, und dass der Anteil an 404-Antworten allein die beiden Fälle nicht unterscheidet.
-
CRA-Schwachstellenprozess eines Herstellers vorbereiten: Meldungseingang, Beweise und Meldefristen
Ein vorgeschlagenes Vorbereitungsverfahren verknüpft den Eingang von Schwachstellenmeldungen und Komponentennachweise mit der Entscheidung über eine CRA-Meldung. Es trennt die bereits 2026 geltende Meldepflicht von den umfassenderen Anforderungen an den Umgang mit Schwachstellen, die ab Dezember 2027 gelten.
-
Standard Webhooks im Vergleich: Shopifys HMAC-Header und GitLabs Shared-Secret-Token
Die Standard-Webhooks-Spezifikation definiert die Header webhook-id, webhook-timestamp und webhook-signature, ein mit whsec_ präfixiertes Base64-Secret, dessen dekodierte Bytes den HMAC-Schlüssel bilden, sowie eine Signatur v1,<base64> über "{id}.{timestamp}.{payload}". GitLabs Signing Tokens (GitLab 19.0, allgemein verfügbar ab 19.1) setzen genau das um. Shopify sendet stattdessen einen Base64-HMAC des rohen Bodys in X-Shopify-Hmac-SHA256, und GitLabs älterer X-Gitlab-Token ist ein schlichtes Shared Secret und gar kein HMAC.
-
Installierte RPM-Pakete mit rpm -V auf Manipulation prüfen
rpm -V vergleicht installierte Dateien mit den bei der Installation erfassten Prüfsummen, Berechtigungen und Besitzverhältnissen; die einbuchstabigen Codes in der Ausgabe zeigen genau, was sich geändert hat. Die Methodik beschreibt, wie die Ausgabe zu lesen ist und wo die Grenzen als Integritätsprüfung liegen.
-
Die Same-Origin Policy: was eine Origin ist und was sie isoliert
Eine Origin besteht aus Schema, Host und Port einer URL. Skripte dürfen Dokumente, Speicher und Antworten derselben Origin lesen und ändern; ursprungsübergreifende Lesezugriffe sind standardmässig blockiert, während ursprungsübergreifende Schreibzugriffe wie Formularübermittlungen sowie Einbettungen wie Bilder und Skripte grundsätzlich erlaubt sind. CORS lockert Lesezugriffe; CSRF-Schutzmassnahmen bleiben trotzdem nötig.
-
Nach Eingang eines Schwachstellenberichts: bestätigen, bewerten, privat beheben, offenlegen
Sobald ein Bericht die Sicherheitskontaktstelle des Projekts erreicht, ist die Arbeit eine Abfolge mit Terminen: schnell bestätigen, klassifizieren (wie vorgesehen, Bug, Feature-Wunsch, Schwachstelle), mit der meldenden Person ein Embargo vereinbaren, den Fix privat entwickeln, eine CVE-Kennung beschaffen, dann veröffentlichen und ein Advisory publizieren, das betroffene und behobene Versionen nennt und die meldende Person würdigt. Der OpenSSF-Leitfaden für Maintainer und GitHubs Hinweise zur Offenlegung beschreiben diesen Prozess; dieser Artikel fasst ihn für ein Projekt mit ein bis fünf Maintainern zusammen.
-
Agentenhandlungen sandboxen: Grenzen für Dateisystem, Netzwerk und Zugangsdaten
Ein Agent, der Befehle oder Code ausführt, sollte dies innerhalb einer Grenze tun, die einschränkt, auf welche Dateien er zugreifen, welche Hosts er erreichen und welche Geheimnisse er lesen kann; Container mit entzogenen Capabilities und einem seccomp-Profil, User-Space-Kernel wie gVisor, ein standardmässig gesperrtes Netzwerk und kurzlebige, eng begrenzte Zugangsdaten sind die Bausteine dafür.
Maschinenlesbar: JSON