“Garbage-in, Garbage-out” is Killing your Application Security Program

Your application security program is a key contributor to the successful functioning of all other organizational processes. The complexities involved in managing a successful application security (AppSec) program cannot be denied and what you put in, is what you get out. In this article, Moshe Zioni, VP of Security Research, Apiiro, talks about how to ensure the success of your application security operations.

Managing an application security operation is inherently complex. It does not matter whether you come from Application Security or DevSecOps – you are grossly outnumbered and fatigued by the sheer complexity of the effort. At Apiiro we have seen many different approaches to application security and have gained insights into what makes an AppSec program successful. 

One of the simplest ways to understand why some programs are more successful than others is to highlight common mistakes we have seen in the field and how you can avoid common pitfalls.

We Become What We Behold

Like Nicky Case’s game, We Become What We Behold, AppSec has multiple cycles that we need to navigate and it all comes down to the applicable tools that you have at hand. To level set – here is a list of common tools and processes that many organizations gravitate towards when building an application security program:

1. Tools
   1. Static Application Security Testing (SAST)
   2. Software Composition Analysis (SCA)
   3. Container Scanning 
   4. Application Security Orchestration and Correlation (ASOC)
2. Processes
   1. Application risk assessment questionnaires
   2. Threat models / Security design reviews
   3. Security code reviews
   4. Penetration testing
   5. 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, let’s re-evaluate their stance and premise.

See More: What Is Application Security? Definition, Types, Testing, and Best Practices

The Missing Link

The main problem with SAST and SCA tools is that they are missing context. This leads to a lot of noise (false positives) that eventually produces a hefty pile of unnecessary work for AppSec engineers and developers alike.

Here is what missing context actually means: SAST is a 20 year-old technology that scans a snapshot of code to detect vulnerabilities (e.g. SQL Injection, XSS), and SCA is a 10 year-old technology that scans Open Source Software (OSS) dependencies to detect vulnerabilities. Both tools do not understand the following:

1. The history of the application & infrastructure code (components, security controls, and data) across repositories and in one detection engine
2. What constitutes a “product”
3. The business impact of this product
4. If this product is user-facing and internet-facing
5. If this product stores/exposes sensitive data (e.g., PII, Payment, PHI)
6. The regulatory requirements of the product
7. The knowledge and security skill set of the developer

These are just a few examples of the context needed to connect the dots across all the results from current tools and processes in order to focus AppSec engineers only on the risks that matter.

Today, this context is being collected manually using an application risk assessment questionnaire, which is based on self-attestation and not correlated to the source code. This is a huge industry-wide problem that slows down delivery, increases costs and eventually leads to dev teams releasing code with risks. You can collect this context automatically and continuously using a new technology of code, text and developer knowledge analysis.

Looking only at the number of vulnerabilities per snapshot of code in a repository and prioritizing them based on CVSS score is a proven doomed-to-fail approach. Your AppSec team will waste their time and your developers’ time, in turn, without remediating the relevant risks.

ASOC and other DevSecOps platforms aim to consolidate all the AppSec tools and processes into one “single pane of glass” to reduce noise and false positives by normalizing the data and removing duplicates. The problem with these tools is that they do not understand the code. Moreover, they cannot understand who changed what and what missing context is needed to make informed decisions. 

These tools cannot connect the dots and trace back to the source code where the risk resides. For example, a new API was exposed by AWS API Gateway, this API exposes PII data and as part of the bug bounty program (i.e., HackerOne) a data leak was found due to missing authorization.

Now the outnumbered AppSec engineer needs to manually connect the dots and find the context and that is quite the needle in the haystack challenge. The steps would include:

1. Understanding the high-level product architecture and where the authorization is implemented – is it in the code or at the API gateway level?
2. Discovering the relevant source code repository (out of hundreds/thousands)
3. Finding the relevant API in the source code (out of hundreds/thousands)
4. Identifying the relevant developer that developed this API and 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

This is exactly the reason why all AppSec programs must start with visibility. This means Application Inventory and Asset discovery. Further to that, there is a clear need to automatically and continuously assess the risk of their applications.

In theory, it makes sense to consolidate AppSec processes and tools but in reality, ASOC tools ingest all the garbage from existing AppSec tools and processes and spit out more garbage.

See More: Application Security Engineer: Job Role and Key Skills for 2021

Achieve 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 must have one platform that provides:

1. Visibility:

• Scan code and text (from commit messages, PR discussions and user stories in Jira) to automatically discover application and cloud infrastructure assets (e.g., components, security controls, sensitive data, frameworks, developers knowledge, and business impact) and maintain a real-time inventory
• Automate risk assessment and change management processes accordingly

1. One Control Plane

• Enrich data from AppSec tools and processes and add context on top of the visibility provided by the code, text, and developer knowledge analysis 
• Trigger and manage AppSec tools and processes based on context and alert/assign the relevant people based on their knowledge
• Manage all risks from one place (sensitive data exposure, cloud infrastructure misconfigurations, secrets, vulnerabilities and more) 
• Define governance and have a continuous assurance of security and compliance requirements early in the SDLC

1. Automation & Reporting

• Define automated remediation workflows
• Define KPIs and continuously measure your risk
• Get risk-based management reports

This is Application Risk Management (ARM). Such a system gives AppSec practitioners not only the visibility needed to focus solely on risks that impact the business, but also reports 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 context is impossible to achieve.

Did you find this article helpful? Tell us what you think on LinkedInOpens a new window , TwitterOpens a new window , or FacebookOpens a new window . We’d be thrilled to hear from you.