Apiiro Blog ﹥ Building Bridges Between Security and R&D:…
Product, Technical

Building Bridges Between Security and R&D: Apiiro’s Continuous Investment in Finding the Right Code Owner

Nadav Shakarzy
Product Manager
Karen Cohen
VP Product
Published September 25 2025 · 3 min. read

The Challenge of Code Ownership

In today’s fast-paced development environments, security and R&D often operate in silos. This disconnect makes it difficult to identify not just who contributed to a piece of code, but who is ultimately responsible for maintaining it and addressing vulnerabilities. Mapping ownership effectively is about more than tracking commits—it’s about connecting the right security champions to the right issues.

Apiiro bridges this gap, giving AppSec teams the tools and context they need to collaborate seamlessly with R&D. By identifying key contributors, context owners, and active maintainers, Apiiro ensures vulnerabilities are routed to the right people at the right time.

Why Git Blame Falls Short

For developers familiar with the codebase, Git Blame can provide initial context. But for security teams, it often leads to dead ends. The last committer is not always the true owner—sometimes it’s just someone who fixed a typo or updated formatting.

Apiiro addresses this by focusing on material changes—the significant contributions that define functionality. By analyzing these meaningful changes, Apiiro accurately identifies the people or teams responsible for maintaining critical areas of the codebase.

When the Original Owner is No Longer Active

Codebases evolve, and contributors move on. The original author of a component may no longer be active within the team—or even at the company. Assigning vulnerabilities to inactive owners wastes time and slows down remediation.

Apiiro prevents this by dynamically detecting active maintainers. Through analysis of recent contribution patterns, vulnerabilities are assigned only to current owners, keeping accountability clear and actionable.

Internal Package Detection: Closing a Major Blind Spot

One of the biggest blind spots in traditional Software Composition Analysis (SCA) tools is their inability to detect and govern internal (non-OSS) packages. These InnerSource components are widely used across large organizations and are therefore a source for major blast radius of vulnerabilities, yet remain invisible to most security programs.

Unlike open-source software, internal packages lack public vulnerability databases, making them even harder to monitor. They often house critical functionality—such as authentication libraries, data processing pipelines, or logging frameworks—that ripple across the entire organization. A single weakness in one of these packages can cascade into multiple systems, dramatically raising risk exposure.

Apiiro solves this by providing full visibility into proprietary dependencies. The platform not only detects internal packages directly from your repositories, but also integrates with your private registries to pull and analyze packages in use across the organization. With Apiiro, security teams can gain:

  • Centralized inventory of all internal packages across repositories
  • Mapping of package versions and full dependency trees, providing remediation context such as compatibility insights and recommended upgrade paths.
  • Identification of the exact teams responsible for maintenance
  • Assignment of risks to the right teams for faster remediation

This holistic view allows enterprises to manage their software supply chain with the same rigor they apply to open-source components. Instead of being caught off guard when an internal library turns out to be vulnerable, security teams can proactively track usage, prioritize risks, and enforce governance policies across the organization, preventing issues from spreading and limiting potential blast radius.

For enterprises, this visibility is critical. A single vulnerable authentication library, for example, could be embedded in dozens of services. Without tracking, patching one instance leaves the rest of the organization exposed. Apiiro ensures no vulnerable dependency slips through the cracks, empowering teams to address risks systematically and at scale.

Mapping Runtime Findings Back to Code

Runtime findings, such as vulnerabilities in APIs or containers, introduce a new layer of complexity when it comes to assigning ownership. These issues often surface in production, making it extra challenging to trace them back to the teams responsible for the underlying code.

Apiiro’s Deep Code Analysis (DCA) based Code-to-Runtime Matching addresses this challenge by mapping runtime findings to the relevant code, ensuring vulnerabilities are quickly assigned to the correct owner. For example, if an API vulnerability is discovered in production, Apiiro identifies the code owner responsible for the code that implements the API and denotes them directly in the risk summary. This eliminates ambiguity and speeds up the remediation process. You can learn more about this approach in our Akamai Technical Alliance Blog on API security.

When a container vulnerability is detected, Apiiro traces it back to the responsible team using its matching algorithms based on Deep Code Analysis (DCA). This not only identifies the right team but also links to the specific code dependencies that contributed to the vulnerability in the container. This clarity accelerates the remediation process by ensuring the right team can address the issue quickly. This approach is demonstrated in our Code-to-Runtime Blog on container findings, which shows how we connect container vulnerabilities to active code ownership.

The Apiiro Advantage

By combining deep code analysis, dynamic ownership mapping, and visibility into internal packages, Apiiro eliminates one of the biggest barriers between AppSec and engineering teams. Security practitioners gain confidence that vulnerabilities are routed correctly, while developers receive only the issues relevant to their areas of responsibility.

The result: faster remediation, reduced risk exposure, and stronger collaboration between security and R&D. With ownership made visible and actionable at every layer—from individual functions to internal packages to runtime systems—teams can work together to secure applications without slowing innovation.