Erstellen Sie einen Threat-Intelligence-Feed für Cybersicherheit für SaaS

Ein Threat-Intelligence-Feed für Cybersicherheit ist ein kontinuierlicher, gefilterter Strom von Sicherheitssignalen – Verstöße, CVEs, ausgenutzte Schwachstellen und Anbieterereignisse –, der in einem einzigen Kanal normalisiert, auf Relevanz für Ihren Stack bewertet und an die Personen weitergeleitet wird, die darauf reagieren können. Die meisten Artikel raten Ihnen, kommerzielle Feeds von 12 zu abonnieren. Für ein kleines oder mittelständisches Unternehmen (KMU) von SaaS bedeutet dies 12× Rauschen – und eine Rechnung von $20k–$100k/Jahr – für ein Problem, das Sie mit einem gut aufgebauten Aggregator für unter $50/Monat lösen können.

Dies richtet sich an SaaS-Engineering- und Sicherheitsteams, die Signal und keinen Lärm wünschen: Benachrichtigungen über Sicherheitslücken in Ihren Abhängigkeiten (Postgres, Stripe, Cloudflare, Auth0), CVEs in von Ihnen ausgelieferten Bibliotheken und Vorfälle bei den Marken Ihrer Kunden. (Offenlegung: APITube ist die Nachrichten-API, die im Beispiel verwendet wird, und der Sponsor dieses Artikels. Das Muster funktioniert mit NewsAPI, GNews, NewsCatcher; der CISA KEV und der NVD CVE Feed sind kostenlos.)

Wichtige Erkenntnisse:

1. Der 80/20-Stack ist CISA KEV + NVD CVE Feed + eine strukturierte Nachrichten-API. Sie brauchen kein MISP, kein SIEM-Modul, keinen kommerziellen Feed für $30k/Jahr.
2. Jedes Signal bewerten anhand von vier Achsen – KEV-Übereinstimmung, CVSS-Schweregrad, Anbieter in Ihrem Stack, Aktualität. Alles unterhalb des Schwellenwerts geht in ein Digest, nicht auf eine Seite.
3. Filtern nach Ihren Abhängigkeiten. Eine Sicherheitsverletzung bei Stripe ist wichtig; eine Sicherheitsverletzung bei einem CRM, das Sie nicht verwenden, ist Rauschen.
4. Routen nach Schweregrad: P0 → PagerDuty, P1 → Slack #sec-alerts, P2+ → täglicher Digest-E-Mail.
5. Ein funktionierender Aggregator ist ~150 Zeilen Python + ein winziger SQLite-Speicher. Gesamtkosten pro Monat: ~$30 (News API-Stufe) + ~$5 (Hetzner-Box).

Das Problem

Ein typisches SaaS-Team hat das gleiche Threat-Intel-Problem in drei Varianten:

• Engineering: „Ist das Postgres CVE, das gerade in unserer Nebenversion in den Nachrichten war?“
• Kundenerfolg: "Einer unserer Top-50-Kunden ist wegen eines Verstoßes in den Nachrichten — sollten wir ihn kontaktieren?"
• Compliance: "Ist heute etwas mit unseren Unterprozessoren passiert, das ich protokollieren muss?"

Was im Angebot ist:

1. Abonnieren Sie 12 kostenlose Feeds + RSS sie in Feedly. Sie erhalten Firehose-Volumenrauschen, keine Schweregradbewertung, keine Filterung nach Stack, kein Routing.
2. Kaufen Sie eine kommerzielle Threat-Intel-Plattform ($10k–100k/Jahr — Recorded Future, Mandiant, Anomali). Overkill für einen 30-Ingenieur SaaS, und das Relevanzsignal ist immer noch generisch.
3. Bauen Sie es selbst. Dieser Artikel führt Sie durch diesen Weg.

Die Lücke in der öffentlichen Diskussion ist, dass niemand diese dritte Option aufschreibt. Top--10-SERP-Ergebnisse sind Anbieter-Listen („12 kostenlose Feeds zum Folgen“) und SEO-optimierte Seiten „Was ist ein TI-Feed“, von denen keine eine funktionierende Architektur erreicht.

Lösungsübersicht

Sie erstellen einen kleinen Daemon, der fünf Dinge in einem 30-Minuten-Cron ausführt:

1. Ruft aktuelle Elemente aus drei Quellen ab: einer Nachrichten-API (Sentiment + Entitäten + Themen), dem CISA Known Exploited Vulnerabilities (KEV) Katalog und dem NVD CVE Feed.
2. Normalisiert jedes Element in ein gemeinsames ThreatSignal-Schema.
3. Deduziert gegen einen SQLite Speicher von gesehenen IDs.
4. Bewertet jedes Signal gegen Ihren Stack und einen Relevanzschwellenwert.
5. Routen nach Schweregrad: PagerDuty für P0, Slack für P1, wöchentlicher Digest für P2.

