Blog | Ben Benhemo

The Security Archipelago: Why Your Tools are Sovereign States in a Lawless Sea

Tue, 27 Jan 2026 00:00:00 +0000

I — The Specialist’s Blindness

If you’re anything like me, you were taught that security is a game of coverage.

We were told that if we just have enough domain expert tools, an EDR for the endpoint, a CSPM for the cloud, a SIEM for monitoring, the “gaps” would disappear. We built a stack of “Best in Class” sovereigns.

But there is a paradox at the heart of the modern security stack: The more specialized our tools become, the more fragmented our reality feels.

We didn’t build a unified defense. We built an Archipelago of Data.

Think of your security stack as a chain of isolated islands. Each island is a sovereign state with its own laws, its own language, and its own guarded borders.

The Island of Endpoint (EDR) speaks the language of processes, kernel events, and file hashes.
The Island of Identity (IdP) speaks the language of user profiles, MFA status, and group memberships.
The Island of Infrastructure (Cloud) speaks the language of resource exposure, vulnerabilities, and attack paths.

Each island is a “Domain Expert”. Within its own borders each tool is nearly perfect. But the business doesn’t happen on the islands, it happens in the transit between them.

Because these islands refuse to speak the same language the burden of correlation falls on the human analyst. When a potential issue is flagged your team is forced to act as a manual ferry.

For example when you ask a cross platform question:

"Which user is an admin in AWS despite using unmanaged devices,
has no MFA configuration in the IdP, and is being targeted
by a high volume of malicious emails in the last month?"

The archipelago falls silent. No single island has the answer because no single island owns the “connective tissue” of the data.

You are paying your most expensive talent to do the work of correlation. This isn’t security analysis. It’s a Translation Tax.

III — The Outcome: Achieving Architectural Visibility

The goal of bridging the archipelago isn’t just to catch risks faster, it’s to fundamentally change the way your team works. When you move from Linear Observation (looking at one tool at a time) to Architectural Visibility (seeing the whole map), the whole thing changes.

The value of extracting and linking these data points can help you to gain the ability to:

Map the “Blast Radius”: Instantly see what an identity can touch across the entire environment before it is ever compromised.
Prioritize the Human Element: Focus on the users who are more likely to be targeted by external threats, rather than treating every identity with equal weight.
Eliminate the Tax: Reclaim the hours lost to manual correlation and redirect them toward high value security visibility.

IV — Conclusion: Build the Bridge

The life of a security teams shouldn’t be spent in the gaps between platforms. The future belongs to those who recognize that domain expertise is only half the battle. The other half is the connectivity that turns experts into a system.

You don’t have to get more islands. Just start building the bridges.

Lightweight Reachability System: GitLab Knowledge Graph + AI Agents

Sat, 04 Oct 2025 00:00:00 +0000

The Problem: Not Every SCA Vulnerability is Exploitable

When CVE-2025-29927 dropped for the Next.js library, many appsec teams worldwide immediately started working on a fix. Dependency scanners generated a vast amount of security findings across companies codebases that had the vulnerable version of the package.

The reason many false positive alerts were generated was due to a technical aspect that most traditional dependency scanners miss: Vulnerability != Exploitability.

The Next.js CVE perfectly illustrates this gap. From an exploitability perspective this vulnerability is only relevant where:

Self-hosted deployments using next start with output: standalone
Middleware file (middleware.js/middleware.ts) exists and is actively used
Middleware performs critical security operations like authentication or authorization checks

Yet every traditional dependency scanner will flag any application using affected Next.js versions, regardless of deployment context or middleware usage. This creates a massive false positive problem that burns security & engineering hours and creates alert fatigue.

Why Reachability Analysis Matters

Traditional SCA (Software Composition Analysis) tools operate on a simple binary: They extract the SBOM ➡️ Compare versions to a vulnerability database ➡️ Flag any match as risk.

This simplistic approach results in a high rate of false positives, as it doesn’t consider whether the vulnerable code is actually reachable or exploitable in your specific context. Because real exploitation requires:

Vulnerable code must be imported - Is the vulnerable function/module actually imported?
Reachable execution path - Does the call graph show that application flow can reach the vulnerable code?
Client controlled input - Can external input influence the vulnerable code path?

GitLab’s Knowledge Graph: Tool Overview

GitLab recently released a Knowledge Graph tool that transforms your codebase into a queryable graph database. It understands:

Function call hierarchies
Import dependencies
Variable flow
Cross-file relationships

The special thing about this tool is that it can be easily integrated into your AI agents & LLMs by providing a local MCP setup, which helps you query your codebase for code insights.

