Apiiro Blog ﹥ Introducing Code-to-Runtime: Enriching AppSec with True…
Product, Technical

Introducing Code-to-Runtime: Enriching AppSec with True End-to-End Visibility

Neta Coral
Product Manager
Ariel Levy
Software Architect
Published November 19 2024 · 5 min. read

For application security teams, connecting vulnerabilities identified in runtime back to their source in the code has long been a complex and time-consuming challenge. Apiiro’s new Code-to-Runtime capability directly addresses this difficulty, enabling AppSec practitioners to prioritize risks more effectively and ensure remediation reaches the right developers – without the need for manual setup or complex configurations.

In this post, we’ll explore why achieving true code-to-runtime mapping has been so challenging for the industry, how Apiiro’s Code-to-Runtime addresses these complexities through autonomous mapping, and what this means for AppSec engineers working to maintain secure software architectures.

The Challenge: Why Code-to-Runtime Mapping is Harder Than it Looks

In modern software development, containerization has become the standard for deploying and managing applications. By packaging an application and its dependencies into lightweight, isolated containers, developers can streamline both the deployment process and the maintenance of operational consistency. Containers are orchestrated to scale as needed and offer portability across different systems, making them an essential element of today’s cloud-native architectures.

At the heart of containerized deployment is the container image – a read-only template (a file system snapshot and configuration) that contains everything needed to run an application, from code and libraries to necessary dependencies. While many base images are sourced from public repositories, organizations often create custom images to meet specific security, compatibility, or compliance standards. Once deployed, these images become live instances (containers) within the runtime environment, where they are executed and interact with other services and systems.

The complexity arises when we try to connect a vulnerability detected in runtime back to its precise location in the original code. During the build process, code often undergoes transformations – such as compilation, minimization, and stripping of unused elements – which obscure the original structure and make it difficult to pinpoint the source of any issues.

Traditional approaches to matching runtime components back to their code sources rely on superficial indicators, such as naming conventions, tags, or pipeline metadata. But these methods entail additional effort and leave AppSec teams with incomplete visibility.

Why these methods don’t work:

  • High dependence on manual setup: Most existing solutions require developers to add tags, labels, or follow strict naming conventions to trace components. This manual effort is often inconsistent, leading to gaps in visibility and increased workload for AppSec teams.
  • Incomplete tracing in complex architectures: Many applications today are built on large monorepos with hundreds or thousands of interconnected modules. Shallow mapping approaches can sometimes identify the repository but rarely pinpoint the specific module or code component responsible for a vulnerability.
  • Transformation of code in runtime: During the build process, code undergoes multiple transformations that make it nearly impossible to trace accurately without deeper analysis.
  • Additional code in the build: Code-to-runtime matching services usually require AppSec teams to incorporate the matching code into their buildstep, or as an additional component in the CICD pipeline.
Consider a Java project compiled into a JAR archive and packaged inside a container image. The metadata from the pom.xml file (found in the source code) can be found inside the JAR as well, and indicate a match. Another possible hint is the entry class name, which can also be deduced from the META-INF metadata file, as well as the source code and java build configuration.
But relying on shallow indications, such as metadata or file names alone, is bound to result in false positives. In a large organization, the likelihood of duplications is too high to ignore, as different teams might use similar naming conventions or metadata. Additionally, not all features remain consistent across the build process — files can be stripped or altered, making shallow matches unreliable.

These limitations create a situation where AppSec teams face alert fatigue and are left with a partial view of their software’s security posture. This is the problem Code-to-Runtime was designed to solve.

How Apiiro’s Code-to-Runtime Solves This Problem

Unlike existing solutions that rely on metadata or manual input, Apiiro’s Code-to-Runtime takes an autonomous approach. Powered by our Deep Code Analysis (DCA) technology, Code-to-Runtime automatically matches runtime components back to their code source, identifying both high-level components (e.g., container images) and granular components (e.g., specific APIs or open-source packages) without requiring any manual setup. Apiiro also reduces the burden placed on AppSec teams to incorporate traceback-dedicated code into their build step –  all matching is done passively, requiring read-only access to the container registry.

Key features include:

1. Precise source-to-component mapping: By analyzing both the code repository and runtime components, Code-to-Runtime identifies unique “fingerprints” that connect code directly to the deployed runtime. This is achieved through a combination of indicators, including project-specific metadata and structural identifiers, to create a robust match between the source and runtime environments.

In a C# project, the invocation graph between different methods and 3rd party packages is susceptible to inlining and the removal of unreachable code, making direct correlations challenging. To improve our matching accuracy, we can focus on collecting a sufficient number of “hot spot” symbols – those identified by Apiiro as likely to remain untouched and unique to each project. This approach relies on a semantic understanding of these symbols and their overall role within the system.

2. Autonomous mapping without manual input: Apiiro’s approach eliminates the need for tags, labels, or naming conventions, removing dependency on CI/CD configurations or developer intervention. The platform passively scans both code and runtime environments, ensuring accurate mapping without interrupting the development pipeline – and requiring read-only access to the container registry.

3. Risk prioritization based on runtime context: Code-to-Runtime provides enriched insights by contextualizing vulnerabilities detected at runtime with information about the code. For instance, a container exposed to the internet is flagged with higher priority if it contains sensitive data handling or critical application logic in the source code. This allows AppSec teams to focus on the issues that matter most without sifting through false positives.

Real-World Application: Solving for Ownership in Monorepos

Consider a scenario common in large organizations that rely on monorepos: an AppSec engineer is notified of a potential vulnerability detected in a container image at runtime. With traditional tools, they might be able to trace this image back to a repository, but identifying the specific module or team responsible for remediation is nearly impossible without deep access to the original code structure.

With Code-to-Runtime, Apiiro analyzes the runtime container image alongside the source code in the monorepo. The platform can pinpoint the specific code components contributing to that container, allowing the AppSec engineer to identify not only the location of the vulnerability but also the correct code owner. This precision significantly reduces the time required to assign responsibility and address the issue.

Benefits for AppSec Teams

By providing a clear connection from code to runtime, Apiiro’s Code-to-Runtime capability enhances the efficiency and effectiveness of application security in several ways:

  • Reduced friction across teams: Without the need for manual tagging or naming conventions, AppSec engineers can now achieve consistent and accurate mapping, reducing friction with development and DevOps teams.
  • Improved risk prioritization: Enriched runtime context helps AppSec teams prioritize vulnerabilities based on real-world exposure, such as internet accessibility, or the presence of sensitive data in the source code.
  • Single pane of glass for security posture: Code-to-Runtime consolidates all relevant data, providing a unified view of software architecture and its risk posture across development, deployment, and runtime.

By solving the code-to-runtime challenge, Apiiro empowers AppSec engineers to take a proactive approach to security. This means they can focus on what truly matters – ensuring that vulnerabilities are accurately traced, assigned, and remediated before they pose a risk in production.

Looking Ahead

Code-to-Runtime is just one of the ways Apiiro is pushing the boundaries of application security posture management. As we continue to enhance our platform, we’re committed to addressing the challenges AppSec practitioners face in today’s complex software environments, where application architectures evolve rapidly and securing each layer is more critical than ever.

For more information on how Code-to-Runtime can strengthen your security posture, visit our documentation or contact us for a demo.