Pith. sign in

REVIEW 3 major objections 5 minor 1 cited by

GoLeash: Mitigating Golang Software Supply Chain Attacks with Runtime Policy Enforcement

T0 review · 3 major / 5 minor · reviewed 2026-08-15 · deepseek-v4-flash

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

Pith's one-line read GoLeash attributes every system call to the Go package that made it, then enforces a per-package capability policy that caught 98% of injected attacks.

desk verdict GoLeash is a solid contribution with a real gap: its stack-trace attribution is untested against an attacker that can forge the stack, which the threat model allows. read the letter →

arxiv 2505.11016 v1 pith:CVPGHZ3Y submitted 2025-05-16 cs.CR cs.SE

Carmine Cesarano , Martin Monperrus , Roberto Natella This is my paper · ORCID
classification cs.CRcs.SE
keywords softwaresupplychainsecurityruntimepolicyenforcementGolangeBPFleastprivilegesystemcallattributiondependencysandboxingobfuscationresistance
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

The paper introduces GoLeash, a runtime enforcement system that applies least privilege to individual Go packages rather than to whole processes or containers. Its central claim is that tracing system calls back to the package that caused them lets it detect malicious dependencies, such as a compromised library that suddenly opens a network connection or spawns a shell. In an evaluation with 3,265 simulated attacks on five real-world Go projects, GoLeash achieved a 98% detection rate, compared with 32% for process-level enforcement. The authors further argue that the approach survives obfuscation and adds about 9.34% average runtime overhead, making it practical for critical Go infrastructure like Kubernetes.

What carries the argument

The load-bearing mechanism is eBPF-based syscall tracing combined with stack-trace-to-package attribution. GoLeash attaches kernel tracepoints to syscall entries, captures a hash of the user-space stack, resolves return addresses to Go package names via ELF symbols, and walks the trace from the most recent frame to the first frame that belongs to an application or third-party package, skipping the Go runtime and standard library as trusted infrastructure. A manually curated taxonomy maps syscalls to capabilities such as CAP_CONNECT_REMOTE, CAP_WRITE_FILE, and CAP_EXEC, and the analysis phase records, for each package, the set of capabilities and the hashed call paths through which they were legitimately invoked. Enforcement then rejects any syscall whose package, capability, and call path do not appear in the allowlist, which is what lets it catch a restricted dependency that tries to borrow a privileged operation from a more permissive package.

What would settle it

Inject a malicious Go package that invokes a syscall through a self-modifying or assembly-level stack frame such that the first non-runtime, non-standard-library frame resolves to a trusted package, then check whether GoLeash flags it; if such a payload passes, the attribution premise is false.

Watch

Extended reading notes

Core claim

GoLeash's central discovery is that the first non-runtime, non-standard-library frame in a Go stack trace can reliably attribute a system call to the specific third-party package that initiated it, turning a flat Go binary into a per-package observable. On that basis, GoLeash learns an allowlist during an analysis run, mapping each package to the capabilities it legitimately uses along with the full call paths observed, and then enforces it at runtime with eBPF syscall probes. In an evaluation with 3,265 injected malicious variants across Kubernetes, etcd, CoreDNS, frp, and go-ethereum, the per-package enforcement detected 98% of attacks, while a process-level policy detected only 32%; detection stayed between 92% and 100% under plugin, reflection, external-binary, and CGO obfuscation. The paper positions this as the missing precision between coarse sandboxing and static analysis: it sees behavior sandboxes miss, and it survives obfuscation that defeats static scanners.

Load-bearing premise

The entire scheme rests on the assumption that a compromised package cannot alter or forge the Go runtime's stack traces, so the first non-runtime, non-standard-library frame in a trace is genuinely the package that caused the system call.

Editorial extensions

If this is right

  • Process- and container-level syscall policies are insufficient for Go supply chain defense: aggregating capabilities across the whole application lets malicious packages reuse legitimate capabilities, which is why the baseline detected only 32%.
  • Obfuscation techniques such as plugins, reflection, external binaries, and CGO do not evade GoLeash, because every malicious operation still reaches the kernel and the stack trace still reveals its package of origin.
  • Confused deputy attacks are mitigated: even if a compromised package is allowed a capability, its full call path must match an approved sequence, so it cannot trigger that capability through a more permissive package.
  • GoLeash can be deployed without source code, build, or runtime changes, and supports multi-process and multi-binary Go applications such as Kubernetes' multiple control-plane binaries.
  • Static capability analysis and GoLeash are complementary: dynamic tracing catches what static analysis misses under obfuscation, while static analysis remains useful when no representative workload is available.

