Pith. sign in

REVIEW 3 major objections 4 minor 44 references

An Effective Docker Image Slimming Approach Based on Source Code Data Dependency Analysis

T0 review · 3 major / 4 minor · reviewed 2026-08-10 · deepseek-v4-flash

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

Pith's one-line read Static source-code analysis can slim Docker images by up to 61.4% while keeping them runnable.

desk verdict A genuinely new static approach to Docker image slimming, with a clever symlink-aware pruning structure, but the 'ensures normal operation' claim outruns an evaluation that only covers exec calls and npm test. read the letter →

arxiv 2501.03736 v1 pith:R4SBJS4K submitted 2025-01-07 cs.SE

Jiaxuan Han , Cheng Huang , Jiayong Liu , Tianwei Zhang This is my paper · ORCID
classification cs.SE
keywords DockerimageslimmingstaticcodeanalysisdatadependencycommandlinkedlistattacksurfacereductionNPMpackagescontainersecurity
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

δ-SCALPEL is a Docker image slimming tool that decides which files a container truly needs by reading the project's source code statically, rather than by running the container and watching what happens. The paper argues that this static approach captures system commands the program may invoke only on rare code paths, and it works even when the image has no explicitly declared entry point. The tool applies data-dependency analysis to the project and its NPM packages, extracts the command tokens that flow into exec calls, and prunes the image's file system accordingly. In tests on 20 NPM projects and two official base images, δ-SCALPEL reduced image size by up to 61.4% while the projects still ran, compared with a runtime-tracing baseline that often produced broken images.

What carries the argument

The central mechanism is a pipeline that combines static taint tracking over the project's JavaScript and its NPM dependencies with a file-system model called the command linked list. The taint tracking treats arguments of exec calls as sinks and traces string constants that flow into them, recovering potential command tokens without executing the code; shell scripts and docker-entrypoint.sh are also scanned. The command linked list enumerates every system command in the image, follows symbolic links to their target binaries (for example, /usr/bin/sh to /usr/bin/dash, and /bin to /usr/bin), and records the full chain of paths that must be kept. Matching tokens against this list produces the retain set, to which the dynamic libraries of each retained binary are added, and everything outside /bin, /sbin, and /lib is kept unconditionally.

What would settle it

Take an NPM project that invokes a binary through child_process.execFile or spawn instead of exec, slim its image with δ-SCALPEL, then run the code path that calls that binary; if the binary is missing from the container, the claim that slimmed images remain functional is refuted. A simpler check: examine whether the test suite actually exercises every command-invoking line before declaring a slimmed image successful.

Watch

Extended reading notes

Core claim

The paper proposes and evaluates δ-SCALPEL, claimed to be the first Docker image slimming model based on static code analysis. It extracts environment dependencies by tracing data flow from source nodes to the arguments of exec API calls in the project's JavaScript and NPM dependency code, then prunes the image's file system by matching extracted command tokens against the command linked list. The evaluation reports size reductions up to 61.4% across 80 images built from 20 NPM projects on two base images, with all slimmed images still running correctly, including when the image entry point is not specified.

Load-bearing premise

The pipeline assumes that every system command needed at runtime is reachable through a JavaScript exec call in the project or its NPM dependencies (or through the parsed shell scripts), and that running npm test before and after slimming is a sufficient check that the project still works.

Editorial extensions

If this is right

  • Projects that use system commands only on rarely triggered paths will keep those commands, because extraction does not depend on which code paths happen to execute during a test run.
  • Images without an explicit CMD or ENTRYPOINT can still be slimmed, since the analysis inspects the source code rather than the configured entry point.
  • Attack surface, measured as the number of supported commands, drops by an average of 74.5% for images based on the slim Node.js base image and 70.3% for the standard base image.
  • Because everything outside /bin, /sbin, and /lib is retained, the method is conservative and should not break files needed by the base runtime even if command extraction is incomplete.

Reading between the lines

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

  • The same static extraction could be extended to child_process.spawn, execFile, and fork sinks, which would close the main known gap in the current exec-only analysis.
  • The command linked list and file-system pruning half of the pipeline is language-agnostic, so the approach could be adapted to other ecosystems, such as Python or Ruby, by swapping the front-end dependency extractor.
  • A natural stress test is to compare slimmed images against a runtime oracle that deliberately exercises every exec path, to see whether static extraction misses commands that a coverage-complete dynamic trace would catch.
  • Since /var and /opt are kept intact, the true slimming potential may be larger than reported if those directories are also pruned; the paper itself flags this as future work.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 4 minor

