Stop wasting your time on irrelevant changes while developing software

Introduction

If you are a developer, software engineering manager, or deal with application security in any capacity, you probably faced the challenge of reading commit diffs, Pull Requests, or entire repository histories in order to determine if something material (more on that later!) was introduced. If you manage a team of three developers, this might be manageable, but as your team grows to dozens or thousands of developers – changes are flying all around and it is impossible to find needles in haystacks.

As a developer, I read code much more than I write code. After many years, I still find it very hard to understand the real semantic changes in a Pull Request, let alone the developer’s intent behind them. This is amplified by the possible implications of adding or omitting even just one character.

When I review Pull Requests I use GitHub’s diff tool which shows modified lines. When I dive into a repository history, I explore commit diffs, and when I see something suspicious in code, I might run git blame, or go over the git history of that specific file. All of these tools lack the semantic understanding of the code. They can’t distinguish between a logical change and a simple refactoring, and they can’t pinpoint the commit where a certain RESTful API was introduced, or tell me if a new OSS package was downgraded in a 300 file change Pull Request.

Another limitation of these tools is that they are limited to one repository. Often, my perspective includes multiple repositories or modules within repositories that together assemble an Application. The Application, in its broader definition, includes external systems like ticketing systems, CI/CD pipelines, API Gateways and Cloud infrastructure, and even the developers themselves – all of which are missing from the diffing tools’ context. This is especially problematic when I want to perform a security code review, threat model, or decide if a certain change warrants a pen test.

Material Changes

A material change is an update that has the potential to introduce significant risk into the application, infrastructure, or open source code, but it cannot be identified by looking at the code alone. It requires analyzing a number of contextual factors, from developer metadata to the business impact of the change. Apiiro analyzes and correlates data from Design to Code to Cloud, including:

• Code (e.g., application code, Infra-as-Code, open source code, configuration files)
• Contributors (e.g., developer experience, behavioral patterns, permissions, and locations)
• Metadata (e.g., User stories, commit messages, Pull Request discussions)
• SSDLC Processes (e.g., Risk Assessments, Security Code Reviews, and Pen Tests)
• Third-party tools (e.g., SAST, SCA, DAST, IAST)
• Runtime (e.g., API Gateway, Kubernetes)

Why do I care?

In order to determine if some risk is introduced, organizations tend to choose either of the following:

1. Slow down – all changes need to go through a security review, where someone reads the code and determines whether it needs further inspection and changes, or not.
2. Aggregate security reviews to once every month (or any other time frame), where the review is much harder (as the “diff” is much bigger, and might span various areas of a code base). 
3. Have developers answer manual Risk Assessment Questionnaires, hoping that developers would know that a high-risk Material Change was introduced.

OWASP Attack Surface Analysis Cheat Sheet

To be able to perform an efficient and effective security code review, threat modeling, or pen-testing before releasing to the cloud, you must first map the application attack surface so that you can focus on high-risk areas.

The following OWASP article clearly defines what an application’s attack surface consists of, and emphasizes the importance of tracking changes in the attack surface over time but does not provide a solution. Unfortunately, in modern cloud applications that use agile development methodologies and daily deployments, the challenge is even bigger.

The Solutions

With Apiiro’s Material Change detection, you can trigger workflows (like opening a ticket with the relevant context, assigned to the relevant person) or even block a PR or break a build – only when a Material Change is introduced. A good example is referring or automatically assigning the security champion, pen-tester, or dev team lead to Pull Requests – only if there was a change to the authorization logic, or PII data was exposed through an internet-facing API – otherwise, they are free to focus on other tasks, and not block developers from bringing value to customers!

The following table will help a pen-tester, AppSec engineer, or software engineering manager choose the right tool when performing pen-testing, security code review, or threat modeling:

Key Takeaways

1. Stop the risk team from wasting your time by using manual Risk Assessment Questionnaires
2. Automation is the key – move from reactive mode to proactive mode to increase velocity with confidence! Get automated notification at the commit / PR when your developers introduce material changes 
3. Stop using contextless tools when conducting a security code review or threat model, or assessing the risk of a PR