Notifications
Clear all
Topic starter
18/08/2026 2:10 pm
TL;DR: Roughly a third of first-wave DORA Register of Information submissions returned invalid or missing LEI codes, while blank sub-outsourcing templates were common, showing that manual, scanner-led inventories still fail when institutions must map dependency chains and vendor-of-vendor relationships, according to Kusari. The real issue is not filing quality but governance blindness across source, build, and supplier data.
NHIMG editorial — based on content published by Kusari: DORA register errors reveal the limits of scanner-built inventories
By the numbers:
- The median time to remediate vulnerabilities was 43 days in the 2026 Verizon DBIR.
Questions worth separating out
Q: What breaks when software inventories are built only from scanners?
A: Scanner-only inventories usually stop at the manifest and a small part of the dependency tree, so the deepest transitive components, provenance, and supplier relationships never appear in the record.
Q: Why do transitive dependencies create such a large security problem?
A: Because most teams do not install every library directly, they inherit risk through frameworks, plugins, and bundled components they may not know are present.
Q: How do security teams know whether an inventory is actually trustworthy?
A: A trustworthy inventory is reconcilable across source, build, and runtime records.
Practitioner guidance
- Build source-native dependency inventories Reconstruct software and service dependencies from source repositories and build systems, then reconcile them with runtime scans so deeper transitive layers are not lost in the manifest.
- Map sub-outsourcing chains to named owners Assign a business and technical owner to every material outsourced dependency, including vendor-of-vendor relationships, so gaps in accountability are visible before reporting cycles begin.
- Add provenance checks to inventory workflows Compare distributed artefacts against source and build attestations, and flag any divergence between what was released and what is actually running.
What's in the full article
Kusari's full analysis covers the operational detail this post intentionally leaves for the source:
- How the DORA Register of Information templates map to ICT assets, sub-outsourcing chains, and contractual evidence.
- Why scanner-built inventories miss the deeper dependency graph and where source-built approaches change the evidence model.
- How SPDX, CycloneDX, and in-toto attestations support verifiable provenance across built and bought software.
- What the article's filing-error patterns suggest about where organisations should start their remediation work.
👉 Read Kusari's analysis of DORA register errors, dependency inventories, and provenance gaps →
DORA register errors: why scanner-built inventories keep failing?
Explore further
18/08/2026 3:03 pm
Inventory completeness is now a governance control, not a reporting exercise. The DORA filing errors show that many institutions still treat asset and dependency records as periodic paperwork. In reality, incomplete inventories create downstream failures in accountability, resilience, and access control. When ownership and dependency chains cannot be assembled on demand, the governance model itself is incomplete, which makes the problem visible across IAM, PAM, and third-party access programmes.
A question worth separating out:
Q: Who is accountable when outsourcing chains cannot be fully mapped?
A: Accountability sits with the organisation that must file the record and operate the service, even when the missing data sits with suppliers. That means compliance, security, and procurement teams need a shared ownership model for sub-outsourcing evidence, because a blank template is still a governance failure when a regulator asks for the chain.
👉 Read our full editorial: DORA register errors expose the limits of scanner-built inventories
