TL;DR: Kaltura reports that OX Active ASPM helped cut false positives by 80% and increase critical issue resolution by 40% while extending code-to-cloud visibility across its software supply chain, according to OXSecurity. The real lesson is that security tooling sprawl slows delivery when prioritisation and workflow automation are not aligned to engineering reality.
At a glance
What this is: Kaltura’s experience shows how software supply chain visibility, prioritisation, and automation can reshape application security governance when tool sprawl is slowing delivery.
Why it matters: Appsec and platform teams need to treat supply chain visibility as a governance control because fragmented tooling can obscure risk, delay remediation, and weaken engineering adoption.
By the numbers:
- Kaltura saw an 80% decrease in false positives after consolidating its security approach, according to OXSecurity.
- Kaltura recorded a 40% increase in critical issue resolution, according to OXSecurity.
Context
Software supply chain visibility is the ability to trace risk across code, build, deployment, and runtime touchpoints. In practice, appsec programmes struggle when those touchpoints are monitored by separate tools that generate too many findings and too little prioritisation.
This article is about the governance side of that problem: how teams decide what deserves attention, how security work fits engineering flow, and how much of the software supply chain is actually visible to the people responsible for release assurance. The Kaltura case looks typical for modern engineering teams that have accumulated tools faster than they have created an operating model.
Key questions
Q: What breaks when software supply chain visibility is fragmented across appsec tools?
A: When visibility is fragmented, teams cannot turn findings into a coherent risk decision. That usually produces alert fatigue, inconsistent ownership, and slow remediation because engineers must interpret each tool separately. The result is not just slower response, but weaker governance over what gets fixed first and what is allowed to ship.
Q: Why do software supply chain issues create so much appsec governance friction?
A: They cross multiple layers at once, from code and build pipelines to deployment and runtime context. If those layers are governed separately, appsec teams lose the ability to see how one weakness moves through the delivery chain. That is why visibility must support prioritisation and accountability, not just detection.
Q: What are the signs that appsec visibility is failing to improve software supply chain security?
A: Common signs include a high volume of findings with little change in remediation speed, repeated manual triage, and developers ignoring security output because it does not map to their workflow. If visibility is working, fewer issues should linger, and critical items should move faster to resolution.
Q: How should security teams govern software supply chain risk in application delivery?
A: Treat software supply chain risk as a lifecycle control problem, not just a vulnerability-management issue. Teams should govern dependency trust, build integrity, release signing, and the service accounts that can alter artefacts. The key question is whether any identity in the pipeline can change what gets shipped without strong approval and provenance controls.
Technical breakdown
Why software supply chain visibility breaks down in appsec stacks
Software supply chain visibility fails when scanning, triage, and remediation live in disconnected systems. Teams may have broad coverage on paper, but if findings do not converge into a usable risk view, engineers see noise rather than actionable control. In appsec governance terms, visibility is not the same as insight. A flood of alerts without context forces teams to choose between moving fast and staying safe, which is exactly the trade-off mature programmes are supposed to remove.
Practical implication: Consolidate findings into a single risk model so engineers can act on severity, exploitability, and business impact rather than raw alert volume.
How prioritisation and automation change security workflow design
Prioritisation determines which vulnerabilities or supply chain exposures are routed first, while automation reduces the cost of turning that decision into action. No-code workflows matter because they let security teams encode escalation and ownership without forcing every change through manual triage. That does not eliminate judgment, but it does shift governance from ad hoc ticket handling toward repeatable policy execution. In appsec programmes, automation is only useful when it reflects how engineering already ships software.
Practical implication: Map severity and ownership rules into workflow automation so remediation paths match how code is built, reviewed, and released.
Why code-to-cloud visibility is now an appsec control
Code-to-cloud visibility connects source code, build artefacts, cloud deployment, and runtime context so appsec teams can see where a weakness becomes operational risk. That matters because software supply chain exposure rarely stops at the repository. It travels through CI/CD, package dependencies, infrastructure configuration, and deployment permissions. In a governed environment, the goal is not simply more scanning, but a traceable control path that shows how software risk moves across the delivery chain and where intervention actually changes outcomes.
Practical implication: Track controls across the delivery chain, not just inside code review, so ownership and risk acceptance remain visible from commit to production.
Threat narrative
Attacker objective: The practical attacker objective in this pattern is to exploit the weakest governed point in the software supply chain before the organisation can reliably detect and prioritise it.
- Entry begins in the software delivery chain, where accumulated tools and fragmented visibility leave gaps between code, build, and deployment oversight.
- Escalation happens when security findings are not prioritised well enough to separate true supply chain risk from benign noise, allowing high-risk issues to linger.
- Impact is slower release flow, weaker developer adoption, and reduced confidence that security controls are actually governing the path from code to cloud.
Breaches seen in the wild
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
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
Software supply chain visibility has become an application security governance issue, not a tooling issue. The decisive question is no longer whether teams can scan more places, but whether findings are converted into governed decisions that engineering can use. When appsec coverage exists without decision quality, programmes accumulate data faster than they reduce risk. Practitioners should treat visibility as an operating model problem first and a tooling problem second.
Tool sprawl creates governance debt in appsec programmes. Multiple scanners and workflow systems can make security look more complete while making action slower. That delay is especially damaging in software supply chains, where the risk path spans code, build, package, and cloud layers. The practitioner lesson is to reduce the number of handoffs between detection and remediation.
Code-to-cloud visibility: this is the control concept that matters here because software supply chain risk only becomes governable when the chain from commit to runtime is traceable. Kaltura’s example shows that visibility is most useful when it supports prioritisation, ownership, and repeatable response. Teams should measure whether they can follow a risk from source change to deployed service without losing accountability.
OSC&R-style coverage only matters when it changes triage behaviour. Framework alignment is useful if it helps teams decide what to fix first, not if it merely adds another layer of reporting. The governance test is whether security policy can be expressed in the workflow the engineering team actually uses. Practitioners should favour controls that shorten the path from finding to resolution.
Engineering adoption is now a core security outcome. The article shows that reduced false positives and faster critical issue resolution are not just operational wins, they are evidence that the security model is easier to use. In appsec governance, a control that developers cannot absorb becomes an exception generator. Practitioners should assess whether their supply chain controls improve decision quality and developer uptake at the same time.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
- Read next: AI Supply Chain Security and AI-BOM Guide
What this signals
Software supply chain visibility debt is what happens when teams own many scanners but no single risk path from commit to cloud. That debt shows up as slower remediation, inconsistent ownership, and a growing gap between what is observed and what is actually governed.
The practitioner response is to treat appsec visibility as a control design problem. If the organisation cannot explain how a finding becomes a decision, the programme is not yet governing the supply chain, only observing it.
For practitioners
- Consolidate software supply chain risk views Create a single governance layer that merges code, build, deployment, and runtime findings so appsec teams can prioritise by risk rather than by tool output.
- Automate triage and ownership routing Define no-code or low-code workflows that route findings to the right engineering owner based on severity, service criticality, and deployment context.
- Measure false positives as an adoption signal Track whether alert quality is improving developer trust and remediation throughput, not just whether scan volume is increasing.
- Extend governance past repository scanning Treat CI/CD, cloud deployment, and runtime exposure as part of the same control surface so visibility does not stop at the source code boundary.
Key takeaways
- Software supply chain visibility becomes a governance problem when appsec teams cannot turn distributed findings into consistent decisions.
- Kaltura’s case shows that reducing false positives and improving critical issue resolution can make security work more usable for engineering teams.
- The control objective is not more scanning, but a traceable path from code change to deployed service with clear ownership and prioritisation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API9 — Improper Inventory Management | The article centres on visibility and inventory across a distributed software delivery chain. |
| Recommendation — Inventory code, build, and deployment assets so appsec findings can be tied to the correct software path. | ||
| CIS Controls v8 | CIS-2 — Asset Inventory and Control | Supply chain visibility depends on knowing which code, services, and pipelines exist and are in use. |
| Recommendation — Maintain an authoritative inventory of software assets and delivery pipelines to support governance. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Appsec governance depends on controlling who and what can change code, pipelines, and deployments. |
| Recommendation — Restrict pipeline and deployment permissions so only authorized identities can alter software delivery paths. | ||
| MITRE ATT&CK | TA0007;TA0009 — Discovery; Collection | Supply chain attackers rely on discovering weak points and collecting secrets or artifacts across the chain. |
| Recommendation — Map supply chain visibility gaps to discovery and collection tactics in your detection engineering. | ||
Key terms
- Software supply chain visibility: Software supply chain visibility is the ability to see what software components, dependencies, build steps, and delivery paths are present in an application and how they change over time. It includes tracing source code, packages, containers, signatures, and deployment artifacts so security teams can detect tampering, hidden risk, and unapproved changes.
- AppSec governance: The set of policies, ownership rules, review gates, and evidence requirements used to control application security outcomes. In AI-heavy delivery environments, governance must operate earlier in the pipeline because late-stage review may no longer have enough time or context to be effective.
- Code-to-cloud visibility: Code-to-cloud visibility is the ability to trace a security issue from source code through deployment into the runtime environment. It matters because the same defect can look harmless in development but become high risk once it is connected to identities, secrets, and production access.
- False Positive Rate: False positive rate is the share of alerts, detections, or test results that incorrectly indicate a problem when none exists. In security and identity operations, it measures how often a control flags benign activity as suspicious, usually expressed as a percentage of all negative cases. Lower rates reduce analyst noise and wasted response effort.
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 the NHI Foundation Level course, the industry's only accredited NHI security programme, if your programme needs stronger identity governance across modern delivery environments.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org