DORA register errors expose the limits of scanner-built inventories

At a glance

What this is: This analysis shows that first-wave DORA submissions exposed how many institutions still cannot assemble a complete dependency and outsourcing inventory from their existing tooling and records.

Why it matters: For IAM, PAM, NHI, and broader governance teams, the same visibility gap affects third-party access, service ownership, and machine identity lifecycle control across regulated environments.

By the numbers:

• The average JavaScript project carried 683 transitive dependencies in J.P. Morgan's Eye on the Market analysis.
• The median time to remediate vulnerabilities was 43 days in the 2026 Verizon DBIR.

👉 Read Kusari's analysis of DORA register errors, dependency inventories, and provenance gaps

Context

DORA reporting exposed a governance problem that many security and compliance programmes already suspected but could not easily prove: institutions often know their direct suppliers, but not the full chain of dependencies behind them. In practice, that means inventories, ownership records, and outsourced-service mappings can look complete until a regulator asks for the evidence in a machine-readable form. The same problem appears across identity and access governance when service ownership, external delegation, and privileged access paths are spread across multiple teams.

A scanner-built inventory is not the same thing as a source-built inventory. Scanners inspect finished artefacts and manifests, but they do not reconstruct the full dependency graph, the build provenance, or the vendor-of-vendor chain that compliance now expects. That distinction matters for IAM and NHI governance because access decisions, service accountability, and machine identity controls all depend on knowing what exists, who owns it, and how far trust is delegated.

Key questions

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. That means the inventory can look compliant while still failing the regulatory question that matters most: what is actually in scope, who owns it, and how far trust has been delegated?

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. A single vulnerable dependency can therefore affect many services at once, which means visibility into software composition is as important as patching speed.

Q: How do security teams know whether an inventory is actually trustworthy?

A: A trustworthy inventory is reconcilable across source, build, and runtime records. If the same system produces different answers depending on which layer you inspect, the inventory is not trustworthy enough for regulatory reporting or access governance. Teams should look for consistent component lists, provenance evidence, and named accountability for outsourced services.

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.

Technical breakdown

Why scanner-built inventories stop short of regulatory truth

Most inventory tools operate from the delivered artefact, not from the source and build systems that created it. That means they can read a manifest, resolve a limited number of direct dependencies, and then lose visibility into the deeper graph where transitive components, provenance, and hidden supplier relationships live. The result is not an obvious error. It is a report that looks complete while silently omitting the very layers regulators are asking about. For regulated environments, that creates a compliance gap that also affects access governance and trust decisions.

Practical implication: build inventories from source and build pipelines, not only from runtime scans.

Why vendor-of-vendor chains change the ownership problem

Sub-outsourcing is a graph problem, not a list problem. Once a service depends on another provider's provider, simple spreadsheet ownership models break down because each node can have different legal, operational, and recovery obligations. This is where identity governance overlaps with third-party risk: service accounts, delegated access, and machine identities often sit inside those same outsourced pathways. If the organisation cannot map the chain, it cannot confidently assign accountability or define recovery commitments with precision.

Practical implication: map contractual and technical ownership together so each outsourced dependency has a named accountable owner.

Why provenance matters as much as component inventory

A component list tells you what should be inside a package. Provenance tells you where the package actually came from and whether the distributed artefact matches the source it claims to represent. That distinction mattered in incidents such as SolarWinds and XZ, where trust was broken at the artefact or release layer rather than by a simple missing component entry. For compliance and security teams, provenance closes the gap between inventory and integrity, which is especially important when bought software and internally built software converge in the same estate.

Practical implication: pair inventory controls with provenance attestation and artifact-source comparison.

Threat narrative

Attacker objective: The objective is to exploit blind spots in the dependency graph so that trust, accountability, or malicious artefact changes remain outside effective governance.

