Pith. sign in

REVIEW 4 major objections 6 minor 56 references

ORCA: Unveiling Obscure Containers In The Wild

T0 review · 4 major / 6 minor · reviewed 2026-08-04 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Container obscuration hides vulnerable packages from SCA tools, and ORCA's layer-by-layer analysis recovers them with about 40% higher file coverage.

desk verdict Useful taxonomy and tool, but the prevalence and coverage numbers lean on an obscuration definition that counts routine package updates, so the headline 40% gain needs independent ground truth. read the letter →

arxiv 2509.09322 v1 pith:6PUUIPIN submitted 2025-09-11 cs.SE cs.CR

Jacopo Bufalino , Agathe Blaise , Stefano Secci This is my paper
classification cs.SEcs.CR
keywords containersecuritysoftwarecompositionanalysisSBOMobscurationlayer-by-layervulnerabilityscanningsupplychainDocker
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper tries to establish that container obscuration—benign build practices that delete or modify package metadata files, install software outside a package manager, or compress/link layers—is common in popular registries and causes software composition analysis (SCA) tools to produce incomplete SBOMs that miss vulnerable packages. The authors introduce ORCA, a layer-by-layer analyzer that reconstructs a container's file-modification history, analyzes package content files in addition to metadata, and parses the reconstructed build file to catch externally downloaded packages. On a dataset of 600 popular containers from six registries, more than half show modification or deletion of OS package-manager files and nearly a third download software directly from the internet; ORCA achieves a median file coverage of 87.5%, roughly 40% higher than Docker Scout and Syft, while running in about 45 seconds. If the claim holds, current SBOMs from leading tools are systematically under-reporting components, and security decisions based on those SBOMs should be revisited.

What carries the argument

The central mechanism is layer-by-layer analysis combined with a formal obscuration taxonomy. ORCA unpacks each container layer in order, reconstructs the Containerfile from image metadata, detects modifications or deletions of files matching package-metadata patterns (OS release files, dpkg/rpm/apk databases, lockfiles such as package-lock.json and requirements.txt), and analyzes package content directories (node_modules, site-packages, gems) plus file paths to capture non-standard installs. The 'modification history' it reconstructs is what lets it recover packages that a squashed-filesystem scan would miss, and its Containerfile pattern-matching catches software fetched via URLs in build

What would settle it

Build a benchmark of 100 container images with known ground-truth package sets (e.g., from explicit package-manager install lists), obscure half of them by deleting/modifying metadata, and measure precision and recall of ORCA vs Syft/Scout on detected packages. If ORCA's higher file coverage does not translate into higher recall on true package identities, the central claim fails; if it does, the claim is confirmed.

Watch

Extended reading notes

Core claim

The paper's central discovery is that all tested SCA tools—open-source Grype/Syft, Trivy, and Docker Scout, and cloud services Google Artifact Registry, Microsoft Defender, and Amazon Inspector—lose packages or vulnerabilities when container layers are obscured: deleting the OS package-manager file makes Amazon and Google skip scanning, URL downloads bypass every tool, and combined obscuration can drive detected vulnerabilities to zero. ORCA resists these tactics by scanning each layer's file history and content, not just the final squashed filesystem. The authors also demonstrate that obscure containers are prevalent in the wild: over 50% of 600 popular images modify or delete OS package-ma

Load-bearing premise

The load-bearing premise is that 'obscuration' is correctly identified by any modification or deletion of a package-metadata pattern file, so routine updates count as obscuration—and the paper's prevalence numbers and coverage improvement depend on that classification without a ground-truth precision/recall check.

Editorial extensions

