Pith. sign in

REVIEW 4 major objections 6 minor 61 references

Fingerprint-Driven Automation: Coupling Reconnaissance with POC Verification

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

Pith's one-line read A fingerprint-driven pipeline closes the loop between reconnaissance and exploit verification.

desk verdict A plausible engineering integration whose central claim is undermined by a checklist-style evaluation that never measures whether the fingerprint-to-PoC coupling actually makes good decisions. read the letter →

arxiv 2607.26655 v2 pith:6WLGIHMQ submitted 2026-07-29 cs.CR

classification cs.CR
keywords reconnaissancevulnerabilityverificationproof-of-conceptwebfingerprintingautomatedpenetrationtestingclosed-looppipelinedirectoryscanningsecurityautomation
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

Deepscan is proposed as a reconnaissance and vulnerability-verification tool that fuses two traditionally separate stages of penetration testing into one pipeline. The paper's central claim is that web fingerprints captured during scanning can serve as the trigger for selecting and executing proof-of-concept (PoC) scripts, so that the analyst's manual job of triaging scan output and choosing an exploit check disappears. The tool performs DNS/geolocation, port and directory scanning, OS/WAF/CDN detection, and multi-layer fingerprint identification, then passes the collected target profile to standardized PoC check functions. The authors report that tests against realistic CTF-style vulnerable environments confirm the closed loop works with high efficiency and very low network overhead. A sympathetic reader would care because the paper points at a concrete way to close the 'semantic gap' between what a scanner finds and what a verifier executes.

What carries the argument

The load-bearing object is the fingerprint-linked PoC scheduler, a nexus that connects the reconnaissance and verification phases. Fingerprint rules—keyed to headers, page keywords, script paths, and meta tags—are compiled from multiple community fingerprint libraries into a JSON database; WebInfo data from a scan is matched against this database to determine the application stack. Each PoC script exposes a standardized check function that receives open ports and application fingerprints and decides whether execution conditions hold. That standardized interface plus the fingerprint-to-PoC mapping is what converts raw scan data into an executable verification decision, making the closure of t

What would settle it

Deploy a target with a deliberately unrecognized application stack (custom framework, no matching fingerprint rule) and a known vulnerability matching an existing PoC; run Deepscan. If the tool completes a scan and reports no vulnerability without invoking any PoC, that observation would falsify the closed-loop claim for unrecognized fingerprints, showing the loop depends entirely on database coverage.

Watch

Extended reading notes

Core claim

The paper's central claim is that a fingerprint-driven mechanism can bridge the gap between reconnaissance and verification: Deepscan identifies a target's application stack from HTTP responses, page content, meta tags, and script sources, maps that fingerprint to matching proof-of-concept modules, and automatically executes those modules whose check conditions are met. This replaces the traditional workflow in which an analyst manually reviews scan output, picks suspicious targets, and selects verification scripts. The tool records all results in a structured database and emits HTML/terminal reports. On real CTF-style environments with live vulnerable chains, the authors say, the tool compl

Load-bearing premise

The whole pipeline depends on the fingerprint database being complete and accurate enough to recognize a target's application stack from limited HTTP evidence; the paper reports no coverage statistics, no fingerprint-error analysis, and no fallback when no fingerprint matches.

Editorial extensions

If this is right

  • An analyst no longer needs to manually sift scan results; the tool's verification stage is triggered directly by recognized fingerprints.
  • Because only PoCs matching the fingerprint are run, the tool avoids enumerating every known vulnerability, cutting network traffic and scan time.
  • Directory scanning combines HTTP status, content-type, soft-404 detection, and redirect validation, addressing a common failure in scanners that trust response codes alone.
  • The modular PoC interface and extensible fingerprint database allow future detection rules and checks to be added without rewriting the pipeline.
  • Cross-platform execution (threaded on Windows, async I/O on Linux) makes the same closed loop available in typical operator environments.

