Topic starter
02/08/2026 9:40 am
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.
Editorial analysis by NHI Mgmt Group, based on content published by OXSecurity: “Agility Meets Security: Kaltura’s Journey to Streamlined Development with OX Security”.
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.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Software supply chain visibility becomes a governance problem when appsec teams cannot turn distributed findings into consistent decisions.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:34 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Software supply chain visibility is now an appsec governance issue