If this is right

  • Existing SBOMs generated by Docker Scout, Syft, and similar tools are likely incomplete for a large fraction of popular and 'official' images, so vulnerability scans built on them understate exposure.
  • Cloud SCA products that silently skip images lacking OS or package-manager files should be interpreted as 'not scanned' rather than 'no findings'; ORCA provides a way to identify those skipped images.
  • File coverage should be adopted as a standard SBOM metric alongside package and CVE counts, since it reveals how much of an image's content remains unidentified.
  • ORCA's ~45-second average runtime makes continuous obscuration detection feasible in CI/CD pipelines, allowing teams to catch images that scanners will later fail to analyze.
  • Applying the paper's remediations—keeping dependency metadata in multi-stage builds, installing via package managers, preserving .git for source builds—would make images scannable and reduce the hidden vulnerability surface.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Because the paper counts routine OS updates as obscuration, its >50% OSPKG 'modification' prevalence is an upper bound on genuinely suspicious behavior; the safer conclusion is that metadata loss is widespread, not that most images are maliciously obscured.
  • The authors do not parse binaries, so ORCA likely still misses dynamically embedded dependency metadata (e.g., stripped Go binaries); an extension that combines ORCA's layer history with binary string scanning could close that gap.
  • The obscuration tactics are 'benign' primitives an attacker could adopt deliberately to hide known-vulnerable components in a convincing, reproducible image; ORCA-style layer inspection would expose this evasion even when the image's final state looks clean.
  • A testable extension: run ORCA and competing tools on a polyglot dataset (multi-stage Node/Python/Go images) with known ground-truth package lists to measure precision and recall, not just file coverage.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper introduces and studies 'container obscuration'—modifications to container filesystems (deleted/modified package metadata, OS files, source-installed software, layer compression, links, aliases) that hinder Software Composition Analysis (SCA) tools. The authors catalog eight obscuration tactics (Table 1), evaluate seven cloud/OSS scanners on a single obscure container derived from python:3.10.0 on Debian (Table 4), survey 600 popular images from DockerHub, Quay.io, and ECR for obscuration prevalence (Tables 5–6), and present ORCA, an open-source layer-by-layer analyzer that reconstructs image history, analyzes package-related content files beyond metadata, and reconstructs Containerfile commands. The headline claims are that ORCA detects obscure container content and achieves a median 40% improvement in file coverage over Docker Scout and Syft.

Significance. If the results hold, this is a valuable contribution: it gives the field a systematic vocabulary and initial catalog of container obscuration, quantifies that such images are not rare in popular registries, provides an open-source tool (ORCA) with a reproducible artifact, and responsibly discloses findings to vendors. The paper is also honest about several limitations, including the single-base-image evaluation and the false-positive issue in obscuration detection. However, the central empirical claims—prevalence of obscuration and the 40% file-coverage improvement—rest on definitions and metrics that are not independently validated. The contribution is therefore promising but not yet established.

major comments (4)
  1. [§3.4(4), Table 5] The obscuration detection definition conflates benign package updates with intentional obscuration. The paper states: '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.' This is not a minor caveat: it directly drives RQ3. Table 5 reports 364 of 600 containers with 'Modified' OSPKG and attributes most of these to running OS updates. The prevalence claim that 'OSPKG obscuration manifests in more than 50% of the tested containers' is therefore an artifact of the detection rule, not evidence of deliberate or accidental obscuration. The same rule makes ORCA's layer-by-layer analysis include stale, superseded, or whiteouted versions of packages, which can inflate package counts and the file-coverage metric. I ask for a ground-truth validation—e.g., a manua
  2. [§4.4, Figure 2a] The central 'median 40% improvement in file coverage' claim is computed with a metric defined by ORCA's own counting convention, with no independent ground truth. The paper does not define the denominator of 'file coverage' or state how each tool's reported files are counted. The explanation that 'Scout and Syft only report the files installed by the package manager (dpkg), while Trivy only includes files that index packages' indicates that the comparison is not apples-to-apples: ORCA counts all package-related content files by construction, while the baselines count only package-manager metadata. Without validating ORCA's analyzed-file set against a known-correct inventory of files/packages that actually remain in the final image, the 40% gain may simply reflect ORCA's broader scanning policy, not improved detection of genuinely obscure content. Please provide a precise definition of th
  3. [§4.2, Table 4] The resilience evaluation uses a single base image (python:3.10.0 on Debian) with one simple web server. This is acknowledged in §6.1, but the conclusions drawn in §4.2 are stated broadly: 'every tested tool is vulnerable to URL obscuration' and 'ORCA is not affected by any of the single-obscuration techniques.' A single-stack, single-application evaluation cannot support such general claims, especially because ORCA's design is tailored to the OS/package managers in the dataset (also acknowledged). The authors should either evaluate on multiple base distributions and ecosystems (e.g., Alpine, Ubuntu, distroless, non-Python runtimes) or substantially temper the wording so the RQ2 answer explicitly reflects the tested conditions.
  4. [§4.3, Table 5] Counting 'Missing' OS and OSPKG information as obscuration is problematic because the paper itself later acknowledges that '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.' Yet Table 5 and the surrounding text treat 49 missing-OS and 55 missing-OSPKG images as cases of 'OS obscuration' and 'OSPKG obscuration.' This conflates legitimate minimal images (scratch, distroless, single-binary) with obscuration and further overstates prevalence. The analysis needs to separate legitimate minimal images from images where OS/package-manager metadata was present and then removed or modified.
