top of page
  • Writer's pictureDaria Chadwick

Why Garbage-In, Garbage-Out Will Be The Death of Your AppSec Program

Your organization's AppSec program is a key contributor to the successful functioning of all other organizational processes. The complexities involved in managing successful application security (AppSec) programs cannot be denied, and what you put in, is what you get out.

Managing an application security operation is inherently complex. It does not matter whether you come from Application Security or DevSecOps - the sheer complexity of the effort has likely made you feel grossly outnumbered and fatigued.

At ReactFirst, we’ve heard many leaders share this sentiment with us, regardless of the type of security approach these leaders chose to take. In working with them, we've gained interesting insight into what makes a successful AppSec program. More specifically, we've learned of some of the common pitfalls that should be avoided.

Tools are everywhere - but where's the platform?

Here is a list of common tools and processes that many organizations gravitate towards when building an application security program:


  • Static Application Security Testing (SAST)

  • Software Composition Analysis (SCA)

  • Container Scanning

  • Application Security Orchestration and Correlation (ASOC)


  • Application risk assessment questionnaires

  • Threat models / Security design reviews

  • Security code reviews

  • Penetration testing

  • Vulnerability prioritization & remediation

As the preceding tools and processes have become a de-facto standard and embedded in many workflows of AppSec practices across industries, it’s worth briefly re-evaluating their stance and premise. Ask if they are giving the returns they need to when it comes to your overarching AppSec program goals.

The Missing Link

We’ve seen many leaders have very few problems with these tools and processes when evaluated individually. Improvement is always possible, but for the most part, they serve their purpose. The main problem leaders face with these tools and processes is not the purpose they serve, but rather, how they act as a collective. More specifically, how they fail to act as a collective. The greatest purpose these tools collectively serve is providing context into the big picture of operations. A lack of context leads to a lot of noise, which produces a hefty pile of unnecessary work for engineers, developers, and managers alike.

Here is what missing context actually means. Let’s take SAST, a 20-year-old technology that scans a snapshot of code to detect vulnerabilities (e.g. SQL Injection, XSS). Let’s also take SCA, a 10-year-old technology that scans Open Source Software (OSS) dependencies to detect vulnerabilities.

While these tools are important, they do not understand the following:

  1. The history of the application & infrastructure code (components, security controls, and data)

  2. What constitutes a “product”

  3. The business impact of the product

  4. Whether the product is user-facing and/or internet-facing

  5. Whether the product stores/exposes sensitive data (e.g., PII, Payment, PHI)

  6. Regulatory requirements of the product

  7. The knowledge and security skill set of the developer

These are some examples of the context required to connect the dots across current tools and processes in order for teams to focus on the risks that matter most. These tools individually cannot connect the dots and trace back to the source code where the risk resides.

Let's say a new API was exposed by AWS API Gateway, and this API exposes PII data and a data leak was found due to missing authorization. Without this context being readily available, the engineer needs to manually connect the dots to find all the aforementioned context. This is needle in the haystack type work. It is neither reflective of the core competencies of the engineer or development teams, nor should it be on their plates. But without that natural context afforded to them, these engineers have to become investigators that go through a number of steps, including:

  1. Understanding the high-level product architecture

  2. Understanding where the authorization is implemented (is it in the code or at the API gateway level?)

  3. Discovering the relevant source code repository (out of hundreds/thousands)

  4. Finding the relevant API in the source code (out of hundreds/thousands)

  5. Identifying the relevant developer that developed this API

  6. Identifying the last person who changed the API, or the DevOps engineer that missed the authorization configuration on the API gateway so they can fix the problem

Not only does this process needlessly add hours of unnecessary work to an engineer’s plate, but it’s highly likely that this engineer doesn’t comprehensively document these valuable findings. This results in a broken feedback loop between engineers, which further perpetuates their backlog. This context issue could be remedied with proper visibility and communication amongst teams.

This is exactly the reason why all AppSec programs must start with visibility. Visibility translates to good application inventory and asset discovery.

Garbage-In, Garbage Out

Visibility is critical to help provide context and reduce noise/duplicate work. But when there is also a clear need to automatically and continuously assess the risk of applications, visibility provides even more value.

In theory, it makes sense to consolidate data surrounding the API effort. But most ASOC tools don't involve the required amount of care when it comes to sourcing, cleaning, and ingesting good data.

In the same way that organizations lifted and shifted obscene amounts of poor quality data and poor data models directly into the cloud, standard ASOC platforms do the same. These platforms simply ingest all the garbage from existing AppSec tools and processes, and spit out more garbage as a result.

Good API security relies on good decision-making supported by good data. By fueling an API security effort with poor data, you’re guaranteeing poor decision-making and poor outcomes as a result. This is entirely preventable.

Get Clarity, Automate the Mundane, Highlight the Risky

If you want to build an AppSec program that focuses your team on the risks that matter to your business, you should consider leveraging some external resources and supporting consolidation platforms to make sure no stone goes unturned and to centralize data.

Before selecting any kind of consolidation platform, be sure to go with a service that has clear experience and understanding of the GIGO problem. Ideally, the service and accompanying technology works with you as a bolt-on support system, helping you create the cleanest system of record to help support all your related workflows.

The supporting platform should be able to:

  • Enrich data from tools and processes that adds context on top of the visibility provided by the code, text, and developer knowledge analysis

  • Define governance and procedures early, but support frameworks that are flexible enough to continuously align with policy

  • Manage tools and processes based on context and assign relevant stakeholders

  • Help support automation and reporting through automated workflows, defined KPIs that continuously monitor and measure risk

  • Incorporate risk-based management reports, especially for executives. High-level dashboards and reporting capabilities should be able to readily identify the most pressing vulnerabilities.

This is true application risk management. This system gives AppSec practitioners not only the visibility needed to focus solely on risks that impact the business but also report on findings in a cohesive and actionable way. An important aspect in achieving this is to have multi-dimensional contexts weighed in to realize both probability and impact, which, without a centralized platform approach, is impossible to achieve.

Learn more in our guide or schedule a demo to see how ReactFirst can help reduce GIGO.


Introducing ReactFirst: an award-winning, comprehensive API threat remediation solution that goes beyond technology to help minimize the threat caused by API security vulnerabilities.

ReactFirst helps bring together a combination of capabilities - a program, technology, and team of experts - to appropriately address the risk caused by API vulnerabilities. Instead of merely identifying problems, it tracks the organization's ability to resolve them, providing a command and control structure that delivers the necessary insights and accountability to see each vulnerability move through the remediation process.

This program is backed by executive sponsorship, supported by cross-industry experts, and enabled by state-of-the-art technology. ReactFirst works as the perfect accompaniment to your existing API strategy, providing the transparency, oversight, and control into the API Remediation process your organization needs as the risk around API vulnerabilities grows.

Talk to us to see if the ReactFirst is a fit for you, and whether it help boost your API Remediation efforts into one you can trust:


bottom of page