Im Gegensatz zu einer kommerziellen Plattform, die Ihnen einen generischen Feed plus Dashboards verkauft, die Sie nie öffnen werden, zeigt dieser Aggregator nur das an, was sich mit Ihrer Anbieterliste und Ihrer Kundenliste überschneidet – was bedeutet, dass das Signal-Rausch-Verhältnis durch Ihre Konfigurationsdatei bestimmt wird, nicht durch die Vorstellung eines Anbieters von „wichtig“.

Architektur

                     ┌────────────────┐
                     │  CISA KEV JSON │──┐
                     └────────────────┘  │
                     ┌────────────────┐  │
                     │  NVD CVE feed  │──┤
                     └────────────────┘  │
                     ┌────────────────┐  │     ┌──────────────┐    ┌──────────┐
                     │  APITube news  │──┼────▶│  Normalizer  │───▶│  SQLite  │
                     │  topic:cyber   │  │     │  + Dedup     │    │  (seen)  │
                     └────────────────┘  │     └──────┬───────┘    └──────────┘
                                         │            │
                                         │            ▼
                                         │     ┌──────────────┐
                                         │     │   Scorer     │
                                         │     │ KEV+CVSS+    │
                                         │     │ stack+recent │
                                         │     └──────┬───────┘
                                         │            │
                                         │            ▼
                                         │     ┌──────────────┐
                                         │     │   Router     │
                                         │     └──────┬───────┘
                                         │            │
                                         │      ┌─────┴─────┬───────────────┐
                                         │      ▼           ▼               ▼
                                         │  PagerDuty    Slack       Daily digest
                                         │   (P0)       (P1)         (P2 / weekly)
                                         │
                                       cron 30m

Drei Datenquellen, ein Normalisierer, ein persistenter Deduplizierungsspeicher, ein Scorer, drei Ausgaben.

Implementierung

Stack-Konfiguration (der Teil, der ihn SaaS-spezifisch macht)

# stack.yml
vendors:
  critical:                # P0 if breach
    - postgres
    - postgresql
    - stripe
    - cloudflare
    - auth0
    - okta
  important:               # P1 if breach
    - sendgrid
    - twilio
    - datadog
    - segment
  customers:               # match by entity name (case-insensitive)
    - "Acme Corp"
    - "Globex"
    - "Initech"
libraries:                 # CVE matching by package name
    - django
    - psycopg
    - requests
    - jwt
keywords:                  # plain-text fallback for news scan
    - "supply chain attack"
    - "credential stuffing"

Diese Datei ist der Hauptgrund, warum Ihr Aggregator für SaaS-Anwendungsfälle einen kommerziellen Feed übertrifft – er weiß, was Sie interessiert.

Quellen

# sources.py
import os, requests
from datetime import datetime, timezone

def fetch_kev() -> list[dict]:
    r = requests.get("https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json", timeout=15)
    r.raise_for_status()
    return r.json().get("vulnerabilities", [])

def fetch_cves(modified_since: str) -> list[dict]:
    r = requests.get("https://services.nvd.nist.gov/rest/json/cves/2.0",
                     params={"lastModStartDate": modified_since,
                             "lastModEndDate": datetime.now(timezone.utc).isoformat()},
                     timeout=20)
    r.raise_for_status()
    return r.json().get("vulnerabilities", [])

def fetch_news_cyber() -> list[dict]:
    r = requests.get("https://api.apitube.io/v1/news/everything",
                     params={"topic.id": "cybersecurity",
                             "language.code": "en",
                             "per_page": 50,
                             "sort.by": "published_at",
                             "sort.order": "desc"},
                     headers={"X-API-Key": os.environ["APITUBE_API_KEY"]},
                     timeout=15)
    r.raise_for_status()
    return r.json().get("results", [])

Der Nachrichten-API-Aufruf ist die Schlüsselkomponente. APITube gibt jeden Artikel mit bereits angehängten entities (Personen, Organisationen, Marken), topics und sentiment zurück – sodass Sie die zurückgegebenen entities[].name mit Ihrem kritischen Stapel abgleichen können, anstatt selbst eine Entitätsextraktion durchzuführen – und serverseitig mit den typisierten Filtern (organization.name, brand.name, person.name) oder einer numerischen entity.id eingrenzen.

Normalisierer

# normalize.py
from dataclasses import dataclass, field
from datetime import datetime
from typing import Literal

Kind = Literal["news", "kev", "cve"]

@dataclass
class ThreatSignal:
    id: str                     # stable dedup key
    kind: Kind
    title: str
    url: str
    summary: str
    published_at: datetime
    entities: list[str] = field(default_factory=list)
    cvss: float | None = None
    cve_ids: list[str] = field(default_factory=list)
    raw: dict = field(default_factory=dict)