minor comments (6)
  1. [Abstract, §1, §7] The improvement claims are inconsistent: abstract says 'median 40% improvement,' introduction says 'at least 24%,' and conclusion says 'up to 600%.' Please use a single, precisely defined statistic throughout (e.g., median, minimum, maximum) and report the corresponding distributions.
  2. [Footnote 5] Typo: 'ORCA is vailable at' should be 'available.' Also, the relationship between ORCA and Grype for vulnerability detection should be stated in the main text, since Table 4 reports vulnerability counts for ORCA.
  3. [Figure 2] Figure 2a lacks axis units and a clear definition of 'file coverage'; Figure 2b reports execution time but does not state the machine/container environment used for measurements. Please add this information to the caption or text.
  4. [§3.2] The text says the systematic review identified 'four existing tactics,' but Table 1 lists eight rows. Clarify whether the remaining four are the novel tactics and how the 'Novel' column relates to this count.
  5. [§4.1, Table 2] Table 2 lists 'Microsoft Defender for Cloud' with checkmark 'OSS' but footnote says only the SBOM generation tool is open-source. This is confusing; clarify in the table or footnote.
  6. [Tables 5–6] The tables would benefit from statistical comparison across registries (e.g., tests for whether DockerHub OSS/ECR differ from Docker Official). Without such tests, statements like 'obscure containers tend to be more present in DockerHub OSS and third-party registries' are impressionistic.

Circularity Check

2 steps flagged · score 5.0 of 10

Headline file-coverage gain is largely endogenous to ORCA's own counting convention, and obscuration prevalence is measured with a definition that admits routine updates as obscuration.

  1. self definitional [Section 4.4, Figure 2a; Section 3.5(4)]
    "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."

    ORCA's 'file coverage' is defined as the set of files ORCA decides to analyze (package metadata plus package-related content files), while Scout and Syft's coverage is defined as only package-manager-installed files. The reported 40% median improvement is therefore a consequence of the numerator in ORCA's own metric, not of an external ground-truth comparison. The paper does not validate the extra files against a known-correct SBOM, so the headline improvement is endogenous to ORCA's counting convention rather than an independent prediction.

  2. self definitional [Section 3.4(4) and 'False positives' paragraph; Section 4.3, Table 5]
    "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... 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 paper defines obscuration as any modification or deletion of files matching the Table 7 pattern corpus. The prevalence results (e.g., 'OSPKG obscuration manifests in more than 50% of the tested containers') then count exactly those modifications, with the paper itself attributing most cases to routine OS updates. Thus the reported prevalence is entailed by the detection definition, and the admitted false positives mean the numbers are not an independent, ground-truth-validated measure of genuinely obscure content.

full rationale

The paper contains no fitted equations and no load-bearing self-citation chain. The resilience benchmark in Table 4 is self-contained: ORCA is tested on deliberately obscured images generated from a fixed base image, and its package/vulnerability counts are compared directly to other tools; that part is not circular. However, the two headline results are partially self-definitional. First, the median 40% file-coverage improvement over Scout and Syft is measured with a metric whose numerator ORCA defines by its own analysis choices (package metadata plus package-related content), whereas the comparison tools count only package-manager-installed files; without a known-correct SBOM ground truth, the improvement is largely a consequence of counting convention. Second, the RQ3 prevalence results are obtained by defining obscuration as modification/deletion of files matching the authors' Table 7 patterns; the paper's own 'False positives' paragraph admits that benign OS package updates are counted and marked as obscured. Consequently, the finding that more than 50% of containers exhibit OSPKG obscuration is partly an artifact of the operational definition rather than an externally validated discovery. These issues are closer to endogenous benchmarking and validity limitations than to formal derivation circularity, so the score is moderate rather than extreme.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The central evaluation rests on a hand-built pattern corpus, a lossy Containerfile reconstruction assumption, and a coverage definition supplied by the paper. No numeric parameters are fitted, and no new physical or conceptual entities are introduced beyond the categorization of obscuration.

assumptions (4)
  • domain assumption The image configuration command history is faithful enough to reconstruct the Containerfile and detect URL or source-based installs.
    Section 3.4(3) reconstructs the Containerfile from image metadata, while Section 2 states the config is a processed result, not the original. COPY and ADD commands show only shasums, so reconstruction is lossy.
  • domain assumption Modification or deletion of any file matching Table 7 patterns indicates obscuration rather than normal package updates or unrelated edits.
    Section 3.4(4) and Section 6.1 admit that routine OS updates are counted as obscured, which creates false positives in the prevalence and coverage results.
  • ad hoc to paper File coverage, as defined by ORCA's analyzed-file set, is a valid proxy for SBOM completeness.
    Section 4.4 defines coverage using ORCA's own analysis scope, with no external ground truth or independent baseline for what complete coverage should be.
  • domain assumption The 100 most popular images per registry are representative of production container usage.
    Section 4.1 and Table 3 select the most popular images from each registry, but exact popularity criteria and snapshot versions are not specified.