Reading between the lines

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

  • The reported tests pass their listed cases, but no coverage statistics are given; for targets whose application stack is absent from the fingerprint database, the pipeline would likely silently skip verification, so real-world recall remains untested.
  • Because verification is gated by fingerprint matching, reconnaissance precision is the true ceiling on the tool's accuracy; measuring fingerprint recall and precision separately would predict end-to-end performance.
  • The same 'structured scan output -> condition-checked script' connector could generalize beyond this tool, e.g., mapping indicators of compromise to response playbooks in incident response.
  • A testable extension is to report the fraction of scanned targets that yield at least one PoC execution, along with false-negative cases where a known vulnerable target produced no match.
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 presents Deepscan, a Python-based tool that couples automated reconnaissance (webinfo collection, port/directory scanning, service fingerprinting) with PoC-based vulnerability verification. The design is described across three modules — basic info reconnaissance, fingerprint-driven scanning/identification, and data aggregation — with a proposed fingerprint-to-PoC mapping as the key innovation. The evaluation reports functional tests on the BUUCTF CTF platform and the Vulhub Docker-based range, claiming that all test cases passed and that the tool achieves automatic reconnaissance and vulnerability verification. The central claim is that the fingerprint-driven mechanism "successfully bridges the semantic gap between reconnaissance and utilization" (\S5.2).

Significance. If fully substantiated, the paper would describe a useful engineering integration: an open, extensible tool that automatically turns reconnaissance signals into targeted PoC execution, reducing manual hand-off and potentially lowering network traffic compared to blind scanning. The design is internally coherent, and the choice to test on real CTF/Vulhub environments rather than synthetic benchmarks is a positive feature. However, the paper currently provides no quantitative evidence for the central claims: there are no measurements of accuracy, false-positive/false-negative rates, network overhead, or runtime, and no comparison against existing tools or baselines. The feasibility of the module integration is plausible but unproven beyond a checklist of self-reported passes. The significance rests almost entirely on evaluation data that the paper does not supply.

major comments (4)
  1. [§5.1, Tables 5–6] The functional evaluation is a checklist of module names with '✓' marks. There is no definition of what constitutes a 'pass' for any test case, no count of targets scanned, no number of fingerprints matched or missed, no list of PoCs actually executed, and no true-positive/true-negative/false-positive/false-negative breakdown. The statement 'all test cases have passed' is therefore underspecified. Because the central claim is that the fingerprint-to-PoC coupling makes correct decisions (rather than merely that modules execute without crashing), Table 6's 'PoC Detection' row cannot support that claim. Please report per-target results: how many fingerprints were recognized, how many PoC conditions were met, how many verifications succeeded, and how many were false positives/negatives.
  2. [§5.2] The robustness section states: 'Empirical results confirm that the proposed fingerprint-driven mechanism successfully bridges the semantic gap between reconnaissance and utilization, and achieves efficiency and accuracy with extremely low network overhead.' No efficiency or overhead measurements appear anywhere in the paper — no request counts, no byte counts, no wall-clock times, no comparison to a blind-scan baseline. The 'extremely low network overhead' claim is load-bearing for the contribution (the paper argues the fingerprint-driven approach avoids blind scanning), but it is completely unsupported by data. Please add quantitative overhead and efficiency measurements against a baseline that performs full PoC traversal without fingerprint filtering.
  3. [§3.2.5 / §4.5] The fingerprint-to-PoC pipeline relies on a database assembled from Wappalyzer, Webeyes, and FOFA, but the paper reports no coverage statistics, no accuracy analysis, and no behavior when a fingerprint is absent or ambiguous. If a target runs an unrecognized framework or returns conflicting signatures, the tool has no stated fallback; it may silently skip verification, which would invalidate the closed-loop claim. Please report match/miss rates on the test sets, describe the decision rule when fingerprints are missing, and provide any error analysis of the fingerprint database.
  4. [§5.1 / Conclusion] The conclusion claims Deepscan offers advantages in 'scanning depth, adaptability, and efficiency' relative to existing scanners, but no comparative evaluation is performed. The paper would be strengthened by a direct comparison with at least one existing tool (e.g., WPScan for a known WordPress target, or a general scanner like AWVS) on the same test cases, reporting precision/recall or at least detection results and resource usage. Without a baseline, the claimed advantages cannot be assessed.