Reading between the lines

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

  • If the attribution premise holds broadly, the same stack-based technique could be adapted to other managed languages whose binaries retain package symbols, such as Rust or Java, where the paper's portability argument suggests but does not demonstrate the design.
  • A testable extension is to enrich the allowlist with syscall arguments such as destination IPs, file paths, and socket types, which would address the capability-reuse limitation the paper acknowledges and likely push detection beyond 98%.
  • The 98% figure was measured on workloads chosen to exercise intended behavior; in the field, legitimate updates that introduce new call paths may raise false positives, so a practical recipe for policy drift detection would be a natural next step.
  • GoLeash's threat model assumes the Go runtime itself is trustworthy; if a future attack compromises the runtime or exploits a stack-trace forgery bug, per-package attribution would be the first thing to fail, so defense-in-depth should keep independent process-level limits as a backstop.
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 / 5 minor

Summary. GoLeash proposes a runtime policy-enforcement system for Go applications that attributes system calls to the originating Go package by walking the user-space stack captured at syscall entry, mapping addresses to package symbols, and taking the first non-runtime, non-standard-library frame. In analysis mode it builds per-package capability allowlists (including observed call paths); in enforcement mode it denies any syscall whose (package, capability, call path) triple is outside the policy. The evaluation injects five classes of malicious behavior into exercised packages of Kubernetes, etcd, CoreDNS, frp, and go-ethereum, producing 3,265 variants for RQ1 and 5,224 obfuscation variants for RQ2. The paper reports an average detection rate of 98% for GoLeash versus 32% for a process-level baseline, robustness to four Go-specific obfuscation techniques, an execution-time overhead averaging 9.34%, and gains over the static analyzer Capslock.

Significance. If the security guarantees hold, GoLeash is a useful contribution to Go supply-chain defense: it shows that package-level rather than process-level syscall policy can be enforced without source changes, and it provides an automated policy-generation workflow. The paper ships an open-source artifact and a large synthetic injection dataset, and the comparison against a process-level baseline is a sensible first step. The main value, however, is conditional on the correctness of the syscall-to-package attribution mechanism. The threat model explicitly assumes that a compromised dependency cannot manipulate the stack traces used for attribution, but the same threat model grants the attacker inline assembly and CGO capabilities that can affect the user stack and syscall context. Since no experiment exercises that adversarial capability, the measured 98% detection rate should be presented as applying to attackers that do not spoof or forge the attribution frames.

major comments (3)
  1. [Section 3 and Section 4.4] The central security claim rests on the assumption that a compromised package cannot manipulate the syscall context or the integrity of the runtime's stack traces. This assumption is in tension with the same threat model, which explicitly grants the attacker arbitrary code execution, inline assembly, and CGO. A malicious package that can execute inline assembly or C code controls the register state and the user stack memory at the instant a syscall is issued; the eBPF stack walker reads that memory and does not verify that the return addresses form a genuine call chain. An attacker could therefore arrange for the captured stack to resolve to a benign package's frames, causing GoLeash to attribute the syscall to that package and, if the capability and call path are in the policy, to allow it. RQ2 (Tables 4a and 4b) tests plugin, reflection, external-binary, and CGO indirections, but none of these variants forges the user stack. I recommend adding an adversarial experiment that deliberately corrupts or rewrites the user stack frames (or, alternatively, hardening the attribution so that it validates the stack contents), and scoping the abstract and RQ1/RQ2 claims to attackers that do not target the attribution mechanism itself.
  2. [Section 5.1, Table 3] The aggregate row reports 32% and 98% as simple averages over the 25 project-malware cells, not over the 3,265 injected variants. Weighting by the inj. column gives approximately 35.6% for the baseline and 99.0% for GoLeash. The qualitative conclusion is unchanged, but the headline numbers as printed are not the correct aggregate detection rates for the dataset. I recommend reporting injection-weighted rates in the aggregate row, or prominently labeling the value as an unweighted average over cells. The same unweighted averaging appears in Table 4, where projects with very different variant counts (441 per malware for Kubernetes versus 20 for CoreDNS) contribute equally to the per-row averages.
  3. [Section 5.1] The paper claims that 'GoLeash enforcement incurs zero false positives in our experiments,' but no experimental protocol or result table for false positives is described. A false-positive measurement would require running the benign applications in enforcement mode against the automatically generated policies and counting blocked legitimate syscalls; this is not reported. The claim matters because enforcement mode can disrupt production behavior when the training workload does not cover all legitimate paths, a limitation acknowledged in Section 7. I recommend adding an explicit false-positive experiment and reporting the number of benign syscalls traced, blocked, and allowed.
