# ORCA: Unveiling Obscure Containers In The Wild

Jacopo Bufalino, Agathe Blaise, Stefano Secci

► To cite this version:

Jacopo Bufalino, Agathe Blaise, Stefano Secci. ORCA: Unveiling Obscure Containers In The Wild. ACM Workshop on Software Supply Chain Offensive Research and Ecosystem Defenses (SCORED '25), Oct 2025, Taipei, Taiwan. 10.48550/arXiv.2509.09322. [PDF] [ Biblio ]

HAL Id: hal-05288015

https://hal.science/hal-05288015v1

Submitted on 29 Sep 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
# ORCA: Unveiling Obscure Containers In The Wild

Jacopo Bufalino*

Cnam, Cedric

Paris, France

jacopo.bufalino@cnam.fr

Agathe Blaise

Thales SIX GTS France

Gennevilliers, France

agathe.blaise@thalesgroup.com

Stefano Secci

Cnam, Cedric

Paris, France

stefano.secci@cnam.fr

## ABSTRACT

Modern software development increasingly depends on open-source libraries and third-party components, which are often encapsulated into containerized environments. While improving the development and deployment of applications, this approach introduces security risks, particularly when outdated or vulnerable components are inadvertently included in production environments. Software Composition Analysis (SCA) is a critical process that helps identify and manage packages and dependencies inside a container. However, unintentional modifications to the container filesystem can lead to incomplete container images, which compromise the reliability of SCA tools. In this paper, we examine the limitations of both cloud-based and open-source SCA tools when faced with such obscure images. An analysis of 600 popular containers revealed that obscure containers exist in well-known registries and trusted images and that many tools fail to analyze such containers. To mitigate these issues, we propose an obscuration-resilient methodology for container analysis and introduce ORCA (Obscuration-Resilient Container Analyzer), its open-source implementation. We reported our findings to all vendors using their appropriate channels. Our results demonstrate that ORCA effectively detects the content of obscure containers and achieves a median 40% improvement in file coverage compared to Docker Scout and Syft.

However, such tools work on a best-effort basis and make implicit assumptions about the organization of the container filesystem. In practice, such assumptions do not always hold, as legitimate developers may accidentally modify container contents in ways that hinder vulnerability detection. For instance, this can happen by deleting index files, installing software from source without a package manager, using multi-stage builds, or compressing container layers. These common practices, while not malicious, can hide the presence of vulnerable packages, leading to incomplete or misleading SBOMs. We refer to such as *obscure* containers.

While prior work and industry reports [5, 32] have hinted at the existence of such issues, no study to date has systematically cataloged obscuration techniques, quantified their impact, or provided practical mitigation strategies. This paper is the first, to the best of the authors’ knowledge, to formalize container obscuration as a software supply chain vulnerability and analyze its impact. As such, we establish the following research questions:

* RQ1: What are the different types of container obscuration?

* RQ2: Are state-of-the-art tools vulnerable to obscuration?

* RQ3: Are there obscure containers among popular container registries?

## 1 INTRODUCTION

Modern software development increasingly relies on open-source libraries and third-party components, which are often encapsulated into containerized environments. Together, software, dependencies, tools, and processes form a complex ecosystem known as the software supply chain. Such networked architecture improves productivity but also increases the attack surface, creating new opportunities for adversaries to infiltrate and compromise software systems. Among the different threats to the Software Supply Chain, the issue of vulnerable and outdated components is of primary importance, as acknowledged in the OWASP Top 10 project [41]. The importance of this problem is such that regulators [15, 37] have defined policies and mandatory requirements to secure the Software Supply Chain of digital products. In this respect, one of the key documents is the Software Bill of Materials (SBOM), which is a record of the details and relationships of the components included in a digital product. Much like labels for physical products, SBOMs can be used to identify outdated or vulnerable components. SBOMs for containers are generated using Software Composition Analysis (SCA) [23] techniques and tools that automatically analyze the content of the container image to extract package and metadata information. They do that by scanning for known filenames and paths across the different container layers.

We designed a three-stage study to systematically address these research questions. First, we conducted a comprehensive review of prior work on container security to construct a corpus of known and novel obscuration techniques. Second, we applied these techniques to create increasingly obscure containers, which we then evaluated against popular state-of-the-art SCA tools. Finally, we formulated a methodology to identify instances of obscure containers and to assess their prevalence across registries. Building on the findings from the previous stages, we also propose a novel methodology for SCA that is resilient to diverse forms of container obscuration. This methodology was implemented in ORCA, an open-source tool that improves file coverage by at least 24% compared to state-of-the-art alternatives. Our evaluation demonstrates that ORCA can be integrated into CI/CD pipelines, enabling early detection of obscure containers. We disclosed our findings to affected vendors.

The remainder of the paper is organized as follows. We provide the necessary background on containers and container image security in §2. In §3, we detail our methodologies: i) for analyzing container obscuration, and ii) for improving package detection with resilience against obscuration. In §4, we highlight the research questions we address through an extensive analysis of open-source containers. In §5 we analyze the related work on SCA for container images and attacks to the software supply chain. In §6, we discuss the key findings, proposed mitigation, and responsible disclosure. Finally, in §7 we conclude the paper.

<footnote>*Also with Aalto University.</footnote>
# 2 BACKGROUND

## 2.1 Containers: A primer

A container is a lightweight form of virtualization that allows a collection of processes to run in an isolated user-space environment. Containers consist of an image (the software and libraries) and a set of namespaces that define the running environment. A container runtime provides a user interface and libraries for managing containers.

A container image represents the filesystem of a container. Due to the isolated nature of containers, the software running within them must include all the needed dependencies and libraries. These dependencies are often reused across multiple containers [56], as are application libraries and packages. Container images are thus composed of layers that, combined, generate the final filesystem. Starting from a root filesystem, each new layer represents a change-set of added, deleted, and modified files. This allows for the storage, caching, and reuse of individual layers, optimizing both space and resource consumption. Deleted or modified files are not removed from the layer; instead, they are marked as whiteouts. Containers are typically generated from declarative files called Containerfiles, which contain instructions to assemble the final filesystem. A fixed set of instructions is available in [11].

A container image follows a structured format consisting of three key components. First, the layers are provided as a list of archives, each representing a change-set on the filesystem of the image. The manifest describes the image, including references to the layers, their cryptographic digests, and metadata. The configuration defines the order in which layers are applied and includes the commands used to generate each layer. While this configuration reflects how the image is built and run, it is not the same as the original Containerfile. Instead, it is a processed result of the build that includes the actual runtime instructions derived from those build files.

## 2.2 Container image security

The security of container images is an obvious concern, especially in interconnected cloud computing scenarios. Many studies [8, 16, 49, 50] have meticulously explained and grouped the different threats to containers. These threats can be divided into two broad areas, namely security of the container execution environment (e.g., privileges, network, OS isolation, container runtime) and security of the container image (e.g., vulnerabilities, exploits, secrets, licenses). The former measures and inspects the behavior of containers by monitoring network connections, processes, and access logs. The latter targets the problem of finding vulnerable files and dependencies in the container filesystem. We focus on this problem, which is typically addressed in two phases: discovery and mapping.

Discovery consists of analysing the image filesystem, typically by listing and analyzing a subset of known paths that are likely to contain package-related information ("paths of interest"). Similarly, not all layers are analyzed, but only the squashed representation of the filesystem (i.e., excluding intermediate changes to the image). This process, known as Software Composition Analysis (SCA), has gained attention in recent years due to the increasing complexity of code dependencies in software and containers. Information about the included packages is consolidated into a machine-readable

record known as the SBOM [37]. A standard format for SBOM is the System Package Data Exchange (SPDX) [51], developed by the Linux Foundation.

Mapping involves converting the SBOM into Common Vulnerabilities and Exposures (CVEs) using dedicated databases such as the National Vulnerability Database [38]. Mapping packages to CVEs is not a one-time operation, as new vulnerabilities are discovered every day, making it necessary to execute this task at regular intervals.

# 3 METHODOLOGY

In this section, we outline the methodology and assumptions to answer the research questions.

## 3.1 Assumptions and scope

