Cookies Notice
This site uses cookies to deliver services and to analyze traffic.
November 20 2022 | 4 min read
Technical | November 20 2022 | 4 min read
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.
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:
In order to determine if some risk is introduced, organizations tend to choose either of the following:
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.
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!
Tools → | GitHub Diff | Apiiro Material Changes |
Processes ↓ | ||
Pen-Testing | Manual, time consuming, contextless | Automatically trigger when necessary, provides context for the pen-tester |
Risk Assessment | Manual, time consuming, error prone | Fully automatic |
Threat Modeling | Manual, time consuming, contextless | Automatically trigger when necessary, provides context |
Security Code Review | Manual, time consuming | Automatically trigger when necessary, provides context for the reviewer |
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:
Tools → | GitHub Diff | Apiiro Material Changes |
Features ↓ | ||
Track all changes (e.g., spaces, dots) | ✔ | ✘ |
Identify code owners per line | ✔
Using git blame – contextless |
✘ |
Identify code owners per code component (e.g., API, DataModel) | ✘ | ✔
Contextual (e.g., developer X changed the logic of an API POST /login/check-login) |
API logic changes | ✘ | ✔ |
Data Model logic changes | ✘ | ✔ |
Docker files changes | ✔
Contextless |
✔
Contextual (e.g., Docker instructions and configurations) |
OSS packages changes (e.g., downgrade, upgrade, added, removed) | ✘ | ✔ |
Infra-as-Code changes (e.g., firewall rules, routes, permissions) | ✘ | ✔ |
Identify logic changes across repositories | ✘ | ✔ |
PII changes | ✘ | ✔ |
OSS licenses changes | ✘ | ✔ |
Secrets in code changes | ✘ | ✔ |
Authentication changes | ✘ | ✔ |
Authorization changes | ✘ | ✔ |
Input validation changes | ✘ | ✔ |
Technologies usage changes (e.g., DB frameworks, Serialization frameworks) | ✘ | ✔ |