minor comments (5)
  1. [Section 5.1] The sentence 'Malware IDs used in the evaluation are defined in Table ??' should refer to Table 2; the placeholder appears unresolved in the submitted text.
  2. [Section 5.2] Table 4 reports per-project detection rates but does not state how the 5,224 injection total is distributed across projects; since each project has a different number of exercised packages (e.g., 441 for Kubernetes, 20 for CoreDNS), the reader cannot infer the underlying counts from the percentages alone.
  3. [Section 5.3] The syscall-latency measurement would benefit from a short statement of how latency was measured (e.g., which syscalls were sampled, whether the ring-buffer consumer was included) and whether the reported values are means over 1,000 traced syscalls per project as stated in the methodology.
  4. [Section 6] There are several typographical errors that should be corrected: 'preventing preventing' (Section 6.3), 'operats' (Section 6.1), 'in constrast' (Section 6.2), 'lage codebases' (Section 6.1), and 'the malicious code in obfuscated inside a dependency' (Section 5.2).
  5. [Appendix A] The policy excerpt at the end of Listing 1 uses the key 'syscalls_paths' while the body of the listing and the rest of the paper refer to 'call_paths'; the excerpt also appears to contain spacing artifacts (e.g., 'e xe cu te d_ bin ar ie s') that should be cleaned up.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity: GoLeash's detection is a transparent allowlist membership test, and its 98% result measures attribution quality rather than restating the method.

full rationale

The central mechanism is not circular. In Section 4.6, the policy is built as an allowlist A={(P_i,{(C_ij,T_ij)})} from benign executions, and enforcement in Section 4.7 allows a syscall only if the (package, capability) pair and call path are present in that allowlist. A detection in RQ1 is explicitly defined as the malicious package exercising 'a malicious capability absent from the policy,' which is the direct complement of allowlist membership. This is the intended semantics of an allowlist enforcement system, not a hidden reduction: the empirical contribution lies in the stack-trace-to-package attribution (Section 4.4) and in measuring how often realistic injections fall outside per-package versus process-aggregated policies. The 32%-versus-98% comparison is meaningful because the same membership test at coarser granularity fails. The paper also openly acknowledges in Section 7 that malware reusing already-allowed capabilities can evade detection, confirming that the definitional nature of the check is not disguised. The stated threat-model assumption that attackers cannot forge stack traces or manipulate syscall context is a security assumption and potential correctness risk, but it is not circularity: it is not fitted from data and no result is derived from it by restating the input. The only self-citation is the use of the authors' prior GoSurf work [11] as the source of the four obfuscation strategies in RQ2; this is a test-case taxonomy, not a load-bearing proof or uniqueness argument, and the detection results are measured empirically. Overall, the paper is self-contained against external benchmarks, and no fitted parameter is renamed as a prediction.

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

No fitted parameters or invented entities. The system is an allowlist of observed capabilities per package. The main added assumptions are the trustworthiness of Go stack traces and representativeness of the training workload, both stated in the paper.

