Software supply chain visibility is now an appsec governance issue

At a glance

What this is: This case study describes how Kaltura used Active ASPM to improve software supply chain security, reduce false positives, and improve critical issue resolution.

Why it matters: It matters because appsec and cloud security teams need governance models that scale with delivery speed, tool sprawl, and code-to-cloud risk.

By the numbers:

• Kaltura observed an 80% decrease in false positives and a 40% increase in critical issue resolution.

👉 Read OXSecurity's case study on Kaltura's software supply chain security programme

Context

Software supply chain security is the governance layer that connects source code, dependencies, build systems, cloud deployments, and the identities allowed to move changes through them. In this case, the problem was not a single exploit but the operational drag created by too many tools, too much noise, and too little prioritisation. For appsec and cloud teams, that is an identity and access problem as much as a code risk problem, because every pipeline, service account, and automation path expands the control surface.

Kaltura's situation is typical of organisations trying to balance agile delivery with stronger security oversight. The case study shows that the real challenge is not finding more issues, but deciding which ones deserve immediate attention and which workflows can safely be automated. That is where software supply chain governance intersects with NHI and workload identity management: the systems that build and deploy software are themselves privileged actors.

OXSecurity presents Active ASPM as the mechanism used to tie these pieces together for Kaltura, but the broader lesson is architectural. When security signals are not prioritised, engineering teams absorb the cost through slow remediation, noisy alerts, and fragmented accountability. The issue is common across modern appsec programmes, not unique to this deployment.

Key questions

Q: How should security teams reduce tool sprawl in software supply chain security programmes?

A: Security teams should consolidate findings into a small number of decision points rather than more dashboards. The objective is to standardise triage, ownership, and remediation routing across code, build, and cloud layers. When tool sprawl creates overlapping alerts, the programme loses speed and accountability at the same time.

Q: Why do false positives slow down appsec and DevSecOps programmes?

A: False positives slow programmes because engineers stop trusting findings that do not reliably predict real risk. Once that happens, triage becomes manual, remediation slows, and security teams spend more time defending the tooling than fixing exposure. In fast-moving delivery environments, noise becomes an operational blocker.

Q: What breaks when code-to-cloud visibility is missing in software supply chain security?

A: When code-to-cloud visibility is missing, teams cannot trace how a finding moves from source to build to deployment and runtime impact. That makes prioritisation inconsistent and leaves privileged automation paths under-governed. The result is fragmented accountability and slower containment when real risk emerges.

Q: How do you know if appsec automation is actually improving governance?

A: You know automation is working when it shortens decision time, improves critical fix rates, and reduces manual back-and-forth at triage. If the programme still depends on human interpretation for every alert, automation has only scaled output, not control.

Technical breakdown

How software supply chain visibility changes appsec operations

Software supply chain visibility means tracking risk across code, dependencies, build pipelines, deployment paths, and cloud runtime rather than treating each layer separately. In practice, this reduces blind spots between development and production where insecure artefacts, risky libraries, or misconfigured delivery controls can slip through. The important shift is that visibility must be actionable, not just observational, or teams end up with more alerts and no clearer decision path.

Practical implication: consolidate signals so engineering and security can prioritise the same risk queue.

Why false positives become a delivery problem

False positives are not only a detection-quality issue. In high-velocity development, excessive noise changes team behaviour, causing engineers to distrust findings, delay triage, or bypass controls that are perceived as unreliable. A security programme that cannot distinguish material from immaterial findings will push work back into spreadsheets and manual debate, which undermines both speed and accountability.

Practical implication: tune detection and triage logic around developer workflow, not just security coverage metrics.

What OSC&R style risk modelling adds to supply chain security

A structured risk model helps normalise how findings are classified, prioritised, and operationalised across environments. That matters in software supply chains because the same weakness can have different impact depending on where it appears, how it is invoked, and which privileges the surrounding automation holds. For appsec, the value is not the framework name itself but the discipline of translating findings into consistent risk decisions.

Practical implication: map supply chain findings to a repeatable risk rubric before assigning remediation ownership.

NHI Mgmt Group analysis

Software supply chain governance has become a prioritisation problem, not just a scanning problem. The article shows that tool proliferation and alert noise can slow deployments as effectively as a real vulnerability. That is the key governance failure mode in modern appsec programmes: teams know too much and decide too little. The practical conclusion is that security value now depends on triage quality, not scan volume.

