Deine gefährlichste Schwachstelle steht in Deinem eigenen Code. Und niemand sieht sie.
CAVRIX durchleuchtet Deine Repositories laufend auf hartkodierte Zugangsdaten, verwundbare Abhängigkeiten und unsichere Code-Muster. Bei jedem Commit, nicht einmal im Jahr. Findet sich etwas Kritisches, bekommst Du nicht nur einen Alarm, sondern die erledigte Behebung.
Eine Firewall schützt das Netz, ein Virenscanner den Rechner. Aber die Lücke, über die heute die meisten Angriffe starten, sitzt in der Software selbst: ein vergessener API-Schlüssel im Repository, eine veraltete Bibliothek mit bekannter Lücke, eine Zeile Code, die Eingaben ungeprüft weiterreicht.
Warum der Code zum Einfallstor Nummer eins geworden ist
aller Angriffe starten inzwischen mit der Ausnutzung einer Software-Schwachstelle. Erstmals noch vor gestohlenen Passwörtern.
neue hartkodierte Zugangsdaten wurden allein 2024 in öffentlichen GitHub-Repositories gefunden, ein Viertel mehr als im Vorjahr.
des von KI generierten Codes enthielt in kontrollierten Tests eine sicherheitsrelevante Schwachstelle.
aller untersuchten Codebasen enthalten mindestens eine bekannte Schwachstelle in ihren Open-Source-Abhängigkeiten.
Quellen: Verizon Data Breach Investigations Report 2026, GitGuardian State of Secrets Sprawl 2025, Veracode GenAI Code Security Report 2025, Black Duck OSSRA 2026. Branchendaten, keine Einzelfallgarantie.
Der Angreifer braucht keinen Einbruch. Er liest Deinen Code.
Ein Passwort im Code ist ein öffentliches Passwort.
API-Schlüssel, Datenbank-Passwörter und Tokens landen schneller im Repository, als man denkt. Ein einziger Commit ins falsche Repository, und der Schlüssel steht im Umlauf. Angreifer durchsuchen öffentliche und geleakte Repositories automatisiert danach. 2024 wurden fast 24 Millionen solcher Zugangsdaten allein auf öffentlichem GitHub gefunden. Ein einmal veröffentlichter Schlüssel bleibt gültig, bis ihn jemand zurückzieht.
Fremder Code, den Du nie geschrieben hast, mit Lücken, die Du nicht kennst.
Moderne Software besteht zu großen Teilen aus Open-Source-Paketen. 87 Prozent aller Codebasen tragen mindestens eine bekannte Schwachstelle in genau diesen Abhängigkeiten. Wird in einer weit verbreiteten Bibliothek eine Lücke öffentlich, haben Angreifer die Adressen der Verwundbaren binnen Stunden. Software-Lieferkette ist 2025 neu unter den Top drei der OWASP Top 10.
Schnell geschriebener Code ist selten sicherer Code.
Eingaben, die ungeprüft in Datenbankabfragen wandern. Zugriffskontrollen, die man vergisst. Broken Access Control steht 2025 auf Platz eins der OWASP Top 10. Der Druck steigt zusätzlich durch KI-Assistenten: In kontrollierten Tests lieferte KI-generierter Code in 45 Prozent der Fälle eine Schwachstelle mit, und die neueren Modelle waren nicht sicherer.
Scannen. Einordnen. Beheben.
Ein Bericht voller Funde, den niemand abarbeitet, ist kein Schutz. CAVRIX prüft in drei Tiefen und übernimmt die Behebung, statt sie Dir weiterzureichen.
Sofort-Scan bei jedem Commit.
- Hartkodierte Passwörter, Schlüssel und Tokens
- Bekannte unsichere Funktionen und Muster
- Gefährliche Aufrufe wie ungeprüfte Systembefehle
- Ergebnis in Sekunden, bevor der Code weiterläuft
- Kein Warten auf den nächsten Prüftermin
Prüfung jeder Änderung im Zusammenhang.
- Jede Änderung im Kontext der Codebasis bewertet
- Zugriffskontrolle und Eingabeprüfung im Blick
- Fehlerbewertung nach echtem Risiko, nicht nach Menge
- Falschmeldungen aussortiert, bevor sie Dich erreichen
- Klare Priorität statt endloser Trefferliste
Tiefenprüfung der ganzen Codebasis.
- Alle Abhängigkeiten gegen bekannte Schwachstellen
- Verlauf des Repositories auf alte Secrets durchsucht
- Konfiguration und unsichere Voreinstellungen
- Behebung umgesetzt, Secret rotiert, Bibliothek aktualisiert
- Fund und Maßnahme datiert dokumentiert
Von der Anbindung zum laufenden Schutz. In Tagen, nicht Monaten.
Anbindung
Wir binden Deine Repositories an und scannen den Bestand erstmalig auf Secrets, verwundbare Abhängigkeiten und unsichere Muster.
Erster Befund
Du bekommst einen klaren Bericht: welche Funde echt und kritisch sind, welche warten können und was zuerst passieren muss.
Aufräumen
Kritische Secrets werden rotiert, verwundbare Bibliotheken aktualisiert, gefährliche Muster entschärft. Priorisiert nach realem Risiko.
Überwachen
Ab jetzt bei jedem Commit. Neue kritische Funde bearbeiten wir sofort und melden Dir, was schon erledigt ist.
Was Normen und Aufsicht bei sicherer Entwicklung tatsächlich verlangen.
Andere behaupten pauschal, ein Code-Scanner sei Pflicht. Wir zeigen Dir die Stellen im Wortlaut und sagen offen, wo keine ausdrückliche Pflicht steht.
Sicherheit bei Entwicklung und Wartung
Die Richtlinie verlangt ausdrücklich Sicherheit bei Erwerb, Entwicklung und Wartung von Systemen, einschließlich Management und Offenlegung von Schwachstellen. In Deutschland umgesetzt in § 30 BSIG. Schwachstellen im eigenen Code sind genau das, was diese Anforderung adressiert.
Sicherer Entwicklungslebenszyklus
Die 2022er Fassung führt eigene Controls für sichere Entwicklung ein: A.8.25 sicherer Entwicklungslebenszyklus, A.8.26 Anforderungen an Anwendungssicherheit, A.8.28 sichere Codierung. Ergänzend verlangt A.8.8 das technische Management von Schwachstellen. Alle vier sind mit einem laufenden Scan direkt belegbar.
Pflichten für Produkte mit digitalen Elementen
Wer Software oder vernetzte Produkte in Verkehr bringt, muss Schwachstellen über den Lebenszyklus aktiv behandeln. Der CRA ist am 10. Dezember 2024 in Kraft getreten. Meldepflichten für aktiv ausgenutzte Schwachstellen gelten ab dem 11. September 2026, die Hauptpflichten ab dem 11. Dezember 2027.
Der fachliche Referenzrahmen
Kein Gesetz, aber der weltweit anerkannte Standard für die häufigsten Risiken in Anwendungen. Broken Access Control steht auf Platz eins, Software-Lieferkette ist neu unter den Top drei. Unser Scan orientiert sich an genau diesem Katalog.
Keine dieser Normen schreibt ein bestimmtes Scanner-Produkt vor. NIS2 und ISO 27001 verlangen sicheres Entwickeln und Schwachstellenmanagement, nicht ein konkretes Werkzeug. Der Cyber Resilience Act bindet Hersteller von Produkten mit digitalen Elementen, nicht jeden, der Software nur intern nutzt. Wir behaupten deshalb keine Kaufpflicht, sondern zeigen, welche Anforderungen ein laufender Scan messbar unterstützt. Diese Übersicht ist eine fachliche Einordnung, keine Rechtsberatung.
Prüfung neuer Änderungen, nicht einmal im Jahr zum Audit.
Reaktion bei kritischen Funden, proaktiv in Deinen Kanälen.
Aufwand für Dich, wir beheben den Fund und dokumentieren ihn.
Fragen zur Code-Sicherheit
Was genau scannt Ihr?
Drei Dinge. Erstens hartkodierte Zugangsdaten wie Passwörter, API-Schlüssel und Tokens, auch im Verlauf des Repositories. Zweitens verwundbare Abhängigkeiten, also Open-Source-Pakete mit bekannten Lücken. Drittens unsichere Code-Muster wie ungeprüfte Eingaben, gefährliche Systemaufrufe und fehlende Zugriffskontrollen.
Ersetzt das einen Penetrationstest?
Nein, und das behaupten wir auch nicht. Ein Scanner findet Muster und bekannte Lücken laufend und günstig. Ein Pentest prüft Dein System aus Angreifersicht als Ganzes. Das eine ist die tägliche Hygiene, das andere die periodische Tiefenprüfung. Beides gehört zusammen, keines ersetzt das andere.
Findet ein Scanner wirklich alle Fehler?
Nein. Kein Scanner findet alle Schwachstellen. Geschäftslogik-Fehler, etwa eine falsch gedachte Berechtigungslogik, haben kein festes Muster und entziehen sich der automatischen Analyse. Und jeder Scanner meldet auch Funde, die im konkreten Fall nicht ausnutzbar sind. Genau deshalb ordnet bei uns ein Mensch jeden Fund ein, statt Dich mit einer Rohliste allein zu lassen.
Wir lassen Code von einer KI schreiben. Ist das ein Problem?
Es ist ein Grund, genauer hinzusehen. In kontrollierten Tests lieferte KI-generierter Code in 45 Prozent der Fälle eine Schwachstelle mit, und die neueren Modelle schnitten nicht besser ab. KI beschleunigt die Entwicklung, verlagert die Prüfung aber nach hinten. Ein laufender Scan fängt genau das ab.
Müssen wir das aus Compliance-Gründen?
Kein Gesetz schreibt ein bestimmtes Scanner-Produkt vor. NIS2 verlangt Sicherheit bei Entwicklung und Wartung samt Schwachstellenmanagement, ISO 27001 fordert einen sicheren Entwicklungslebenszyklus. Ein laufender Scan ist eine der wenigen Maßnahmen, die dafür datierte, prüfbare Evidenz erzeugt. So argumentieren wir es auch im Audit.
Bekommt Ihr Zugriff auf unseren Quellcode?
Für die Analyse ja, mit Auftragsverarbeitungsvertrag und klar geregeltem Zugriff. Verarbeitet wird in der EU. Wir prüfen den Code auf Schwachstellen und geben ihn nicht weiter. Auf Wunsch läuft der Scan in Deiner Umgebung, sodass der Code sie nicht verlässt.
Wir entwickeln gar nicht selbst. Ist das für uns relevant?
Zum Teil. Wer keine eigene Software schreibt, hat keine hartkodierten Secrets. Aber auch eingekaufte und selbst betriebene Anwendungen bringen Open-Source-Abhängigkeiten und Konfigurationen mit, die veralten und Lücken bekommen. Wenn Ihr wirklich nur fertige Software von Dritten nutzt, ist eher unser Darknet-Monitoring der passende Einstieg.
Was steht in Deinem Code, das dort nicht stehen sollte?
Kostenlose Code-Analyse, klares Ergebnis, keine Verpflichtung.