CRA component cockpit

During the scan, XICTRAQ detects server software, CMS, frameworks, libraries, CDN, WAF, payment and consent components from server headers, generator meta tags and embedded scripts. Exactly this tech stack is the sole data source of the cockpit. It does not read any internal dependency files — so it knows only what a website makes visible externally and cannot see deeper-nested dependencies.

The list carries the timestamp of the last tech-stack check (last_tech_check_at). This shows how current the derived components are. A new scan refreshes the list; existing acknowledgements are kept as long as a component's key does not change.

The cockpit knows ten categories: server, CMS, plugin, framework, library, CDN, WAF, payment, consent and font. Not every category can be detected externally on every website — the cockpit shows only what the scan actually determined. Components without a detectable version (such as a CDN) appear without a version number and without a version notice.

A finding carries a severity from “low” to “critical” and an eol flag if the version branch is no longer maintained. The cockpit counts the potentially outdated components and reports the highest occurring severity (worst_severity) in the overview. The terms follow common practice but are not an official or certified classification.

Where the heuristic associates known vulnerabilities with a version branch, the notice names the CVE identifiers with a link to the public detail page, a recommended target version (fixed_in) and, where available, a vendor advisory link. Only the single most severe matching finding is shown per software. The associated CVEs refer to the version branch as a whole and do not necessarily affect your specific installation.

The heuristic produces version and CVE notices only for a curated list of eight widely used software families whose version a website typically reveals externally: PHP, nginx, Apache httpd and OpenSSL on the server side, the website and shop systems WordPress and Shopware, plus jQuery and Bootstrap on the front end. Each family has its own thresholds below which a finding with a severity is raised. All other detected components still appear in the inventory and the export but receive no version or CVE notice. The list is editorially maintained and not a complete vulnerability catalogue.

For software that typically comes from a Linux distribution — PHP, nginx, Apache httpd and OpenSSL — the cockpit additionally marks the notice with “backport possible” (distro_backport). This is a reminder that distributions often apply security fixes without a version bump, so the externally visible version is no reliable patch indicator. For WordPress, jQuery and Bootstrap this flag is not set, because there the version number usually tracks the patch level directly.

Via the export endpoint you receive a CycloneDX 1.5 file in JSON format as a download (filename sbom-<host>.cdx.json). It contains the detected components with name and — where known — version and package URL (purl in the form pkg:generic/<name>@<version>). The category itself is not a separate field in the file; instead it determines the CycloneDX type of the component: server, framework, library and CMS are emitted as “library”, all other categories as “application”. If a component carries a CVE notice, the export attaches it as the property “xictraq:cve_hint”. Because the list is derived from the externally visible tech stack, it cannot reflect deeper-nested dependencies — complement it with your internal bill-of-materials data where needed.

You answer “Do you place a product with digital elements on the market?” with yes, no or not yet decided. On “yes” you additionally pick the applicable product kinds from six options: downloadable desktop program, mobile app, browser extension, device with its own software or firmware, remote data processing as an integral part of a product, or software customers run themselves (on-premise). The declaration applies to your account, not per website, and can be changed at any time. While the question is unanswered the cockpit keeps showing the deadlines and states explicitly that the scope has not been clarified yet.

If you answer “no”, the deadline tiles disappear from the cockpit and the daily reminder cron skips your account entirely — whoever places no products with digital elements on the market does not carry the CRA obligations, and for them a CRA deadline is not worth a message. The component inventory, the outdated notices and the CycloneDX export are unaffected: they remain useful without any CRA obligation, simply to know what runs on your website.

The cockpit tracks two dates: the start of reporting and notification obligations (11 Sep 2026) and the full application of the regulation (11 Dec 2027). For each date the cockpit shows the remaining days (days_until).

A reminder cron runs once a day (06:30 server time). An alert of type “cra_deadline” is triggered solely by the finding: the website must carry at least one component with severity “high” or “critical”. An approaching deadline on its own reports nothing — it applies to every account at the same time and moves by exactly one day per day, which would produce a wave of alerts with no connection to any action. If the next pending deadline — since 11 Sep 2026 the full application on 11 Dec 2027 — additionally falls within a stage of 90, 30 or 7 days, the cron adds the remaining lead time to the alert text; the stage therefore words the alert rather than raising it. The alert goes out through the regular notification channels (email, Slack, Teams and others) and is deduplicated via an alert key (website plus worst severity plus deadline stage), so the same situation reports only once. If the situation changes — a different worst severity or the next stage —, a new alert reports and closes the previous one without an all-clear; at most one “cra_deadline” alert per website is open. Components with a “medium” or “low” notice do not trigger an alert.

If the reason disappears, the cron resolves the open “cra_deadline” alert on its next run by itself — for instance once you have updated the affected component, once the severity drops below “high”, or once you answer the scope question with “no”. That is not a detail: the alert list filters on open, not on acknowledged, and an alert that never closes would stand there permanently and make a settled situation look like an ongoing one. If after your change the website no longer reveals any version number at all, the cron does not close the alert: that would be an all-clear for something nobody could check. Close such an alert by hand.

The closer a due date moves, the more prominent the notice. The threshold is fixed: with more than 90 days lead time “info”, at 90 days or less “warning”, at 30 days or less “critical”. A date that has already passed deliberately falls back to “info” and is shown as “in force for N days”: an expired deadline is a fact, not an incident — kept permanently red it would blunt the display and mask real findings. The banner is a reminder, not a statement about whether and which obligations apply in your specific case. Which CRA obligations affect you must be clarified with qualified advice.

Via the acknowledge function you mark a component by key (component_key) as acknowledged and can attach a free-text note — for example a note that a distro backport already closes the gap. The cockpit stores the timestamp (acknowledged_at). With the undo flag you reverse an acknowledgement. This documents in a traceable way which notices you have assessed.

The checklist asks six items: whether software components and versions are documented (SBOM-like list), whether a process for security updates and EoL replacement is established, whether known vulnerabilities are monitored and assessed regularly, whether a channel to receive vulnerability reports exists, whether a plan to respond to security incidents is in place and whether third-party components are reviewed contractually and technically. The counter shows the confirmed items (for example “3/6”). The answers stay in the browser only and are not sent to the server.

Three tiles show the total number of detected components (components_total), the number of components carrying a notice (outdated_count, labelled “potentially affected”) and the highest occurring severity (worst_severity). Below the number you see how many of the detected components disclose a version number at all — only those can be checked by the heuristic. If there is not a single notice, “no findings” is shown instead of a severity; if not one component discloses a version, it reads “not assessable”. Many servers deliberately hide their version, and then a zero says nothing about the patch level.

The overview shows per website the total number of components (components_total), the number of potentially outdated components (outdated_count), the number of components with a readable version (assessable_count) and the highest severity (worst_severity), plus the timestamp of the last tech-stack check. Below it the total of potentially outdated components across all websites is shown — as a prioritization aid for your CRA preparation.