minor comments (6)
  1. [Throughout] The tool name is inconsistently spelled 'Deepscan' and 'DeepScan'; please unify. Also, 'W AF' appears with a spurious space in several places (§3.2.2, §3.2.6, Table 1) — should be 'WAF'.
  2. [Tables 1–4] The type 'V ARCHAR' is a typo for VARCHAR; several Data Type entries contain stray spaces. Also, Table 4 shows a 'Mine' relationship in the ER diagram (Figure 3) that is not explained in the text.
  3. [§3.2.3] The port spoofing heuristic — 'if more than 30 ports are open, port spoofing is highly probable' — is presented as a rule of thumb with no justification or sensitivity analysis. At a minimum, cite a source or clearly label it as a heuristic.
  4. [§2] The related-work section asserts that 'the rates of false positives and false negatives are controlled within an acceptable range,' but this statement appears before any evaluation is presented and is not repeated with data in §5. Please either remove the unsupported claim or move it to the evaluation section with supporting numbers.
  5. [§5.1] The evaluation section does not state the versions of BUUCTF and Vulhub environments used, nor the date of testing. This matters for reproducibility, since vulnerable images may be patched or removed over time.
  6. [References] Several references have inconsistent formatting (e.g., 'Z. Ming, Jiang,' in [3], 'V . J. M. Manes' in [60], and the use of 'Version 1' / 'Version 3' for arXiv items). Please standardize the reference list.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper reports an engineering tool with external evaluation targets; no derivation reduces to its inputs.

full rationale

The paper makes no formal derivation or fitted-parameter prediction. Its central mechanism—using fingerprints collected from Wappalyzer/Webeyes/FOFA (§3.2.4, §4.5) to select PoC scripts (§3.2.5, §4.6)—is a software-engineering design choice, not a result derived from data. The evaluation uses external targets (BUUCTF and Vulhub, §5.1), so the claimed functionality is checked against independent test environments rather than against the paper's own fitted quantities. The only mild self-referential aspect is that the same fingerprint database both recognizes applications and chooses PoCs, which could create a limited self-confirmation effect, but the paper does not present this as a statistical prediction or as a theorem; it is standard tool architecture. Self-citations appear in the reference list (e.g., refs [5],[6],[7],[22],[27],[28],[29],[31]) but none is load-bearing: no uniqueness theorem, no imported ansatz, and no central claim is justified solely by these citations. The skeptical concerns about missing precision/recall and coverage statistics are evidence gaps about evaluation quality, not circularity. Under the provided rules, a paper with external benchmarks and no fitted prediction should receive score 0.

Assumptions & free parameters 1 free parameters · 3 assumptions · 0 invented entities

No new physical or formal entities are postulated; Deepscan is a software system assembled from existing libraries and databases. The only hand-set design choices are minor heuristics such as the port-spoofing threshold. The central scientific-weight assumptions are the completeness of third-party fingerprint data and the representativeness of the test ranges.

free parameters (1)
  • port_spoofing_threshold = >30 open ports
    Ad-hoc heuristic in §3.2.3: if more than 30 ports are open, the tool treats port spoofing as highly probable. It is not empirically calibrated and could bias service identification.
