Topic starter
02/08/2026 9:40 am
TL;DR: 80% fewer false positives and 40% better critical issue resolution show what OXSecurity found in Kaltura case work. Software supply chain visibility then becomes a governance problem because findings only help when ownership and prioritisation are consistent.
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: 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.
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.
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.
Glossary terms: AppSec governance, Software supply chain visibility, Code-to-cloud visibility, False Positive Rate
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
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: Kaltura’s case shows appsec governance needs traceable supply chain control
This post was modified 5 days ago by NHI Mgmt Group