The AppSec Context Gap - Code, Runtime, and Business

The Heeler team dedicated several months collaborating with research partners from various organizations to identify the most significant gaps in application security. A recurring theme emerged: the absence of context was a major issue, and obtaining this context was costly, often necessitating the involvement of key personnel from both security and development teams. Furthermore, this substantial time investment did not yield lasting value due to the dynamic nature of applications in cloud and agile environments, rendering these context investigations transient and expensive.

Due to the high cost of obtaining context, prioritizing security issues became impossible and crucial activities such as impact analysis, threat modeling, and developer guidance could only be performed on an ad hoc basis. This led to friction between security and development teams, as they were forced to work independently on different platforms to determine context and assess security impact. It became evident that the transformation needed to build secure and resilient applications requires a shared operating platform for security and development that automates code, runtime, and business context.

Code Context

It is the code that defines the intended state and behavior of an application. When assessing application security, it is crucial to have a deep understanding of the dependencies, data, APIs, and usage of AI involved in both first-party and third-party code. This context is essential for accurately identifying and addressing security issues. For most companies today, the challenge is not merely identifying problems in the code but understanding which issues matter most and, more importantly, how to operate more effectively to reduce future security debt.

Here are some examples of questions that code context can help answer:

• Where is the issue, which repository(s), which file(s), and which line number(s)?
• When was it introduced? By which team?
• Why was it introduced? What feature or bug fix was implemented when the issue was introduced?
• What are the dependencies?
• Which API(s) are impacted?
• What service to service connections are made?
• What data is made available to an LLM?
• What is the fix?

Ultimately code context by itself will leave a noisy list of issues with little guidance on the true security impact. "If a tree falls in a forest and no one is around to hear it, does it make a sound?", the same can be said with code context. Without knowing where the code is going and without knowing how it intersects with the infrastructure and related application services, does it matter? The code is your intended state, runtime is your actual state.

Runtime Context

Applications operate within an environment that includes data, network and identity considerations. Integrating application code with infrastructure configuration is crucial for understanding the impact of a security issue. Though evaluating runtime goes beyond the inside-out perspective of configuration and needs to include the outside-in activity which is how users (and attackers) engage with the application. Additionally, runtime context includes monitoring developer behavior, which can result in polluted or leaked code.

Here are some examples of questions that runtime context can help answer:

• Where is the issue in my environment?

• What deployments are affected? How many resources are impacted?
• What is the impact on the application?
• Is the affected resource Internet accessible?
• Does the affected resource provide or consume public APIs?
• Does the affected API transmit or consume sensitive information?
• Is sensitive data transmitted to 3rd party AI service?
• Has the behavior of the application changed?
• What is the technical impact of the security issue? Could an attacker pivot to cause greater damage?
• Has a repository been cloned from outside the expected network?
• Is the leaked secret still valid (active)?

Analyzing runtime context in real-time is essential for understanding the current impact and avoiding stale information that can lead to confusion and friction. Runtime context provides you with guidance into what is the technical impact of this security issue. Though still missing is what is the impact to the business. How can this security issue impact the trust of customers?

Business Context

Understanding the business impact is a significant gap in existing AppSec programs. Business context must convey the potential impact on the business and customer trust. This process is often highly manual, and insights are rarely communicated effectively to development teams to aid their guidance and understanding. When analyzing a security issue, it is essential to consider the importance of the application (tier) and the environment (e.g., production) to determine if there is a material or irreversible impact on the business

Here are further examples of questions that business context can help answer:

• What application is impacted? Is it the production deployment?
• How important is this application to the business? How much revenue is tied to the application?
• Who owns the affected application?
• What other services and applications are affected (upstream and downstream)?
• What is the level of customer trust at risk?

Heeler’s Unified Context

Heeler uniquely combines code, runtime and business context into a shared operating platform for security and development. This involves enriching the code and runtime context of the application with its importance to the business. Often, this process relies on tracing the communication paths of the application to identify dependencies that may directly or indirectly affect a critical application. For example, if a shared micro-service handling customer authentication for four critical applications is compromised or degraded, the impact on the dependent applications can significantly affect the business's bottom line.

One outcome of unified context is significantly improved prioritization that enables both security and development teams to assess the impact of security issues. But you cannot prioritize your way out of security debt as prioritization alone leads to a reactive strategy that overwhelms both development and security teams.

The benefit of Heeler’s unified context goes even further, enabling teams to evaluate the potential impact of code changes and remediations as they are being developed. Developers receive guidance within their existing workflows on how a change will impact the application before it is deployed to the running systems. The developer guidance acts as a force multiplier for security, allowing developers to make improved security choices with no additional time spent.

With Heeler, security teams are able to perform impact analysis and threat modeling continuously through the SDLC. They can provide business impact to developers which demonstrates the importance of fixing the issue and they provide remediation guidance which arms developers with the confidence to make the fix. Unified context helps identify not only what changes to make but also how those changes could positively or negatively impact the application.

Join the Heeler Revolution in Application Security

At Heeler, we're not merely solving today's problems; we're redefining what's possible in application security. Stay connected with us through LinkedIn and follow our journey as we continue to innovate and lead in securing applications across diverse environments. Heeler is here to transform application security, ensuring your applications are secure, resilient, and ready for the future.

‍