how reviews work

0 comments
Cite this review

Pith. "Pith review of ORCA: Unveiling Obscure Containers In The Wild." pith.science (2026). https://pith.science/paper/6PUUIPIN

@misc{pith2026250909322,
  author       = {Pith},
  title        = {Pith review of: ORCA: Unveiling Obscure Containers In The Wild},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/6PUUIPIN}},
  note         = {Machine review of arXiv:2509.09322}
}
read the original 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.

Figures

Figures reproduced from arXiv: 2509.09322 by the authors.

Figure 1
Figure 1. Our layer-by-layer methodology for Software Composition Analysis in containers. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. (a) File coverage per scanner and (b) average execution time [PITH_FULL_IMAGE:figures/full_fig_p008_2.png] view at source ↗
Figure 3
Figure 3. a) An example of an obscure JavaScript container build. b) [PITH_FULL_IMAGE:figures/full_fig_p011_3.png] view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: a) OS binary (OSPKG) package installed from source. b) The [PITH_FULL_IMAGE:figures/full_fig_p011_4.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

56 extracted references · 4 canonical work pages

  1. [1]

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

    2024

  2. [2]

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

    2024

  3. [3]

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

    2024

  4. [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

    2024

  5. [5]

    Geesaman Brad, Coldwater Ian, McCune Rory, and Cooley Duffie. 2023. Malicious Compliance: Reflections on Trusting Container Scanners. In KubeCon Europe

    2023

  6. [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

    arXiv 2020

  7. [7]

    Lum Brandon and Hepworth Isaac. 2024. Lessons Learned from Generating 100m SBOMs Google’s Approach to SBOM Compliance. InKubeCon Europe 2024. Cloud Native Computing Foundation (CNCF)

    2024

  8. [8]

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

    arXiv 2015

Show all 56 references
  1. [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

    2022

  2. [10]

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

    2024

  3. [11]

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

    2024

  4. [12]

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

    2024

  5. [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)

    2020 arXiv

  6. [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

    2022 doi

  7. [15]

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

    2024

  8. [16]

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

    2020 doi

  9. [18]

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

    2024

  10. [19]

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

    2024

  11. [21]

    Andreas Halbritter and Dominik Merli. 2024. Accuracy Evaluation of SBOM Tools for Web Applications and System-Level Software. InProceedings of the 19th International Conference on A vailability, Reliability and Security (Vienna, Austria) (ARES ’24). Association for Computing M...

    2024

  12. [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

    2021

  13. [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

    2021

  14. [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

    2024

  15. [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

    2024

  16. [26]

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

    2024

  17. [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

    2021 doi arXiv

  18. [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

    2024 doi

  19. [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, Bo...

    2022

  20. [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

    2023

  21. [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

    2003 arXiv

  22. [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.). Spring...

    2020 doi

  23. [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/

    2023

  24. [34]

    Melara and Santiago Torres-Arias

    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

    2023

  25. [35]

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

    2024

  26. [36]

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

    2024

  27. [37]

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

    2024

  28. [38]

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

    2024

  29. [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

    2019

  30. [40]

    Eric O’Donoghue, Brittany Boles, Clemente Izurieta, and Ann Marie Reinhold

  31. [41]

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

    2021

  32. [42]

    In Proceedings of the 2024 Workshop on Software Supply Chain Offensive Research and Ecosystem Defenses

    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

    2024

  33. [43]

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

    2024

  34. [44]

    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

    2015

  35. [45]

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

    2024

  36. [46]

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

    2024

  37. [47]

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

    2024

  38. [48]

    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

    2017

  39. [49]

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

    2017

  40. [50]

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

    2024

  41. [51]

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

    2024

  42. [52]

    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

    2019

  43. [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

    2023

  44. [54]

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

    2024

  45. [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

  46. [56]

    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.). Sprin...

    2021 doi

  47. [58]

    Paul, Keren Chen, and Ali R

    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 Distri...

    2021

  48. [2023]

    Cloud Native Computing Foundation (CNCF)

Pith tools

Reviewed August 4, 2026 · model on record in the stance chip above.