While this tool is primarily designed to assist engineers during development, I realized its capabilities could be redirected to help AppSec engineers investigate SCA vulnerabilities.

Quick Example: CVE-2024-47081 Analysis

To demonstrate this approach I analyzed a sample repository for SCA findings. From the initial traditional scan I identified the requests library at version 2.32.3 which has CVE-2024-47081: a credential leakage vulnerability in Python’s requests library. This vulnerability allows .netrc credential leakage when processing malicious URLs, but our analysis revealed:

3 files using the requests library: github_collector.py, npm_collector.py, and smithery_collector.py
All requests calls use hardcoded URL templates with validated string formatting
No arbitrary URL injection vectors found in the codebase

This analysis took < 30 seconds using GitLab’s Knowledge Graph + Claude, compared to a long time of manual code review. The system correctly identified that while the vulnerable package was present, the specific conditions for exploitation were not met.

Automating the Process

Taking this a step further, we can essentially automate the process to help with remediations by creating a job that takes the SCA findings from our traditional scanners and uses the knowledge graph along with an AI agent to review them. It will automatically generate a reachability report for each repository.

Architecture Overview

graph LR A[SCA Scanner Findings] --> B[LLM + Knowledge Graph] B --> C[Call Graph Analysis] C --> D[Reachability Report] E[Your Codebase] --> B

Example: The Reachability Analysis Prompt

Here’s the prompt template that powers the analysis:

You are a security researcher analyzing CVE reachability.
Given CVE: [CVE-ID]
Vulnerable component: [package@version]
Vulnerability details: [description]
Target Project: [project]

Using the GitLab Knowledge Graph, determine:
1. Is the vulnerable package imported anywhere?
2. What are the call paths to vulnerable functions?
3. Are these paths reachable from external entry points?
4. What conditions must be met for exploitation?

Provide a reachability verdict: REACHABLE | UNREACHABLE

Beyond CVEs: Advanced Security Applications

The knowledge graph isn’t just for investigating CVEs, it opens up entirely new possibilities for answering complex security questions that traditional SAST and SCA tools can’t address. For example:

Finding Authentication Bypasses

"Show me all code flows that reach database queries without passing through an authentication check"

Tracking PII Flow

"Trace all paths where PII data flows from API input to external services"

Detecting SSRF Patterns

"Find all places where user input can influence URL parameters in HTTP requests"

The combination of GitLab’s Knowledge Graph and AI agents enables us to perform deep level analysis of SCA vulnerabilities in a budget friendly manner, using this open source tool combined with our AI agents. This approach not only saves time and reduces alert fatigue, but it also opens up new possibilities for automated security analysis without the need for expensive commercial tools.

References:

CVE-2025-29927 - Next.js Authorization Bypass Vulnerability | National Vulnerability Database
CVE-2025-29927 Deep Dive | JFrog Security Research
GitLab Knowledge Graph MCP Server | Official Documentation
CVE-2024-47081 - Python Requests Credential Leakage | GitHub Security Advisory

The Three Pillars For Container Security

Sun, 18 Aug 2024 00:00:00 +0000

When you are surfing the web, you can find countless approaches on how to secure containers. There are plenty best practices available, but this abundance of information can often be misleading and confusing.

This dedicated guide aims to cut through the noise and present a focused perspective on what I believe are the three most critical pillars of container security. These pillars are essential for anyone in the security field to understand and implement when securing containers. This guide assumes that you already have a basic understanding of what Docker and containers are.

So, let’s get started.

TL;DR of the Three Pillars

💡 Securing Docker Images, Securing Kubernetes, Runtime Security.

1️⃣ Securing Docker Images

Securing your Dockerfile is the first process you should follow.

Some Basics: Understanding the Docker Build Process

A Docker build process involves creating a Docker image from a Dockerfile. A Dockerfile is essentially a blueprint containing instructions that define the environment and the steps required to build the application.

During the build process, Docker reads these instructions, executes them, and packages the results into an image. This image can then be run as a container, ensuring a consistent and reproducible environment for applications.

Docker

💡 A great explanation of the build process can be found here: https://iximiuz.com/en/posts/you-need-containers-to-build-an-image/

Dockerfile Security

From what I have seen so far, the three most important aspects of securing Dockerfiles are:

Pulling a secure base image.
Securing additional dependencies and packages.
Ensuring containers do not run as root.

Base Image

The first layer in a Dockerfile is the base image. This is the foundation upon which all other layers are built. The base image typically comes from an external registry.