In this work, we consider the creator of the container image to be a legitimate user who does not intend to harm the system. Therefore, we do not target malicious containers or motivated attackers. We also assume that users do not use binary packers or other mechanisms to purposely hide the content of files or packages. Finally, we assume SCA tools report only the packages and vulnerabilities they find in the image and do not inflate their findings.

## 3.2 Systematic review

To ground our research in plausible obscuration scenarios, we conducted a systematic review of existing work on container image security. This process allowed us to catalog known obscuration tactics and also revealed significant gaps, which led to the identification of previously unknown techniques. For that, we followed the three-step approach as recommended by Petersen et al. [42].

(1) *Source identification.* We gathered information sources from both academia and industry. In detail, we considered research work from the top-tier venues in security and software engineering [13, 14, 17, 22, 30, 31, 34] — including ACM CCS, NDSS, USENIX Security, IEEE S&P, ICSE, FSE, ASE — and published in the last five years. We also searched for papers outside of the top conferences but containing relevant keywords [6, 9, 27, 56]. Finally, we included industry standards [36, 37, 49], white-papers [1, 24, 25, 35], conferences [5, 7], and open-source tools [3, 10, 19, 26, 33, 44, 45].

(2) *Inclusion and Exclusion Criteria.* Among the initial corpus of sources, we selected the ones discussing attacks on the software supply chain or on container images. In the end, we were left with five academic works [6, 13, 14, 30, 34] and two industry ones [5, 7].

(3) *Codify results.* Two of the authors independently extracted obscuration tactics and targets from the final artifacts and identified four existing tactics for container image obscuration.

(4) *Novel tactics.* Building upon the systematic review, we identified new obscuration cases that, to the best of the authors' knowledge, have not been previously documented. We found new ways to alter the content of the container images. A summary of the results is available in Table 1.
<figure><img src="image_2.png" /><figcaption>Figure 1: Our layer-by-layer methodology for Software Composition Analysis in containers.</figcaption></figure>

<table><caption>Table 1: Summary of obscuration tactics</caption><thead><tr><td>ID</td><td>Tactic</td><td>Target</td><td>Description</td><td>Novel</td></tr></thead><tbody><tr><td>OS</td><td>Operating System Hiding</td><td>Operating System files</td><td>Modify/Delete OS name and version</td><td></td></tr><tr><td>OSPKG</td><td>OS Package Manager Hiding</td><td>OS Package Manager lockfile</td><td>Modify/Delete Package manager lockfile</td><td></td></tr><tr><td>DEP</td><td>Dependency Hiding</td><td>Language lockfile</td><td>Modify/Delete programming language lockfile</td><td></td></tr><tr><td>COMPRESS</td><td>Layer Compression</td><td>Every file in the system</td><td>Compress the layers of the container</td><td></td></tr><tr><td>LINK</td><td>File Linking</td><td>Any file in the system</td><td>Creating links to avoid path scanners</td><td></td></tr><tr><td>URL</td><td>External sources</td><td>Any type of package</td><td>Downloading external packages</td><td></td></tr><tr><td>PKG</td><td>Package Hiding</td><td>Language packages</td><td>Modify/Delete installed language dependencies</td><td>✓</td></tr><tr><td>ALIAS</td><td>Alias Creation</td><td>Any type of package</td><td>Creating alias to avoid path scanners</td><td>✓</td></tr></tbody></table>

## 3.3 Obscuration targets and tactics (RQ1)

In the following, we detail the different container obscuration targets and tactics.

**Operating System Hiding.** Information about the operating system is stored in specific files under the `/etc` or `/usr` directories. These generally include data about the operating system name (e.g., Ubuntu) and version (e.g., 22.04.4). Security tools use this content to identify OS-specific package versions and vulnerabilities, and if they are edited or removed then those tools will not be able to identify the OS and will report fewer packages and vulnerabilities.

**OS Package Manager Hiding.** Many operating system libraries and binaries are installed through package managers that depend on Linux distributions (e.g., `apk` for Alpine or `apt` for Debian). When a new package is installed, metadata information such as the generated files, version, and checksum is stored by the manager in a lockfile. Accessing such files is sometimes the only way to find the exact version of a package.

**Dependency Hiding.** Similarly to OS packages, programming languages have package managers that track dependencies and their

status. Dependency information may be stored in one (e.g., `requirements.txt` in Python) or two files (e.g., `package.json` and `package-lock.json` in JavaScript). In the latter case, one file contains a high-level overview of the dependencies (i.e., in terms of minimum version required or major version used); the other file is more detailed and contains hash values and timestamps.

**Layer Compression.** Compressing layers of a container image is a routine and totally legitimate operation. However, compressing layers inevitably removes information about the layers and therefore any potential obscure commands.

**File Linking.** Creating links can confuse SCA tools because they usually do not follow links, especially if the link and the linked file belong to different layers.

**Package Hiding.** The dependencies of a given application can, at times, store information about their version and their dependencies. This is not standardized, so the actual information and the way it is stored may vary. Usually, version information can be found as part of the source code, inside the package license file, or in other files that have the sole purpose of documenting the package itself. Dependency information can be fetched from the software dependency file of the package, and other files may contain hashes of the package's files.
*External sources.* Packages downloaded from the Internet are referred to as external software. They manifest either as git repositories or as compiled binaries [28]. The danger associated with external sources is that the resulting artifacts (i.e., the binaries) do not leave any provenance information in the container, and therefore SCA tools are unable to identify them.

*Alias Creation.* Aliases produce similar effects as links, but they are harder to find because the aliases are usually written in environment variables or files.

## 3.4 Detect obscure containers

Detecting cases of obscure containers is key to understanding their presence in the wild. For that, we analyze container images layer by layer by extracting them as archives and evaluating their modification history. Together with that, we analyze and parse the metadata information of the container image. We describe hereafter the overall process for detecting obscuration.

(1) *Layer and metadata extraction.* The first step of our obscuration detection process involves extracting the container metadata (which includes the index file – see Section 2) along with all image layers, which are unpacked as directories.

(2) *File extraction.* The second step consists of retrieving, for each layer of the image, the list of files within the layer directory. It is important to preserve the ordering of the layers, which we retrieve from the container's metadata.

(3) *Containerfile reconstruction and analysis.* The metadata extracted from the container image index file enables the partial reconstruction of the Containerfile content<fnref n="1" />. This reconstruction is essential for detecting instances of URL obscuration. Our approach first interpolates environment variables and arguments, after which pattern matching is applied to individual instructions in order to identify URLs or repositories. The outcome of this procedure is a list of packages.

(4) *Obscuration detection.* For each ordered layer, we list the files that have been created, modified, and deleted. This effectively generates a history of the container. We search the history for files with package content using a list of common names and paths (available in Table 7 in Appendix A). We detect obscuration when the history of such files shows updates or deletions (layer-by-layer analysis of the history), and when we find packages installed from source (using the reconstructed Containerfile).

*False positives.* Our methodology inherently introduces false positives. These stem from the fact that modification or deletion of a package can occur for benign reasons, such as software updates. In such cases, we still include the outdated packages in our results and mark them as obscured. The impact of this approach is mostly visible in the OS package manager dependencies, because application dependencies are rarely updated during the image generation process. We adopt this conservative approach because some software may have been built and statically linked to the old package and may still contain vulnerable code.

## 3.5 Obscuration-Resilient Container Analyzer

To improve SBOM accuracy, we introduce an open-source methodology named ORCA based on layer-by-layer analysis that reconstructs the full modification history of container image layers, drawing inspiration from techniques we previously demonstrated to detect obscuration. This approach increases resilience to obscuration by offering a more detailed and comprehensive analysis. In addition to identifying package metadata files (as other SCA tools do), we also analyze package-related content files, improving both file coverage (the total number of analyzed files) and SBOM completeness. Figure 1 outlines the main steps of our methodology, highlighting key features that enhance obscuration resilience in green.

(1) *Layers analysis,* (2) *File extraction,* and (3) *Containerfile reconstruction.* The first three steps follow the same process outlined in Section 3.4.

(4) *Iterative file analysis.* The fourth step involves analyzing the files in each layer. For each layer, we record the list of files present, the list of analyzed files, and a dictionary of the packages mapped to their related files, in a *layer analysis report*, updating the SBOM incrementally. We begin by analyzing the OS and its version, and updating the list of analyzed files. Next, we focus on identifying the operating system package manager. Currently, we support the DPKG, RPM, and APK OS package managers (which correspond to the ones we found in our datasets). These package managers have dedicated files or databases with the list of installed files and folders. We use this information to populate the list of analyzed files and the package dictionary. We adopt a similar approach to analyze programming language package managers.

