Infrastructure Security Advisory Normalizer

Merges security advisories from CERT-Bund (BSI, Germany) and Microsoft MSRC into one clean schema, filters them against your infrastructure stack, enriches them with CISA KEV (and optionally EPSS), and returns a deterministically prioritized, machine-readable triage list — for MSP technicians, sysadmins, automations and AI agents.

This is not another NVD/CVE dump. Generic CVE actors hand you the whole database. This actor answers the question that actually costs you time every week: "Which of this week's advisories affect MY stack — and what do I patch first?" It deduplicates per source, normalizes product names and severities across German and English sources, never hides an advisory because of uncertain version data, and shows the full calculation behind every priority score.

Input

{
  "stack": [
    { "vendor": "microsoft", "product": "Exchange Server 2019" },
    { "vendor": "fortinet", "product": "FortiOS", "versions": ["7.4.2"] }
  ],
  "sources": ["cert-bund", "msrc"],
  "days_back": 14,
  "min_severity": "medium",
  "only_known_exploited": false,
  "status": "both",
  "max_results": 100
}

• stack is required (at least one entry with vendor). product and versions are optional.
• Simple mode: omit versions — matching happens on product level and the result is clearly flagged as product_match_version_unknown.
• Vendor-only entries ({"vendor": "fortinet"}) return all advisories of that vendor with vendor_match_only confidence.

Quick start: the input form is prefilled with a fast MSRC-only demo (Windows Server 2022, last 45 days, a few results in seconds). For a full triage keep both sources and set your own stack — the JSON above is the full-run default that API calls get when a field is omitted.

Example configurations (copy-paste)

1. Weekly Stack Triage (Microsoft on-prem)

Monday-morning triage for a typical Microsoft stack: every matching advisory from the last 7 days, ranked P1–P4, ready for your ticket system. Copy it, change the stack to yours, run it on a weekly schedule.

{
  "stack": [
    { "vendor": "microsoft", "product": "Exchange Server 2019" },
    { "vendor": "microsoft", "product": "Windows Server 2022" },
    { "vendor": "microsoft", "product": "Hyper-V" }
  ],
  "sources": ["cert-bund", "msrc"],
  "days_back": 7,
  "min_severity": "medium",
  "status": "both",
  "max_results": 100
}

2. Known-Exploited Watch (30 days)

Only what is actually being exploited: advisories listed in CISA KEV or flagged Exploited: Yes by the vendor, across your vendors. Near-empty most weeks — loud when it matters. Run it daily or weekly.

{
  "stack": [
    { "vendor": "microsoft" },
    { "vendor": "fortinet" },
    { "vendor": "vmware" }
  ],
  "sources": ["cert-bund", "msrc"],
  "days_back": 30,
  "only_known_exploited": true,
  "min_severity": "low",
  "status": "both",
  "max_results": 50
}

Vendor-only entries match every advisory of that vendor (vendor_match_only); the KEV/exploited filter is what keeps this config quiet.

Use it from n8n

Ready-made workflow: examples/n8n_weekly_triage.json (Schedule → Actor → filter P1/P2 → e-mail).

1. n8n → Workflows → Import from File → pick n8n_weekly_triage.json.
2. Set APIFY_TOKEN as an environment variable in n8n (or replace the query parameter with an n8n credential) — do not paste the token into the workflow.
3. Edit the stack in the Apify: run advisory triage node to your products.
4. Change the recipient in Email the finding (or swap the node for Slack).
5. Activate. It fires Mondays 07:00 and only e-mails P1/P2 findings.

It calls run-sync-get-dataset-items, so the workflow receives the finished dataset items directly — one n8n item per matched advisory. If your n8n version wraps the response in a single item, add a Split Out node after the HTTP Request.

Use it from AI agents (MCP)

The actor is plain request/response with a strict input schema, so it works well as an agent tool — no browser, no session state, deterministic output.

• Via Apify MCP: expose your Apify actors to an MCP-capable client (Claude, Cursor, or any MCP host) and call this actor by name (hankel_labs/infrastructure-advisory-normalizer). The agent supplies the same JSON input documented above.
• Directly over HTTP: POST https://api.apify.com/v2/acts/hankel_labs~infrastructure-advisory-normalizer/run-sync-get-dataset-items?token=… with the input JSON returns the ranked advisories in one call.
• Why it suits agents: every item carries match_reason, match_confidence and a priority_breakdown that sums exactly to priority_score — an agent can explain why something is on the list instead of guessing.
• Pay-per-result billing works for agentic use too: you are charged per emitted advisory, and max_results caps the cost of any single agent call.

Output (one dataset item per matched advisory)

Key fields (full example in examples/output.example.json):

Field	Meaning
advisory_id, source, source_url	Stable source ID (WID-SEC-… / CVE-…) and original link
normalized_product / original_product	Curated alias slug vs. raw source name
severity + severity_source	Normalized low/medium/high/critical; vendor, derived-cvss or default-unknown
cvss, cves, epss, known_exploited	Vendor CVSS, CVE list, EPSS score, CISA-KEV / vendor "Exploited: Yes"
affected_versions, fixed_versions	As published by the source
status	new or updated within the window
action_type	patch_available, workaround_only, mitigation, no_fix_yet, informational
matched_stack_item, match_reason, match_confidence	Why this advisory concerns your stack
priority_score, priority_band, priority_breakdown	Deterministic score with the full calculation

