Known Limitations
Read this before trusting a result. These are accepted, documented, and surfaced to the user in the UI banner and in every generated report.
:::danger Not legal advice Every CRITICAL/HIGH finding needs legal confirmation. The license tier table has not been ratified by counsel — that is milestone M-8, and it is the single gate between the current prototype and operational use. :::
1. Distributed-unit granularity
Compatibility conflicts are computed over the transitive subtree of a root. Two components in different processes do not actually conflict, but if they share an SBOM root they will be reported as conflicting.
You need an executable/process boundary map to make this precise — request it from the supplier. Until then conflicts are conservatively over-reported. This is tracked as P2-06 and TD-03.
2. DEPENDS_ON is not a linkage statement
If the SBOM only uses DEPENDS_ON, the tool conservatively assumes static linkage. That
over-reports; it is the safe direction, but expect pushback from suppliers.
Every finding raised on this path states "linkage not declared", so the supplier can correct the
SBOM and the finding disappears. Ask for STATIC_LINK / DYNAMIC_LINK in the quality agreement
(see S-4).
3. No per-file analysis
A package with filesAnalyzed: false is taken at its declared license. Real audits need
file-level scanning (ScanCode / FOSSology) to catch mixed-license files inside a package. This is
P2-04.
4. License text is not matched
Only license IDs are matched, plus a keyword heuristic for LicenseRef- entries. The actual
license text is never parsed, so a custom license that behaves like the GPL but does not mention
it by name will be missed.
Related: the expression parser does not validate against the SPDX license list, so a typo'd identifier classifies as UNKNOWN rather than erroring (TD-09).
5. The score is a triage aid, not an SLA metric
It is normalised by component count, and the weights are judgement, not calibration — they have not been fitted against historical outcomes. Read the score as a trend indicator between milestones. See Risk Scoring.
6. Graph rendering is capped
Rendering is capped at 600 nodes: roots, high-risk and high-degree nodes are kept, and the hidden count is reported. The layout itself is O(n²) per tick, which is fine to roughly 1 000 nodes (TD-04).
7. No persistence, no workflow
Every session re-analyses from scratch, and there is no approval or waiver workflow. Auditors ask for the waiver register, not the scan — that is Phase 2 (P2-01, P2-02).
8. Single-ECU, single-SBOM view
There is no cross-ECU or cross-supplier roll-up. Each analysis is one SBOM at a time.
9. Not tested against real supplier SBOMs
All fixtures are synthetic. The false-positive rate has not been calibrated against a real supplier delivery — that is the first thing to do in Phase 2 (RR-02).
Summary table
| Limitation | Direction of error | Mitigation | Phase 2 item |
|---|---|---|---|
| No process boundary map | Over-reports conflicts | Documented; request boundary maps | P2-06 |
| Undeclared linkage | Over-reports copyleft reach | Every finding says "linkage not declared" | S-4 |
| No per-file analysis | Under-reports mixed files | Take declared license at face value | P2-04 |
| No license-text parsing | Under-reports custom licenses | Keyword heuristic only | P2-04 |
| Score weights uncalibrated | Unquantified | Treat as a trend indicator | TD-10 |
| Tier table unratified | Unknown | Legal confirmation required | M-8 |
:::tip The pattern is intentional Every ambiguous case resolves towards more caution, never less, and always with a visible, correctable reason attached. A compliance tool that silently under-reports is far more dangerous than one that asks you to confirm. :::