It is important to check the current vulnerability state of an image in the external registry. For instance, Docker Hub provides information on the existing vulnerabilities in an image.

In the following example, you can see an node:10.0.0 image sourced from Docker Hub. The image shows a significant number of vulnerabilities and was last pushed six years ago.
This indicates that the image is outdated and vulnerable. Therefore, it is advisable to upgrade to a newer version or change the image to a different tag to ensure better security.

Node

Securing additional dependencies and packages.

Since a Dockerfile is built using layers and starting with a base image, developers will often need to add dependencies and packages on top of that. These dependencies and packages are crucial for the functionality of the application.

It is essential to ensure that all dependencies and packages are up-to-date and secure.

💡 For more information on securing dependencies and packages, feel free to read my previous blog: https://benbenhemo.com/post/securing-dependencies/

Ensuring containers do not run as root

By default, containers run as root. Since containers might share the same host, a container running as root will have access to the root of the host node. This means it can potentially access other containers on the same node, posing significant security risks.

To mitigate these risks, ensure that your Dockerfile is configured to run containers as a non-root user.

# Use an official base image
FROM python:3.9-slim

# Create a non-root user and set permissions
RUN useradd -m myuser

# Set the user to the newly created non-root user
USER myuser

Container Scanning in CI/CD

Implementing and configuring security scanners as part of the CI/CD pipeline is a topic for another day, but since it is a major component of securing Docker images, it should be mentioned in this blog.

Container scanning in CI/CD pipelines ensures that any vulnerabilities in your Docker images are detected early in the development cycle. This approach helps maintain the security and integrity of your applications by detecting and addressing potential vulnerabilities before they reach production.

The Trivy documentation is a great resource and can help you gain a more in-depth understanding of the concept: Trivy Documentation

2️⃣ Securing Kubernetes

once your Dockerfile is secure, the next important layer is securing your Kubernetes cluster.

Kubernetes, an open-source project, is an important tool for deploying, scaling, and managing containerized applications. Its flexibility and power make it a key component in modern infrastructure, but this also means that securing Kubernetes effectively is essential to protect your applications and data from potential threats.

https://kubernetes.io/docs/home/

Securing The Control Plane

The Kubernetes API server is the heart of your cluster’s control plane, managing all interactions within the cluster. Given its critical role, securing the API server is extremely important. Here are the key steps to ensure its security:

Implement Role-Based Access Control (RBAC): Role-Based Access Control (RBAC) is essential for limiting access to the Kubernetes API based on the principle of least privilege. RBAC allows you to define precise roles and permissions for users and applications, ensuring that only authorized entities can interact with the API.
Secure API Communication with TLS: Ensure that the API server is only accessible over a secure, encrypted connection using TLS. TLS encryption protects the data transmitted between the API server and its clients, preventing unauthorized access and tampering.
Regularly Auditing API Server Logs: Monitor and audit API server logs to detect unusual or unauthorized activities. Implement logging and monitoring tools to provide visibility into API usage and potential security incidents.

You can also check: https://kubernetes.io/docs/concepts/security/controlling-access/

Pod Security

Pods are groups of containers running on the same host, sharing a network stack and other resources. It’s essential to configure your pods to limit their permissions and capabilities, minimizing potential attack surfaces and preventing lateral movement. This can be achieved by:

Setting Pod Security Admission: Define a set of conditions that a pod must meet to be accepted into the system. These conditions control aspects such as privilege escalation, host network access, and volume usage.
- More details can be found here: https://kubernetes.io/docs/concepts/security/pod-security-admission/
Using Security Contexts: Security contexts allow you to define privileges and access control settings for a pod or container. For example, you can prevent containers from running as root by setting the runAsNonRoot option. https://kubernetes.io/docs/concepts/security/pod-security-standards/

Host Security

Host security is a critical yet often overlooked aspect of securing Kubernetes. The host machines, whether they are bare-metal or virtual machines (VMs), must be properly secured to protect the entire Kubernetes environment.

Restrict Access: Limit access to your host machines by using dedicated VPNs and strict access controls. This helps prevent unauthorized users from accessing the underlying infrastructure.
Minimize Attack Surface: Only install the necessary components required for running Kubernetes, such as the Kubernetes code, its dependencies (like Docker), and essential supporting features (logging or security tools). This is often referred to as running a “thin OS.” Container-specific distributions like CoreOS Container Linux, RancherOS, or Red Hat Atomic can help minimize the installed code on your hosts and include features like a read-only root filesystem.
Use Hardened OS Distributions: Consider using container-specific OS distributions or general-purpose Linux distributions that are stripped of unnecessary libraries and tools. This reduces potential vulnerabilities by limiting the software running on the host.