To enhance file coverage, we map files associated with a project according to either the project's structural organization or the installation format imposed by its package manager. For example, in the case of a JavaScript project that relies on `npm`, all files located in the `node_modules` directory can be associated with that project. This strategy ensures that both package-related content and package metadata files are included in the analysis. While our aim is to maximize file coverage, we avoid redundant analysis and do not individually parse all files, especially those related to previously analyzed files.

Another unique feature of ORCA is path analysis, which identifies files and dependencies based on their path. This is useful, for instance, when Python packages are installed in non-default locations.

With respect to binaries, we choose to analyze only Go binaries because they include metadata information about the installed dependencies. This choice is in accordance with state-of-the-art tools. In fact, expression-based search of content is slow and ineffective, as there is no common structure for how versions are stored in a binary. Sometimes they may be hard-coded strings, other times they may be fetched from a shared library or computed at runtime by concatenating multiple variables. We refer the reader to existing tools such as the Intel `cve-bin` [26] for that purpose.

Finally, the packages extracted from the filesystem are added to the ones computed from the Containerfile. The final corpus of packages is then consolidated in an SBOM.

<footnote n="1">¹COPY and ADD commands will only show the shasum of the files/directories.</footnote>
In summary, our tool ORCA benefits from these four key features – layer-by-layer analysis, increased file coverage, Containerfile analysis, and file path analysis – to increase its resilience against obscure containers.

# 4 EVALUATION

This section starts by describing the dataset and the setup of our experiments. It then introduces the experiments and our answers to the research questions.

## 4.1 Datasets and experiment setup

We first describe the container analysis tools (both open-source and proprietary) used for comparison and then introduce the datasets employed for the different experiments.

Scanner tools. Several tools aim to identify software components within container images. For our study, we retrieved the most well-known open-source [40] and commercial tools. We excluded tools that do not target containers specifically (e.g., cve-bin-tool [26]) or that are outdated (e.g., Tern [52]). The list of the tools we used is provided in Table 2. All of the tools have the possibility of downloading an SBOM of the container or of the filesystem in SPDX format. Only three container security tools — namely, Scout, Trivy, and Grype — can produce SBOMs and find vulnerabilities locally, while the others require a subscription to the respective cloud provider. Cloud tools cannot be configured or fine-tuned. For each of the OSS tools, we ensured they operated under their best possible conditions. Among them, only Grype could be setup to scan every container layer.

<table><caption>Table 2: Static analysis tools used for Software Composition Analysis.</caption><thead><tr><td>Tool</td><td>Version</td><td>Company</td><td>OSS</td></tr></thead><tbody><tr><td>Grype<sup>2</sup> [3, 4]</td><td>0.77.0</td><td>Anchore</td><td>✓</td></tr><tr><td>DockerScout [10]</td><td>1.11.0</td><td>Docker</td><td></td></tr><tr><td>Trivy [45]</td><td>0.50.2</td><td>Trivy</td><td>✓</td></tr><tr><td>Artifact registry [18]</td><td>unknown</td><td>Google</td><td></td></tr><tr><td>Defender for Cloud [35]</td><td>2.2.9</td><td>Microsoft</td><td>✓<sup>3</sup></td></tr><tr><td>Inspector [1]</td><td>unknown</td><td>Amazon</td><td></td></tr></tbody></table>

Obscure container images dataset. We built our own set of obscure containers to measure the resilience of SBOM tools. We started from the official, non-obscure, python:3.10.0 container image from DockerHub that we used as a base to install a simple web server. We purposely selected this popular container as it is based on Debian and Python, both of which are supported by all the container analysis tools. Furthermore, the 3.10 version has many known vulnerabilities, making it a relevant candidate for our obscuration tests. This base image allowed us to systematically apply a variety of obscuration techniques, targeting different layers of the container, including the OS, OS packages, and language-specific dependencies. We then generated multiple variations of this image, each implementing one or more obscuration techniques.

<table><caption>Table 3: Considered datasets and their size (number of containers).</caption><thead><tr><td>Dataset</td><td>Size</td><td>Description</td></tr></thead><tbody><tr><td>DockerHub Official</td><td>100</td><td>Curated images built in collaboration with software maintainers</td></tr><tr><td>DockerHub Bitnami</td><td>100</td><td>Images maintained by Bitnami</td></tr><tr><td>DockerHub Verified</td><td>100</td><td>Images from trusted software publishers</td></tr><tr><td>DockerHub OSS</td><td>100</td><td>Images published and maintained by open-source projects sponsored by Docker</td></tr><tr><td>Quay.io</td><td>100</td><td>Most used container images in Quay.io</td></tr><tr><td>ECR</td><td>100</td><td>Images published and maintained by Amazon</td></tr></tbody></table>

Container images dataset. We assembled a dataset of 600 publicly available containers from various registries, including DockerHub [12], Quay.io [43], and Amazon Elastic Container Registry (ECR) [2]. The online repositories, maintained by Docker, RedHat, and Amazon Web Services (AWS), respectively, allow developers and organizations to upload, share, and download container images. We selected the 100 most popular container images from DockerHub Official, DockerHub Bitnami, DockerHub Verified, DockerHub OSS, Quay.io, and ECR. Table 3 provides a detailed breakdown of the datasets included in this study; they were selected to provide a diverse and representative collection of container images from different maintainers and platforms. This dataset is used to study the prevalence of obscuration in containers.

## 4.2 Resilience to obscure images (RQ2)

This experiment measures the resilience of popular open-source and proprietary SCA tools when analyzing obscure images. For that, we used the container dataset described in Section 4.1. For each tool and test case, we apply the obscuration technique(s), we generate an SBOM in the SPDX format, and measure the number of detected packages and vulnerabilities <fnref n="4" />. For Syft, the experiment was conducted both with and without enforcing layer-by-layer analysis to assess its impact on detection accuracy. We repeated the same experiment using our ORCA methodology <fnref n="5" />. We define the original, non-obscure container as our baseline.

A tool is considered vulnerable to a technique if the number of vulnerabilities or packages changes with respect to the baseline. Usually, this means that the number of packages or vulnerabilities becomes smaller. However, the URL obscuration is a special case because when we install packages without a package manager, we expect the number of total packages to grow, so if the number stays the same, it means that the tool was unable to recognize such packages. We selected a subset from all possible permutations of the obscuration techniques. We decided to analyze all individual obscuration techniques and then include combined techniques that

<footnote n="4">⁴Grype is using Syft for generating the SBOM.</footnote>

<footnote n="5">⁵Only the SBOM generation tool is open-source.</footnote>

<footnote n="4">⁴The obscured Containerfiles are available at: https://github.com/kube-security/conta-iner-obfuscation-benchmark</footnote>