Summary. The paper proposes δ-SCALPEL, a Docker image slimming approach for Node.js projects that uses static data dependency analysis (via CodeQL) to extract environment dependencies from source code, and a command linked list (CLL) data structure to model the image's file system for pruning rootfs contents. The method is evaluated on 20 NPM projects built on two Docker base images (node:current-slim and node:current), showing size reductions up to 61.4% while preserving functional behavior as judged by the projects' npm test suites. The authors claim that δ-SCALPEL overcomes limitations of the dynamic-analysis-based Slim tool, particularly when the image entry point is not specified, and that it is the first Docker image slimming model leveraging static code analysis.

Significance. If the claimed results hold, the paper makes a useful contribution: it demonstrates that static, entry-point-independent dependency extraction can produce functional slimmed images for a set of common NPM packages, and its command linked list is a sensible mechanism for handling symlink-aware command path retention. The availability of a replication package (Zenodo) is a strength, and the threat-to-validity discussion already acknowledges that the method retains large parts of the base environment, which limits the slimming rate. However, the core claim of 'ensuring normal operation' is not established beyond the narrow exec-API sink definition and the npm-test validation, so the current evidence supports only a qualified version of the paper's central contribution.

major comments (3)
  1. [§3.2.2, §3.3.3, §4.1.1] The sink definition in §3.2.2 is restricted to CallExpr nodes named 'exec'. This means commands invoked through child_process.spawn, spawnSync, execFile, fork, or libraries wrapping those functions are not extracted into the Command Token List. Since rootfs pruning in §3.3.3 removes /bin, /sbin, and /lib content based only on CTL matches, a project that uses such APIs at runtime may lose required binaries. The evaluation in §4.1.1 validates slimming solely by running npm test before and after; if the test suite does not exercise the non-exec subprocess paths, the failure is undetected. As a result, the RQ1 answer in §4.2 ('ensures that the project code ... runs normally') is overgeneralized. Please extend the static analysis to cover the full set of child_process APIs, or explicitly restrict the claims and evaluation to projects that invoke system commands only through exec (and shell scripts analyzed in §3.2.3), and add validation cases that exercise spawn/execFile paths.
  2. [§4.1.1] The evaluation uses rolling Docker tags (node:current-slim and node:current) without specifying image digests or snapshots. Since these tags are updated over time, the exact base image content is not fixed, making the reported size reductions and command counts non-reproducible by later readers. The paper should pin the base images to specific digests (or record the build dates and image IDs), and ideally include a repeatability measure such as running each slimming operation multiple times and reporting variance.
  3. [§4.1.1 and RQ1 answer (§4.2)] The criterion for 'normal operation' is the consistency of npm test results before and after slimming. This is an internal, project-specific check and does not necessarily cover the behaviors that would be encountered in real usage of the container (e.g., network-triggered commands like the example in Fig. 2, or commands run by external clients). The paper should either strengthen the validation with an independent smoke test or workload that exercises the commands extracted, or explicitly qualify the RQ1 claim as 'passes the project's own test suite' rather than 'runs normally' in unqualified form.
minor comments (4)
  1. [Throughout] There is a consistent typo in Tables 1 and 2 and in the RQ statements: 'δ-SPELCAL' should be 'δ-SCALPEL'.
  2. [Fig. 4] The framework diagram is dense and difficult to read at the printed scale; a higher-resolution figure or a numbered, step-by-step textual walkthrough of the pipeline would improve comprehensibility.
  3. [Algorithms 1 and 2] The pseudocode for the command linked list is not fully self-contained (e.g., the recursive call in Algorithm 1 assumes linkNode.nextNode is non-null after the if statement, and the termination condition when cycles exist in symlinks is not discussed). Adding a short prose explanation of the recursion and cycle handling would aid implementation.
  4. [§4.4] RQ3 measures 'attack surface' by the number of supported commands. This is a reasonable proxy, but the paper should note that command count is not a direct security guarantee; many other factors (exposed ports, user privileges, dynamically loaded libraries) also matter.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: extraction and validation are independent, and self-citations are not load-bearing.

full rationale