💡 Discussing Kubernetes security can be an extensive and varied topic. For a comprehensive and informative guide, I recommend reading the book Kubernetes Security by Liz Rice. It’s an excellent resource that covers a wide range of important topics in depth.

3️⃣ Runtime Security

If you work in the security industry, you’ve probably heard the phrase “Runtime Security.” Although runtime security is not entirely new, it has gained significant adoption in recent years, with companies like Wiz, Upwind Security, and Sweet Security that utilizing this technology. But what exactly is runtime security, and how does it work?

Understanding Runtime Security

Runtime security refers to the protection of applications while they are running, in that simple but that complex too. It involves monitoring and securing the application in real time to detect and mitigate threats as they occur. This is crucial because even if your application is secure at the build and deploy stages, vulnerabilities can still be exploited at runtime.

eBPF: The Engine Behind Runtime Security

eBPF (short for Extended Berkeley Packet Filter) is a powerful Linux kernel technology that enables efficient and dynamic tracing of various system events such as network packets, function calls, and system events. Originally, BPF (Berkeley Packet Filter) was developed in the early 1990s to filter network packets in a performant way, primarily in network monitoring tools like tcpdump.

Kernel vs. User Space and How eBPF Leverages It

The Linux kernel is the core software layer that sits between applications and the hardware they run on. Applications operate in a restricted environment called user space, where they can’t directly access hardware. Instead, they make system calls to the kernel, which handles these requests.

eBPF operates in the kernel space, allowing it to monitor and interact with system events in real time. What makes eBPF powerful is that it can do this without modifying the kernel itself, maintaining system stability and security. This capability enables eBPF to provide deep visibility and control, making it a vital tool for real-time security monitoring.

eBPF technology allows companies and products to monitor and extract crucial insights and data in real time during application runtime. Since every network call and system call originates from the kernel, eBPF operates close to the kernel level, providing deep visibility into system behavior without affecting the actual kernel operations.

A great book about eBPF: https://isovalent.com/books/learning-ebpf/
I believe the best way to learn about runtime security is by getting hands-on experience with it. I highly recommend exploring the Falco project, an open-source security tool that leverages runtime security concepts. https://falco.org/

So, I hope I’ve provided a short and precise summary of the three key aspects to focus on when securing your containers. From the first step of building a secure container with a well-written Dockerfile, scanning it during the build process, securing the orchestration platform, to implementing runtime security to monitor and prevent threats in real time. I hope you find this helpful and that it guides you in securing your containerized environments.

Uncovering the Risks of Third-Party Software Dependencies

Sun, 23 Jun 2024 00:00:00 +0000

Introduction

What comes to mind when you hear the term “Software”? Do you imagine massive lines of code and complicated algorithms?

Actually, at its core, software is built from various components. These components can include things like snippets of code, or external software modules that add specific functionalities. These external modules, known as dependencies, play a crucial role in modern software development. They allow developers to use existing solutions and speed up their projects.

In this blog, we’ll explore the world of third-party dependencies and the risks associated with them. Understanding and effectively managing these dependencies is crucial for maintaining the security and reliability of applications.

Four Key Terms

Third-Party Library: External software components used to add functionality without building from scratch.
Software Package (or simply package): An library metadata containing the release version of a library, which is a piece of software.
Open Source Packages: Code made publicly available under an open-source license, allowing for code reviews, community collaboration, and easy reuse in projects.
Dependency: You probably heard the term before. When you use a specific package in a project, that project “depends” on this package, hence it is called a dependency.

Real-World Example: Using Pandas for Data Analysis

Let’s say you’re working on data analysis and you need to process CSV files. To achieve this, you could write numerous functions from scratch, which might involve complex tasks like reading the CSV file, handling missing values, filtering data, and performing calculations. Or you could use an external third-party library called Pandas.

When you decide to use Pandas, you pull a specific software package of Pandas based on the version that suits your needs. Each version offers different capabilities and improvements.
```
# Install a specific version of Pandas
pip install pandas==1.3.3
```
Pandas itself is an open source package, meaning its code is publicly available for anyone to use and contribute to. See: https://github.com/pandas-dev/pandas
When you incorporate Pandas into your project, your project becomes dependent on Pandas, relying on this external library to function correctly. That’s why Pandas is part of your software dependencies.

Direct vs Indirect Dependency

It’s important to understand the difference between direct and indirect dependencies to better assess the risks associated with third-party libraries.