assumptions (5)
  • domain assumption The Go runtime stack traces cannot be forged or manipulated by compromised dependencies.
    Section 3: threat model excludes actors who manipulate the context of system calls or compromise runtime stack trace integrity; all syscall-package attribution in Section 4.4 depends on this.
  • domain assumption Analysis workload is representative of production behavior.
    Section 7: false positives occur if rarely executed paths are missed; the method assumes integration tests or representative workloads exercise intended behavior (Sections 4.6 and 7).
  • domain assumption Go binaries are typically unstripped so symbol tables map addresses to package paths.
    Section 7 'Stripped Binaries' acknowledges this reliance; Section 4.4 resolves symbols from the ELF symbol table.
  • domain assumption The Go runtime and standard library are trusted and not responsible for syscalls.
    Section 4.4: GoLeash skips standard library and runtime frames and attributes syscalls to the 'first application-defined or third-party package function'; Section 3 assumes trusted Go runtime.
  • standard math Linux tracepoints and eBPF capture complete syscall events with stack IDs.
    Section 4.3 relies on kernel tracepoints and eBPF; this is a standard Linux facility.

how reviews work

0 comments
Cite this review

Pith. "Pith review of GoLeash: Mitigating Golang Software Supply Chain Attacks with Runtime Policy Enforcement." pith.science (2026). https://pith.science/paper/CVPGHZ3Y

@misc{pith2026250511016,
  author       = {Pith},
  title        = {Pith review of: GoLeash: Mitigating Golang Software Supply Chain Attacks with Runtime Policy Enforcement},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/CVPGHZ3Y}},
  note         = {Machine review of arXiv:2505.11016}
}
read the original abstract

Modern software supply chain attacks consist of introducing new, malicious capabilities into trusted third-party software components, in order to propagate to a victim through a package dependency chain. These attacks are especially concerning for the Go language ecosystem, which is extensively used in critical cloud infrastructures. We present GoLeash, a novel system that applies the principle of least privilege at the package-level granularity, by enforcing distinct security policies for each package in the supply chain. This finer granularity enables GoLeash to detect malicious packages more precisely than traditional sandboxing that handles security policies at process- or container-level. Moreover, GoLeash remains effective under obfuscation, can overcome the limitations of static analysis, and incurs acceptable runtime overhead.

Figures

Figures reproduced from arXiv: 2505.11016 by the authors.