assumptions (3)
  • domain assumption Third-party fingerprint libraries (Wappalyzer, Webeyes) and the FOFA-synthesized fingerprint JSON are complete and accurate enough to identify a target's application stack from headers, HTML, and script src attributes.
    Invoked in §3.2.4 and §4.5; the entire fingerprint-to-PoC coupling depends on these databases, but coverage and error rates are never measured.
  • domain assumption BUUCTF and Vulhub environments are representative of real-world vulnerable web applications and produce authentic service responses.
    Invoked in §5.1; used to claim real-world robustness, but representativeness is asserted, not demonstrated with comparison to production systems.
  • domain assumption Each PoC's check() function can decide applicability from the collected WebInfo parameters.
    Invoked in §3.2.5 and §4.6; if the standardized parameters are insufficient for vulnerability-specific checks, the claimed automated mapping fails.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Fingerprint-Driven Automation: Coupling Reconnaissance with POC Verification." pith.science (2026). https://pith.science/paper/6WLGIHMQ

@misc{pith2026260726655,
  author       = {Pith},
  title        = {Pith review of: Fingerprint-Driven Automation: Coupling Reconnaissance with POC Verification},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/6WLGIHMQ}},
  note         = {Machine review of arXiv:2607.26655}
}
read the original abstract

In the field of network security confrontation, reconnaissance is the first and most critical step. Accurate, efficient, and comprehensive reconnaissance can help network security workers more fully understand the target's current state, identify potential weaknesses, and formulate a targeted attack strategy. However, there are some problems in the existing tools on the market, such as low accuracy of the collected information, lack of concealment, time-consuming, low or high integration of tools, which makes them difficult to start using. With the continuous development of technology, systems need to continuously upgrade their technologies and strategies, and expand new functions. The scalability of tool functions is also one of the factors that need to be taken into consideration. These problems in the practice of network security have a serious impact on user experience and work efficiency. In view of this, a more user-friendly, more automated reconnaissance and vulnerability verification tool is designed. This paper proposes to develop a highly automated reconnaissance and vulnerability verification tool. This paper presents the tool functions and conducts the basic design. Finally, we implement and test all the functions specifically to verify the feasibility of the tool functions and highlight the advantages of this tool in terms of automation, retrieval, and use in network security operations. Through the test of the online security simulation range, the results show that this tool can complete the automatic reconnaissance and in-depth data processing of specific targets, and conduct automatic vulnerability detection and verification.

Figures

Figures reproduced from arXiv: 2607.26655 by the authors.

