Code risk is multi-dimensional: How to build an AppRisk program

Call to Action: Transform your AppSec program into an AppRisk program!

Today, everything is code! From developing the application logic, adding PII to a DataModel, changing a network policy, adding IAM roles, to publishing a new API in the cloud API gateway and configuring authorization control.

When thinking about code risk, we have a tendency to focus on – and limit ourselves to – vulnerabilities and detection tools like SAST, SCA, DAST, IAST or even orchestration tools that connect them together.

Relying only on those tools is fundamentally misguided because they miss a significant amount of context, which leads to a lot of noise and False Positives. This slows down developers’ progress and holds back digital transformation.

There are multiple Secure Development Lifecycle (SDLC) process gates, each functioning independently of the others and it looks different from one application security program to another:

Most of the time, we examine each gate without looking at the full context across all development stages. Material code changes and configurations need to combine in order to create a vulnerability. This requires taking into account many factors, from design to code to production (e.g., the schema of the data type to the validation of inputs to the security controls on the production systems).

Looking at those items as a single dimension won’t give us the full visibility – context – and hence can create False Positives. The end results of this is as described above, developers and security architects are wasting time triaging False Positives, which leads to lack of trust in those tools.

Instead of viewing risk in terms of vulnerabilities, focus on the actual risks to your business. This requires an extensive understanding of context. We can classify different types of Risk Dimensions:

Single Dimensional Analysis

During the SDLC, companies trigger the execution of tools at the specific stages where those tools fit (e.g., SAST at the CI/CD). SAST scans the code at a single point in time, building all possible permutations of code flows, but focusing only on vulnerabilities and disregarding the code components, data, security controls, deployment location, developer experience, and business impact. This results in the discovery of massive numbers of “issues”, where a good percentage of those will be false positives.

Developers, Security Architects and AppSec Engineers become frustrated from wasting time investigating issues that turn out to be false positives. In addition, when people lose confidence in the tools they’re using, they don’t take the results as seriously, and may fail to appropriately follow up on significant issues. In most scenarios, R&D may choose to express negative feelings towards the CISO and application security leaders. This places security in a no-win situation, which often insists on continuing use of the tools just because “we need to use something,” often according to regulatory requirements.

Another problem arises with Software Composition Analysis (SCA) tools that are used to discover, govern, and monitor OSS licenses, and security vulnerabilities in dependencies. These tools also lack a multi-dimensional approach and look only at the included package. They don’t know if the code is using the aforementioned OSS vulnerability code path. In addition, they don’t take into consideration if it’s a sensitive dependency because of its essence (e.g., authentication framework) or the experience of the developer that added this to the source code.

The Benefits of Multi-Dimensional Risk Analysis

Taking into consideration a multi-dimensional approach to Code Risk Analysis can reduce and optimize those processes by focusing SDLC tools and processes on the “changes that matter most” by collecting information and building complete context profiles composed of different metadata information. We call these “Risky Material Changes.”

For example, building knowledge and activity profiles for each developer based on historical code changes can help with better decision-making. This includes how many code changes they have committed, whether those were security-related changes, and if they had any business impact. We can also take into consideration data handling, deployment location, and internet exposure among other things

Combining the above and more, we can produce a Multi-dimensional Risk Analysis using a contextual model that will help Security Architects and developers focus on the changes that matter most.

The benefits of such an approach will help different stakeholders in the company:

• CIO and CISO will gain a high-level and contextual risk into the real risks to the business.
• Security Architects and AppSec leaders will receive an actionable workplan of high business impact (HBI) risky material code changes. Security tools can be focused to scan only those code changes for a quick turn over with minimal FP.
• Penetration testers will get contextual alerts related to risky material code changes which allow them to start incremental pen-tests
• Developers work on security findings that should be addressed and can have a substantial impact on the product.
• Legal/compliance can more easily and accurately identify compliance issues, such as open-source software licenses, copyrights, etc. along with a notices file.