Direct Dependencies

A direct dependency is a package that is directly included in the project. Developers intentionally add these dependencies and reference them directly in the code.

For example, in our project, Pandas is a direct dependency.

Indirect (Transitive) Dependencies

A dependency can use other dependencies for its functionality; these are called indirect dependencies. A recent study found that an average NPM package can have up to 79 indirect dependencies. Do you understand the depth of this?

These types of dependencies are installed along with the direct dependencies, and the developer usually does not have direct control over which transitive packages are installed.

Here’s an example of what the dependency tree might look like when you use Pandas:

pandas==1.3.3
 ├── numpy>=1.17.3
 ├── python-dateutil>=2.7.3
 └── pytz>=2017.3

In this example, Pandas is a direct dependency, while numpy, python-dateutil, and pytz are indirect dependencies because Pandas relies on them to function properly.

Package Management

You might have heard about the recent news of PyPi being under attack, but what exactly is PyPi? PyPi is a trusted Python “Package Repository” that is widely used by the community.

A package repository is a centralized location that stores packages, primarily for a specific programming language. The aim of the package repository is to distribute packages more efficiently, providing important information such as metadata, versions, licenses, and indirect dependencies.

It helps us better understand the packages we plan to use and enhances security and usability by scanning for known vulnerabilities and malware.

In our case, you can install pandas package from the PyPI Repo. You can use “pip” to install the package from PyPI:

pip install pandas

Package managers are tools that automate the process of installing, upgrading, configuring, and removing software packages in a consistent manner. They are responsible for resolving dependencies and retrieving packages from their respective repositories. Well-known package managers include pip for Python, npm for Node.js, and Maven for Java.

A Grain Of Pessimism

Dependency Hell 👹

As a developer, you often bear the responsibility for a particular service, which includes developing and maintaining an existing software service. As you may already know, this service can depend on numerous packages and third-party libraries.

Managing a multitude of dependencies that contain numerous indirect dependencies can be overwhelming. This unmanageable scenario can lead to what is commonly known as Dependency Hell.

As stated by Wikipedia:

Wikipedia

Challenges of Managing Open Source Dependencies

Developers often do not examine the actual code of open-source dependencies. If you utilize code reviews in your SDLC process, why not review code from external authors as well? This implicit trust approach can significantly risk your application’s security.
Unused Dependencies: Changing the package manager file is an easy task that typically requires a merge request process or even a direct commit sometimes. This ease of modification leads developers to add dependencies they think they need for specific functions, but they often end up not using the functionality of these dependencies while still installing them in their application.
As you have seen, dependencies function like actual software, meaning they are constantly updated and new versions are published to add or modify functionality and apply security patches. This process puts developers in a problematic situation: they may avoid updating dependency versions due to the possibility of breaking changes, but by not updating, they risk using vulnerable and unpatched dependencies.

Managing Dependencies: Current Security Challenges

Supply Chain Risks

As you already understand, a single vulnerable dependency can have a massive impact. All it takes is a single vulnerable piece of code in a ‘hidden’ dependency used by other popular dependencies to put a wide range of companies at risk.

Typosquatting

Anyone can create an open-source dependency, so why wouldn’t attackers? Creating a malicious package is easy, and naming it similarly to a known existing package, hoping a victim will misspell the name, is a well-known attack called typosquatting.

A recent attack on the PyPi registry was a classic example of typosquatting.

It Always About Priorities

Developers are not primarily focused on security. Their main priority is to develop new features that bring value to the business. Sometimes, the hard and continuous task of updating dependencies is not something developers are happy to do. Updating to a new version requires them to learn about the vulnerable package and the new updates, and understand how these changes will affect the current software without causing production crashes.

A Grain Of Optimism

As you can understand, managing and securing software can be very hard and overwhelming due to the complexity and depth of triaging. We will never be 100% secure, but we can take a few steps to decrease our risk exposure.

Software Bill of Materials (SBOM)

With the increase in supply chain attacks, it is crucial for developers to be aware of all dependencies in their projects. Manually cataloging these dependencies is both inefficient and prone to errors. A Software Bill of Materials (SBOM) provides an automated, machine-readable inventory of all packages and their versions within a project. This helps in better managing and securing dependencies. For more information, visit GitHub Docs.

Detecting Vulnerabilities

Before updating and fixing vulnerabilities in dependencies, you need to detect them right? 🙂 There are two primary approaches to doing this:

