TL;DR: DLT security can look sound at the code level yet still fail under load, dependency delays, or upgrade changes, according to CertiK, so institutions need runtime evidence of availability, consistency, and recovery as well as static review. Governance now depends on proving how the system behaves when assumptions break, not only whether the code passes inspection.
At a glance
What this is: This is CertiK’s analysis of Chain Scan, which links static code review with runtime testing to show how DLT systems behave under failure conditions and operational stress.
Why it matters: It matters because DLT programmes used for payments, settlement, and other critical workflows need evidence of resilience, not just code correctness, to support governance and service continuity.
Context
Distributed ledger technology is moving from pilot use into operational environments where availability, recovery, and consistency matter as much as code correctness. In that setting, a code review that finds no obvious defect can still miss system-level failure modes when demand spikes, dependencies slow, or upgrades change resource use.
That makes DLT assurance a governance problem as well as an engineering one. Institutions need evidence that the system behaves safely under realistic stress, including how failures spread, whether quorum holds, and how quickly services recover.
Key questions
Q: How should teams validate DLT resilience before production rollout?
A: They should combine static code review with isolated runtime testing against realistic demand, dependency, and failure conditions. The goal is to learn whether the live system remains available, consistent, and recoverable when assumptions break, not just whether the repository looks clean. Version-specific evidence should be kept with the release being assessed.
Q: What breaks when DLT systems are tested only at the code level?
A: Teams miss failure modes that appear only when nodes, dependencies, and network conditions interact. A codebase can be logically sound while the live system still stalls consensus, exhausts resources, or recovers too slowly under stress. That gap turns a technical issue into an operational resilience problem for regulated services.
Q: How do security and resilience teams know if DLT testing is actually working?
A: They should look for repeatable evidence that the same fault scenario produces consistent results, that remediation removes the issue, and that later rescans confirm the fix still holds. If the assessment does not produce versioned checkpoints, clear PASS or FAIL outcomes, and repeatable retests, it is not giving governance teams reliable evidence.
Q: Which governance obligations does DLT runtime testing support?
A: It supports the evidence needs behind operational resilience and ICT risk management, especially where institutions must show that critical services can continue through disruption. The test results do not certify compliance, but they do provide oversight teams with concrete proof about response, recovery, and remediation status.
Technical breakdown
Why static code review is not enough for DLT systems
Static code review examines logic, implementation choices, and known vulnerability patterns in a repository or release. It is useful, but it cannot reproduce the interactions that emerge when multiple nodes, network conditions, external dependencies, and real workloads are present at the same time. A DLT system can therefore look sound in source code while still failing under consensus pressure, resource exhaustion, or degraded infrastructure. That gap matters because the operational question is not only whether a defect exists, but whether the live system remains available and correct when conditions change.
Practical implication: Treat static review as one assurance layer, not the whole control, and pair it with runtime testing before production decisions.
How isolated runtime testing exposes availability and recovery failures
Runtime testing recreates the relevant environment in isolation and then introduces controlled stress conditions such as heavy demand, dependency problems, abnormal network behaviour, or mixed-version upgrades. The point is to observe whether the system stays consistent, whether failover mechanisms work, and how quickly normal operation returns. This approach surfaces failure propagation that static analysis cannot measure. It also creates evidence that can be repeated after releases or configuration changes, which is essential when the environment itself is part of the risk picture.
Practical implication: Run representative fault scenarios in a non-production environment and compare recovery behaviour across releases.
Why continuous assurance is now part of DLT governance
Continuous assurance means repeating scans and tests on a scheduled basis and after material changes. That matters because commits, forks, protocol upgrades, dependency updates, and infrastructure changes can alter the risk profile of a DLT system without changing its headline purpose. Evidence gathered before launch can become stale after a major release. Governance therefore depends on checkpointed evidence that can be compared across versions, not a one-time assessment that quickly ages out.
Practical implication: Tie reassessment to releases and material changes so resilience evidence stays aligned with the current environment.
Threat narrative
Attacker objective: The objective is to destabilise availability and disrupt transaction processing, consensus, or recovery in a critical distributed system.
- Entry occurs when a peer, dependency, or operational change triggers behaviour that was not safely bounded in the live DLT environment.
- Escalation happens when resource exhaustion, consensus disruption, or dependency failure spreads beyond the initial condition and affects quorum or correctness.
- Impact is service interruption, delayed transactions, or recovery that takes longer than the business can tolerate.
Breaches seen in the wild
- tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
DLT assurance is now a resilience discipline, not a code-quality exercise. Once distributed ledger systems support payments, settlement, and other critical workflows, assurance has to answer whether the service survives realistic operational stress. Static review can identify defects, but only runtime evidence shows how consensus, failover, and recovery behave when the environment changes. Practitioners should treat runtime behaviour as a governance signal, not an afterthought.
System-level failure modes are the real risk in distributed infrastructure. A weakness that looks local in source code can become a service-wide availability issue when multiple nodes, shared dependencies, and network conditions interact. That is why the operational boundary matters: the failure may not be theft or corruption, but interruption, delayed transactions, or slow recovery. Institutions should measure the blast radius of runtime faults, not just the presence of code flaws.
Continuous assurance closes the gap between development and regulated operations. Scheduled and change-triggered retesting matters because the risk profile shifts as releases, forks, dependencies, and topology change. A system validated before launch may no longer behave the same after an upgrade. This is where software supply chain security thinking intersects with DLT governance: versioned evidence must stay current if oversight teams are to trust it. Practitioners should build recurring validation into the lifecycle, not rely on one-time review.
Operational resilience frameworks are the right lens for DLT evidence. Basel operational resilience principles and DORA both emphasise severe-but-plausible testing, remediation, and continuity under disruption. That is the correct governance frame for distributed systems because the question is not just whether code is safe, but whether the institution can keep critical operations running. Teams should align technical testing with resilience obligations and treat PASS or FAIL evidence as oversight input.
Read next: Software Supply Chain Security Guide
What this signals
Runtime assurance is becoming the deciding control for DLT programmes. As distributed systems move into regulated operations, the important question shifts from whether code is correct to whether the service still behaves safely when demand, topology, or dependencies change. Practitioners should expect resilience evidence to matter more in governance reviews and change approvals.
Version drift creates assurance drift. Every fork, dependency update, protocol upgrade, or infrastructure change can make old evidence less trustworthy, even when the business use case stays the same. The practical response is to bind testing to releases and material changes so oversight teams are not relying on stale assumptions.
Operational resilience and identity governance now intersect at evidence quality. Where distributed platforms depend on multiple services, keys, and operational roles, governance teams need current proof that those controls still work after change. This is not a tooling question alone; it is a lifecycle assurance problem that should be tracked as part of broader control effectiveness.
For practitioners
- Define the assessment scope by release and architecture Pin the repository, branch, commit or release, and include relevant forks, packages, and version context so the assessment matches the system being operated.
- Pair static scanning with runtime fault testing Use both methods together so code-level findings and live behaviour are assessed in the same assurance cycle, especially for consensus and recovery risks. See the Software Supply Chain Security Guide.
- Test failure propagation, not only component behaviour Measure whether a fault stays contained, whether failover works, and how quickly normal operation returns after stress is introduced.
- Re-run checks after material changes Trigger rescans and retests after protocol upgrades, dependency updates, topology changes, and new releases so evidence stays relevant.
Key takeaways
- DLT systems can appear secure in code yet still fail at runtime when load, dependencies, or upgrades alter behaviour.
- CertiK’s analysis shows that availability, consistency, and recovery are the decisive assurance outcomes for regulated distributed systems.
- Institutions should make runtime retesting part of the release and change process so resilience evidence stays current.
Related NHI Mgmt Group resources: Software Supply Chain Security Guide · Infrastructure as Code Security Guide · SOC Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, NIST CSF 2.0, CIS Controls v8 and SLSA set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0007;TA0040 — Discovery; Impact | The article focuses on runtime failure modes that disrupt availability and service continuity. |
| Recommendation — Map disruptive runtime behaviours to ATT&CK impact and resilience tests that show how faults affect service availability. | ||
| NIST CSF 2.0 | PR.IR-04 — Adaptive Incident Response | The article emphasises recovery, failover, and repeatable validation after change. |
| Recommendation — Use PR.IR-04 to validate that recovery mechanisms still work after protocol and infrastructure changes. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Scheduled rescanning and retesting are central to the assurance model described. |
| Recommendation — Build recurring rescans and retests into your control programme so new releases do not outpace assurance. | ||
| SLSA | L3 — Build provenance | The post stresses version-specific evidence and change-triggered reassessment across releases and forks. |
| Recommendation — Track release provenance and reassessment evidence so runtime findings remain tied to the correct build or version. | ||
| ISO/IEC 27001:2022 | A.5.29 — Information security during disruption | The subject is maintaining service continuity and recovery during operational disruption. |
| Recommendation — Apply A.5.29 to ensure disruption testing and recovery evidence support continuity decisions. | ||
Key terms
- Runtime assurance: Runtime assurance is the practice of validating how an application actually behaves after deployment. It matters because configuration, identity flow, and integration state can change security outcomes in ways that source code analysis alone cannot prove.
- Operational Resilience: Operational resilience is the ability to keep critical services running or recover them quickly after disruption. In identity-led environments, that depends on authentication services, privilege management, and recovery procedures that can be tested under realistic failure conditions.
- Continuous Runtime Testing: Continuous runtime testing is automated security testing that runs against live or newly deployed applications on every build or deployment cycle. It produces evidence from real runtime behavior, which makes it better suited to DevSecOps than a periodic penetration test that captures only one moment in time.
- Version-Specific Baseline: A version-specific baseline is a recorded security and resilience snapshot tied to a particular repository state, release, or configuration. It gives practitioners a stable reference point for comparing later scans and retests after upgrades, commits, or environmental changes.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org