Drei kleine Adapterfunktionen (from_news, from_kev, from_cve) geben jeweils einen ThreatSignal zurück. Die Beibehaltung einer einheitlichen Form ermöglicht es einem Scorer, alle drei Quellen zu verarbeiten.

Dedup

# dedup.py
import sqlite3
db = sqlite3.connect("seen.db")
db.execute("CREATE TABLE IF NOT EXISTS seen (id TEXT PRIMARY KEY, ts INTEGER)")

def is_new(id_: str) -> bool:
    return db.execute("SELECT 1 FROM seen WHERE id=?", (id_,)).fetchone() is None

def mark(id_: str) -> None:
    db.execute("INSERT OR IGNORE INTO seen VALUES (?, strftime('%s','now'))", (id_,))
    db.commit()

Für die Nachrichtenquelle ist id die Artikel-URL. Für KEV ist es die CVE-ID. Für CVE ist es <cve_id>:<lastModified>, sodass eine neu bewertete CVE genau einmal erneut ausgelöst wird.

Der Bewerter

# score.py
import yaml
from datetime import datetime, timezone

cfg = yaml.safe_load(open("stack.yml"))
CRIT = {v.lower() for v in cfg["vendors"]["critical"]}
IMP  = {v.lower() for v in cfg["vendors"]["important"]}
CUST = {c.lower() for c in cfg["vendors"]["customers"]}
LIBS = {l.lower() for l in cfg["libraries"]}

def severity(sig) -> int:
    """Return 0=ignore, 1=digest, 2=slack, 3=pagerduty"""
    text = (sig.title + " " + sig.summary).lower()
    ents = {e.lower() for e in sig.entities}

    if sig.kind == "kev":
        affected = (sig.raw.get("vendorProject", "") + " " + sig.raw.get("product", "")).lower()
        if any(v in affected for v in CRIT): return 3   # critical KEV → PagerDuty
        if any(v in affected for v in IMP):  return 2
        return 1

    if sig.kind == "cve":
        cvss = sig.cvss or 0
        prod = " ".join(sig.entities).lower()
        if any(lib in prod for lib in LIBS) and cvss >= 7.0:  return 3
        if cvss >= 9.0: return 2
        if cvss >= 7.0: return 1
        return 0

    if sig.kind == "news":
        age_hours = (datetime.now(timezone.utc) - sig.published_at).total_seconds() / 3600
        recency = max(0, 1 - age_hours / 48)              # 0..1
        crit_hit = bool(ents & CRIT) or any(v in text for v in CRIT)
        cust_hit = bool(ents & CUST)
        if "breach" in text and crit_hit:    return 3
        if cust_hit and "breach" in text:    return 3
        if crit_hit and recency > 0.3:       return 2
        if cust_hit:                          return 2
        if any(v in text for v in cfg["keywords"]):  return 1
        return 0

Dies ist absichtlich meinungsbildend. KEV-Abgleiche gegen einen kritischen Anbieter gehen an PagerDuty, denn wenn CISA ihn als aktiv ausgenutzt kennzeichnet und Sie diesen Anbieter einsetzen, müssen Sie am selben Tag eine Entscheidung treffen. Ein hoher CVSS CVE in einer Bibliothek, von der Sie nicht abhängen, gibt 0 zurück – Irrelevanz ist die halbe Wertigkeit eines TI-Feeds.

Routen

# route.py
import os, requests, json

def to_pagerduty(sig):
    requests.post("https://events.pagerduty.com/v2/enqueue", timeout=10, json={
        "routing_key": os.environ["PAGERDUTY_KEY"],
        "event_action": "trigger",
        "payload": {
            "summary": f"[SEC-P0] {sig.title}",
            "severity": "critical",
            "source": "ti-feed",
            "custom_details": {"url": sig.url, "kind": sig.kind, "cves": sig.cve_ids},
        },
    })

def to_slack(sig, channel="#sec-alerts"):
    requests.post(os.environ["SLACK_WEBHOOK_URL"], timeout=10, json={
        "channel": channel,
        "text": f"*[{sig.kind.upper()}] {sig.title}*\n{sig.summary}\n<{sig.url}|source>"
                + (f"\nCVEs: {', '.join(sig.cve_ids)}" if sig.cve_ids else ""),
    })

def to_digest(sig):
    # append to a daily file, send at 09:00 UTC by separate cron
    with open("digest.ndjson", "a") as f:
        f.write(json.dumps({"title": sig.title, "url": sig.url, "kind": sig.kind}) + "\n")

Die 30-Minuten-Cron-Schleife

# run.py
from sources  import fetch_kev, fetch_cves, fetch_news_cyber
from normalize import from_news, from_kev, from_cve
from dedup    import is_new, mark
from score    import severity
from route    import to_pagerduty, to_slack, to_digest