The derivation chain is: source code and NPM dependencies are analyzed with CodeQL to produce a Command Token List (Sections 3.2.1-3.2.3); the fat image's rootfs is modeled as a Command Linked List (Section 3.3.2); tokens are matched against the CLL to build a retain list and prune /bin, /sbin, and /lib (Section 3.3.3). The claimed result, that the slimmed image 'runs normally,' is validated by running npm test before and after slimming and comparing results (Section 4.1.1). This validation is a behavioral test that is independent of the token-extraction process: the npm test outcome is not computed from the CTL or the retain list, so the result is not forced by construction. No fitted parameters are renamed as predictions, and no output quantity is defined in terms of an input quantity. The paper's self-citations ([10]-[12]) concern prior defect-prediction and bug-localization work and are not used to justify the slimming method, so no self-citation is load-bearing. The identified weakness that sinks are defined only as arguments of CallExpr nodes named exec (Section 3.2.2), and the validation only covers behaviors exercised by npm test (Section 4.1.1), is an incompleteness or evaluation-coverage limitation, not circularity: it concerns how broadly 'normal operation' is established, not whether the claimed result reduces to the method's inputs. The paper itself acknowledges that it retains /var and /opt and prunes only /bin, /sbin, and /lib (Section 4.5), which is a scoping limitation rather than a circular step. Therefore the honest finding is no significant circularity.

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

No numeric parameters are fitted to data; the method's behavior is determined by hand-defined source/sink rules and retain-list policies. The core assumptions are coverage of exec calls, symlink resolution, and the npm test success criterion.

assumptions (4)
  • domain assumption All environment dependencies of Node.js project code are reachable through calls to the exec API (CallExpr nodes named exec).
    Section 3.2.2 defines sinks as arguments of CallExpr nodes named exec; spawn, execFile, and fork are not analyzed.
  • domain assumption Files outside /bin, /sbin, and /lib can be safely retained to preserve the runtime environment.
    Section 3.3.3 adds all non-bin/sbin/lib files to the retain list; Section 4.5 acknowledges this limits slimming but guarantees operation.
  • domain assumption Equivalence of npm test results before and after slimming is a valid proxy for normal operation.
    Section 4.1.1 defines success as identical test suite results; this may not cover production-only code paths.
  • domain assumption The command linked list correctly resolves symbolic links for all commands in the base images.
    Section 3.3.2 relies on ldd and symlink traversal; incorrect resolution could drop required binaries.

how reviews work

0 comments
Cite this review

Pith. "Pith review of An Effective Docker Image Slimming Approach Based on Source Code Data Dependency Analysis." pith.science (2026). https://pith.science/paper/R4SBJS4K

@misc{pith2026250103736,
  author       = {Pith},
  title        = {Pith review of: An Effective Docker Image Slimming Approach Based on Source Code Data Dependency Analysis},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/R4SBJS4K}},
  note         = {Machine review of arXiv:2501.03736}
}
read the original abstract

Containerization is the mainstream of current software development, which enables software to be used across platforms without additional configuration of running environment. However, many images created by developers are redundant and contain unnecessary code, packages, and components. This excess not only leads to bloated images that are cumbersome to transmit and store but also increases the attack surface, making them more vulnerable to security threats. Therefore, image slimming has emerged as a significant area of interest. Nevertheless, existing image slimming technologies face challenges, particularly regarding the incomplete extraction of environment dependencies required by project code. In this paper, we present a novel image slimming model named {\delta}-SCALPEL. This model employs static data dependency analysis to extract the environment dependencies of the project code and utilizes a data structure called the command linked list for modeling the image's file system. We select 20 NPM projects and two official Docker Hub images to construct a dataset for evaluating {\delta}-SCALPEL. The evaluation results show that {\delta}-SCALPEL can reduce image sizes by up to 61.4% while ensuring the normal operation of these projects.

Figures

Figures reproduced from arXiv: 2501.03736 by the authors.

