{"id":"474a760d-825f-4486-80b2-1e1428361c5b","arxiv_id":"2501.03736","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"Static source-code analysis of Node.js projects can identify the system commands needed at runtime, allowing Docker images to be slimmed by up to 61.4% without breaking the tested apps.","lead":"Researchers built a tool that shrinks Docker container images by statically analyzing the application's source code to find which system commands are actually used. On 20 popular Node.js projects, it cut image size by up to 61.4% while the projects' own tests still passed.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Static analysis only treats CallExpr nodes named 'exec' as sinks (Sec. 3.2.2), so commands invoked via child_process.spawn/execFile/fork are not extracted; npm test validation (Sec. 4.1.1) does not exercise these paths, so the 'normal operation' claim is not established.","rationale":"The reader's weakest assumption identifies exactly the gap I find most load-bearing: the pipeline's sink definition is restricted to CallExpr nodes named 'exec', and the functional validation relies solely on npm test. This is not a peripheral concern; it directly undermines the central claim that δ-SCALPEL 'ensures normal operation'. The method may work for the 20 selected projects because their npm test suites likely avoid these APIs, but the paper generalizes the result. The paper's own threats-to-validity section acknowledges the slimming is conservative (retaining /var and /opt) but does not acknowledge the exec-only sink limitation, so the manuscript is incomplete rather than internally inconsistent. A targeted reproduction with a spawn/execFile-based project would settle the question. Since the reader's conditional verdict already requires stronger validation and broader analysis, my concern reinforces that conditional status without moving it to reject: the flaw is concrete but fixable by expanding the sink set and validating with real application entry points rather than npm test alone.","tokens_in":37101,"tokens_out":5052,"duration_ms":48386,"concrete_test":"Construct a minimal Node.js project whose main entry point calls child_process.execFile('ls', ['-l'], cb) (or spawn) after a short delay; build a Docker image from node:current-slim with CMD [\"node\", \"app.js\"], run δ-SCALPEL on it, then docker run the slimmed image and observe whether the ls command executes. If the command is missing (ENOENT) or the app errors, the central 'normal operation' claim fails. Additionally, run the same check with npm test as the only validation to confirm the test-based verdict would miss the missing binary.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 3.2.2 defines sinks as 'the arguments of the CallExpr nodes named exec', and package filtering in Sec. 3.2.1 selects only packages with 'exec API calls'. Consequently, any runtime dependency triggered by child_process.spawn(), spawnSync(), execFile(), fork(), or libraries that wrap these functions is invisible to δ-SCALPEL. Section 3.2.3 builds the Command Token List from these exec paths plus shell scripts in the project folder and docker-entrypoint.sh, but not from arbitrary subprocess invocations. Section 3.3.3 then prunes /bin, /sbin, and /lib by matching only these tokens. For a project that calls require('child_process').spawn('ls', ...) at runtime, 'ls' is absent from the CTL, so /bin/ls is removed and the slimmed container fails when that code runs. The evaluation in Sec. 4.1.1 validates slimming by running npm test before and after and comparing results; if the test suite does not exercise the spawn/execFile path, the failure is undetected. The answer to RQ1 ('ensures that the project code ... runs normally') is therefore only supported for the 20 selected projects, and only for behaviors covered by their npm test suites.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":37389,"tokens_out":3818,"duration_ms":38680,"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":[{"comment":"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.","section":"§3.2.2, §3.3.3, §4.1.1"},{"comment":"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.","section":"§4.1.1"},{"comment":"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.","section":"§4.1.1 and RQ1 answer (§4.2)"}],"minor_comments":[{"comment":"There is a consistent typo in Tables 1 and 2 and in the RQ statements: 'δ-SPELCAL' should be 'δ-SCALPEL'.","section":"Throughout"},{"comment":"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.","section":"Fig. 4"},{"comment":"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.","section":"Algorithms 1 and 2"},{"comment":"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.","section":"§4.4"}],"recommendation":"major_revision","confidential_remarks":"The paper has merit and the experimental direction is promising, but the central claim about 'normal operation' needs to be narrowed or the method needs to be extended to cover more process-spawning APIs. The missing exec sink handling is a correctness risk that should be addressed explicitly in the revision. I also recommend the editor ask the authors to verify the novelty claim, since the phrase 'first Docker image slimming model that leverages static code analysis' is strong and the related-work section does not cite any prior static analysis–based image slimers besides the dynamic Slim tool."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Your Pith Report is close to mine; the stress-test note lands. The paper is a real engineering contribution: static taint analysis over Node.js source to find exec call sites, then a command linked list that resolves symlink chains when pruning /bin, /sbin, /lib. The linked list is a neat way to handle the sh->dash and /bin->/usr/bin cases and seems genuinely new. The evaluation is detailed: 20 projects, two base images, with size and attack-surface numbers, and the comparison with Slim correctly shows that Slim breaks almost everything when entry points are absent. Credit also for shipping a replication package.\n\nThe soft spots are the ones flagged, and they matter. Sinks are only CallExpr nodes named exec. spawn, execFile, fork, and wrappers are invisible. So the command token list is incomplete for many real Node projects. The validation is npm test before/after, which only proves that the tested paths still work. The paper's phrase 'ensures normal operation' is too strong; the honest claim is 'passes the project's own test suite for these 20 projects.' Rolling base image tags (node:current, node:current-slim) also mean the numbers are not pinned to a specific image digest; error bars and repeats are absent. The 'first static image slimming model' claim is hard to take literally; static analysis has been used for related debloating and package filtering work, and the novelty is better stated as a specific combination.\n\nNone of this is disqualifying. The core mechanism is plausible, the experiments are honestly reported (they even note the slimming rate is limited because they retain /var and /opt), and the attack-surface reduction is meaningful. The paper just needs scoping: limit claims to exec-based Node.js projects, add spawn/execFile handling or explicitly say it is out of scope, pin artifacts, and strengthen functional validation beyond npm test.\n\nWho benefits: container security researchers, DevOps tooling folks, and anyone building static debloating tools. It deserves a serious referee; I would send it to review and ask for major revision, not desk reject.","headline":"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.","tokens_in":37878,"tokens_out":2294,"would_cite":false,"duration_ms":22139,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Static source-code analysis can slim Docker images by up to 61.4% while keeping them runnable.","keywords":["Docker image slimming","static code analysis","data dependency analysis","command linked list","attack surface reduction","NPM packages","container security"],"falsifier":"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.","tokens_in":36929,"feed_emoji":"🐳","tokens_out":5877,"duration_ms":50321,"temperature":0.7,"pith_summary":"δ-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.","feed_headline":"Source-code analysis slims Docker images up to 61.4%","feed_subtitle":"The method finds needed system commands statically, so it works even without an entry point.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"The Slim tool is the baseline that motivates the work; its runtime-tracing approach is what δ-SCALPEL is compared against and shown to outperform.","marker":"[33]"},{"why":"The NIST Application Container Security Guide supplies the standard rationale for reducing container attack surface, which the paper uses to justify slimming as a security goal.","marker":"[28]"},{"why":"Docker's Dockerfile documentation defines CMD and ENTRYPOINT semantics, which the evaluation manipulates to test images with and without explicit entry points.","marker":"[6]"},{"why":"Docker is the containerization technology whose images the slimming method manipulates; the paper builds on its image model.","marker":"[22]"},{"why":"The Node.js Docker official images are the base images used in the experiments, defining the two tested environments.","marker":"[29]"}],"fun_headline_variants":["Static analysis slims Docker images 61%","Trace dependencies to shrink Docker images 61%","First static image slimming cuts up to 61.4%","Code dependency analysis trims Docker bloat 61%","Cut Docker size 61% via source code analysis"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Static analysis slims Docker images 61%","Trace dependencies to shrink Docker images 61%","First static image slimming cuts up to 61.4%","Code dependency analysis trims Docker bloat 61%","Cut Docker size 61% via source code analysis"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000163,"raw_usage":{"total_tokens":1199,"prompt_tokens":858,"completion_tokens":341,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":474,"completion_tokens_details":{"reasoning_tokens":263}},"tokens_in":474,"tokens_out":341,"duration_ms":3950,"temperature":1.0,"reasoning_tokens":263,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T21:47:53.730765+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The Slim tool is the baseline that motivates the work; its runtime-tracing approach is what δ-SCALPEL is compared against and shown to outperform."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The NIST Application Container Security Guide supplies the standard rationale for reducing container attack surface, which the paper uses to justify slimming as a security goal."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Docker's Dockerfile documentation defines CMD and ENTRYPOINT semantics, which the evaluation manipulates to test images with and without explicit entry points."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Docker is the containerization technology whose images the slimming method manipulates; the paper builds on its image model."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The Node.js Docker official images are the base images used in the experiments, defining the two tested environments."}],"review_version":1}