Scanner Job in CI/CD Pipelines: You can run a dependency scanner as part of your CI/CD pipelines. The scanner compares the versions of your dependencies with a vulnerabilities database and returns a list of detected vulnerabilities that you can start working on. An example of a scanner is Dependabot.
Manual Scan: You can scan your repository manually at a frequency you deem appropriate. The scanner will return the relevant vulnerabilities as well. An example of this is OWASP Dependency-Check.

Risk Prioritizations

Each vulnerability has a different risk score. Most of the time, you’ll get the CVSS risk score from the dependency scanners. However, you should prioritize vulnerabilities based on several other factors, such as the specific service’s goal, the presence of sensitive data, public exposure, and more.

Remediation

Remediation and fixing vulnerabilities in dependencies typically involve updating the dependency to the latest secure version. This should be done in close collaboration with the development departments to ensure nothing breaks during the update.

You can also check: The Risks and Benefits of Updating Dependencies

Hope this post provided valuable insights into securing third-party software dependencies. Thank you for taking the time to read!

BigQuery Security 101 - Core Concepts

Wed, 15 May 2024 00:00:00 +0000

Introduction

Today, in the cloud computing age, the Cloud Service Providers provide services that essentially cut across every aspect of computing and data management needs. From scalable computing power and robust data storage solutions to advanced data analytics and machine learning platforms, these services are designed to empower businesses and developers. They provide the flexibility, scalability, and efficiency required to drive innovation and optimize operations in a digitally transformed world.

In a brief, these services can broadly be categorized into several types:

Service Category	Description	Examples
Compute Services 💻	Provide virtualized computing resources over the Internet.	Amazon EC2, Microsoft Azure Virtual Machines, Google Compute Engine
Storage Services 🗄️	Dedicated to storing data in the cloud, ensuring security and accessibility.	Amazon S3, Azure Blob Storage, Google Cloud Storage
Databases 📚	Offer scalable, distributed systems for data storage and management.	Amazon RDS, Azure SQL Database, Google Cloud SQL
Data Analytics 🔍	Designed to process and analyze large datasets efficiently.	AWS Redshift, Azure Synapse Analytics, Google BigQuery
Machine Learning and AI 🤖	Enable building, training, and deploying machine learning models.	AWS SageMaker, Azure Machine Learning, Google AI Platform
Networking 🌐	Provide interconnectivity between cloud services, on-premises data centers, and end-users.	AWS VPC, Azure Virtual Network, Google Cloud VPC

Today, we’ll zero in on BigQuery, spotlighting the risks that tag along.

What is BigQuery?

💡 BigQuery, offered by Google Cloud Platform (GCP), stands out as a premier, fully managed, and serverless data warehouse within the Data Analytics spectrum. It enables scalable analysis across petabytes of data, boasting a robust, fast, and interactive SQL-on-terabyte-class database infrastructure. This technology paves the way for the modernization of data-driven applications, ensuring efficient data management and analysis at scale.

For a deeper dive and more context, check out Google’s own explanation in the video below:

Essential BigQuery Concepts Explained

BigQuery Jobs: Jobs in BigQuery are specific operations that you can perform on the data stored within. These include executing queries to analyze data, loading new data into tables, or exporting data to different formats or external locations.
BigQuery Tables: Tables are the fundamental building blocks of BigQuery where your actual data resides. Organized in rows and columns, tables support the storage and retrieval of large quantities of structured data.
BigQuery Datasets: A dataset in BigQuery is a container that holds tables and views. Datasets are used to organize and control access to your tables based on needs and are defined at the project level.
BigQuery Queries: Queries in BigQuery are used to interact with the data stored in tables. By writing SQL-like commands, you can perform complex data analysis, manipulate data, and generate insights.

Now Let’s Talk Security

Supporting companies with huge data stores—and some may be containing sensitive information, such as PII, financial records, or intellectual property—makes BigQuery capabilities for advanced data analytics more than mandatory. Such an approach equalizes to an increased level of sensitivity and, accordingly, turns BigQuery into a priority target of cyber threats. Attackers will exploit this service for carrying out such actions as access and exfiltration of sensitive data but not limited to DoS or misuse of computational resources.

Unauthorized Access

The Problem → Gaining unauthorized access to BigQuery can lead to sensitive data exposure.

The Solution → Adopt the principle of Least Privilege Access, granting users only the access they need.

1️⃣ The IAM Solution

You might think everyone knows about IAM (Identity and Access Management) by now, but getting it right is crucial for keeping your BigQuery data safe. BigQuery Access control with IAM provides detailed guidance on establishing strict IAM policies.

I’ve included an overview of the roles, just in case:

High-Risk BigQuery Roles

