Pith. sign in

REVIEW 4 major objections 4 minor 72 references

A Risk Manager for Intrusion Tolerant Systems: Enhancing HAL 9000 with New Scoring and Data Sources

T0 review · 4 major / 4 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 This paper claims that adding continuously scraped OSINT feeds and a pulse-aware logarithmic term to HAL 9000's risk score lets an intrusion-tolerant system recommend configurations with lower computed risk than two published baseline…

desk verdict The scraper and pulse-count term are real additions, but the paper's only risk-manager comparison excludes the new sources, so the central claim rests on a single arithmetic example. read the letter →

arxiv 2508.13364 v1 pith:5ZUQ3W4A submitted 2025-08-18 cs.CR cs.LG

Tadeu Freitas , Carlos Novo , Inês Dutra , João Soares , Manuel Correia , Benham Shariati , Rolando Martins This is my paper · ORCID
classification cs.CRcs.LG
keywords intrusiontolerantsystemsriskmanagementCVSSscorepredictionOSINTscraperAlienVaultOTXEPSSCVEclusteringadaptiveconfiguration
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 claims that an intrusion-tolerant system's risk manager becomes substantially more responsive to new threats when it continuously scrapes additional public threat feeds instead of relying on NVD and ExploitDB alone. The extended HAL 9000 automatically ingests AlienVault OTX and OSV data, predicts CVSS scores for unassessed CVEs, and reassesses each vulnerability with a new score that adds $\log(\#related\_pulses)$ when a CVE appears in AlienVault pulses. In a simulated 2023 deployment across sixteen operating systems, the configurations HAL recommends have lower computed security risk and resilience risk than the two earlier risk managers on several months, while occasionally trading away some resilience for security. If correct, the contribution is a concrete route to narrowing the window between vulnerability disclosure and automated defensive action.

What carries the argument

The central object is the revised risk score in Eq. (7), a hazard formula that combines a Lazarus-style multiplicative CVSS score with EPSS probability weighting and a new logarithmic "threat attention" term. The work it does is to make the Configurator's objective function, the sums of these scores over nodes and over shared or clustered CVEs, sensitive to active discussion of a CVE in curated AlienVault pulses. Supporting machinery includes a Rust scraper that writes NVD, ExploitDB-via-searchsploit, AlienVault OTX, and OSV data into a local PostgreSQL store; a random-forest CVSS predictor for unscored CVEs; OPTICS clustering, a density-based clustering algorithm robust to outliers, applied to sentence embeddings to find descriptions that describe the same vulnerability; and the Configurator that enumerates operating-system combinations and recommends the one minimizing security and resilience risk, prioritizing resilience.

What would settle it

Take the paper's simulated 2023 dataset, recompute HAL's recommended configuration after setting the number of related pulses to zero for every CVE, and compare the resulting security and resilience scores against the two baselines; if the advantage disappears or reverses, the improvement comes entirely from the pulse term. Alternatively, correlate each CVE's pulse count with actual exploitation within 30 days, for example through EPSS or incident reports, across a large sample; a near-zero or negative correlation would undercut the assumption that the log term measures real-world risk.

Watch

Extended reading notes

Core claim

The paper's central claim is that "integrating scraper-derived intelligence with HAL 9000's risk management framework substantially improves its ability to address emerging threats," and its evidence is a head-to-head comparison of recommended configurations. In the revised scoring equation, $\mathit{hal\_score}(v) = \min(10, \mathit{score}(v)(1-\mathit{EPSS}(v)) + \mathit{score}(v)_{wp}\mathit{EPSS}(v) + \log(\#related\_pulses))$, the new last term is the load-bearing change: it raises a vulnerability's accepted risk according to how many AlienVault OTX pulses mention it. The paper illustrates with CVE-2017-11882, whose score is 3.65 under the earlier calculation, 7.2 in HAL's prior weighted formulation, and 8.9 once the 50 related pulses are counted, placing it near "Critical" despite having a patch. The experiments then show that across 2023 the configurations selected by the extended HAL carry lower security and resilience scores than the baselines in the months shown, supporting the claim that the added data source improves risk management.

Load-bearing premise