<footnote n="5">⁵ORCA is available at: https://github.com/kube-security/orca. We used Grype to find vulnerabilities on the generated SBOM.</footnote>
<table><caption>Table 4: Comparison between different obscuration types with different tools. The metrics correspond to the number of vulnerabilities and packages identified. Colors indicate obscuration resilience: red if obscuration hides vulnerabilities or packages from the tool, green if obscuration has no impact. N/A indicates that the tool did not scan the container.</caption><thead><tr><th rowspan="2">Technique(s)</th><th colspan="2">Trivy</th><th colspan="2">Syft</th><th colspan="2">Syft (All)</th><th colspan="2">Scout</th><th colspan="2">Microsoft</th><th colspan="2">Gcloud</th><th colspan="2">Amazon</th><th colspan="2">ORCA</th></tr><tr><th>V</th><th>P</th><th>V</th><th>P</th><th>V</th><th>P</th><th>V</th><th>P</th><th>V</th><th>P</th><th>V</th><th>P</th><th>V</th><th>P</th><th>V</th><th>P</th></tr></thead><tbody><tr><td>BASE (no obscuration)</td><td>1164</td><td>441</td><td>625</td><td>448</td><td>625</td><td>448</td><td>123</td><td>585</td><td>154</td><td>429</td><td>722</td><td>441</td><td>471</td><td>587</td><td>2355</td><td>1046</td></tr><tr><td>OSPKG</td><td></td><td>6</td><td>11</td><td>25</td><td>25</td><td>625</td><td>448</td><td>10</td><td>23</td><td>154</td><td>429</td><td>6</td><td>12</td><td>N/A</td><td>0</td><td>2355</td><td>1046</td></tr><tr><td>URL</td><td>1164</td><td>441</td><td>625</td><td>448</td><td>625</td><td>448</td><td>123</td><td>585</td><td>154</td><td>429</td><td>722</td><td>441</td><td>471</td><td>587</td><td>2357</td><td>1047</td></tr><tr><td>LINK</td><td>1164</td><td>441</td><td>625</td><td>448</td><td>625</td><td>448</td><td>123</td><td>585</td><td>154</td><td>429</td><td>722</td><td>441</td><td>471</td><td>587</td><td>2355</td><td>1046</td></tr><tr><td>DEP</td><td>1164</td><td>441</td><td>625</td><td>448</td><td>625</td><td>448</td><td>123</td><td>585</td><td>154</td><td>429</td><td>722</td><td>441</td><td>471</td><td>579</td><td>2355</td><td>1046</td></tr><tr><td>PKG</td><td>1158</td><td>430</td><td>619</td><td>436</td><td>625</td><td>448</td><td>117</td><td>573</td><td>148</td><td>429</td><td>716</td><td>429</td><td>469</td><td>576</td><td>2355</td><td>1046</td></tr><tr><td>ALIAS</td><td>1164</td><td>441</td><td>625</td><td>448</td><td>625</td><td>448</td><td>123</td><td>585</td><td>154</td><td>429</td><td>722</td><td>441</td><td>471</td><td>587</td><td>2355</td><td>1046</td></tr><tr><td>COMPRESS</td><td>1164</td><td>441</td><td>625</td><td>448</td><td>625</td><td>448</td><td>123</td><td>585</td><td>154</td><td>429</td><td>722</td><td>441</td><td>471</td><td>587</td><td>2355</td><td>1046</td></tr><tr><td>OS</td><td>1164</td><td>441</td><td>9</td><td>448</td><td>625</td><td>448</td><td>6</td><td>18</td><td>154</td><td>429</td><td>6</td><td>12</td><td>471</td><td>587</td><td>2355</td><td>1046</td></tr><tr><td>OS + OSPKG</td><td>6</td><td>11</td><td>27</td><td>25</td><td>625</td><td>448</td><td>6</td><td>23</td><td>154</td><td>429</td><td>6</td><td>12</td><td>N/A</td><td>0</td><td>2355</td><td>1046</td></tr><tr><td>DEP + PKG</td><td>1158</td><td>430</td><td>619</td><td>436</td><td>625</td><td>448</td><td>117</td><td>573</td><td>148</td><td>429</td><td>716</td><td>429</td><td>465</td><td>568</td><td>2355</td><td>1046</td></tr><tr><td>OS + DEP</td><td>1164</td><td>441</td><td>9</td><td>448</td><td>625</td><td>448</td><td>6</td><td>18</td><td>154</td><td>429</td><td>6</td><td>12</td><td>471</td><td>579</td><td>2355</td><td>1046</td></tr><tr><td>OS + PKG</td><td>1158</td><td>430</td><td>3</td><td>436</td><td>625</td><td>448</td><td>0</td><td>6</td><td>148</td><td>429</td><td>N/A</td><td>0</td><td>469</td><td>576</td><td>2355</td><td>1046</td></tr><tr><td>OS + OSPKG + COMPRESS</td><td>6</td><td>12</td><td>27</td><td>25</td><td>27</td><td>25</td><td>6</td><td>23</td><td>0</td><td>0</td><td>6</td><td>12</td><td>N/A</td><td>0</td><td>14</td><td>454</td></tr><tr><td>OS + OSPKG + PKG</td><td>0</td><td>0</td><td>21</td><td>13</td><td>625</td><td>448</td><td>0</td><td>11</td><td>148</td><td>429</td><td>N/A</td><td>0</td><td>N/A</td><td>0</td><td>2355</td><td>1046</td></tr><tr><td>OS + OSPKG + DEP</td><td>6</td><td>11</td><td>27</td><td>25</td><td>625</td><td>448</td><td>6</td><td>23</td><td>154</td><td>429</td><td>6</td><td>12</td><td>N/A</td><td>0</td><td>2355</td><td>1046</td></tr><tr><td>OS + OSPKG + DEP + LINK</td><td>6</td><td>11</td><td>27</td><td>25</td><td>625</td><td>448</td><td>6</td><td>23</td><td>154</td><td>429</td><td>6</td><td>12</td><td>N/A</td><td>0</td><td>2355</td><td>1046</td></tr><tr><td>OS + OSPKG + DEP + PKG</td><td>0</td><td>0</td><td>21</td><td>13</td><td>625</td><td>448</td><td>0</td><td>11</td><td>148</td><td>429</td><td>N/A</td><td>0</td><td>N/A</td><td>0</td><td>2355</td><td>1046</td></tr><tr><td>OS + OSPKG + DEP + COMPRESS</td><td>6</td><td>12</td><td>27</td><td>25</td><td>27</td><td>25</td><td>6</td><td>23</td><td>0</td><td>0</td><td>6</td><td>12</td><td>N/A</td><td>0</td><td>14</td><td>454</td></tr><tr><td>OS + OSPKG + DEP + ALIAS</td><td>6</td><td>11</td><td>25</td><td>24</td><td>625</td><td>448</td><td>6</td><td>22</td><td>154</td><td>429</td><td>6</td><td>12</td><td>N/A</td><td>0</td><td>2355</td><td>1046</td></tr><tr><td>OS + OSPKG + DEP + ALIAS + COMPRESS</td><td>6</td><td>12</td><td>25</td><td>24</td><td>27</td><td>25</td><td>6</td><td>22</td><td>0</td><td>0</td><td>6</td><td>12</td><td>N/A</td><td>0</td><td>14</td><td>454</td></tr><tr><td>OS + OSPKG + DEP + ALIAS + PKG</td><td>0</td><td>0</td><td>19</td><td>12</td><td>625</td><td>448</td><td>0</td><td>10</td><td>148</td><td>429</td><td>N/A</td><td>0</td><td>N/A</td><td>0</td><td>2355</td><td>1046</td></tr></tbody></table>

obscure different parts of the container image (e.g., OS and package manager). The results are shown in Table 4.

**Single obscuration.** We started the experiment by analyzing the effect of single instances of obscuration techniques. The LINK, ALIAS, and COMPRESS techniques alone were not effective against any tool. The DEP technique was only effective against Amazon's package count. This test case is interesting because the number of vulnerabilities discovered with dependency obscuration is the same as in the baseline case. This happens because the Python dependencies of the application did not have vulnerabilities at the time of the scan.

Only Syft (with all layers scanning enabled) and Microsoft's tool were not affected by the deletion of the OS package manager file (OSPKG). In the case of Amazon Inspector, if the OS package manager is deleted, the UI does not show any sign of error, but the container is not scanned.

The table also shows that every tested tool is vulnerable to URL obscuration. This is evident from the fact that tools are unable to find the manually downloaded packages in the container image, and they report the same number of packages and vulnerabilities as the baseline.

Only Syft, in the all-layer configuration, is not affected by PKG obscuration. In the case of Microsoft Defender, the number of detected packages does not change compared to the baseline, but the number of vulnerabilities detected is lower. This mismatch occurs

because the tool cannot find the correct version of the package, and consequently, the vulnerabilities associated with it.

Finally, the OS technique only affects Syft (regarding the number of CVEs), Scout, and Google Artifact Registry. This result is explained by the fact that Syft is unable to find the correct CVE information because it misses OS information, and the other tools do not search for package information without OS information. The tools that are resilient against this technique either find OS information in other layers or by other means (e.g., metadata information of the container).

In contrast, ORCA is not affected by any of the single-obscuration techniques.