Figure 1
Figure 1. GoLeash Architecture 4.2 Architecture [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. On the left: example stack trace with highlighted [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Classport: Designing Runtime Dependency Introspection for Java

    cs.SE 2025-10 conditional novelty 7.0 of 10

    Classport embeds Maven dependency coordinates into Java class files as runtime annotations and uses a Java agent to report the dependencies actually executed during a run.

Reference graph

Works this paper leans on

79 extracted references · 76 canonical work pages · cited by 1 Pith paper

  1. [1]

    Marco Abbadini, Dario Facchinetti, Gianluca Oldani, Matthew Rossi, and Stefano Paraboschi. 2023. Cage4Deno: A fine-grained sandbox for Deno subprocesses. In ACM ASIA Conference on Computer and Communications Security (ASIACCS) . 149–162

    work page 2023

  2. [2]

    Marco Abbadini, Dario Facchinetti, Gianluca Oldani, Matthew Rossi, and Stefano Paraboschi. 2023. NatiSand: Native code sandboxing for JavaScript runtimes. In 26th International Symposium on Research in Attacks, Intrusions and Defenses (RAID). 639–653

    work page 2023

  3. [3]

    Paschal C Amusuo, Kyle A Robinson, Tanmay Singla, Huiyun Peng, Aravind Machiry, Santiago Torres-Arias, Laurent Simon, and James C Davis. 2025. GoLeash: Mitigating Golang Software Supply Chain Attacks , , ZTD𝐽𝐴𝑉𝐴 : Mitigating Software Supply Chain Vulnerabilities via Zero-Trust Dependencies. IEEE/ACM 47th International Conference on Software Engineering (I...

    work page 2025

  4. [4]

    Aqua Security. 2025. Trivy: Open Source Vulnerability and Misconfiguration Scanner. https://www.aquasec.com/products/trivy/ Accessed: 2025-04-12

    work page 2025

  5. [5]

    Jacob Baines. 2023. Hijackable Go Module Repositories. https://vulncheck.com/ blog/go-repojacking

    work page 2023

  6. [6]

    William Blair, Frederico Araujo, Teryl Taylor, and Jiyong Jang. 2024. Automated Synthesis of Effect Graph Policies for Microservice-Aware Stateful System Call Specialization. In 2024 IEEE Symposium on Security and Privacy (SP) . IEEE, 4554– 4572

    work page 2024

  7. [7]

    Kirill Boychenko. 2025. Go Supply Chain Attack: Malicious Package Exploits Go Module Proxy Caching for Persistence. https://socket.dev/blog/malicious- package-exploits-go-module-proxy-caching-for-persistence

    work page 2025

  8. [8]

    Kirill Boychenko. 2025. Typosquatted Go Packages Deliver Malware Loader Targeting Linux and macOS Systems. https://socket.dev/blog/typosquatted-go- packages-deliver-malware-loader

    work page 2025

Show all 79 references
  1. [9]

    Tyler Bui. 2019. Using Go Modules - The Go Programming Language. https: //blog.golang.org/using-go-modules Accessed: 2025-04-12

    2019

  2. [10]

    GoLeash: Mitigating GoLang Software Supply Chain Attack with Runtime Polocy Enforcement

    Roberto Natella Carmine Cesarano, Martin Monperrus. 2025. Replication Package for "GoLeash: Mitigating GoLang Software Supply Chain Attack with Runtime Polocy Enforcement". https://figshare.com/s/ce9afb61cdc87936543a. Accessed: 2025-04-15

    2025

  3. [11]

    Carmine Cesarano, Vivi Andersson, Roberto Natella, and Martin Monperrus. 2023. GoSurf: Identifying Software Supply Chain Attack Vectors in Go. In Proceedings of the 2024 Workshop on Software Supply Chain Offensive Research and Ecosystem Defenses. 33–42

    2023

  4. [12]

    cilium. 2025. bpf2go. https://github.com/cilium/ebpf/tree/main/cmd/bpf2go Accessed: 2025-04-12

    2025

  5. [13]

    Cilium. 2025. eBPF-based Networking, Observability, Security. https://cilium.io/ Accessed: 2025-04-12

    2025

  6. [14]

    CISA and NSA. 2021. Defending Against Software Supply Chain At- tacks. https://www.cisa.gov/sites/default/files/publications/defending_against_ software_supply_chain_attacks_508.pdf. Accessed: 2025-04-11

    2021

  7. [15]

    CoreDNS Authors. 2025. CoreDNS: DNS Server That Chains Plugins. https: //github.com/coredns/coredns Accessed: 2025-04-12

    2025

  8. [16]

    Russ Cox. 2025. Fifty Years of Open Source Software Supply Chain Security. ACM Queue 23, 1 (2025), 84–107

    2025

  9. [17]

    Milo Craun, Khizar Hussain, Uddhav Gautam, Zhengjie Ji, Tanuj Rao, and Dan Williams. 2024. Eliminating eBPF Tracing Overhead on Untraced Processes. In Proceedings of the ACM SIGCOMM 2024 Workshop on eBPF and Kernel Extensions . 16–22

    2024

  10. [18]

    Datadog. 2024. GuardDog: CLI Tool to Identify Malicious PyPI, npm Packages. https://github.com/DataDog/guarddog Accessed: 2025-04-12

    2024

  11. [19]

    Datadog. 2025. Malicious Software Packages Dataset. https://github.com/ DataDog/malicious-software-packages-dataset Accessed: 2025-04-12

    2025

  12. [20]

    Go Dev. 2025. Case Studies. https://go.dev/solutions/case-studies

    2025

  13. [21]

    DNS-OARC. 2025. dnsperf: DNS Performance Testing Tools. https://github.com/ DNS-OARC/dnsperf Accessed: 2025-04-12

    2025

  14. [22]

    Docker Inc. 2024. Docker: Empowering App Development for Developers. https: //www.docker.com. Accessed: 2025-04-11

    2024

  15. [23]

    eBPF Foundation. 2024. What is eBPF? https://ebpf.io/what-is-ebpf/. Accessed: 2025-04-11

    2024

  16. [24]

    etcd Authors. 2024. etcd: A Distributed, Reliable Key-Value Store for the Most Critical Data of a Distributed System. https://etcd.io. Accessed: 2025-04-11

    2024

  17. [25]

    Ethereum Foundation. 2025. go-ethereum: Go Implementation of the Ethereum Protocol. https://github.com/ethereum/go-ethereum Accessed: 2025-04-12

    2025

  18. [26]

    Falco. 2025. Detect security threats in real time. https://falco.org/ Accessed: 2025-04-12

    2025

  19. [27]

    fatedier. 2025. frp: A Fast Reverse Proxy to Help You Expose a Local Server Behind a NAT or Firewall to the Internet. https://github.com/fatedier/frp Accessed: 2025-04-12

    2025

  20. [28]

    Gabriel Ferreira, Limin Jia, Joshua Sunshine, and Christian Kästner. 2021. Con- taining Malicious Package Updates in npm with a Lightweight Permission System. In Proceedings of the 43rd International Conference on Software Engineering (ICSE ’21). IEEE Press, 1334–1346. https:/...

    2021

  21. [29]

    Adrien Ghosn, Marios Kogias, Mathias Payer, James R Larus, and Edouard Bugnion. 2021. Enclosure: language-based restriction of untrusted libraries. In Proceedings of the 26th ACM International Conference on Architectural Support for Programming Languages and Operating Systems ...

    2021

  22. [30]

    GitHub. 2025. GitHub. https://github.com Accessed April 12, 2025

    2025

  23. [31]

    GitHub Community. 2018. Malicious code found in npm package event-stream. https://github.com/dominictarr/event-stream/issues/116. Accessed: 2025-04-11

    2018

  24. [32]

    Go Team. 2023. Go standard library - Go Packages. https://pkg.go.dev/std Accessed April 2025

    2023

  25. [33]

    Go Team. 2023. Go standard library - the runtime package. https://pkg.go.dev/ runtime Accessed April 2025

    2023

  26. [34]

    Google Cloud Blog. 2022. Ready, Set, Go — Golang Internals and Symbol Recov- ery. https://cloud.google.com/blog/topics/threat-intelligence/golang-internals- symbol-recovery/

    2022

  27. [35]

    Google Inc. 2025. Google Capslock. https://github.com/google/capslock

    2025

  28. [36]

    Nuwan Goonasekera, William Caelli, and Colin Fidge. 2015. LibVM: an archi- tecture for shared library sandboxing. Software: Practice and Experience 45, 12 (2015), 1597–1617

    2015

  29. [37]

    goretk. 2025. Redress: A Tool for Analyzing Stripped Go Binaries. https://github. com/goretk/redress Accessed: 2025-04-12

    2025

  30. [38]

    gVisor Team. 2024. gVisor: The Container Security Platform. https://gvisor.dev/. Accessed: 2025-04-11

    2024

  31. [39]

    HashiCorp. 2024. Terraform by HashiCorp. https://www.terraform.io. Accessed: 2025-04-11

    2024

  32. [40]

    Isovalent. 2025. eBPF-based networking, security, and observability. https: //isovalent.com/ Accessed: 2025-04-12

    2025

  33. [41]

    Raphaël Khoury and Nadia Tawbi. 2012. Which security policies are enforceable by runtime monitors? a survey. Computer Science Review 6, 1 (2012), 27–45

    2012

  34. [42]

    Kube-Burner Contributors. 2025. kube-burner: Kubernetes Performance and Scale Test Orchestration Framework. https://github.com/kube-burner/kube-burner Accessed: 2025-04-12

    2025

  35. [43]

    Kubernetes Authors. 2024. Kubernetes: Production-Grade Container Orchestra- tion. https://kubernetes.io. Accessed: 2025-04-11

    2024

  36. [44]

    2024.{iHunter}: Hunting Privacy Violations at Scale in the Software Supply Chain on{iOS}

    Dexin Liu, Yue Xiao, Chaoqi Zhang, Kaitao Xie, Xiaolong Bai, Shikun Zhang, and Luyi Xing. 2024.{iHunter}: Hunting Privacy Violations at Scale in the Software Supply Chain on{iOS}. In 33rd USENIX Security Symposium (USENIX Security 24). 5663–5680

    2024

  37. [45]

    Microsoft. 2025. DTrace on Windows. https://github.com/microsoft/DTrace-on- Windows Accessed: 2025-04-12

    2025

  38. [46]

    MITRE. 2025. CWE-441: Unintended Proxy or Intermediary (’Confused Deputy’). https://cwe.mitre.org/data/definitions/441.html Accessed: 2025-04-12

    2025

  39. [47]

    Borja Molina-Coronado, Antonio Ruggia, Usue Mori, Alessio Merlo, Alexander Mendiburu, and Jose Miguel-Alonso. 2025. Light up that Droid! On the effec- tiveness of static analysis features against app obfuscation for Android malware detection. Journal of Network and Computer Ap...

    2025

  40. [48]

    National Institute of Standards and Technology (NIST). 2025. CVE-2021-44228: Apache Log4j2 Remote Code Execution Vulnerability. https://nvd.nist.gov/vuln/ detail/CVE-2021-44228 Accessed: 2025-04-12

    2025

  41. [49]

    Nir OhfeldSasson. 2025. IngressNightmare: CVE-2025-1974 - 9.8 Critical Unau- thenticated Remote Code Execution Vulnerabilities in Ingress NGINX . https: //www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities Accessed: 2025- 04-12

    2025

  42. [50]

    Marc Ohm, Henrik Plate, Arnold Sykosch, and Michael Meier. 2020. Backstab- ber’s knife collection: A review of open source software supply chain attacks. In Detection of Intrusions and Malware, and Vulnerability Assessment: 17th Interna- tional Conference, DIMV A 2020, Lisbon,...

    2020

  43. [51]

    Marc Ohm, Timo Pohl, and Felix Boes. 2023. You Can Run But You Can’t Hide: Runtime Protection Against Malicious Package Updates For Node.js. arXiv preprint arXiv:2305.19760 (2023)

    2023 arXiv

  44. [52]

    Philip O’Kane, Sakir Sezer, and Kieran McLaughlin. 2011. Obfuscation: The hidden malware. IEEE Security & Privacy 9, 5 (2011), 41–47

    2011

  45. [53]

    Open Source Insights Team. 2025. Open Source Insights. https://deps.dev/ Accessed April 12, 2025

    2025

  46. [54]

    Shankara Pailoor, Xinyu Wang, Hovav Shacham, and Isil Dillig. 2020. Auto- mated policy synthesis for system call sandboxing. Proceedings of the ACM on Programming Languages 4, OOPSLA (2020), 1–26

    2020

  47. [55]

    Github repo. 2015. wg/wrk: Modern HTTP Benchmarking tool. https://github. com/wg/wrk

    2015

  48. [56]

    Github repo. 2019. Ethereum Benchmark. https://github.com/OBrezhniev/ ethereum-benchmark

    2019

  49. [57]

    Github repo. 2024. etcd - benchmark. https://github.com/etcd-io/etcd/blob/main/ tools/benchmark/README.md

    2024

  50. [58]

    Michen Riksen. 2025. Finding Evil Go Packages. https://michenriksen.com/ archive/blog/finding-evil-go-packages/. Accessed: 2025-04-15

    2025

  51. [59]

    Nick Roessler, Lucas Atayde, Imani Palmer, Derrick McKee, Jai Pandey, Vasileios P Kemerlis, Mathias Payer, Adam Bates, Jonathan M Smith, Andre DeHon, et al

  52. [60]

    Maryam Rostamipoor, Seyedhamed Ghavamnia, and Michalis Polychronakis

  53. [61]

    Jerome H Saltzer and Michael D Schroeder. 1975. The protection of information in computer systems. Proc. IEEE 63, 9 (1975), 1278–1308

    1975

  54. [62]

    Adriana Sejfia and Max Schäfer. 2022. Practical automated detection of malicious npm packages. In Proceedings of the 44th International Conference on Software Engineering (ICSE ’22). Association for Computing Machinery, 1681–1692. doi:10. 1145/3510003.3510104 , , Carmine Cesar...

    2022

  55. [63]

    Jaebaek Seo, Daehyeok Kim, Donghyun Cho, Insik Shin, and Taesoo Kim. 2016. FLEXDROID: Enforcing In-App Privilege Separation in Android.. In NDSS

    2016

  56. [64]

    Hossein Siadati, Sima Jafarikhah, Elif Sahin, Terrence Hernandez, Elijah Tripp, Denis Khryashchev, and Amin Kharraz. 2024. DevPhish: Exploring Social En- gineering in Software Supply Chain Attacks on Developers. In 2024 IEEE 15th Annual Ubiquitous Computing, Electronics & Mobi...

    2024

  57. [65]

    Richard E Smith. 2012. A contemporary look at Saltzer and Schroeder’s 1975 design principles. IEEE Security & Privacy 10, 6 (2012), 20–25

    2012

  58. [66]

    Snyk Ltd. 2025. Snyk CLI Documentation. https://docs.snyk.io/snyk-cli Accessed: 2025-04-12

    2025

  59. [67]

    Tetragon. 2025. eBPF-based Security Observability and Runtime Enforcement. https://tetragon.io/ Accessed: 2025-04-12

    2025

  60. [68]

    The Linux Kernel Archives. 2025. Using the Linux Kernel Tracepoints. https: //docs.kernel.org/trace/tracepoints.html

    2025

  61. [69]

    The Linux Kernel Community. 2024. seccomp(2) — Linux manual page. https: //man7.org/linux/man-pages/man2/seccomp.2.html. Accessed: 2025-04-11

    2024

  62. [70]

    The Linux Kernel Community. 2025. x86_64 System Call Table (syscall_64.tbl). https://github.com/torvalds/linux/blob/v6.7/arch/x86/entry/syscalls/syscall_64. tbl Accessed: 2025-04-12

    2025

  63. [71]

    Nikos Vasilakis, Cristian-Alexandru Staicu, Grigoris Ntousakis, Konstantinos Kallas, Ben Karel, André DeHon, and Michael Pradel. 2021. Preventing Dynamic Library Compromise on Node.js via RWX-Based Privilege Reduction. In ACM SIGSAC Conference on Computer and Communications Se...

    2021

  64. [72]

    Wenya Wang, Xingwei Lin, Jingyi Wang, Wang Gao, Dawu Gu, Wei Lv, and Jiashui Wang. 2023. HODOR: Shrinking Attack Surface on Node.js via System Call Limitation. In ACM SIGSAC Conference on Computer and Communications Security (CCS). 2800–2814

    2023

  65. [73]

    Alex Williams. 2024. Giving Go a Go: Simplifying Cloud Infrastructure De- velopment. https://cacm.acm.org/blogcacm/giving-go-a-go-simplifying-cloud- infrastructure-development/

    2024

  66. [74]

    Yongzheng Wu, Sai Sathyanarayan, Roland HC Yap, and Zhenkai Liang. 2012. Codejail: Application-transparent isolation of libraries with tight program in- teractions. In Computer Security–ESORICS 2012: 17th European Symposium on Research in Computer Security, Pisa, Italy, Septem...

    2012

  67. [75]

    Elizabeth Wyss, Alexander Wittman, Drew Davidson, and Lorenzo De Carli. 2022. Wolf at the door: Preventing install-time attacks in npm with latch. InACM ASIA Conference on Computer and Communications Security (ASIACCS) . 1139–1153

    2022

  68. [76]

    Wei Xu, Fangfang Zhang, and Sencun Zhu. 2012. The power of obfuscation techniques in malicious JavaScript code: A measurement study. In 2012 7th Inter- national Conference on Malicious and Unwanted Software . IEEE, 9–16

    2012

  69. [77]

    github . com / fatedier / frp / client

    Zhaoqi Zhang, Panpan Qi, and Wei Wang. 2020. Dynamic malware analysis with feature engineering and feature learning. In Proceedings of the AAAI conference on artificial intelligence, Vol. 34. 1210–1217. A Example Security Policy for frp In the following we provide an excerpt f...

    2020

  70. [2021]

    In Proceedings of the 24th International Symposium on Research in Attacks, Intrusions and Defenses

    Mscope: A methodology for analyzing least-privilege compartmentalization in large software artifacts. In Proceedings of the 24th International Symposium on Research in Attacks, Intrusions and Defenses . 296–311

  71. [2023]

    Computers & Security 132 (2023)

    Confine: Fine-grained system call filtering for container attack surface reduction. Computers & Security 132 (2023)

    2023

Pith tools

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