The load-bearing premise is that the number of AlienVault pulses mentioning a CVE is a reliable proxy for real-world exploitation risk; the $\log(\#related\_pulses)$ term is asserted with only a single illustrative example, and if pulse counts do not correlate with exploit likelihood, the claimed security improvement in the recommended configurations collapses.

Editorial extensions

If this is right

  • If HAL's claim holds, an ITS can ingest four public feeds automatically, so newly disclosed CVEs receive a predicted score and a reconfigured risk evaluation within hours rather than after NVD's manual analysis, which the paper notes can lag by a year.
  • A CVE with a high AlienVault pulse count can be pushed into a higher severity band even when a patch exists, giving the Configurator a reason to avoid configurations that include that software.
  • Because the Configurator optimizes the pulse-aware score, the recommended configurations can differ from those a pure CVSS-sum minimizer would choose; in the paper's April example, HAL accepts higher resilience risk to obtain lower security impact.
  • The scraper's measured runtimes and API limits suggest that periodic hourly updates are feasible, with AlienVault OTX as the bottleneck, making continuous risk reassessment practical for a deployed ITS.

Reading between the lines

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

  • The logarithmic pulse term is an untested functional form; a natural follow-up is to estimate its coefficient or replace it with a calibrated attention weight from historical exploitation data rather than fixing the increment as $\log(\#related\_pulses)$.
  • The same scraper architecture could be extended to dark-web forums, vendor advisories, and social media with a weighted "threat attention" score, but then misinformation and fake-consensus manipulation, which the paper acknowledges as future work, would become a first-order concern.
  • The paper's "more secure configurations" claim is about computed risk scores, not realized compromises; a testable implication is that deployments using HAL should show fewer successful intrusions over time than deployments using the baselines.
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

4 major / 4 minor

Summary. This paper extends HAL 9000, an intrusion-tolerant-system risk manager previously introduced by the same group, with two additions: a custom scraper that periodically harvests vulnerability and exploit data from NVD, ExploitDB, AlienVault OTX, and OSV into a local PostgreSQL database, and a revised hazard scoring formula, Eq. (7), which appends the term log(#related_pulses) to the EPSS-weighted score so that a CVE's presence in AlienVault threat pulses raises its contribution to configuration risk. The architecture consists of four components (CVSS score prediction, description-based clustering, score reassessment, and a Configurator that recommends OS configurations minimizing security_risk and resilience_risk as defined in Eqs. (8)-(9)). The experiments compare clustering/preprocessing choices by their effect on HAL's own risk calculation (Figure 4), compare HAL against the Lazarus and Heo risk managers on a simulated 2023 deployment whose dataset is explicitly limited to NVD and ExploitDB entries (Figures 5-6), compare three CVSS prediction models (Table 3), and measure scraper retrieval time and entry counts (Table 4). The abstract claims that integrating scraper-derived intelligence substantially improves HAL 9000's ability to address emerging threats.

Significance. If the headline claim were established, the paper would offer a useful, deployable pattern for ITS risk management: automated ingestion of multiple OSINT sources with a risk adjustment driven by real-world exploitation chatter. There are genuine strengths to credit: the scraper is a concrete artifact (1,268 lines of Rust, publicly hosted), the paper candidly documents API rate limits and scraping obstacles (notably ExploitDB's anti-scraping protections and OTX's hourly limits), and the CVSS prediction comparison in Table 3 is a fair replication of three published methods with reported RMSE and runtime. However, the specific extension — the pulse-count term in Eq. (7) and the new data sources — is exactly the portion that the evaluation does not exercise: Section 4.1 restricts the comparative dataset to NVD/ExploitDB and Section 4.2 scores all configurations with the Lazarus formula, so Figures 5 and 6 cannot show any effect of the paper's contribution, and the only quantitative support for Eq. (7) is a single arithmetic example. As an engineering description of an OSINT scraper the paper is informative; as a validation of a new risk-scoring mechanism it is not.

major comments (4)
  1. [§4.1, §4.2, Figs. 5–6] The paper's central claim — that integrating scraper-derived intelligence 'substantially improves' HAL's risk management — is not tested by the reported experiments. Section 4.1 explicitly limits the comparative dataset to NVD and ExploitDB 'to ensure a fair comparison', so AlienVault pulse counts and OSV records are absent, and the log(#related_pulses) term in Eq. (7) is identically zero in the only Risk Manager evaluation. Section 4.2 further states that 'both graphs use the Lazarus calculation method for the scores presented', so even HAL's own Eq. (7) score is not the quantity plotted. The improvements visible in Figures 5 and 6 therefore reflect the clustering and configuration-selection machinery inherited from prior work, not the new data sources or the new scoring term, and the abstract's claim rests solely on the CVE-2017-11882 example, where the score rises from 7.2 to 8.9 by arithmetic. An evaluation in which the new sources are actually present, and in which the contribution of the pulse term is isolated (e.g., with vs. without Eq. 7), is required to support the central claim.
  2. [Eq. (7), §3] The new scoring term log(#related_pulses) is introduced without derivation, calibration, or validation. The paper gives no evidence that a CVE's count of AlienVault pulses correlates with exploitation likelihood, and no normalization anchors the dimensionless pulse count against the weighted CVSS product in Eq. (6); the logarithm base is unspecified (the CVE-2017-11882 example, 7.2 + log(50) = 8.9, implies base 10), and the behavior at #related_pulses = 0 is undefined since log(0) is undefined — a case that necessarily arises in the Section 4.1 dataset, which contains no pulse data at all. With the cap of 10, the term can saturate the score entirely: for the example's pre-pulse value of 7.2, a base-10 log reaches the cap at roughly 630 pulses, allowing chatter volume to dominate the hazard estimate. The single illustrative example cannot validate the formula.
  3. [Figure 4, §4.2] The selection of OPTICS with sentence embeddings is circular with respect to the paper's performance claim. Figure 4 evaluates clustering algorithms by their 'subsequent effects on the HAL risk calculation (lower is better)', and the text concludes that OPTICS and DBSCAN are best because they 'provide the lowest risk scores' under HAL's own formula — the same formula that the Configurator in Eqs. (8)–(9) optimizes. An algorithm that depresses the system's objective function is therefore guaranteed to make the system look good in the downstream comparison of Figures 5–6, where configurations are chosen by that very objective. No external clustering-quality measure (e.g., entropy, homogeneity, or adjusted Rand index against a ground truth) and no independent validation of the recommended configurations is reported, so the conclusion in Section 5 that HAL's clustering 'yields better groupings than prior approaches' is unsupported.
  4. [Tables 1–2, Table 4] The generated dataset raises reliability concerns. Table 1 lists 'Ubuntu 16.04 / 2,035' twice, and identical CVE counts appear across many OS versions (Debian 6, 7, 8 and 10 all at 3,923; Ubuntu 10.04 through 22.04 all at 2,035; Fedora 16, 24, 30 and 38 all at 835; Solaris 10 and 11 both at 359), which suggests the generator assigns counts per OS family rather than per version; because Figures 5–6 are computed entirely from this dataset, per-version granularity matters for the validity of the comparison. Additionally, Table 4 reports exactly the same #Entries value (277,152) for NVD and AlienVault OTX, which is implausible and appears to be a copy error. The authors should document the generator's assignment logic and correct Table 4.
minor comments (4)
  1. [§3, Eqs. (4)–(7)] The cross-references to equations are inconsistent: Section 3 says the hal_score(v) is 'presented in equation 4' and 'as shown in equation6', but the displayed hal_score equations are numbered (6) and (7), while Eq. (4) is the second patched(v) formula from Section 2.1; Section 3.1 step 3 refers to 'equations 1 to 6', which does not match the displayed numbering (5)–(7). These references should be corrected.
  2. [§2.1, Eq. (4)] Equation (4) is labeled patched(v) = 1.25^v.exploited, but the right-hand side depends on v.exploited and not on v.patched; it should be the exploited(v) factor consistent with the product in Eq. (1). The label appears to be a typo that makes the scoring system hard to follow.
  3. [§4.2, resilience score] The prose describes the resilience score as 'the multiplication between the reassessed CVSS score of the common CVEs and respective EPSS score', but Eq. (9) sums hal_score(v), which already embeds the EPSS weighting inside hal_score; the descriptive text and the equation should be reconciled.
  4. [Section 5, Conclusion] The conclusion states that HAL is 'demonstrably superior to traditional systems in terms of automation, accuracy, and adaptability' and that experimental results 'demonstrate that HAL's clustering of CVEs yields better groupings than prior approaches'; these statements outrun the evidence in Section 4, where no accuracy metric for clustering against a ground truth and no test of the pulse term are reported.

Circularity Check

2 steps flagged · score 4.0 of 10

Partial circularity: the clustering algorithm is chosen by the same HAL risk score that the Configurator minimizes, and the claimed benefit of the new scraper sources is never tested because the risk-manager dataset excludes OTX/OSV data.

  1. other [Section 4.2, clustering experiment (Figure 4), versus Section 3.1, equations (8)-(9)]
    "Regarding the clustering algorithms, it was noticed that OPTICS and DBSCAN provide the lowest risk scores. Both algorithms are insensitive to outliers and designed to be scalable, addressing the limitations of the K-means algorithm. As such, considering these results, HAL utilizes sentence embeddings for preprocessing data and OPTICS for data clusterization."

    The 'risk scores' used to choose the clustering algorithm are HAL's own hal_score-based quantities; the Configurator then minimizes exactly those quantities in equations (8) and (9). Selecting OPTICS because it minimizes this self-defined objective, and later presenting the resulting configurations as 'better groupings' or 'more secure,' is partly true by construction: the algorithm was fitted to the same objective function that the Configurator optimizes. The comparison in Figures 5-6 uses Lazarus's scoring method, so the headline benchmark retains some independence, but the architecture-level justification for the clustering choice is circular.

  2. self definitional [Section 3, equations (6)-(7), CVE-2017-11882 example]
    "With the proposed extension in the current work, the recalculated score rises to 8.9, placing it on the borderline of the "Critical" category. This adjustment more accurately reflects the actual risk posed by CVE-2017-11882, highlighting the urgency of its mitigation."

    The increase from 7.2 to 8.9 is the definitional effect of adding log(#related_pulses) in equation (7): log(50) is about 1.7, so the score rises by construction. Calling this 'more accurately reflects the actual risk' restates the formula rather than testing it, because no external criterion, such as observed exploitation or incident data, is used to validate that pulse counts improve risk prediction. Since the risk-manager evaluation dataset excludes OTX pulses, this arithmetic example is the only exhibited support for the new term.

full rationale

The paper has independent content in the CVSS-prediction benchmark (Table 3) and in the configuration comparison that uses Lazarus's scoring formula, which is not identical to HAL's own objective. That prevents the whole contribution from reducing to self-evaluation. However, the clustering algorithm selection is circular in a specific, quotable way: OPTICS and DBSCAN were chosen because they produce the lowest values of HAL's own risk calculation, and the Configurator optimizes the same family of risk scores in equations (8) and (9). Additionally, the paper's central novelty, scraper-derived intelligence from AlienVault OTX and OSV, is absent from the risk-manager experiments. Section 4.1 explicitly limits the dataset to NVD and ExploitDB, so log(#related_pulses) is identically zero in Figures 5 and 6, and the only quantitative support for the new scoring term is the CVE-2017-11882 example, whose score increase is a direct arithmetic consequence of equation (7). This is a serious evidence gap and a partial circularity, not a full one, because the main across-manager comparison is scored with Lazarus's method and is not reduced to HAL's own formula by construction.

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

The central claim rests on the hand-chosen log-pulse term, the assumed validity of EPSS and pulse data, and the representativeness of a dataset that excludes the new scraped sources. No new physical or conceptual entities are introduced; the risk modifiers are modeling choices rather than fitted parameters.

free parameters (2)
  • Pulse count weight coefficient = 1
    In Eq. 7, the log(#related_pulses) term is added with implicit coefficient 1; no fitting or external calibration is provided.
  • Risk score cap = 10
    The min(10, ...) saturation cap in Eq. 7 is a modeling choice that determines when the pulse bonus stops affecting the score.
assumptions (5)
  • domain assumption CVE description similarity implies likely shared exploitability across replicas
    Adopted from Lazarus (Section 2.1) and used in the resilience risk (Eq. 9); if false, clustering-based penalties misestimate risk.
  • domain assumption EPSS probability is a valid predictor of 30-day exploitation likelihood
    Used in Eqs. 6 and 7 to weight patched and unpatched scenarios; EPSS is external but its validity is assumed without re-validation.
  • domain assumption AlienVault OTX pulses are timely, accurate signals of active exploitation
    Pulses are user-generated content; the paper does not assess their quality, and Section 5 flags misinformation as an open problem.
  • ad hoc to paper The NVD/ExploitDB-only simulated dataset is representative for evaluating configuration risk
    Section 4.1 limits the dataset to sources used by baseline risk managers, which excludes the new scraped sources that the central claim depends on.
  • ad hoc to paper log(pulse count) is a valid monotonic risk adjustment
    Introduced in Eq. 7 without derivation; the only support is the CVE-2017-11882 arithmetic example.

how reviews work

0 comments
Cite this review

Pith. "Pith review of A Risk Manager for Intrusion Tolerant Systems: Enhancing HAL 9000 with New Scoring and Data Sources." pith.science (2026). https://pith.science/paper/5ZUQ3W4A

@misc{pith2026250813364,
  author       = {Pith},
  title        = {Pith review of: A Risk Manager for Intrusion Tolerant Systems: Enhancing HAL 9000 with New Scoring and Data Sources},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/5ZUQ3W4A}},
  note         = {Machine review of arXiv:2508.13364}
}
read the original abstract

Intrusion Tolerant Systems (ITSs) have become increasingly critical due to the rise of multi-domain adversaries exploiting diverse attack surfaces. ITS architectures aim to tolerate intrusions, ensuring system compromise is prevented or mitigated even with adversary presence. Existing ITS solutions often employ Risk Managers leveraging public security intelligence to adjust system defenses dynamically against emerging threats. However, these approaches rely heavily on databases like NVD and ExploitDB, which require manual analysis for newly discovered vulnerabilities. This dependency limits the system's responsiveness to rapidly evolving threats. HAL 9000, an ITS Risk Manager introduced in our prior work, addressed these challenges through machine learning. By analyzing descriptions of known vulnerabilities, HAL 9000 predicts and assesses new vulnerabilities automatically. To calculate the risk of a system, it also incorporates the Exploitability Probability Scoring system to estimate the likelihood of exploitation within 30 days, enhancing proactive defense capabilities. Despite its success, HAL 9000's reliance on NVD and ExploitDB knowledge is a limitation, considering the availability of other sources of information. This extended work introduces a custom-built scraper that continuously mines diverse threat sources, including security advisories, research forums, and real-time exploit proofs-of-concept. This significantly expands HAL 9000's intelligence base, enabling earlier detection and assessment of unverified vulnerabilities. Our evaluation demonstrates that integrating scraper-derived intelligence with HAL 9000's risk management framework substantially improves its ability to address emerging threats. This paper details the scraper's integration into the architecture, its role in providing additional information on new threats, and the effects on HAL 9000's management.

Review history (2 revisions) →

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

72 extracted references · 70 canonical work pages

  1. [1]

    Zero Trust Architecture vs Traditional Security Models: A Comparative Analysis.; n.d

    TechDirect . Zero Trust Architecture vs Traditional Security Models: A Comparative Analysis.; n.d. Accessed: 2024-12-27

    work page 2024

  2. [2]

    Expected Cost of Cybercrime Worldwide until 2027

    Statista . Expected Cost of Cybercrime Worldwide until 2027. https://www.statista.com/chart/28878/expected-cost-of-cybercrime-until-2027/; n.d. Accessed: 2024-12-27

    work page 2027

  3. [3]

    [Online; accessed 07-February-2023]

    Accellion File Transfer Appliance Hack. https://www.cnn.com/2022/01/25/tech/accellion-file-transfer-appliance-hack-explained/index.html; 2022. "[Online; accessed 07-February-2023]"

    work page 2022

  4. [4]

    [Online; accessed 07-February- 2023]

    Garmin Data Breach. https://www.cnn.com/2022/07/27/tech/garmin-data-breach-explained/index.htm; 2022. "[Online; accessed 07-February- 2023]"

    work page 2022

  5. [5]

    [Online; accessed 07-February- 2023]

    Cloudflare Data Leak. https://www.cnn.com/2022/02/24/tech/cloudflare-data-leak-explained/index.html; 2022. "[Online; accessed 07-February- 2023]"

    work page 2022

  6. [6]

    [Online; accessed 07-February-2023]

    Microsoft Exchange Server Hacks. https://www.cnn.com/2021/03/03/tech/microsoft-exchange-server-hack-explained/index.html; 2021. "[Online; accessed 07-February-2023]"

    work page 2021

  7. [7]

    The CRUTIAL way of critical infrastructure protection

    Bessani AN, Sousa P, Correia M, Neves NF, Verissimo P. The CRUTIAL way of critical infrastructure protection. IEEE Security & Privacy. 2008;6(6):44–51

    work page 2008

  8. [8]

    Lazarus: Automatic management of diversity in bft systems

    Garcia M, Bessani A, Neves N. Lazarus: Automatic management of diversity in bft systems. In: 2019:241–254

    work page 2019

Show all 72 references
  1. [9]

    Diverse Replication for {Single-Machine}{Byzantine-Fault} Tolerance

    Chun BG, Maniatis P, Shenker S. Diverse Replication for {Single-Machine}{Byzantine-Fault} Tolerance. In: 2008

    2008

  2. [10]

    SPARE: Replicas on Hold

    Distler T, Popov I, Schröder-Preikschat W, Reiser HP, Kapitza R. SPARE: Replicas on Hold.. In: 2011

    2011

  3. [11]

    Estimating impact and frequency of risks to safety and mission critical systems using CVSS

    Houmb SH, Franqueira VNL, Engum EA. Estimating impact and frequency of risks to safety and mission critical systems using CVSS. 2008

    2008

  4. [12]

    Follow the blue bird: A study on threat data published on twitter

    Alves F, Andongabo A, Gashi I, Ferreira PM, Bessani A. Follow the blue bird: A study on threat data published on twitter. In: Springer. 2020:217–236

    2020

  5. [13]

    Designing and implementing a diversity policy for intrusion-tolerant systems

    Heo S, Lee S, Jang B, Yoon H. Designing and implementing a diversity policy for intrusion-tolerant systems. IEICE TRANSACTIONS on Information and Systems. 2017;100(1):118–129

    2017

  6. [14]

    OS diversity for intrusion tolerance: Myth or reality?

    Garcia M, Bessani A, Gashi I, Neves N, Obelheiro R. OS diversity for intrusion tolerance: Myth or reality?. In: IEEE. 2011:383–394

    2011

  7. [15]

    A look at the time delays in CVSS vulnerability scoring

    Ruohonen J. A look at the time delays in CVSS vulnerability scoring. Applied Computing and Informatics. 2019;15(2):129–135

    2019

  8. [16]

    https://nvd.nist.gov/general/cve-process

    CVEs and the NVD Process. https://nvd.nist.gov/general/cve-process; . Accessed: 2024-02-09

    2024

  9. [17]

    [Online; accessed 15-April-2024]

    Hendery S. NIST’s backlog of vulnerability analysis blamed on lack of support. https://www.scmagazine.com/news/ nists-backlog-of-vulnerability-analysis-blamed-on-lack-of-support; 2024. "[Online; accessed 15-April-2024]"

    2024

  10. [18]

    Skynet: a Cyber-Aware Intrusion Tolerant Overseer

    Freitas T, Soares J, Correia ME, Martins R. Skynet: a Cyber-Aware Intrusion Tolerant Overseer. In: 2023:111–116

    2023

  11. [19]

    Distributed SDN control: Survey, taxonomy, and challenges

    Bannour F, Souihi S, Mellouk A. Distributed SDN control: Survey, taxonomy, and challenges. IEEE Communications Surveys & Tutorials. 2017;20(1):333–354

    2017

  12. [20]

    Database security-attacks and control methods

    Malik M, Patel T. Database security-attacks and control methods. International Journal of Information. 2016;6(1/2):175–183

    2016

  13. [21]

    Data poisoning attacks against machine learning algorithms.Expert Systems with Applications

    Yerlikaya FA, Bahtiyar ¸ S. Data poisoning attacks against machine learning algorithms.Expert Systems with Applications. 2022;208:118101

    2022

  14. [22]

    A Survey on Data Clustering

    Singhal G, Roy S. A Survey on Data Clustering. International Journal of Advanced Engineering and Management. 2017;2(8):183–188

    2017

  15. [23]

    A brief survey of text mining.Journal for Language Technology and Computational Linguistics.2005;20(1):19–62

    Hotho A, Nürnberger A, Paaß G. A brief survey of text mining.Journal for Language Technology and Computational Linguistics.2005;20(1):19–62

    2005

  16. [24]

    Analysis and study of K-means clustering algorithm

    Singh S, Gill NS. Analysis and study of K-means clustering algorithm. Int. J. Eng. Res. Technol.2013;2(7):2546–2551

    2013

  17. [25]

    An automatic method for CVSS score prediction using vulnerabilities description.Journal of Intelligent & Fuzzy Systems

    Khazaei A, Ghasemzadeh M, Derhami V . An automatic method for CVSS score prediction using vulnerabilities description.Journal of Intelligent & Fuzzy Systems. 2016;30(1):89–96

    2016

  18. [26]

    A conceptual replication on predicting the severity of software vulnerabilities

    Sahin SE, Tosun A. A conceptual replication on predicting the severity of software vulnerabilities. In: 2019:244–250

    2019

  19. [27]

    Learning to predict severity of software vulnerability using only vulnerability description

    Han Z, Li X, Xing Z, Liu H, Feng Z. Learning to predict severity of software vulnerability using only vulnerability description. In: 2017:125–136

    2017

  20. [28]

    Efficient estimation of word representations in vector space

    Mikolov T, Chen K, Corrado G, Dean J. Efficient estimation of word representations in vector space. arXiv preprint arXiv:1301.3781. 2013

    2013 arXiv

  21. [29]

    Fighting N-day vulnerabilities with automated CVSS vector prediction at disclosure

    Elbaz C, Rilling L, Morin C. Fighting N-day vulnerabilities with automated CVSS vector prediction at disclosure. In: 2020:1–10

    2020

  22. [30]

    Predicting cvss metric via description interpretation

    Costa JC, Roxo T, Sequeiros JB, Proenca H, Inacio PR. Predicting cvss metric via description interpretation. IEEE Access. 2022;10:59125–59134. A Risk Manager for Intrusion Tolerant Systems: Enhancing HAL 9000 with New Scoring and Data Sources 19

    2022

  23. [31]

    DistilBERT, a distilled version of BERT: smaller, faster, cheaper and lighter.arXiv preprint arXiv:1910.01108

    Sanh V , Debut L, Chaumond J, Wolf T. DistilBERT, a distilled version of BERT: smaller, faster, cheaper and lighter.arXiv preprint arXiv:1910.01108. 2019

    1910 arXiv

  24. [32]

    VulDistilBERT: A CPS Vulnerability Severity Prediction Method Based on Distillation Model

    Kai S, Shi F, Zheng J, others . VulDistilBERT: A CPS Vulnerability Severity Prediction Method Based on Distillation Model. Security and Communication Networks. 2023;2023

    2023

  25. [33]

    Information retrieval

    Rijsbergen Cv. Information retrieval. Butterworth-Heinemann, 1979

    1979

  26. [34]

    Information retrieval systems: theory and implementation

    Kowalski GJ. Information retrieval systems: theory and implementation. 1. springer, 2007

    2007

  27. [35]

    Optimization of inverted vector searches

    Buckley C, Lewit AF. Optimization of inverted vector searches. In: 1985:97–110

    1985

  28. [36]

    Scatter/gather: A cluster-based approach to browsing large document collections

    Cutting DR, Karger DR, Pedersen JO, Tukey JW. Scatter/gather: A cluster-based approach to browsing large document collections. In: . 51. 2017:148–159

    2017

  29. [37]

    Fast and intuitive clustering of Web documents

    Zamir O, Etzioni O, Madani O, Karp RM. Fast and intuitive clustering of Web documents.. In: . 97. 1997:287–290

    1997

  30. [38]

    A comparison of document clustering techniques

    Steinbach M, Karypis G, Kumar V . A comparison of document clustering techniques. 2000

    2000

  31. [39]

    Comparison of Agglomerative and Partitional Document Clustering Algorithms

    Zhao Y , Karypis G. Comparison of Agglomerative and Partitional Document Clustering Algorithms. 2002

    2002

  32. [40]

    Fast and effective text mining using linear-time document clustering

    Larsen B, Aone C. Fast and effective text mining using linear-time document clustering. In: 1999:16–22

    1999

  33. [41]

    Document clustering using k-means, heuristic k-means and fuzzy c-means

    Singh VK, Tiwari N, Garg S. Document clustering using k-means, heuristic k-means and fuzzy c-means. In: 2011:297–301

    2011

  34. [42]

    On Clustering Algorithms: Applications in Word-Embedding Documents

    Mendonça I, Trouvé A, Fukuda A, et al. On Clustering Algorithms: Applications in Word-Embedding Documents.. J. Comput.. 2019;14(2):88–92

    2019

  35. [43]

    Clustering algorithms

    Hartigan JA. Clustering algorithms. John Wiley & Sons, Inc., 1975

    1975

  36. [44]

    Document clustering with cluster refinement and model selection capabilities

    Liu X, Gong Y , Xu W, Zhu S. Document clustering with cluster refinement and model selection capabilities. In: 2002:191–198

    2002

  37. [45]

    Normalized cuts and image segmentation

    Shi J, Malik J. Normalized cuts and image segmentation. IEEE Transactions on pattern analysis and machine intelligence. 2000;22(8):888–905

    2000

  38. [46]

    Mean shift: A robust approach toward feature space analysis.IEEE Transactions on pattern analysis and machine intelligence

    Comaniciu D, Meer P. Mean shift: A robust approach toward feature space analysis.IEEE Transactions on pattern analysis and machine intelligence. 2002;24(5):603–619

    2002

  39. [47]

    A density-based algorithm for discovering clusters in large spatial databases with noise

    Ester M, Kriegel HP, Sander J, Xu X, others . A density-based algorithm for discovering clusters in large spatial databases with noise. In: . 96. 1996:226–231

    1996

  40. [48]

    Improving the performance of HDBSCAN on short text clustering by using word embedding and UMAP

    Asyaky MS, Mandala R. Improving the performance of HDBSCAN on short text clustering by using word embedding and UMAP. In: 2021:1–6

    2021

  41. [49]

    Accelerated hierarchical density based clustering

    McInnes L, Healy J. Accelerated hierarchical density based clustering. In: 2017:33–42

    2017

  42. [50]

    Comparing clusterings: an overview

    Wagner S, Wagner D. Comparing clusterings: an overview. 2007

    2007

  43. [51]

    ScrapeIOC: Designing a Web-scraping Tool for Malware Detection based on Indicators of Compromise

    Fernandes KCP, Jonker SL, Meng W, Lampe B. ScrapeIOC: Designing a Web-scraping Tool for Malware Detection based on Indicators of Compromise. In: IEEE. 2023:124–128

    2023

  44. [52]

    Processing tweets for cybersecurity threat awareness

    Alves F, Bettini A, Ferreira PM, Bessani A. Processing tweets for cybersecurity threat awareness. Information Systems. 2021;95:101586

    2021

  45. [53]

    Common vulnerability scoring system prediction based on open source intelligence information sources.Computers & Security

    Kuehn P, Relke DN, Reuter C. Common vulnerability scoring system prediction based on open source intelligence information sources.Computers & Security. 2023;131:103286

    2023

  46. [54]

    The not yet exploited goldmine of OSINT: Opportunities, open challenges and future trends

    Pastor-Galindo J, Nespoli P, Mármol FG, Pérez GM. The not yet exploited goldmine of OSINT: Opportunities, open challenges and future trends. IEEE Access. 2020;8:10282–10304

    2020

  47. [55]

    https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator

    Common Vulnerability Scoring System Calculator. https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator; . Accessed: 2024-04-08

    2024

  48. [56]

    Optimal detection of changepoints with a linear computational cost

    Killick R, Fearnhead P, Eckley IA. Optimal detection of changepoints with a linear computational cost. Journal of the American Statistical Association. 2012;107(500):1590–1598

    2012

  49. [57]

    Scikit-learn: Machine Learning in Python.Journal of Machine Learning Research

    Pedregosa F, Varoquaux G, Gramfort A, et al. Scikit-learn: Machine Learning in Python.Journal of Machine Learning Research. 2011;12:2825– 2830

    2011

  50. [58]

    [Online; accessed 07-April-2024]

    Adam S. Unpatched Vulnerabilities: The Most Brutal Ransomware Attack Vector. https://news.sophos.com/en-us/2024/04/03/ unpatched-vulnerabilities-the-most-brutal-ransomware-attack-vector/; 2024. "[Online; accessed 07-April-2024]"

    2024

  51. [59]

    Exploit prediction scoring system (epss)

    Jacobs J, Romanosky S, Edwards B, Adjerid I, Roytman M. Exploit prediction scoring system (epss). Digital Threats: Research and Practice. 2021;2(3):1–17

    2021

  52. [60]

    https://www.first.org/cvss/specification-document

    Common Vulnerability Scoring System version 4.0: Specification Document. https://www.first.org/cvss/specification-document; . Accessed: 2024-06-29

    2024

  53. [61]

    https://www.exploit-db.com/searchsploit

    Exploit Database SearchSploit Manual. https://www.exploit-db.com/searchsploit; . Accessed: 2024-04-14. 20 FREITAS ET AL

    2024

  54. [62]

    The national vulnerability database (nvd): Overview

    Booth H, Rike D, Witte GA, others . The national vulnerability database (nvd): Overview. 2013

    2013

  55. [63]

    https://www.exploit-db.com/

    Exploit Database. https://www.exploit-db.com/; . Accessed: 2024-04-14

    2024

  56. [64]

    https://otx.alienvault.com

    AlienVault Open Threat Exchange. https://otx.alienvault.com; . Accessed: 2024-04-14

    2024

  57. [65]

    OSV - Open Source Vulnerabilities.; 2025

    Vulnerabilities OS. OSV - Open Source Vulnerabilities.; 2025. Accessed: 2025-01-14

    2025

  58. [66]

    https://nvd.nist.gov/developers/start-here

    NVD Developers. https://nvd.nist.gov/developers/start-here; . Accessed: 2024-04-15

    2024

  59. [67]

    https://nvd.nist.gov/developers/vulnerabilities

    NVD Vulnerabilities API. https://nvd.nist.gov/developers/vulnerabilities; . Accessed: 2024-04-15

    2024

  60. [68]

    vex_hk.; 2023

    SecureSolutionsLab . vex_hk.; 2023

    2023

  61. [69]

    Common vulnerability scoring system

    Mell P, Scarfone K, Romanosky S. Common vulnerability scoring system. IEEE Security & Privacy. 2006;4(6):85–89

    2006

  62. [70]

    SITAR: A scalable intrusion-tolerant architecture for distributed services

    Wang F, Gong F, Sargor C, Goseva-Popstojanova K, Trivedi K, Jou F. SITAR: A scalable intrusion-tolerant architecture for distributed services. In: . 1. 2003:1100

    2003

  63. [71]

    Securing web servers using self cleansing intrusion tolerance (SCIT)

    Bangalore AK, Sood AK. Securing web servers using self cleansing intrusion tolerance (SCIT). In: 2009:60–65

    2009

  64. [72]

    The design of a generic intrusion-tolerant architecture for web servers.IEEE Transactions on dependable and secure computing

    Saidane A, Nicomette V , Deswarte Y . The design of a generic intrusion-tolerant architecture for web servers.IEEE Transactions on dependable and secure computing. 2008;6(1):45–58

    2008

Pith tools

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