Code-to-cloud visibility is now a control-plane issue for modern delivery systems. When pipeline, code, and cloud signals are separated, accountability fragments and remediation becomes reactive. This is especially relevant where service accounts, CI/CD runners, and deployment automation act as privileged non-human identities. The distinction matters because NHI governance is increasingly embedded in appsec, even when the case study is framed as software supply chain security.

False-positive reduction should be treated as a governance metric, not a vanity metric. An 80% drop in noise only matters if it changes who acts, when they act, and how quickly they can close the loop. If teams still need manual interpretation to trust the output, the programme has improved reporting but not control. Practitioners should measure whether lower noise actually shortens decision time.

Named concept: security-to-delivery friction. This post illustrates the drag created when security tooling, prioritisation, and developer workflows are not aligned. The concept is useful because it captures a repeated failure pattern across appsec and software supply chain programmes. Practitioners should treat friction as an operational risk that weakens both release velocity and security assurance.

For identity programmes, the important signal is how much trust the pipeline is given. The build and release chain is a chain of privileged actors, many of them non-human, and the article reinforces that these identities need lifecycle, access, and workflow governance. That is where appsec and NHI governance meet: controlling what can act, what it can reach, and how its risk is reviewed. The practitioner conclusion is to manage pipeline identity as a first-class part of software supply chain defence.

What this signals

Security-to-delivery friction will remain the hidden tax on appsec programmes until teams treat prioritisation as a control. Visibility alone does not reduce risk if every team interprets findings differently. The practical shift is toward shared decision logic for code, pipeline, and cloud risk, with governance anchored in repeatable outcomes rather than alert counts.

Pipeline identities now deserve the same governance attention as human admins. CI/CD runners, build tokens, and deployment service accounts can create the same blast radius as over-privileged users if their lifecycle is unmanaged. That is where appsec and NHI governance converge, and the control question becomes whether the organisation can prove who or what is allowed to move code into production.

Aligning appsec with the NIST SP 800-53 Rev 5 Security and Privacy Controls and OWASP Non-Human Identity Top 10 helps convert noisy findings into enforceable policy. Teams should use those standards to define ownership, access scope, and remediation thresholds across the delivery chain. The programme signal to watch is whether lower noise produces faster closure, not just cleaner reporting.

For practitioners

• Map security findings to engineering decision paths Define which findings trigger immediate remediation, which enter backlog, and which are suppressed with documented justification. The goal is to reduce debate at triage time and make prioritisation consistent across teams.
• Measure alert quality against remediation speed Track whether reductions in false positives shorten time to fix critical issues and improve engineer trust in the platform. If noise drops but decision time does not, the control is not materially improving operations.
• Treat CI/CD runners and pipeline service accounts as governed identities Inventory the non-human identities that can build, sign, approve, or deploy software, then review their access scope, rotation, and offboarding controls. Software supply chain risk often persists because these identities are invisible in standard IAM processes.
• Use a repeatable risk rubric for code-to-cloud findings Classify issues by exploitability, blast radius, and delivery stage so the same weakness is handled consistently whether it appears in source, build, or runtime. A shared rubric prevents local teams from inventing their own severity logic.
• Align appsec tooling with workflow automation Automate only the parts of the process that do not require human judgment, such as routing, enrichment, and assignment, while preserving manual control for high-impact decisions. No-code automation only helps when it reduces toil without obscuring accountability.

Key takeaways

• Software supply chain security fails when visibility is abundant but prioritisation is weak.
• An 80% reduction in false positives only matters if it shortens remediation time and clarifies ownership.
• Appsec teams should govern pipeline identities and workflow automation as part of the same control plane.

Key terms

• Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.
• False Positive: A false positive is a scanner result that looks like a secret but is not actually sensitive. In secret governance, false positives matter because they consume analyst time, weaken trust in alerts, and can delay response to the findings that truly change exposure and access risk.
• Code-to-cloud visibility: Code-to-cloud visibility is the ability to trace a security issue across source, build, deployment, and runtime environments. It helps teams understand where a problem originated, which identities touched it, and how far its impact may extend across the delivery chain.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

What's in the full article

OXSecurity's full case study covers the operational detail this post intentionally leaves for the source:

• Specific platform workflow design used to route, prioritise, and automate findings across Kaltura's development lifecycle.
• Detailed account of how OSC&R-based risk management was adapted to the company's software supply chain.
• Implementation detail on how code-to-cloud visibility was applied without disrupting existing development operations.
• The full outcome narrative behind false-positive reduction and critical issue handling across teams.

👉 OXSecurity's full case study covers the workflow design, risk prioritisation, and implementation detail behind the results.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners connect identity controls to the broader operational risks that shape delivery and resilience.