Figure 1
Figure 1. Functional Diagram 3.2 Functional Design The execution flow of the entire tool consists of the following steps: collection of basic information, vulnerability information matching, and generation of the scan report. The vulnerability information matching process requires the use of the necessary basic information parameters collected earlier, while the report includes two sections: basic information data and details… view at source ↗
Figure 2
Figure 2. Function Flowchart 3.2.1 User Interface The user interface is the initial presentation of the system to users. Whether it is a terminal command-line interface or a graphical web interface, it should be simple and clear, highlighting the tool’s core functions. The tool offers two interface options, a terminal command-line interface and a graphical web interface, to meet the needs of different users. 4 [PITH_FULL_IMA… view at source ↗
Figure 3
Figure 3. Entity-Relationship Diagram of the System [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

61 extracted references · 2 linked inside Pith

  1. [1]

    Alhamed and M

    M. Alhamed and M. M. H. Rahman. A systematic literature review on penetration testing in networks: Future research directions.Applied Sciences, 13(12):6986, 2023

  2. [2]

    Shiri Harzevili, A

    N. Shiri Harzevili, A. Boaye Belle, J. Wang, S. Wang, Z. M. (Jack) Jiang, and N. Nagappan. A systematic literature review on automated software vulnerability detection using machine learning.ACM Computing Surveys, 57(3):1–36, 2025

  3. [3]

    N. S. Harzevili, A. B. Belle, J. Wang, S. Wang, Z. Ming, Jiang, and N. Nagappan. A survey on automated software vulnerability detection using machine learning and deep learning.arXiv, 2023. Version 1

  4. [4]

    Zhang, J

    B. Zhang, J. Li, J. Ren, and G. Huang. Efficiency and effectiveness of web application vulnerability detection approaches: A review.ACM Computing Surveys, 54(9):1–35, 2022

  5. [5]

    Exploring vulnerabilities and concerns in Solana smart contracts.arXiv preprint arXiv:2504.07419, 2025

    Xiangfan Wu, Ju Xing, and Xiaoqi Li. Exploring vulnerabilities and concerns in Solana smart contracts.arXiv preprint arXiv:2504.07419, 2025

  6. [6]

    Blockchain security based on cryptography: A review.arXiv preprint arXiv:2508.01280, 2025

    Wenwen Zhou, Dongyang Lyu, and Xiaoqi Li. Blockchain security based on cryptography: A review.arXiv preprint arXiv:2508.01280, 2025

  7. [7]

    Sybil attacks detection and traceability mechanism based on beacon packets in connected automobile vehicles.Sensors, 24(7):2153, 2024

    Yaling Zhu, Jia Zeng, Fangchen Weng, Dan Han, Yiyu Yang, Xiaoqi Li, and Yuqing Zhang. Sybil attacks detection and traceability mechanism based on beacon packets in connected automobile vehicles.Sensors, 24(7):2153, 2024

  8. [8]

    Amankwah, J

    R. Amankwah, J. Chen, P. K. Kudjo, and D. Towey. An empirical comparison of commercial and open-source web vulnerability scanners.Software: Practice and Experience, 50(9):1842–1857, 2020

Show all 61 references
  1. [9]

    Koman and M

    J. Koman and M. Janiszewski. SCAnME - scanner comparative analysis and metrics for evaluation.International Journal of Information Security, 24(3):147, 2025

  2. [10]

    Mazurczyk and L

    W. Mazurczyk and L. Caviglione. Cyber reconnaissance techniques.Communications of the ACM, 64(3):86–95, 2021

  3. [11]

    Ferrara, P

    E. Ferrara, P. De Meo, G. Fiumara, and R. Baumgartner. Web data extraction, applications and techniques: A survey.Knowledge-Based Systems, 70:301–323, 2014

  4. [12]

    Dr. S. Sarumathi, Ms. M. Sharmila, M. Saraswathy, and M. R. L. Priya. The benchmark analysis of different web scraping tools and techniques.IJARCCE, 13(5), 2024

  5. [13]

    I. A. Essien, A. O. Adebayo, A. A. Afuwape, B. O. Eboseremen, F. Oladega, and O. M. Soneye. The ethics of web scraping in research: A review: Investigating the boundaries, legal implications, and societal acceptance of web scraping as a data collection method.Journal of Fronti...

  6. [14]

    Rahman, R

    A. Rahman, R. Mahdavi-Hezaveh, and L. Williams. A systematic mapping study of infrastructure as code research. Information and Software Technology, 108:65–77, 2019

  7. [15]

    Leite, C

    L. Leite, C. Rocha, F. Kon, D. Milojicic, and P. Meirelles. A survey of devops concepts and challenges.ACM Computing Surveys, 52(6):1–35, 2020

  8. [16]

    Ivanˇci´c, D

    L. Ivanˇci´c, D. Suˇsa Vugec, and V . Bosilj Vukˇsi´c. Robotic process automation: Systematic literature review. In C. Di Ciccio, R. Gabryelczyk, L. Garc ´ıa-Ba˜nuelos, T. Hernaus, R. Hull, M. Indihar ˇStemberger, A. K ˝o, and M. Staples, editors,Business Process Management: B...

  9. [17]

    Wiklund, S

    K. Wiklund, S. Eldh, D. Sundmark, and K. Lundqvist. Impediments for software test automation: A systematic literature review.Software Testing, Verification and Reliability, 27(8):e1639, 2017

  10. [18]

    S. G. Bianou and R. G. Batogna. PENTEST-AI, an LLM-powered multi-agents framework for penetration testing automation leveraging Mitre Attack. In2024 IEEE International Conference on Cyber Security and Resilience (CSR), pages 763–770, 2024

  11. [19]

    H. Xu, S. Wang, N. Li, K. Wang, Y . Zhao, K. Chen, T. Yu, Y . Liu, and H. Wang. Large language models for cyber security: A systematic literature review.ACM Transactions on Software Engineering and Methodology, page 3769676, 2025. 13

  12. [20]

    R. Fang, R. Bindu, A. Gupta, Q. Zhan, and D. Kang. LLM agents can autonomously hack websites.arXiv, 2024. Version 3

  13. [21]

    Sheng, Z

    Z. Sheng, Z. Chen, S. Gu, H. Huang, G. Gu, and J. Huang. LLMs in software security: A survey of vulnerability detection techniques and insights.ACM Computing Surveys, 58(5):1–35, 2026

  14. [22]

    SmartBugBert: BERT-enhanced vulnerability detection for smart contract bytecode.arXiv preprint arXiv:2504.05002, 2025

    Jiuyang Bu, Wenkai Li, Zongwei Li, Zeng Zhang, and Xiaoqi Li. SmartBugBert: BERT-enhanced vulnerability detection for smart contract bytecode.arXiv preprint arXiv:2504.05002, 2025

  15. [23]

    H. Fang, J. Herbsleb, and B. Vasilescu. Novelty begets popularity, but curbs participation—A macroscopic view of the Python open-source ecosystem. InProceedings of the IEEE/ACM 46th International Conference on Software Engineering, pages 1–11, 2024

  16. [24]

    Paramitha and F

    R. Paramitha and F. Massacci. Technical leverage analysis in the Python ecosystem.Empirical Software Engineering, 28(6):139, 2023

  17. [25]

    Yadav, A

    A. Yadav, A. Kumar, and V . Singh. Open-source intelligence: A comprehensive review of the current state, applications and future perspectives in cyber security.Artificial Intelligence Review, 56(11):12407–12438, 2023

  18. [26]

    J. R. G. Evangelista, R. J. Sassi, M. Romero, and D. Napolitano. Systematic literature review to investigate the application of open source intelligence (OSINT) with artificial intelligence.Journal of Applied Security Research, 16(3):345–369, 2021

  19. [27]

    Interaction-aware vulnerability detection in smart contract bytecodes.IEEE Transactions on Dependable and Secure Computing, 23(1):298–315, 2026

    Wenkai Li, Xiaoqi Li, Yingjie Mao, and Yuqing Zhang. Interaction-aware vulnerability detection in smart contract bytecodes.IEEE Transactions on Dependable and Secure Computing, 23(1):298–315, 2026

  20. [28]

    IntelliCon: Confidence-based approach for fine-grained vulnerability analysis in smart contracts

    Yiming Shen, Kunhua Li, Lin Mao, Wenkai Li, and Xiaoqi Li. IntelliCon: Confidence-based approach for fine-grained vulnerability analysis in smart contracts. InInternational Conference on Blockchain and Trustworthy Systems, pages 45–59. Springer, 2023

  21. [29]

    Penetrating the hostile: Detecting DeFi protocol exploits through cross-contract analysis.IEEE Transactions on Information Forensics and Security, 20:11759–11774, 2025

    Xiaoqi Li, Wenkai Li, Zhiquan Liu, Yuqing Zhang, and Yingjie Mao. Penetrating the hostile: Detecting DeFi protocol exploits through cross-contract analysis.IEEE Transactions on Information Forensics and Security, 20:11759–11774, 2025

  22. [30]

    N. K. Kahlon and W. Singh. A systematic review of web scraping: Techniques, LLM-enhanced approaches, performance metrics, and legal–ethical issues.Data & Knowledge Engineering, 164:102598, 2026

  23. [31]

    No more hidden pitfalls? exposing smart contract bad practices with LLM-powered hybrid analysis.ACM Trans

    Xiaoqi Li, Zongwei Li, Wenkai Li, Yuqing Zhang, and Xin Wang. No more hidden pitfalls? exposing smart contract bad practices with LLM-powered hybrid analysis.ACM Trans. Softw. Eng. Methodol., February 2026

  24. [32]

    Di Francesco, P

    P. Di Francesco, P. Lago, and I. Malavolta. Architecting with microservices: A systematic mapping study.Journal of Systems and Software, 150:77–97, 2019

  25. [33]

    Aydos, C ¸

    M. Aydos, C ¸. Aldan, E. Cos ¸kun, and A. Soydan. Security testing of web applications: A systematic mapping of the literature.Journal of King Saud University - Computer and Information Sciences, 34(9):6775–6792, 2022

  26. [34]

    Bednarz and M

    B. Bednarz and M. Miłosz. Benchmarking the performance of Python web frameworks.Journal of Computer Sciences Institute, 36:336–341, 2025

  27. [35]

    Albesher and R

    L. Albesher and R. Alfayez. An observational study on Flask web framework questions on stack overflow (SO). IET Software, 2024(1):1905538, 2024

  28. [36]

    R. R, H. F. I, A. M, A. M. J, and D. S. Web application security testing framework using Flask. In2023 2nd International Conference on Applied Artificial Intelligence and Computing (ICAAIC), pages 1646–1652, 2023

  29. [37]

    S. Liu, H. Duan, L. Heimes, M. Bearzi, J. Vieli, D. Basin, and A. Perrig. A formal framework for end-to-end DNS resolution. InProceedings of the ACM SIGCOMM 2023 Conference, pages 932–949, 2023

  30. [38]

    Livadariu, T

    I. Livadariu, T. Dreibholz, A. S. Al-Selwi, H. Bryhni, O. Lysne, S. Bjørnstad, and A. Elmokashfi. On the accuracy of country-level IP geolocation. InProceedings of the Applied Networking Research Workshop, pages 67–73, 2020

  31. [39]

    A survey on IP geolocation

    Bin Zhu, Zhihong Tian, and Wenliang Duan. A survey on IP geolocation. In2014 IEEE Workshop on Advanced Research and Technology in Industry Applications (WARTIA), pages 1039–1041, 2014

  32. [40]

    Zolfaghari, G

    B. Zolfaghari, G. Srivastava, S. Roy, H. R. Nemati, F. Afghah, T. Koshiba, A. Razi, K. Bibak, P. Mitra, and B. K. Rai. Content delivery networks: State of the art, trends, and future roadmap.ACM Computing Surveys, 53(2):1–34, 2021

  33. [41]

    J. Wei, F. Zhu, and J. Jia. CDN-DF: A learning-based CDN domain name detection method with DNS deep feature extraction. InProceedings of the 2023 6th International Conference on Information Science and Systems, pages 119–125, 2023. 14

  34. [42]

    Ghaznavi, E

    M. Ghaznavi, E. Jalalpour, M. A. Salahuddin, R. Boutaba, D. Migault, and S. Preda. Content delivery network security: A survey.IEEE Communications Surveys & Tutorials, 23(4):2166–2190, 2021

  35. [43]

    Butler, T

    K. Butler, T. R. Farley, P. McDaniel, and J. Rexford. A survey of BGP security issues and solutions.Proceedings of the IEEE, 98(1):100–122, 2010

  36. [44]

    Dimitropoulos, D

    X. Dimitropoulos, D. Krioukov, M. Fomenkov, B. Huffaker, Y . Hyun, K. Claffy, and G. Riley. AS relationships: Inference and validation.ACM SIGCOMM Computer Communication Review, 37(1):29–40, 2007

  37. [45]

    Everson and L

    D. Everson and L. Cheng. A survey on network attack surface mapping.Digital Threats: Research and Practice, 5(2):1–25, 2024

  38. [46]

    P. McMinn. Search-based software test data generation: A survey.Software Testing, Verification and Reliability, 14(2):105–156, 2004

  39. [47]

    L. Han. Password cracking and countermeasures in computer security: A survey.arXiv, 2014. Version 3

  40. [48]

    Nie and H

    C. Nie and H. Leung. A survey of combinatorial testing.ACM Computing Surveys, 43(2):1–29, 2011

  41. [49]

    Faster or slower? performance mystery of Python idioms unveiled with empirical evidence

    Zejun Zhang, Zhenchang Xing, Xin Xia, Xiwei Xu, Liming Zhu, and Qinghua Lu. Faster or slower? performance mystery of Python idioms unveiled with empirical evidence. InProceedings of the 45th International Conference on Software Engineering (ICSE 2023), pages 1495–1507. IEEE, 2023

  42. [50]

    Sodian, J

    L. Sodian, J. P. Wen, L. Davidson, and P. Loskot. Concurrency and parallelism in speeding up I/O and CPU-bound tasks in Python 3.10. In2022 2nd International Conference on Computer Science, Electronic Information Engineering and Intelligent Control Technology (CEI), pages 560–...

  43. [51]

    Olston and M

    C. Olston and M. Najork. Web crawling.Foundations and Trends ® in Information Retrieval, 4(3):175–246, 2010

  44. [52]

    Sejfia, S

    A. Sejfia, S. Das, S. Shafiq, and N. Medvidovi´c. Toward improved deep learning-based vulnerability detection. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering, pages 1–12, 2024

  45. [53]

    Devign: Effective vulnerability identifica- tion by learning comprehensive program semantics via graph neural networks

    Yaqin Zhou, Shangqing Liu, Jingkai Siow, Xiaoning Du, and Yang Liu. Devign: Effective vulnerability identifica- tion by learning comprehensive program semantics via graph neural networks. InAdvances in Neural Information Processing Systems 32 (NeurIPS 2019), volume 32, pages 1...

  46. [54]

    J. Fan, Y . Li, S. Wang, and T. N. Nguyen. A C/C++ code vulnerability dataset with code changes and CVE summaries. InProceedings of the 17th International Conference on Mining Software Repositories, pages 508–512, 2020

  47. [55]

    SySeVR: A framework for using deep learning to detect software vulnerabilities.IEEE Transactions on Dependable and Secure Computing, 19(4):2244–2258, 2022

    Zhen Li, Deqing Zou, Shouhuai Xu, Hai Jin, Yawei Zhu, and Zhaoxuan Chen. SySeVR: A framework for using deep learning to detect software vulnerabilities.IEEE Transactions on Dependable and Secure Computing, 19(4):2244–2258, 2022

  48. [56]

    M. N. Uddin, Y . Zhang, and X. Hei. Deep learning aided software vulnerability detection: A survey.arXiv, 2025. Version 1

  49. [57]

    Zhang, F

    X. Zhang, F. Zhang, B. Zhao, B. Zhou, and B. Xiao. VulD-Transformer: Source code vulnerability detection via transformer. InProceedings of the 14th Asia-Pacific Symposium on Internetware, pages 185–193, 2023

  50. [58]

    J. Li, B. Zhao, and C. Zhang. Fuzzing: A survey.Cybersecurity, 1(1):6, 2018

  51. [59]

    P. Wang, X. Zhou, T. Yue, P. Lin, Y . Liu, and K. Lu. The progress, challenges, and perspectives of directed greybox fuzzing.Software Testing, Verification and Reliability, 34(2):e1869, 2024

  52. [60]

    V . J. M. Manes, H. Han, C. Han, S. K. Cha, M. Egele, E. J. Schwartz, and M. Woo. The art, science, and engineering of fuzzing: A survey.IEEE Transactions on Software Engineering, 47(11):2312–2331, 2021

  53. [61]

    S. Liu, W. Cui, Y . Wu, and M. Liu. A survey on information visualization: Recent advances and challenges.The Visual Computer, 30(12):1373–1393, 2014. 15

Pith tools

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