A summary.json (run window, per-source status, enrichment status, result counts, truncation flag) is stored in the run's key-value store.

Match confidence — and the safety rule

Confidence	Meaning
exact_version_match	Your version is provably inside a published affected range
product_match_version_unknown	Product matches; versions missing or not comparable
vendor_match_only	Stack entry named only the vendor

The actor never claims "not affected" based on uncertain version data. An advisory is only excluded when every published version spec was machine-readable and your versions are provably outside all of them. Anything uncertain is included, explained in match_reason, and scored with lower confidence.

Priority logic (v0.1, fully deterministic — no AI scoring)

Component	Points
Severity critical / high / medium / low	40 / 30 / 15 / 5
CISA KEV or vendor "Exploited: Yes"	+30
EPSS ≥ 0.5 / ≥ 0.1	+20 / +10
Exact version match / product-level match	+15 / +5
Internet-exposed product class (firewall, VPN, mail, hypervisor mgmt, backup, …)	+10
Patch available	+5
New advisory	+5

Capped at 100. Bands: P1 ≥ 80, P2 ≥ 60, P3 ≥ 40, P4 < 40. priority_breakdown in every item contains the exact calculation including the cap adjustment — the score is reproducible from the result itself.

Data sources & fetch behavior

• CERT-Bund WID — official CSAF 2.0 feed (TLP:CLEAR), published by BSI explicitly for automated retrieval: wid.cert-bund.de/.well-known/csaf/ (changes.csv, falling back to year directory listings).
• Microsoft MSRC — public CVRF v3.0 API (no authentication required): api.msrc.microsoft.com/cvrf/v3.0/.
• CISA KEV — single public JSON catalog, cached per run.
• EPSS — FIRST.org API, optional; if unavailable the run continues and the score component is 0.

Polite by design: plain HTTPS GETs with an identifying User-Agent, self-imposed rate limiting, per-run caching, a hard cap of 600 source documents per run. No browser automation, no proxies, no scraping of personal data, no LLM at runtime. One failing source never stops the run — the summary reports it.

Limits & disclaimer

• Best-effort aggregation of public advisories. No guarantee of completeness or correctness. This actor does not provide a full vulnerability assessment and is not a compliance product — it does not by itself fulfil NIS2, ISO 27001 or any regulatory obligation. It supports your triage; verification against the linked original advisory remains your job.
• MSRC publishes affected products mostly without comparable version ranges; those matches are honestly reported as product_match_version_unknown with fixed_versions (builds/KBs) attached.
• CERT-Bund documents often reference vendor fixes without explicit fixed version strings; action_type still reflects them.
• Fortinet PSIRT is planned as v0.2 (after the core proves itself) and is not part of this version.

Pricing

Pay-per-event: a synthetic apify-actor-start ($0.00005, triggered automatically by Apify) plus source-scan ($0.02 per successfully scanned source) and prioritized-advisory ($0.02 per emitted advisory, the primary event). A minimum two-source run with no matches is therefore about $0.04005.

Worked example (real test run): a two-source run capped at 10 emitted advisories charged $0.24005 in events (1 start + 2 source-scans + 10 advisories). Narrow stacks usually cost cents per run; broad Microsoft stacks around Patch Tuesday can reach $1–3 or more — control cost via max_results, a short days_back window, min_severity and your platform spending limit. max_results caps your cost.

On top of the event price you also pay Apify's normal platform usage (compute, data transfer); for the test run above that was about $0.019 of compute. Under "pay per event + usage" this variable usage is billed to the run as usual.

Charging is fail-closed: an advisory is only emitted after its charge succeeded; when your spending limit is reached the actor stops cleanly and flags truncated in summary.json; a real billing error aborts the run instead of silently emitting paid results for free. Details in docs/PRICING.md.

Memory: the configured minimum of 1024 MB is sufficient — no need to raise it. Peak resident memory measured in the release live runs was ~76 MB (MSRC month run 72 MB; combined CERT-Bund + MSRC run 76 MB), far below the 700 MB threshold that would have required 2048 MB. These are local (Windows) measurements; the Apify container value is confirmed on the platform run — see docs/RUN_REPORT.md.

Local development

python3 -m unittest discover -s tests -v   # offline test suite (no network)
apify run --purge --input-file=examples/input.example.json
apify push

---

Kurzfassung auf Deutsch

Dieser Actor führt Sicherheitswarnungen von CERT-Bund (BSI) und Microsoft MSRC in ein einheitliches Schema zusammen, filtert sie gegen Ihren Stack, reichert sie mit CISA KEV (und EPSS) an und priorisiert deterministisch mit offengelegtem Rechenweg. Unsichere Versionsangaben führen nie zum Ausschluss eines Advisories — sie werden aufgenommen, begründet und mit niedrigerer Konfidenz gekennzeichnet. Kein NVD-Dump: beantwortet wird die Frage „Was davon betrifft meinen Stack diese Woche, und was zuerst?". Keine Compliance-Garantie und kein Ersatz für eine vollständige Schwachstellenbewertung; bitte immer die verlinkte Originalquelle prüfen.