Cyber Resilience Act complianceverified on every commit.
Every firmware change is audited against the CRA and your own safety rules in seconds. A finding reaches your GitHub or Jira only after its rule and its evidence have been checked against the diff. Zero false positives across 40 hand-labelled commits.
Now accepting pilot partners · Read-only repository access · No code stored beyond the evidence you choose to retain
Engineering moves at commit speed. Compliance moves at document speed.
An engineer raises a geofence ceiling from 120 to 150 metres on a Tuesday. The change is reasonable and the reason is sound. Nobody in that pull request knows the constant is written into a risk assessment, or that changing it invalidates a test signed off eight months ago.
Today that surfaces at the next quality review, weeks later. Sometimes it surfaces in an audit. Sometimes it does not surface at all. Under the Cyber Resilience Act, a substantial modification can require a new conformity assessment — and the modification is a single line in a header file.
TraceGuard closes the gap at the commit, not at the release.
The model proposes. Code decides.
Language models are useful for reading a diff against regulatory prose. They are not trustworthy as the final authority on a compliance verdict, and no amount of prompting changes that. TraceGuard separates the two roles explicitly.
Hypotheses, structured
The model returns findings in a schema: rule ID, file path, a literal quotation from the diff, the reasoning, and a recommended action. No free-text parsing anywhere in the pipeline.
Verification, by code
Every finding is then checked by code, not by a model. The cited rule must exist in your document. The file must be part of the change. The quoted evidence must appear literally in the diff, line by line. Anything that fails is discarded and logged as discarded.
Severity comes from your document
Never from the model. The verdict is computed by the engine from the findings that survive verification — the model never declares it.
Injection-aware
Diff content and commit messages are treated as data under audit, never as instructions. An attempt to steer the analyser from inside a code comment is detected by pattern and escalated to human review instead of being silently obeyed.
What a verdict looks like
A real output from the evaluation repository. The ticket carries the same content: the rules breached, the reasoning, and the exact lines that triggered it.
Measured, not asserted
Every number on this page comes from an evaluation harness that ships with the system and can be re-run on demand.
VIOLATION SR-01 SR-08 The change raises the maximum operating altitude ceiling from 120 m to 150 m, exceeding the certified limit and breaching the altitude ceiling rule; the behavioural change also requires re-running the safety test suite. evidence firmware/include/safety_params.h -#define GEOFENCE_MAX_ALTITUDE_M 120 +#define GEOFENCE_MAX_ALTITUDE_M 150 7.8 s · €0.018 · 3.1k / 573 tok · ticket SAFE-284
| Measurement | Result |
|---|---|
| Main set — 30 hand-labelled firmware commits | 100% precision · 100% recall |
| Holdout set — 10 commits the system had never seen | 100% precision · 100% recall |
| Verdict stability — 10 ambiguous cases × 3 runs | No verdict changed across 30 runs |
| Rule compiler vs. CRA Annex I, hand-written ground truth | 94.4% recall · 77.8% precision |
Your standard, compiled into evaluable rules.
You do not rewrite your safety documentation. TraceGuard ingests the PDF — a CRA annex, an internal safety manual, an ISO 13849 risk assessment — and proposes machine-evaluable rules with thresholds, severities and indexing terms.
Every rule cites its source
A proposed rule that cannot be quoted literally from your document is discarded automatically. Across 175 rules extracted from the CRA, zero fabricated citations.
Paperwork is separated, not ignored
Obligations no diff can breach — CE marking, retention periods, notified bodies — are listed in an appendix rather than fired at your engineers on every commit.
Your team approves before anything runs
Proposed rules are reviewed and corrected by your quality team. Nothing reaches production until they sign it off.
Any standard, same engine
CRA today. IEC 61508, ISO 13849, EN 4709, FDA guidance: a different input document, not a different product.
Nothing new for your engineers to learn.
There is no portal to log into, no tool to adopt, no workflow to change. Findings arrive where your team already works: as a ticket in your own Jira project or your own GitHub Issues, with the rule, the exact line and the recommended action.
Install a GitHub App on one repository
Read-only access to contents, write access to issues. Nothing else. Only the repositories you select. Uninstallable at any time, without telling us.
A push arrives, signed
The webhook signature is verified over the raw bytes with HMAC-SHA256. Acknowledged in milliseconds; analysis runs asynchronously and never blocks your pipeline.
The change is filtered, then audited
Binaries, lockfiles and generated artefacts are dropped first. A change too large for a reliable verdict produces no verdict — it produces a ticket asking for human review.
A ticket appears in your board
Severity from your document, deduplicated on redelivery. If a later commit removes the line, the ticket is annotated — never closed automatically: confirming a safety finding is a human decision.
Built for a team that will ask hard questions.
| Control | Implementation |
|---|---|
| Repository access | GitHub App with per-installation tokens issued by GitHub. Contents read-only, Issues read-write, scoped to the repositories you select. Isolation is enforced by GitHub, not by our code. |
| Credential storage | Customer tokens encrypted with AES-256-GCM before they reach the database, with a per-secret derived key. The database never sees plaintext. |
| Tenant isolation | Row-level security enabled with no policies on every operational table. Only the server's service role can reach them. Every record carries its owner. |
| Source code handling | Diffs are processed in memory. Only the evidence fragment supporting a finding is retained, because an audit trail without evidence is worthless. |
| Retention | Configurable. After the window you choose, evidence is deleted and the audit trail — verdicts, rules cited, timestamps — survives without it. |
| Offboarding | Your full analysis history is exported to you, then deleted in a single cascading transaction. We will show you the exact SQL that does it. |
| Data residency | Application and database hosted in Frankfurt (eu-central). Diff content is sent to our language-model provider for analysis; details on the data handling page. |
| Model training | Your code is never used to train models. |
No system is impenetrable. We will tell you which vectors are closed, which remain open, and why — before you ask.
Asked first, answered plainly.
Does the Cyber Resilience Act apply to our firmware?
If your product has digital elements and is placed on the EU market, Regulation (EU) 2024/2847 applies. Obligations phase in through 2027, with vulnerability reporting starting earlier. TraceGuard detects engineering changes that affect those requirements; conformity itself is certified by a notified body.
Do you store our source code?
No. The diff is processed in memory. Only the evidence fragment that supports a finding is retained, because an audit trail without evidence is worthless, and you choose how long it is kept before it is deleted.
What permissions does the GitHub App request?
Contents read-only and Issues read-write, scoped to the repositories you select. No organisation-wide access and no administration permissions. You can uninstall it at any time without telling us.
Is the analysis deterministic?
The verification layer is: rule existence and evidence matching are checked by code. The language model that proposes findings is not deterministic, and anyone claiming otherwise is overselling. Across 30 repeated runs on the most ambiguous cases, no verdict changed.
How many false alarms should we expect?
Zero across 40 hand-labelled commits, including ten the system had never seen. An engineer who receives one false alert mutes the tool within a week, so the goal is not to detect a lot — it is to never interrupt anyone without a reason.
Does it work with GitLab or Azure DevOps?
Not yet. GitHub and Jira are supported today. The engine is separated from its integrations by design — the second issue tracker took one working session — so tell us what you use and we will give you a real date rather than a promise.
A technical walkthrough, not a sales call.
Thirty minutes. You describe how your team finds out today that a change invalidated a test or a document. We compile one of your safety documents into proposed rules and send them back for your team to correct. That commits you to nothing and takes us a day.
Pilots are free and run for two weeks. We would rather find out the product is wrong from a team that tells us than announce a launch to nobody. Prefer email? Write to diego.macias@traceguard.eu.