**Multiple obscuration.** We then analyzed the effect of multiple techniques on the same container. Syft, in the non-default configuration, is the only tool not affected by a combination of two or more obscuration techniques (unless one of them is the URL technique). OS and PKG techniques combined reduce the number of vulnerabilities discovered to zero in Google Artifact Analysis and Docker Scout, while in Syft (with default configuration), the number of vulnerabilities goes from 625 to 3. In the case of 3 concurrent obscurations, 5 of the 6 tools analyzed report zero vulnerabilities. We noticed that Google Artifact Registry is unable to produce results when the OS and PKG techniques are applied together. Amazon does not produce results when the OS package manager is not available.

Overall, the effect of obscuration appears to be significant; we were able to reduce the number of vulnerabilities to 0 in every
tool but Syft (which still has a ≈ 97% reduction in the number of vulnerabilities).

*Impact of multi-stage builds.* The only technique effective against all tools, including our own, is observed when a container uses a multi-stage build following other tactics. In such instances, intermediate artifacts generated in earlier layers are systematically removed and cannot be recovered.

## 4.3 Obscuration in popular containers (RQ3)

This experiment investigates the existence of obscure containers in popular container registries, using the categories defined in Section 3.3. We selected Python, Ruby, Node.js, PHP, and Go as target programming languages. Table 5 summarizes the results, showing the number of containers with missing, modified, or deleted information, respectively, across the different obscuration types. We note that the *Missing* column applies only to OS, OSPKG, and URL information, which are expected in a standard container filesystem, whereas language-specific dependencies or packages (DEP and PKG) appear only if the corresponding programming language is included.

More than 10% of the containers present OS obscuration. Among them, the majority do not have OS information in any layer of the container, approximately one-third have modified OS information, and only three containers delete OS information in one of the layers. Almost 20% of the containers download software directly from the Internet without using package managers. OSPKG obscuration manifests in more than 50% of the tested containers. Most of the instances of this misconfiguration modify the content of OS packages, which in many cases is the result of running OS updates. Approximately 10% of containers do not have any OSPKG information, and a similar number delete one or more OS packages in the container layers. The results on missing OS and OSPKG information are particularly important as they highlight that tools such as Amazon Inspector and Google Artifact Registry would not be able to scan them. Similarly, results on URL obscuration show that over 30% of the containers hide externally downloaded packages.

Finally, we found DEP and PKG obscuration on 3% and 15% of the containers, respectively. In such cases, it would be extremely complex to detect if a software dependency or package is missing because not all containers are supposed to have software dependencies.

Another analysis consists of comparing the prevalence of obscuration across containers from different registries. Table 6 shows the number of containers with missing, modified, or deleted information, for different registries across various obscuration types. A first observation is that obscure containers exist in all container registries, from DockerHub to third-party registries. Among all datasets, DockerHub Bitnami seems to be the only one with no instances of by DEP or PKG obscuration. This happens because Bitnami uses tools to automatically compress the container images, removing the layer's history. However, the tool used by Bitnami (crane [19]) keeps the original Containerfile information as metadata. The analysis of Bitnami containers revealed that over 90% of them download and install code from the Internet without using package managers. We also observed that obscure containers tend to be more present in DockerHub OSS and third-party registries

like Quay.io and ECR, where we observed a significant number of deleted or modified Python package information, among others.

<table><caption>Table 5: Number of containers respectively with missing, modified, or deleted information across various obscuration types.</caption><thead><tr><th>Obscuration type</th><th>Missing</th><th>Modified</th><th>Deleted</th></tr></thead><tbody><tr><td>OS</td><td>49</td><td>23</td><td>3</td></tr><tr><td>OSPKG</td><td>55</td><td>364</td><td>58</td></tr><tr><td>URL</td><td>187</td><td>N/A</td><td>N/A</td></tr><tr><td>DEP</td><td>N/A</td><td>15</td><td>3</td></tr><tr><td>Python</td><td>N/A</td><td>1</td><td>2</td></tr><tr><td>Ruby</td><td>N/A</td><td>2</td><td>1</td></tr><tr><td>Node.js</td><td>N/A</td><td>9</td><td>0</td></tr><tr><td>PHP</td><td>N/A</td><td>2</td><td>0</td></tr><tr><td>Go</td><td>N/A</td><td>1</td><td>0</td></tr><tr><td>PKG</td><td>N/A</td><td>69</td><td>23</td></tr><tr><td>Python</td><td>N/A</td><td>48</td><td>19</td></tr><tr><td>Ruby</td><td>N/A</td><td>5</td><td>1</td></tr><tr><td>Node.js</td><td>N/A</td><td>12</td><td>2</td></tr><tr><td>PHP</td><td>N/A</td><td>1</td><td>0</td></tr><tr><td>Go</td><td>N/A</td><td>3</td><td>1</td></tr></tbody></table>

<table><caption>Table 6: Number of containers with missing/modified/deleted information for six different registries across various obscuration types. DO: Docker Official. DB: Docker Bitnami. DV: Docker Verified. DOSS: Docker OSS. Q: Quay.io. E: ECR.</caption><thead><tr><th>Obscuration type</th><th>DO</th><th>DB</th><th>DV</th><th>DOSS</th><th>Q</th><th>E</th></tr></thead><tbody><tr><td>OS</td><td>4</td><td>3</td><td>20</td><td>19</td><td>20</td><td>6</td></tr><tr><td>OSPKG</td><td>93</td><td>3</td><td>91</td><td>98</td><td>84</td><td>50</td></tr><tr><td>URL</td><td>27</td><td>94</td><td>13</td><td>39</td><td>9</td><td>5</td></tr><tr><td>DEP</td><td>0</td><td>0</td><td>0</td><td>7</td><td>6</td><td>7</td></tr><tr><td>Python</td><td>0</td><td>0</td><td>0</td><td>2</td><td>0</td><td>1</td></tr><tr><td>Ruby</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td><td>2</td></tr><tr><td>Node.js</td><td>0</td><td>0</td><td>0</td><td>2</td><td>2</td><td>5</td></tr><tr><td>PHP</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td><td>1</td></tr><tr><td>Go</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>1</td></tr><tr><td>PKG</td><td>6</td><td>0</td><td>4</td><td>18</td><td>22</td><td>38</td></tr><tr><td>Python</td><td>3</td><td>0</td><td>2</td><td>9</td><td>11</td><td>24</td></tr><tr><td>Ruby</td><td>1</td><td>0</td><td>0</td><td>1</td><td>1</td><td>2</td></tr><tr><td>Node.js</td><td>2</td><td>0</td><td>1</td><td>3</td><td>4</td><td>2</td></tr><tr><td>PHP</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>1</td></tr><tr><td>Go</td><td>0</td><td>0</td><td>2</td><td>0</td><td>1</td><td>0</td></tr></tbody></table>

## 4.4 Coverage and Performance

This experiment evaluates the impact of our obscuration-resilient methodology on enhancing file coverage accuracy. For that, we used the same dataset as in Section 4.3. We produced an SBOM of each container using the OSS tools (performing the same analysis using cloud tools was impractical) and ORCA.

As illustrated in Figure 2a, ORCA achieves a median file coverage of 87.5%. This is possible because it analyzes files with package content and at the same time keeps track of the files related to each
package. ORCA's result are ≈40% higher than Scout and Syft and far exceeds Trivy's median file coverage of 0.53%. The reason is that Scout and Syft only report the files installed by the package manager (dpkg), while Trivy only includes files that index packages.

<figure><img src="image_3.png" /><figcaption>(a) Box plot of file coverage per scanner. The red line indicates the median value.</figcaption></figure>

<figure><img src="image_4.png" /><figcaption>(b) Average execution time of ORCA and other state-of-the-art tools. The black lines indicate the standard deviation.</figcaption></figure>

<caption>Figure 2: (a) File coverage per scanner and (b) average execution time of ORCA and other state-of-the-art tools.</caption>

Performance measurements are needed to assess the compatibil-
ity of ORCA with modern CI/CD pipelines. Therefore, we measured
the execution time of ORCA and the other scanners (see Table 2) on
the six datasets presented in Table 3. The average execution times
are shown in Figure 2b. Our analysis reveals that ORCA took, on
average, approximately 45 seconds to complete a scan, which is
one second faster than Docker Scout and about 30 seconds slower
than the other tools. The standard deviation is also limited (<10
seconds), indicating that ORCA scales well with the size of the
container image. Considering ORCA's enhancements in resilience
and filesystem coverage, the resulting execution time is suitable for
typical CI/CD workflows.