1. Entry occurs through incomplete dependency and supplier visibility, where the organisation can only partially reconstruct what its software and services depend on.
2. Escalation follows when missing transitive components, blank outsourcing data, or absent provenance prevent accurate ownership and trust validation.
3. Impact is regulatory failure, delayed incident response, and a wider inability to answer what systems, vendors, or identities are affected when a control question arrives.

NHI Mgmt Group analysis

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.

Source-built dependency graphs are the new baseline for regulated software estates. Scanner-only approaches miss the layers where transitive risk, provenance, and supplier relationships accumulate. That is not a tooling inconvenience, it is a structural mismatch between how software is assembled and how regulators now expect it to be evidenced. Organisations that keep relying on artifact-level snapshots will keep discovering that their records are legally tidy but operationally insufficient.

Provenance drift is the named failure mode this episode exposes. The issue is not simply that inventories are incomplete, but that the running artefact can diverge from the source and build state the organisation thinks it owns. That failure mode matters across software supply chain, cloud, and machine identity governance because trust decisions depend on the integrity of the object being granted access or counted in scope. The practitioner conclusion is that provenance and inventory must be governed as one control surface.

Regulatory pressure is forcing identity programmes to inherit supply chain truth. Once outsourcing chains, service ownership, and ICT assets must be reported together, identity teams can no longer separate machine account governance from third-party governance. Service accounts, delegated admin paths, and access entitlements often sit inside the same outsourced dependencies that DORA now asks institutions to enumerate. The field should expect tighter coupling between identity governance, supplier risk, and evidence collection.

The control gap is not visibility in principle, but verifiable completeness at speed. Quarterly manual exercises can satisfy a filing deadline once, but they do not create an always-current trust map. The next phase of governance will reward organisations that can reconcile source, build, and vendor data continuously rather than assemble it reactively. Practitioners should treat completeness, freshness, and provenance as the three metrics that determine whether an inventory is actually usable.

What this signals

Provenance drift: when the recorded inventory and the running artefact no longer match, regulatory reporting and operational trust fail together. That is why source-to-build reconciliation is becoming a core governance control, not a supply chain nicety.

The broader signal for security programmes is that evidence collection has to move closer to the systems that create change. Teams that can continuously map dependencies, ownership, and delegated access will be better positioned to satisfy DORA-style requests, while also improving machine identity and third-party access governance.

The same control pattern will matter beyond compliance. As outsourced services, service accounts, and cloud dependencies continue to multiply, the organisations that can prove completeness in near real time will spend less effort assembling reports and more time reducing risk.

For practitioners

• 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.
• Reconcile identity and supplier records Align service accounts, delegated access paths, and third-party contracts in one evidence model so identity governance and supplier risk tell the same story.

Key takeaways

• The filing errors exposed a deeper governance gap: many institutions still cannot prove a complete dependency and outsourcing chain when asked.
• Scanner-built inventories are useful but insufficient because they miss deeper transitive layers, provenance, and vendor-of-vendor relationships.
• Practitioners should treat source-built inventories, provenance attestation, and named ownership as a single control surface for compliance and resilience.

Key terms

• Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.
• Sub-outsourcing Chain: A sub-outsourcing chain is the sequence of downstream providers used by a vendor to deliver a service. It matters because accountability, resilience obligations, and data or access risks do not stop at the first supplier. Regulators increasingly expect organisations to understand the whole chain.
• Provenance Attestation: A provenance attestation is evidence that software was produced through a known pipeline or workflow. It helps verify origin, but it does not guarantee that the workflow was free of compromise, poisoned caches, or attacker-controlled inputs.
• Register Of Information: A Register of Information is the live record a regulated organisation uses to describe its assets, dependencies, and controls. Under DORA, its value depends on accuracy, completeness, and the ability to reflect changes in the operating environment rather than storing a stale compliance snapshot.

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.

👉 The full Kusari article breaks down the filing errors, inventory failure modes, and source-built alternatives in detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle controls. It is designed for practitioners who need to connect identity governance to the broader security programmes their organisations depend on.