Role	Permissions	Security Risk
BigQuery Admin (`roles/bigquery.admin`)	Full control over all BigQuery resources.	Can lead to data exposure, loss, or unauthorized modification.
BigQuery Data Owner (`roles/bigquery.dataOwner`)	Full control over datasets and their contents.	Risk of unauthorized access or modifications within datasets.
BigQuery User (`roles/bigquery.user`)	Create new datasets and run jobs.	Potential for unauthorized dataset creation or costly/malicious job execution.
BigQuery Job User (`roles/bigquery.jobUser`)	Run jobs, including queries, within the project.	May be exploited for data exfiltration or incurring high costs.
BigQuery Data Editor (`roles/bigquery.dataEditor`)	Read/write access to datasets, no sharing.	Can lead to data loss or unauthorized alterations.

For more details on BigQuery permissions and API calls, visit this page: https://gcp.permissions.cloud/iam/bigquery

allUsers/allAuthenticatedUsers

Another important aspect is to ensure that no publicly accessible BigQuery datasets are available within your GCP environment. Make sure that role bindings such as allUsers and allAuthenticatedUsers are not configured:

“allUsers:” This allows any user on the internet, whether authenticated or unauthenticated, to access your dataset.
“allAuthenticatedUsers:” This allows any user who can sign in to GCP to access your dataset.

2️⃣ Row-Level Security (RLS)

Row-Level Security (RLS) in BigQuery enhances access control, extending it down to the granularity of table rows. You can implement access control at the project, dataset, and table levels, as well as column-level security through policy tags. This method allows for more delicated access control, by deciding which entity can access specific columns.

I think Google’s explanation regarding Row Level Security is excellent, so I will use their use case to demonstrate how RLS is implemented:

Think of a table, dataset1.table1, where rows are labeled by different regions in the region column.
Row-level security allows a Data Owner or Admin to set specific policies, such as allowing only members of the group:apac to see data from the APAC region.
As a result, only users in the sales-apac@example.com group can view rows where the Region is “APAC”. Similarly, those in the sales-us@example.com group can access rows marked as “US”. Users who aren’t in either the APAC or US groups will not be able to see any rows.
Under the row-level access policy called us_filter, various entities, including the chief US salesperson jon@example.com, are granted access to rows associated with the US region.

From Google Documentation: The resulting behavior is that users in the group sales-apac@example.com can view only rows where Region = "APAC". Similarly, users in the group sales-us@example.com can view only rows in the US region. Users not in APAC or US groups don’t see any rows.

Data Exfiltration

The Problem → Through unauthorized queries and jobs, attackers can export data to external storage for nefarious purposes

The Solution → Implementing Robust Monitoring and Threat Detection Strategies

A Word On BigQuery Log Versions

If you are using BigQuery in your company, you may have noticed that BigQuery has two log versions. In short, here is the difference:

AuditData is the legacy version of BigQuery audit logs, primarily monitoring API calls.
BigQueryAuditMetadata is the “v2” version of the logs, similar to AuditData. It monitors the activities in BigQuery, such as executeing jobs and queries, reading and updating tables and datasets.

We’re not going to delve deeply into which detection rules you can create, but just by examining the protoPayload.methodName, I believe you can come up with a few ideas 🙂 :

Method	Description
`google.cloud.bigquery.v2.TableService.InsertTable`	Creates a new table.
`google.cloud.bigquery.v2.TableService.UpdateTable`	Replaces a table’s metadata.
`google.cloud.bigquery.v2.TableService.PatchTable`	Updates parts of a table’s metadata.
`google.cloud.bigquery.v2.TableService.DeleteTable`	Removes a table.
`google.cloud.bigquery.v2.DatasetService.InsertDataset`	Creates a new dataset.
`google.cloud.bigquery.v2.DatasetService.UpdateDataset`	Replaces a dataset’s metadata.
`google.cloud.bigquery.v2.DatasetService.PatchDataset`	Updates parts of a dataset’s metadata.
`google.cloud.bigquery.v2.DatasetService.DeleteDataset`	Deletes a dataset.
`google.cloud.bigquery.v2.TableDataService.List`	Lists table data.
`google.cloud.bigquery.v2.JobService.InsertJob`	Submits a processing job.
`google.cloud.bigquery.v2.JobService.Query`	Executes a query and returns results.
`google.cloud.bigquery.v2.JobService.GetQueryResults`	Retrieves results of a completed query.
`InternalTableExpired`	Indicates a table was auto-deleted after expiring.