5 RELATED WORK

This section discusses recent works on Software Composition Anal-
ysis for containers and threats to the software supply chain.

5.1 SCA for container images

Recent research produced a large amount of literature on SBOMs, which can be divided into three main categories: SBOM generation, comparative analysis of SBOM tools, and identification of technical challenges. For SBOM generation tools, we refer the reader to Table 2 that provides an overview of available tools for scanning container images. Studies such as [27, 40, 53, 55] do not propose novel SCA methodologies but instead conduct qualitative analysis of existing SBOM generation tools for containers, comparing the tools' results across various datasets and evaluating their performance. The work of Kawaguchi et al. [28] is the first to discuss the issues of external URL not being recognized by SCA tools. However, they do not discuss other causes of obscure containers. Doan et al. [9] also noticed the possibility for containers to download packages from the Internet, but they focus on identifying so-called Potentially Vulnerable Files within container images, aiming to prioritize vulnerability detection over exhaustively finding all packages. These works highlight challenges, particularly in measuring and assuring two key metrics of SBOM generators: 1) completeness, which refers to how well the SBOM captures all components and dependencies, including both direct and transitive dependencies, and 2) accuracy, which assesses the correctness of the information provided in the SBOM, such as precise component names, versions, and metadata. Moreover, the authors in [53] and [21] assess the adherence of SBOM tools to the National Telecommunications and Information Administration (NTIA)'s minimum required elements [39], respectively for the SPDX and CycloneDX standards.

Given the prevalence of vulnerabilities in containers, several Docker Image Vulnerability Scanners have been developed [10, 44, 45, 48, 52] to inspect containers and detect vulnerable components. These tools are relevant to SBOM generators, and some can detect vulnerabilities and generate SBOMs. Other works [8, 46, 54, 56] discuss vulnerabilities of container images caused by third-party components, highlighting the importance of improving SCA techniques to reduce the risk of compromised containers.

## 5.2 Attacks on the software supply chain

Every link in the software supply chain can be targeted by malicious actors or weakened by misconfigurations and a lack of best practices. Ladisa et al. [30] built an inventory of the main attacks and threats to the software supply chain. They identified 107 attack vectors and provided guidelines for both developers and third-party operators. Their primary focus is on malicious actors that either try to subvert legitimate packages — by e.g., injecting malicious payloads in the application’s source code — or to create naming confusions with popular dependencies. Other works [20, 29] have targeted the security of the build systems (CI/CD platforms), which should guarantee an isolated and trusted environment for building artifacts. The authors discovered numerous cases of over-permission and possible data leakage. In contrast, our work focuses on attacks that exploit weaknesses in SCA tools.

# 6 DISCUSSION

This section summarizes the key takeaways of our research, dis-
cusses our interactions with cloud providers, and gives insights
into future work.
## 6.1 Key results and takeaways

**Obscure images.** The first result of our research is that all SCA tools for containers are unable to detect and scan, to varying degrees, obscure images. Such images are often not detected because of an incomplete analysis process that does not take into account all of the layers, files, and externally downloaded software.

**Scanning vs Ignoring obscure images.** We observed that Amazon Inspector and Google Artifact Registry do not analyze containers that lack an operating system or a package manager, respectively. This appears to reflect a deliberate choice by the providers to disregard images that do not contain certain expected files. However, we argue that excluding such images is problematic for several reasons. First, non-scanned images are difficult to distinguish from genuinely non-vulnerable ones, and may therefore be incorrectly perceived as non-vulnerable in the UI. Second, developers may still rely on obscure images, for example, because they trust the correctness of their Containerfiles. Finally, containers without an operating system or package manager are not necessarily obscure by default, as images may legitimately consist of a single binary without targeting a specific operating system.

**Limitations.** Several factors may affect the accuracy and validity of our results. First, we do not parse binary files, which may cause us to miss package information embedded in ELF/PE symbols. Second, all images used to generate the obscured containers are based on the same stack (a Debian base image with Python packages). Third, our methodology is effective against obscure containers only if the entire build process occurs inside the container. For example, we cannot detect LINK or ALIAS techniques if they are created outside the Containerfile. This limits the generalizability of our results, as the evaluation may not fully capture resilience across different distributions, ecosystems, or polyglot container environments. In addition, we do not analyze baseline differences among tools, which prevents us from directly comparing them. Finally, our tool ORCA was optimized for the operating systems and package managers present in our dataset.

**Comparison of SCA tools.** The current literature on SCA tends to measure the performance of container scanning tools based on the number of CVEs they detect. In this paper, we demonstrated that the number of vulnerabilities is not a correct measure of the completeness of a scan. On the contrary, it may give a false sense of security because vulnerabilities may be duplicated or not applicable to a specific context (e.g., development dependency is not installed or the vulnerability relates to a different architecture). Similarly, the number of detected packages alone is not sufficient to demonstrate the performance of a tool. In fact, some tools display Windows packages on Linux containers or have multiple entries for the same package. In this work, we demonstrated that file-system coverage is a better metric because it indicates how many files cannot be identified as packages or package-related content.

## 6.2 Mitigations and Remediations

The main mitigation against obscure containers is ensuring transparency in the container image contents (i.e., make them easy to scan). In practice, this means guaranteeing that the files used to index packages are included in the final container artifact. We have

identified five actionable remediations developers can adopt to avoid building obscure images:

**Reduce image size responsibly.** Reducing space in a container image should not involve manually deleting operating system files (e.g., `rm -rf /etc/*`). This practice can remove critical metadata needed for vulnerability scanning and software auditing. Instead, use tools like `docker-slim` [47] or minimal base images to reduce image size safely.

**Use of multi-stage builds.** When using multi-stage builds, we recommend copying dependency information files along with the final artifacts. These files are often discarded in the final stage, but are essential for tracking software components. Retaining them enables security tools to perform accurate analysis of all installed packages.

**Correct software installation.** Prefer installing software using the operating system's package manager. This ensures that proper metadata and dependency information are preserved, enabling better security analysis. Manual or source-based installations may bypass package tracking, reducing visibility into potential vulnerabilities.

**Transparency of compiled software.** When software must be compiled from source, ensure that package-identifiable metadata is preserved (e.g., `.git/` folder in the case of public repositories). This allows for the detection of vulnerable components and supports better traceability of build-time configurations.

**Verify supported ecosystems.** Each Software Composition Analysis (SCA) tool supports different package managers and programming languages. Ensuring compatibility with the contents of the container image helps avoid false negatives during analysis.

## 7 CONCLUSION AND FUTURE WORK

This paper explores novel attacks on the software supply chain, specifically targeting software containers and SBOM (Software Bill of Materials) documents. Through extensive evaluation of both open-source and proprietary cloud tools, we demonstrate their lack of resilience against such attacks. We introduce new methodologies to uncover obscure container images and mitigate their associated attack surfaces. A comprehensive analysis of 600 popular containers enabled us to identify hundreds of such obscure images. We show that our methodology improves filesystem coverage by up to 600% compared to state-of-the-art tools. We responsibly disclosed our findings to the maintainers of various SCA tools and engaged in constructive discussions. In the future, we anticipate broader adoption of coverage-based SCA mechanisms. As part of future work, we plan to extend our study to include malicious obfuscation and analysis of entry-point scripts. Another potential area of study is understanding the differences in the tools' baseline results regarding packages and vulnerabilities.

## ACKNOWLEDGMENTS

We thank our shepherd for valuable guidance and feedback throughout the review process. This work was partly supported by the European Commission under grant n.101120393 (Sec4AI4Sec).
REFERENCES

[1] Amazon Web Services, Inc. 2024. Amazon Inspector. https://aws.amazon.com/i nspector/. Accessed: 2025-05-10.

[2] Amazon Web Services, Inc. 2024. Elastic Container Registry (ECR). https://aws.amazon.com/ecr/. Accessed: 2025-05-20.

[3] Anchore, Inc. 2024. Grype: A Vulnerability Scanner for Container Images and Filesystems. https://github.com/anchore/grype. Accessed: 2025-05-22.

[4] Anchore, Inc. 2024. Syft: CLI tool and library for generating a Software Bill of Materials from container images and filesystems. https://github.com/anchore/s yft. Accessed: 2024-11-20.