def run():
    sigs = [from_news(a) for a in fetch_news_cyber()] \
         + [from_kev(k)  for k in fetch_kev()] \
         + [from_cve(c)  for c in fetch_cves_recent()]

    for sig in sigs:
        if not is_new(sig.id): continue
        sev = severity(sig)
        if sev == 3: to_pagerduty(sig)
        elif sev == 2: to_slack(sig)
        elif sev == 1: to_digest(sig)
        mark(sig.id)

Das ist das Ganze — etwa 150 Codezeilen, verteilt auf fünf Dateien plus eine Konfiguration.

Ergebnisse / was Sie tatsächlich erhalten

Nach zwei Wochen des Betriebs dieses Systems in einem echten 30-Ingenieur-SaaS-Team (Stichprobengröße eins – Ihre Erfahrungen können variieren):

Das PagerDuty-Volumen macht das System tragfähig. Wenn Sie wegen nicht umsetzbarer Geräusche geweckt werden, werden Sie den Kanal innerhalb einer Woche stumm schalten und das System schlägt fehl. Die strenge Bewertung (KEV + kritische Anbieterübereinstimmung oder Verstoß + Kundennameübereinstimmung) ist der Teil, der von Ihnen abgestimmt werden muss, nicht von einem Anbieter.

Kosten

Über ~200 Ingenieure oder in einer regulierten Branche (Bankwesen, Gesundheitswesen) ist kommerzielle TI gerechtfertigt. Darunter gewinnt die Build-Option gleichzeitig bei Relevanz und Kosten.

Häufig gestellte Fragen

Was ist ein Threat-Intelligence-Feed?

Ein Threat-Intelligence-Feed ist ein kontinuierlicher Strom von Sicherheitssignalen – Schwachstellenoffenlegungen, Breach-Berichte, ausgenutzte CVEs und Indikatoren für Kompromittierung – geliefert in einem strukturierten Format, damit ein Sicherheitsteam Bedrohungen erkennen, priorisieren und darauf reagieren kann. Der Wert des Feeds hängt vollständig davon ab, wie gut er für die Relevanz für Ihren spezifischen Stack, Ihre Kunden und Ihre Anbieter filtert; ein generischer Firehose hat für einen kleinen SaaS ein fast null Signal-Rausch-Verhältnis.

Wie baue ich einen Threat-Intelligence-Feed?

Um einen Threat-Intelligence-Feed zu erstellen, kombinieren Sie drei kostenlose oder kostengünstige Quellen – den CISA KEV-Katalog (kostenlos), den NVD CVE-Feed (kostenlos) und eine strukturierte Nachrichten-API (~30 $/Monat) – in einem Normalisierer, der ein einheitliches ThreatSignal-Schema erzeugt, gegen einen SQLite-Speicher dedupliziert, jedes Signal gegen Ihre Anbieter- und Kundenliste bewertet und nach Schweregrad an PagerDuty, Slack oder eine tägliche Zusammenfassung weiterleitet. Die gesamte Pipeline besteht aus etwa 150 Zeilen Python plus einer YAML-Konfiguration Ihrer Abhängigkeiten.

Welche Quellen sollte ich für Threat Intelligence verwenden?

Die minimalen nutzbaren Quellen für einen SaaS Threat Intelligence Feed sind CISA KEV (aktiv ausgenutzte Schwachstellen, kostenlos), der NVD CVE Feed (alle offengelegten CVEs mit CVSS-Scores, kostenlos) und eine Nachrichten-API mit Sentiment- und Entitätenbewusstsein für Berichterstattung über Verstöße und Anbieter-Vorfälle. Optionale Quellen der zweiten Stufe umfassen MITRE ATT&CK, AlienVault OTX und Abuse.ch – fügen Sie sie erst hinzu, nachdem Sie die ersten drei gut gefiltert haben, sonst stapeln Sie Feuerwehrschläuche.

Wie überwache ich Cyber-Bedrohungen, die für mein SaaS relevant sind?

Um Cyber-Bedrohungen zu überwachen, die für Ihr SaaS relevant sind, pflegen Sie eine Konfigurationsdatei mit Ihren kritischen Anbietern (Postgres, Stripe, Cloudflare, Auth0 usw.), wichtigen Anbietern, Top-Kunden nach Namen und ausgelieferten Bibliotheken. Bewerten Sie jedes eingehende Signal anhand dieser Liste – ein KEV-Treffer gegen einen kritischen Anbieter oder eine Erwähnung einer Sicherheitsverletzung plus Kundenname sollte einen Alarm auslösen; alles andere wird an Slack oder eine tägliche Zusammenfassung weitergeleitet. Relevanz kommt aus der Konfiguration, nicht aus der Quelle.