💡 You can also check out this great blog post by Lionel Saposnik and Dan Abramov, which provides actual examples of threat hunting in BigQuery. One of the use cases shows how to hunt for data being exported to an external dataset.

Data Masking

The Problem → Sometimes, sensitive data within BigQuery should be accessible to users who have legitimate system access but don’t need to see all the details, such as for analysis purposes.

The Solution → Data masking in BigQuery provides a solution by concealing specific data elements, allowing users view only to the information essential for their roles.

Benefits of Data Masking

Data masking offers several important benefits that enhance both security and operational efficiency:

Streamlines Data Sharing: By masking sensitive columns, you can safely share tables with larger groups without compromising sensitive information.
Maintains Query Integrity: Data masking works seamlessly with existing queries. Configuring data masking ensures that sensitive data is automatically obscured, based on the roles assigned to users, without the need to modify each query.
Scalable Data Policies: You can establish a data policy, associate it with a policy tag, and apply this tag across numerous columns. This approach allows for the consistent application of access rules on a wide scale.
Enables Attribute-Based Access Control: By attaching a policy tag to a column, data access becomes contextual, governed by the specifics of the data policy and the roles associated with that policy tag. This method ensures data is accessible only under appropriate circumstances.

Configuring Data Masking

To set up data masking in BigQuery, I suggest following the straightforward guide provided by Google Cloud. It covers everything you need to know to get started: Google Cloud Guide to Data Masking in BigQuery.

In summary, here’s what you need to do:

Set up a taxonomy with policy tags: A taxonomy is a framework you design to categorize your data. Within this framework, policy tags are the markers you’ll use to indicate which data is sensitive.
Create data policies for policy tags: These are the rules attached to your policy tags. Data policies determine who can see data unmasked and who sees it masked.
Set policy tags on columns: Once you’ve got your taxonomy and policies in place, you’ll assign the policy tags to the specific columns in your BigQuery tables that contain sensitive data.
Grant access through the Masked Reader role: This role is for users who should see the masked data. By assigning users to the Masked Reader role at the data policy level, they’ll only be able to access data according to the policy you’ve set.

Using BigQuery? I hope this post has given you a solid introduction to what BigQuery can do and how to protect it. If you have any insights or stories about BigQuery security, please share them in the comments

Blog | Ben Benhemo

The Security Archipelago: Why Your Tools are Sovereign States in a Lawless Sea

I — The Specialist’s Blindness

II — You Aren’t Secure Because You Have Coverage, You’re Blind Because You Have Silos

III — The Outcome: Achieving Architectural Visibility

IV — Conclusion: Build the Bridge

Lightweight Reachability System: GitLab Knowledge Graph + AI Agents

The Problem: Not Every SCA Vulnerability is Exploitable

Why Reachability Analysis Matters

GitLab’s Knowledge Graph: Tool Overview

Quick Example: CVE-2024-47081 Analysis

Automating the Process

Architecture Overview

Example: The Reachability Analysis Prompt

Beyond CVEs: Advanced Security Applications

Finding Authentication Bypasses

Tracking PII Flow

Detecting SSRF Patterns

The Three Pillars For Container Security

TL;DR of the Three Pillars

1️⃣ Securing Docker Images

Some Basics: Understanding the Docker Build Process

Dockerfile Security

Base Image

Securing additional dependencies and packages.

Ensuring containers do not run as root

Container Scanning in CI/CD

2️⃣ Securing Kubernetes

Securing The Control Plane

Pod Security

Host Security

3️⃣ Runtime Security

Understanding Runtime Security

eBPF: The Engine Behind Runtime Security

Kernel vs. User Space and How eBPF Leverages It

Uncovering the Risks of Third-Party Software Dependencies

Introduction

Real-World Example: Using Pandas for Data Analysis

Direct vs Indirect Dependency

Direct Dependencies

Indirect (Transitive) Dependencies

Package Management

A Grain Of Pessimism

Dependency Hell 👹

Challenges of Managing Open Source Dependencies

Managing Dependencies: Current Security Challenges

Supply Chain Risks

Typosquatting

It Always About Priorities

A Grain Of Optimism

Software Bill of Materials (SBOM)

Detecting Vulnerabilities

Risk Prioritizations

Remediation

BigQuery Security 101 - Core Concepts

Introduction

What is BigQuery?

Essential BigQuery Concepts Explained

Now Let’s Talk Security

Unauthorized Access

1️⃣ The IAM Solution

2️⃣ Row-Level Security (RLS)

Data Exfiltration

A Word On BigQuery Log Versions

Data Masking

Benefits of Data Masking

Configuring Data Masking