[5] Geesaman Brad, Coldwater Ian, McCune Rory, and Cooley Duffie. 2023. Malicious Compliance: Reflections on Trusting Container Scanners. In *KubeCon Europe 2023*. Cloud Native Computing Foundation (CNCF).

[6] Kelly Brady, Seung Moon, Tuan Nguyen, and Joel Coffman. 2020. Docker Con- tainer Security in Cloud Computing. In *2020 10th Annual Computing and Com- munication Workshop and Conference (CCWC)*. 0975-0980. https://doi.org/10.110 9/CCWC47524.2020.9031195

[7] Lum Brandon and Hepworth Isaac. 2024. Lessons Learned from Generating 100m SBOMs Google's Approach to SBOM Compliance. In *KubeCon Europe 2024*. Cloud Native Computing Foundation (CNCF).

[8] Thanh Bui. 2015. Analysis of Docker Security. arXiv:1501.02967 [cs.CR]. https://arxiv.org/abs/1501.02967

[9] Phuc Doan and Souhwan Jung. 2022. DAVS: Dockerfile Analysis for Container Image Vulnerability Scanning. *Computers, Materials & Continua* 72 (Jan. 2022), 1699-1711. https://doi.org/10.32604/cmc.2022.025096

[10] Docker, Inc. 2024. Docker Scout. https://docs.docker.com/scout/. Accessed: 2025-05-22.

[11] Docker, Inc. 2024. Dockerfile. https://docs.docker.com/reference/dockerfile/. Accessed: 2025-05-20.

[12] Docker, Inc. 2024. DockerHub. https://hub.docker.com/. Accessed: 2025-05-20.

[13] Ruian Duan, Omar Alrawi, Ranjita Pai Kasturi, Ryan Elder, Brendan Saltaformag- gio, and Wenke Lee. 2020. Towards measuring supply chain attacks on package managers for interpreted languages. *arXiv preprint arXiv:2002.01139* (2020).

[14] William Enck and Laurie Williams. 2022. Top Five Challenges in Software Supply Chain Security: Observations From 30 Industry and Government Organizations. *IEEE Security & Privacy* 20, 2 (2022), 96-100. https://doi.org/10.1109/MSEC.2022. 3142338

[15] European Union. 2024. Regulation 2024/2847 (Cyber Resilience Act). https://eur- lex.europa.eu/eli/reg/2024/2847. Accessed: 2025-05-20.

[16] Olivier Flauzac, Fabien Mauhourat, and Florent Nolot. 2020. A Review of Native Container Security for Running Applications. *Nucleon Computer Science* 175 (Jan. 2020), 157-164. https://doi.org/10.1016/j.procs.2020.07.025

[17] Marcel Fourné, Dominik Wermke, Sascha Fahl, and Yasemin Acar. 2023. A Viewpoint on Human Factors in Software Supply Chain Security: A Research Agenda. *IEEE Security & Privacy* 21, 6 (2023), 59-63. https://doi.org/10.1109/MS EC.2023.3316569

[18] Google, Inc. 2024. Artifact Analysis. https://cloud.google.com/artifact-analysis. Accessed: 2025-05-10.

[19] Google, Inc. 2024. Crane. https://github.com/google/go-containerregistry. Accessed: 2025-05-20.

[20] Yacong Gu, Lingyun Ying, Huajun Chai, Chu Qiao, Haixin Duan, and Xing Gao. 2023. Continuous Intrusion: Characterizing the Security of Continuous Integration Services. In *2023 IEEE Symposium on Security and Privacy (SP)*. IEEE, 3 Park Avenue, 17th Floor, New York, NY 10016-5997, USA, 1561-1577. https://doi.org/10.1109/SP46215.2023.10179471

[21] Andreas Halbritter and Dominik Merli. 2024. Accuracy Evaluation of SBOM Tools for Web Applications and System-Level Software. In *Proceedings of the 19th International Conference on Availability, Reliability and Security (Vienna, Austria) (ARES '24)*. Association for Computing Machinery, New York, NY, USA, Article 55, 9 pages. https://doi.org/10.1145/3664476.3670926

[22] Trey Herr. 2021. Breaking Trust - Shades of Crisis Across an Insecure Software Supply Chain. In *USENIX 2021*. USENIX Association, 2560 Ninth Street, Suite 215, Berkeley, CA 94710, USA.

[23] Nasif Imtiaz, Seaver Thorn, and Laurie Williams. 2021. A comparative study of vulnerability reporting by software composition analysis tools. In *Proceedings of the 15th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)*. 1-11.

[24] Amazon Inc. 2024. Scan Images for OS and Programming Language Package Vulnerabilities in Amazon ECR - Amazon ECR. https://docs.aws.amazon.com/ AmazonECR/latest/userguide/image-scanning-enhanced.html.

[25] Docker Inc. 2024. Understanding the Image Layers. https://docs.docker.com/gu ides/docker-concepts/building-images/understanding-image-layers/. Accessed: 2025-05-17.

[26] Intel, Inc. 2024. cve-bin-tool. https://github.com/intel/cve-bin-tool. Accessed: 2025-05-22.

[27] Omar Javed and Salman Toor. 2021. Understanding the Quality of Container Security Vulnerability Detection Tools. *arXiv preprint* (01 2021). https://doi.org/

10.48550/arXiv.2101.03844

[28] Nobutaka Kawaguchi, Charles Hart, and Hiroki Uchiyama. 2024. Understanding the Effectiveness of SBOM Generation Tools for Manually Installed Packages in Docker Containers. *Journal of Internet Services and Information Security (JISIS)* (2024). https://doi.org/10.58346/JISIS.2024.I3.011

[29] Igibek Koishybayev, Aleksandr Nahapetyan, Raima Zachariah, Siddharth Muralee, Bradley Reaves, Alexandros Kapravelos, and Aravind Machiry. 2022. Character- izing the Security of Github CI Workflows. In *31st USENIX Security Symposium (USENIX Security 22)*. USENIX Association, Boston, MA, 2747-2763. https://www.usenix.org/conference/usenixsecurity22/presentation/koishybayev

[30] Piergiorgio Ladisa, Henrik Plate, Matias Martinez, and Olivier Barais. 2023. SoK: Taxonomy of Attacks on Open-Source Software Supply Chains. In *2023 IEEE Symposium on Security and Privacy (SP)*. 1509-1526. https://doi.org/10.1109/SP 46215.2023.10179304

[31] E. Levy. 2003. Poisoning the software supply chain. *IEEE Security & Privacy* 1, 3 (2003), 70-73. https://doi.org/10.1109/MSECP.2003.1203227

[32] Peiyu Liu, Shouling Ji, Lirong Fu, Kangjie Lu, Xuhong Zhang, Wei-Han Lee, Tao Lu, Wenzhi Chen, and Raheem Beyah. 2020. Understanding the Security Risks of Docker Hub. In *Computer Security - ESORICS 2020*, Liqun Chen, Ninghui Li, Kaitai Liang, and Steve Schneider (Eds.). Springer International Publishing, Cham, 257-276. https://doi.org/10.1007/978-3-030-58951-6_13

[33] Rory McCune. [n. d.]. Fun with Container Images - Bypassing Vulnerability Scanners. https://raesene.github.io/blog/2023/04/22/Fun-with-container-images- Bypassing-vulnerability-scanners/.

[34] Marcela S. Melara and Santiago Torres-Arias. 2023. A Viewpoint on Software Supply Chain Security: Are We Getting Lost in Translation? *IEEE Security & Privacy* 21, 6 (2023), 55-58. https://doi.org/10.1109/MSEC.2023.3316568

[35] Microsoft, Inc. 2024. SBOM Tool. https://github.com/microsoft/sbom-tool. Accessed: 2025-05-10.

[36] National Institute of Standards and Technology. 2024. Common Platform Enu- eration (CPE). https://nvd.nist.gov/products/cpe. Accessed: 2025-05-20.

[37] National Institute of Standards and Technology. 2024. Executive Order 14028. https://www.nist.gov. Accessed: 2025-05-20.

[38] National Institute of Standards and Technology. 2024. National Vulnerability Database. https://nvd.nist.gov/search. Accessed: 2025-05-20.