Figure 1
Figure 1. An example of security risk caused by image resource redundancy. [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. An example that the code needs to depend on the system environment. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. An example of project code operation failure caused by image slimming using Slim. [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (5 more)
Figure 4
Figure 4. Figure 4: The framework of 𝛿-SCALPEL. • Step 1: Environment Dependency Extraction. Create an image for data dependency analysis of the project code and its NPM dependencies, extracting environment dependencies (i.e., system commands executed during exec API calls) from the sourc…
Figure 5
Figure 5. Figure 5: A command linked list example for the sh command. 3.4 Slim Image Building Based on the static inspection result of the fat image from step 2, we first configure the metadata for the slim image, including the image name, exposed ports, image architecture, etc. Then we u…
Figure 6
Figure 6. Figure 6: Efficiency of 𝛿-SCALPEL when specifying image’s entry point. The base image is node:current-slim. CA pre indicates code analyzer preparation, CA exec indicates code analyzer execution, IA pre & exec indicates image analyzer preparation & execution, and SI building indi…
Figure 7
Figure 7. Figure 7: Efficiency of 𝛿-SCALPEL when specifying image’s entry point. The base image is node:current. CA pre indicates code analyzer preparation, CA exec indicates code analyzer execution, IA pre & exec indicates image analyzer preparation & execution, and SI building indicates…
Figure 8
Figure 8. Figure 8: Comparison of the average number of commands supported by the images based on [PITH_FULL_IMAGE:figures/full_fig_p014_8.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

44 extracted references · 42 canonical work pages

  1. [1]

    Maqsood Ahmad, Valerio Costamagna, Bruno Crispo, Francesco Bergadano, and Yury Zhauniarovich. 2020. StaDART: addressing the problem of dynamic code updates in the security analysis of android applications. Journal of Systems and Software 159 (2020), 110386

    work page 2020

  2. [2]

    Liuqing Chen, Yunnong Chen, Shuhong Xiao, Yaxuan Song, Lingyun Sun, Yankun Zhen, Tingting Zhou, and Yanfang Chang. 2024. EGFE: End-to-end Grouping of Fragmented Elements in UI Designs with Multimodal Learning. In Proceedings of the 46th IEEE/ACM International Conference on Software Engineering . 1–12

    work page 2024

  3. [3]

    Theo Combe, Antony Martin, and Roberto Di Pietro. 2016. To docker or not to docker: A security perspective. IEEE Cloud Computing 3, 5 (2016), 54–62. , Vol. 1, No. 1, Article . Publication date: January 2025. 16 Han et al

    work page 2016

  4. [4]

    Abdallah Dawoud and Sven Bugiel. 2021. Bringing balance to the force: Dynamic analysis of the android application framework. Bringing balance to the force: dynamic analysis of the android application framework (2021)

    work page 2021

  5. [5]

    Yangruibo Ding, Saikat Chakraborty, Luca Buratti, Saurabh Pujar, Alessandro Morari, Gail Kaiser, and Baishakhi Ray. 2023. CONCORD: clone-aware contrastive learning for source code. In Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis . 26–38

    work page 2023

  6. [6]

    Docker, Inc. 2024. Dockerfile Overview. https://docs.docker.com/build/concepts/dockerfile/. Accessed: 2024-09-30

    work page 2024

  7. [7]

    Docker, Inc. 2024. Set up Automated Builds. https://docs.docker.com/docker-hub/builds/. Accessed: 2024-09-30

    work page 2024

  8. [8]

    Kalvin Eng and Abram Hindle. 2021. Revisiting dockerfiles in open source software over time. In 2021 IEEE/ACM 18th International Conference on Mining Software Repositories (MSR) . IEEE, 449–459

    work page 2021

Show all 44 references
  1. [9]

    Seyedhamed Ghavamnia, Tapti Palit, Azzedine Benameur, and Michalis Polychronakis. 2020. Confine: Automated system call policy generation for container attack surface reduction. In 23rd International Symposium on Research in Attacks, Intrusions and Defenses (RAID 2020) . 443–458

    2020

  2. [10]

    Jiaxuan Han, Cheng Huang, and Jiayong Liu. 2024. bjCnet: A contrastive learning-based framework for software defect prediction. Computers & Security 145 (2024), 104024

    2024

  3. [11]

    Jiaxuan Han, Cheng Huang, and Jiayong Liu. 2024. bjEnet: a fast and accurate software bug localization method in natural language semantic space. Software Quality Journal (2024), 1–24

    2024

  4. [12]

    Jiaxuan Han, Cheng Huang, Siqi Sun, Zhonglin Liu, and Jiayong Liu. 2023. bjXnet: an improved bug localization model based on code property graph and attention mechanism. Automated Software Engineering 30, 1 (2023), 12

    2023

  5. [13]

    Jordan Henkel, Christian Bird, Shuvendu K Lahiri, and Thomas Reps. 2020. A dataset of dockerfiles. In Proceedings of the 17th International Conference on Mining Software Repositories . 528–532

    2020

  6. [14]

    Cheng Huang, Nannan Wang, Ziyan Wang, Siqi Sun, Lingzi Li, Junren Chen, Qianchong Zhao, Jiaxuan Han, Zhen Yang, and Lei Shi. 2024. DONAPI: Malicious NPM Packages Detector using Behavior Sequence Knowledge Mapping. arXiv preprint arXiv:2403.08334 (2024)

    2024 arXiv

  7. [15]

    Omar Javed and Salman Toor. 2021. Understanding the quality of container security vulnerability detection tools. arXiv preprint arXiv:2101.03844 (2021)

    2021 arXiv

  8. [16]

    Hyungjoon Koo, Seyedhamed Ghavamnia, and Michalis Polychronakis. 2019. Configuration-driven software debloating. In Proceedings of the 12th European Workshop on Systems Security . 1–6

    2019

  9. [17]

    Changyuan Lin, Sarah Nadi, and Hamzeh Khazaei. 2020. A large-scale data set and an empirical study of docker images hosted on docker hub. In 2020 IEEE International Conference on Software Maintenance and Evolution (ICSME) . IEEE, 371–381

    2020

  10. [18]

    Xin Lin, Lingguang Lei, Yuewu Wang, Jiwu Jing, Kun Sun, and Quan Zhou. 2018. A measurement study on linux container security: Attacks and countermeasures. In Proceedings of the 34th annual computer security applications conference. 418–429

    2018

  11. [19]

    Jiayong Liu, Jiaxuan Han, and Cheng Huang. 2022. Vulnerability Detection In Source Code Using Statice Analysis. Journal of Cyber Security 7, 4 (2022), 100–113

    2022

  12. [20]

    Peiyu Liu, Shouling Ji, Lirong Fu, Kangjie Lu, Xuhong Zhang, Wei-Han Lee, Tao Lu, Wenzhi Chen, and Raheem Beyah

  13. [21]

    Antony Martin, Simone Raponi, Théo Combe, and Roberto Di Pietro. 2018. Docker ecosystem–vulnerability analysis. Computer Communications 122 (2018), 30–43

    2018

  14. [22]

    Dirk Merkel et al. 2014. Docker: lightweight linux containers for consistent development and deployment. Linux j 239, 2 (2014), 2

    2014

  15. [23]

    Shachee Mishra and Michalis Polychronakis. 2018. Shredder: Breaking exploits through API specialization. In Proceed- ings of the 34th Annual Computer Security Applications Conference . 1–16

    2018

  16. [24]

    Roberto Morabito, Jimmy Kjällman, and Miika Komu. 2015. Hypervisors vs. lightweight virtualization: a performance comparison. In 2015 IEEE International Conference on cloud engineering . IEEE, 386–393

    2015

  17. [25]

    Adrian Mouat. 2022. Minimal Container Images: Towards a More Secure Future. https://www.chainguard.dev/uncha ined/minimal-container-images-towards-a-more-secure-future Accessed: 2024-09-09

    2022

  18. [26]

    Nitel Muhtaroglu, Birkan Kolcu, and İsmail Arı. 2017. Testing performance of application containers in the cloud with hpc loads. In Proceedings Of The Fifth International Conference On Parallel, Distributed, Grid And Cloud Computing For Engineering. Civil-Comp

    2017

  19. [27]

    Collin Mulliner and Matthias Neugschwandtner. 2015. Breaking payloads with runtime code stripping and image freezing. Black Hat USA (2015)

    2015

  20. [28]

    National Institute of Standards and Technology. 2017. Application Container Security Guide. Technical Report NIST SP 800-190. National Institute of Standards and Technology. Accessed: 2024-09-30. , Vol. 1, No. 1, Article . Publication date: January 2025. An Effective Docker Im...

    2017

  21. [29]

    Node.js. 2023. Node.js Docker Official Images. https://github.com/nodejs/docker-node/tree/58c3b39e5948f82c59439585 7193cd97d01c690e. Accessed: 2024-09-30

    2023

  22. [30]

    Ruben Opdebeeck, Jonas Lesy, Ahmed Zerouali, and Coen De Roover. 2023. The Docker Hub Image Inheritance Network: Construction and Empirical Insights. In 2023 IEEE 23rd International Working Conference on Source Code Analysis and Manipulation (SCAM). IEEE, 198–208

    2023

  23. [31]

    Anh Quach, Aravind Prakash, and Lok Yan. 2018. Debloating software through{Piece-Wise} compilation and loading. In 27th USENIX security symposium (USENIX Security 18) . 869–886

    2018

  24. [32]

    Banyan Security. 2024. Over 30% of Official Images in Docker Hub Contain High-Priority Security Vulnerabili- ties. https://www.banyansecurity.io/blog/over-30-of-official-images-in-docker-hub-contain-high-priority-security- vulnerabilities/. Accessed: 2024-09-30

    2024

  25. [33]

    slimtoolkit. 2022. Optimize Your Experience with Containers. Make Your Containers Better, Smaller, More Secure and Do Less to Get There (free and open source!). https://github.com/slimtoolkit/slim Accessed: 2024-09-09

    2022

  26. [34]

    Stephen Soltesz, Herbert Pötzl, Marc E Fiuczynski, Andy Bavier, and Larry Peterson. 2007. Container-based oper- ating system virtualization: a scalable, high-performance alternative to hypervisors. In Proceedings of the 2Nd ACM SIGOPS/EuroSys european conference on computer sy...

    2007

  27. [35]

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

    2017

  28. [36]

    Benjamin Steenhoek, Hongyang Gao, and Wei Le. 2024. Dataflow analysis-inspired deep learning for efficient vulnerability detection. In Proceedings of the 46th IEEE/ACM International Conference on Software Engineering . 1–13

    2024

  29. [37]

    Sari Sultan, Imtiaz Ahmad, and Tassos Dimitriou. 2019. Container security: Issues, challenges, and the road ahead. IEEE access 7 (2019), 52976–52996

    2019

  30. [38]

    Byungchul Tak, Hyekyung Kim, Sahil Suneja, Canturk Isci, and Prabhakar Kudva. 2018. Security analysis of container images using cloud analytics framework. In Web Services–ICWS 2018: 25th International Conference, Held as Part of the Services Conference Federation, SCF 2018, Se...

    2018

  31. [39]

    Threatpost. 2018. Malicious Docker Containers Earn Crypto-Miners $90,000. https://threatpost.com/malicious-docker- containers-earn-crypto-miners-90000/132816/. Accessed: 2024-09-30

    2018

  32. [40]

    Chao Wang, Ronny Ko, Yue Zhang, Yuqing Yang, and Zhiqiang Lin. 2023. Taintmini: Detecting flow of sensitive data in mini-programs with static taint analysis. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). IEEE, 932–944

    2023

  33. [41]

    Miguel G Xavier, Marcelo V Neves, Fabio D Rossi, Tiago C Ferreto, Timoteo Lange, and Cesar AF De Rose. 2013. Performance evaluation of container-based virtualization for high performance computing environments. In 2013 21st Euromicro International Conference on Parallel, Distr...

    2013

  34. [42]

    Nannan Zhao, Vasily Tarasov, Hadeel Albahar, Ali Anwar, Lukas Rupprecht, Dimitrios Skourtis, Amit S Warke, Mohamed Mohamed, and Ali R Butt. 2019. Large-scale analysis of the docker hub dataset. In 2019 IEEE International Conference on Cluster Computing (CLUSTER) . IEEE, 1–10

    2019

  35. [43]

    Zhuping Zou, Yulai Xie, Kai Huang, Gongming Xu, Dan Feng, and Darrell Long. 2019. A docker container anomaly monitoring system based on optimized isolation forest. IEEE Transactions on Cloud Computing 10, 1 (2019), 134–145. , Vol. 1, No. 1, Article . Publication date: January 2025

    2019

  36. [2020]

    In Computer Security–ESORICS 2020: 25th European Symposium on Research in Computer Security, ESORICS 2020, Guildford, UK, September 14–18, 2020, Proceedings, Part I 25

    Understanding the security risks of docker hub. In Computer Security–ESORICS 2020: 25th European Symposium on Research in Computer Security, ESORICS 2020, Guildford, UK, September 14–18, 2020, Proceedings, Part I 25 . Springer, 257–276

    2020

Pith tools

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