[39] National Telecommunications and Information Administration (NTIA). 2019. NTIA Software Bill of Materials (SBOM) Formats and Standards. https://www. ntia.gov/files/ntia/publications/ntia_sbom formats_and_standards whitepape r_-_version_20191025.pdf Version 20191025.

[40] Eric O'Donoghue, Brittany Boles, Clemente Izurieta, and Ann Marie Reinhold. 2023. Impacts of software bill of materials (SBOM) generation on vulnerability detection. In *Proceedings of the 2024 Workshop on Software Supply Chain Offensive Research and Ecosystem Defenses*. 67-76.

[41] OWASP Foundation. 2021. OWASP Top Ten. https://owasp.org/Top10. https://owasp.org/Top10 Version 2021.

[42] Kai Petersen, Sairam Vakkalanka, and Ludwik Kuzniarz. 2015. Guidelines for conducting systematic mapping studies in software engineering: An update. *Information and software technology* 64 (2015), 1-18.

[43] Red Hat, Inc. 2024. Quay.io. https://quay.io/. Accessed: 2025-05-20.

[44] RedHat, Inc. 2024. Clair: Vulnerability Static Analysis for Containers. https://github.com/quay/clair. Accessed: 2025-05-22.

[45] Aqua Security. 2024. Trivy: A Simple and Comprehensive Vulnerability Scanner for Containers and Other Artifacts. https://trivy.dev/. Accessed: 2025-05-22.

[46] Rui Shu, Xiaohui Gu, and William Enck. 2017. A Study of Security Vulnerabilities on Docker Hub. In *Proceedings of the Seventh ACM on Conference on Data and Application Security and Privacy*. ACM, Scottsdale Arizona USA, 269-280. https://doi.org/10.1145/3029806.3029832

[47] Slim.AI, Inc. 2024. Slim: Optimize and secure your containerized applications. https://github.com/slimtoolkit/slim. Accessed: 2025-05-20.

[48] Snyk. 2024. Docker Security Scanning Guide. https://snyk.io/articles/docker- security-scanning/. Accessed: 2024-12-19.

[49] Murugiah Souppaya, John Morello, and Karen Scarfone. 2017. *Application con- tainer security guide*. Technical Report. National Institute of Standards and Technology.

[50] Sari Sultan, Imtiaz Ahmad, and Tassos Dimitriou. 2019. Container Security: Issues, Challenges, and the Road Ahead. 52976-52996 pages. https://doi.org/10.1109/ACCESS.2019.2911732

[51] The Linux Foundation. 2024. System Package Data Exchange (SPDX). https://spdx dev/. Accessed: 2025-05-20.

[52] Tern Tools. 2024. Tern. https://github.com/tern-tools/tern. Accessed: 2025-05-20.

[53] Santiago Torres-Arias, Dan Geer, and John Speed Meyers. 2023. A Viewpoint on Knowing Software: Bill of Materials Quality When You See It. *IEEE Security & Privacy* 21, 6 (2023), 50-54. https://doi.org/10.1109/MSEC.2023.3315887

[54] Katrine Wist, Malene Helsem, and Danilo Gligoroski. 2021. Vulnerability Analysis of 2500 Docker Hub Images. In *Advances in Security, Networks, and Internet of Things*, Kevin Daimi, Hamid R. Arabnia, Leonidas Deligiannidis, Min-Shiang Hwang, and Fernando G. Tinetti (Eds.). Springer International Publishing, Cham, 307-327. https://doi.org/10.1007/978-3-030-71017-0_22
```bash
# Stage 1 - Build app
FROM node:18 AS builder
WORKDIR /app
COPY . .
RUN rpm install && rpm run build

# Stage 2 - Serve with nginx
FROM nginx:alpine
COPY --from=builder /app/build /usr/share/nginx/html
```

#### (a) Obscure Dockerfile

```bash
# Stage 1 - Build app
FROM node:18 AS builder
WORKDIR /app
COPY . .
RUN rpm install && rpm run build

# Stage 2 - Serve with nginx
FROM nginx:alpine
COPY --from=builder /app/build /usr/share/nginx/html
COPY --from=builder /app/package*.json /app
```

#### (b) Improved Dockerfile

<caption>Figure 3: a) An example of an obscure JavaScript container build. b) Same container made more transparent and easier to scan.</caption>

```bash
FROM debian:bullseye AS builder
ENV CURL_VERSION=8.7.1
RUN curl -LO https://curl.se/download/curl- ${CURL_VERSION}.tar.gz && \ tar -xzf curl-${CURL_VERSION}.tar.gz && \ cd curl-${CURL_VERSION} && \ ./configure --with-ssl && \ make -j$(nproc) && make install && \ cd .. && rm -rf curl-${CURL_VERSION}*```

#### (a) Obscure Dockerfile

```bash
# Stage 1 - Build
FROM debian:bullseye AS builder
RUN apt-get install -y curl
```

#### (b) Improved Dockerfile

<caption>Figure 4: a) OS binary (OSPKG) package installed from source. b) The same package installed via the package manager.</caption>

## A PACKAGE OBSCURATION LOCATION

This appendix contains detailed information about the types and patterns of files used to detect obscuration in our work. They are presented in Table 7.

## B EXAMPLE CHANGES IN CONTAINERFILES

The following illustrates a few examples of changes in a Container-file that ease the scan of the image. The first example in Figure 3 shows two different Containerfiles for a JavaScript (React) application. Both images uses multi-stage builds. The obscure version (Fig. 3a) copies to the final container layer only the build artifact which contains an index.html and a minified JavaScript file. This image is hard to scan because there is no direct information on the dependencies used to build and package the application. The other version of the same Containerfile (Fig. 3b) includes the package metadata, allowing SCA tools to easy find dependencies and possible CVEs. Figure 4 shows instead two different ways to install a package: from source and using the package manager. The first version is impossible to scan using state-of-the-art SCA tools, while the second version is instead easy to scan.

<table><caption>Table 7: Patterns used for obscuration detection. For each file in a container, if the file matches one of the patterns and its history shows modifications, then is considered obscure</caption><thead><tr><th>ID</th><th>Type</th><th>Pattern</th></tr></thead><tbody><tr><td>OS</td><td>Any</td><td>os-release, etc-release<br>debian_version</td></tr><tr><td>OSPKG</td><td>DPKG</td><td>dpkg/status, var/lib/dpkg</td></tr><tr><td></td><td>RPM</td><td>rpm/Packages, rpmbd.sqlite<br>var/lib/yum, var/cache/yum</td></tr><tr><td></td><td>APK</td><td>yum.repos.d<br>apk/db/installed, apk/world</td></tr><tr><td>DEP</td><td>Python</td><td>Pipfile, requirements.txt</td></tr><tr><td></td><td>Ruby</td><td>.gemspec</td></tr><tr><td></td><td>Node.js</td><td>package.json, package-lock.json<br>yarn.lock</td></tr><tr><td></td><td>PHP</td><td>composer.json, composer.lock</td></tr><tr><td></td><td>Go</td><td>go.sum, go.mod</td></tr><tr><td>PKG</td><td>Python</td><td>dist-info/, egg-info/<br>site-packages/, dist-packages/</td></tr><tr><td></td><td>Ruby</td><td>gems/</td></tr><tr><td></td><td>Node.js</td><td>node_modules/</td></tr><tr><td></td><td>PHP</td><td>/vendor/</td></tr><tr><td></td><td>Go</td><td>/go/</td></tr></tbody></table>

<footnote>[55] Sheng Yu, Wei Song, Xunchao Hu, and Heng Yin. 2024. On the Correctness of Metadata-Based SBOM Generation: A Differential Analysis Approach. In 2024 54th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). 29–36. https://doi.org/10.1109/DSN58291.2024.00018</footnote>

<footnote>[56] Nannan Zhao, Vasily Tarasov, Hadeel Albahar, Ali Anwar, Lukas Rupprecht, Dimitrios Skourtis, Arnab K. Paul, Keren Chen, and Ali R. Butt. 2021. Large-Scale Analysis of Docker Images and Performance Implications for Container Storage Systems. IEEE Transactions on Parallel Distributed Systems 32, 4 (April 2021), 918–930. https://doi.org/10.1109/TPDS.2020.3034517</footnote>