dataesr/scientific-paragraphs-categorization huggingface dataset:
These fix commits represent the main input to our approach, and its implementation, Eclipse Steady, requires the maintenance of a knowledge-base with triples each comprising a vulnerability identifier, a URL of the versioning control system of the vulnerable open source project and the identifiers of fix commits (cf. Sections 5 and 6. 2. 3). Steady automatically processes those fix commits in order to determine all changed constructs and the AST (c) f and AST (c) v , so that this information is available when analyzing concrete applications and the libraries they depend upon (directly or transitively). Differently from proprietary vulnerability databases, mentioned in Section 1, our knowledge-base is open source. Furthermore, identifying (typically few) fix commits is less expensive and errorprone than identifying all the library versions affected by a given open source vulnerability, especially because of a popular technique called re-bundling, where code from one open source library is copied into other libraries distributed with different identifiers.
Goals of the Study This section presents a study of the effectiveness of our approach when used to detect vulnerabilities in open source dependencies of real-world enterprise applications. An open source implementation of the approach presented in this paper for the analysis of Java and Python applications is available on GitHub at https://github. com/eclipse/steady. The tool was first developed at SAP and has been released as open source in 2018. At the time of writing, the tool became an incubator project of the Eclipse Foundation under the name Eclipse Steady. This study compares the results produced by Steady with those of OWASP DC in term of findings, i. e. , vulnerabilities reported for a dependency of a project (or project module in case of multi-module projects). We selected OWASP DC, because it is an established open source tool for the detection of OSS vulnerabilities in Java projects, developed since 2012 and a mature flagship project of the OWASP foundation.
Steady on the other hand uses its own vulnerability knowledge-base (whose content is also released under the same license as the tool, Apache v. 2. 0) that we actively maintain since 2014. Essentially, the Steady knowledge-base contains, for each vulnerability, the Fig. 16  Excerpt from the Steady knowledge-base identifiers (i. e. , repository URL and commit hash) of the commits that fix it, as shown in the excerpt in Fig. 16. The knowledge-base is described in further detail in  Ponta et al. (2019) , and is available for download at https://github. com/SAP/vulnerability-assessment-kb. For this study, we used a more recent (thus larger) snapshot, than the one described in  Ponta et al. (2019) , covering 813 vulnerabilities (May 2019).
Retrieval of project data and setup of automated scans Using a set of Python scripts we retrieve the projects and we prepare them for the analysis. A first script is used to clone all repositories. A second script modifies the pom. xml files by removing the name tag (if present) to ensure that both Steady and OWASP DC report the findings referring to the projects by their artifactId. 30 A third python script generates (in the root folder of every project) two bash files containing the commands that are necessary to run the vulnerability detection with either tool. Steady was run using its Maven plugin, which offers the goal vulas:app 31 to retrieve all information about the application and its dependencies, and the goal vulas:report to generate a report containing the detected vulnerable dependencies (i.
e, vulnerabilities whose code is included in application dependencies). The commands for Steady are as follows: mvn -fn com. sap. research. security. vulas:plugin-maven:3. 0. 16:app mvn -fn com. sap. research. security. vulas:plugin-maven:3. 0. 16: report The -fn flag forces Maven to build each project module, even in case a build failure occurs for one of them. Further information on how to run Steady can be found at https://eclipse. github. io/steady/. Note that the vulas:report goal of Steady must be run separately, once the vulas:app goal has been executed for all the modules in the case of multi-module projects, in order to aggregate the results for the entire project. OWASP DC also offers a Maven plugin and the analysis was run using a goal (aggregate) that runs the analysis and generates the report.
A dedicated configuration was used to include findings for dependencies declared in scope TEST as follows mvn -fn -Dformat=ALL -DassemblyAnalyzerEnabled=false -DskipProvidedScope=false -DskipRuntimeScope=false -DskipSystemScope=false -DskipTestScope=false org. owasp:dependency-check-maven:5. 0. 0-M2:aggregate Note that both tools produce a single report for multi-module projects. Collection and post-processing of findings Both Steady and OWASP DC produce reports in several formats. For gathering the results we used the JSON format for both tools. We collected the reports and processed them with help of a Jupyter notebook 32  that parses the reports, retrieves all the findings and gathers them in a data structure containing the following information: -the name of the GitHub repository hosting the project under analysis; -the artifactId of the affected project or module in the case of multi-module projects; -the library dependency for which the finding was reported; -the vulnerability identifier; -the information whether Steady reported the finding; -the information whether OWASP DC reported the finding; -the CPE identifiers that OWASP DC used to associate the vulnerability to the dependency; -the source for the vulnerabilities reported by OWASP DC (either the National Vulnerability Database (NVD) or RETIRE.
JS were found in our study), -the information whether Steady threw an error during the analysis; -the information whether OWASP DC threw an error during the analysis. As the study targets Java, we then filtered out the OWASP DC findings for source RETIRE. JS that provides JavaScript vulnerabilities, and obtained a set of 27769 findings. Finally, we enriched the dataset with the following additional information: -whether the vulnerability is available in the NVD, and -whether the vulnerability has vulnerable constructs (rather than only involving configuration changes).
Category O C (Vulnerabilities with construct changes, found only by OWASP DC) The manual review showed that 3 out of 30 findings are true positives as OWASP DC correctly identifies that vulnerable libraries where re-bundled in another one. Steady was not able to report those findings as the signature of the vulnerable construct was altered while being rebundled (i. e. , a new Java package name-space was created by concatenating the one of the outer and the one of the re-bundled library). The remaining 27 findings are false positives as the vulnerability does not affect the application dependency but another Java archive built from the same library project. This commonly happens when open source projects release a set of Java archives (with disjoint constructs), and when applications can depend on a subset of those, according to the required functionalities.
As an example, according to the NVD description and to the advisory page https://pivotal. io/security/cve-2018-11040, CVE-2018-11040 applies to the part of the Spring Framework responsible for the handling of requests via JSONP; however OWASP DC reports it for dependency spring-expression-4. 3. 16. RELEASE. jar, which does not contain any related functionality or code. Category S NC (Vulnerabilities without construct changes, found only by Steady) Manual review showed that all 27 findings of Steady are true positives. To the best of our knowledge, OWASP DC did not detect them because -17 findings are for vulnerabilities affecting library artifacts bundled in a WAR dependency; -3 findings are for vulnerabilities that are not available in the NVD; -4 findings most likely are for dependencies whose metadata are too far from the affected products listed by the NVD; -3 findings are reported for dependencies that are not listed by OWASP DC (considering all application dependencies).
Considering the conclusions manually reviewed, across all detection criteria, we observe that they concluded correctly in 97. 5% of the cases. However, when compared to the other criteria, the minor release criterion yields a relatively high-number of wrong assessments, roughly 20%, even though the criterion only considers versions having the same MAJOR. MINOR. All of those correspond to false positives, because a library version is wrongly assessed as being vulnerable. This observation relates to the question with which version a given vulnerability has been introduced, which is out of scope of the proposed approach. Nguyen et al. (2016)  investigate this problem, and question the common approach of vulnerability databases such as the NVD to highlight all previous versions as being vulnerable, even those having smaller MAJOR or MINOR versions.
We observed that in this phase, the resistance to updates (especially, to minor releases) is quite low, and developers tend to update their open source dependencies in a short timeframe. Deeper analysis of the vulnerability becomes more and more critical the closer the project gets to the date of release to customers, and stays so throughout the operational lifetime of the application because new vulnerabilities impacting the application could be discovered at any point in time after the release. After the release date, Steady is used mostly in manual scans, as a program comprehension tool, to achieve a deeper understanding of whether and how vulnerable code is reachable in a target application, what its concrete impact is, and what remediation options are available. We observed, for instance, that users run several iterations of dynamic and static scans (using the collected execution traces as entry points for the call graph construction), whereby they observe and step-wise increase the test coverage throughout those iterations.
Decision-support vs. Decision-making Steady is essentially a fact-finding tool, whose goal is to provide comprehensive evidence that vulnerable code is included and reachable in a given application. Clearly, it cannot prove (decide) whether vulnerable code can or cannot be exploited. However, we occasionally observe this expectation, particularly when library updates are difficult and expensive. Again, security training and awareness campaigns are essential to ensure that developers internalize that they are responsible for drawing the final conclusion in regards to the exploitability of each vulnerability, especially before deciding to stick to a vulnerable version of an open source dependency. Also, while such conclusions and the decision to upgrade (or not) a library have to be documented, we decided to keep this functionality out of the scope of Steady and to stick to its fact-finding mission.
Vulnerability knowledge-base The creation and maintenance of a comprehensive vulnerability database is key for our approach. However, the required vulnerability information is scattered across many different sources, e. g. , public vulnerability databases, issue trackers and security advisories of individual projects, or source code repositories. Moreover, as discussed in  Plate et al. (2015)  and  Alqahtani et al. (2016) , different sources like the National Vulnerability Database and code repositories are difficult to integrate using the existing data. Based on a study that we performed on the NVD, we estimate our knowledge-base  (Ponta et al. 2019 ) to cover about 90% of all vulnerabilities affecting Java open source projects and that are part of the NVD, which is consistent with the outcome of the review of all CVEs originating the findings of category O NOKB in Section 5.
(2015)  to create a vulnerability alert service and to perform an empirical investigation about the usage of vulnerable components in proprietary software. The results showed that 54 out of 75 of the projects analyzed have at least one vulnerable library. However the results had to be manually reviewed, as the matching of vulnerabilities to libraries showed low precision. Alqahtani et al. proposed an ontology-based approach to establish a link between vulnerability databases and software repositories  (Alqahtani et al. 2016). The mapping resulting from their approach yields a 38 https://www. whitesourcesoftware. com/oss security vulnerabilities/ 39 https://snyk. io/ 40 https://www. blackducksoftware. com/technology/vulnerability-reporting 41 https://www. sourceclear. com/ precision that is 5% lower than OWASP DC.
Library update The empirical study conducted by  Kula et al. on library migrations of 4600 GitHub projects showed that 81. 5% of them do not update their direct library dependencies, not even when they are affected by publicly known vulnerabilities  (Kula et al. 2018). In particular, that study highlights the lack of awareness about security vulnerabilities. Considering 147 Apache software projects,  Bavota G et al. (2015)  studied the evolution of dependencies and found that applications tend to update their dependencies to newer releases containing substantial changes. Tools based on reward or incentives to trigger the update of outdated dependencies exist (e. g. , the David project, 42 Greenkeeper 43 ), however as shown in Mirhosseini and Parnin (2017), project developers are mostly concerned about breaking changes and mechanisms are needed to provide-next to transparency-a motivation for the update and confidence measures to estimate the risk of performing the update.
Experimental setup CUPID-Mo consists of an array of 20 scintillating bolometer modules arranged in five towers, each with four modules, as shown in Fig. 1. Each module contains one Li 2 100 MoO 4 crystal and one germanium wafer assembled inside a singlepiece copper housing, instrumented with Neutron Transmutation Doped (NTD) Ge thermistors. All the materials used for the towers' construction were carefully selected, and additionally cleaned as needed to minimize radioactive contamination. The detector construction, transportation, and assembly into the underground cryogenic facility were performed in a clean environment. The key ingredients of the detector, its assembly, and the cryogenic apparatus are detailed below.
Detector structure The CUPID-Mo single module and tower structure were designed by the Service de Physique de l'Etat Condensé (SPEC) at CEA (Commissariat à l' Énergie Atomique et aux énergies alternatives, Gif-sur-Yvette, France) according to the following requirements: the single module structure should be compact but permit the housing of four scintillating crystals in a single tower, taking into account the restricted space in the experimental set-up; the towers should be suspended by dedicated springs to mitigate the vibrational noise of the set-up  [28] ; the design should allow a simple installation inside the cryostat (see Fig. 1  and Sec. 2. 8). The mechanical workshop of LAL (Orsay, France) fabricated the detector support structure. Each detector module (see Fig. 3 ) is a single-piece holder, made of highly radiopure NOSV TM copper from Aurubis (Hamburg, Germany).
It contains both a Li 2 100 MoO 4 scintillation element and a Ge wafer. The bolometers are kept in place by small Polytetrafluoroethylene (PTFE) holders which decouple them from the thermal bath. The Li 2 100 MoO 4 crystals are supported with three PTFE elements on the top and bottom, while the LDs are clamped with three PTFE pieces. In Commissioning I, we did not install any reflecting foil around the crystals, because previous measurements demonstrated efficient particle identification performance despite a factor of 2 lower light collection efficiency  [18]. Commissioning I was characterized by sub-optimal LD performance (see Sec. 2. 3), Fig. 3  All components used to assemble a CUPID-Mo single detector module: a copper holder, a Li 2 100 MoO 4 crystal with glued NTD and heater, a Ge LD with NTD, the copper screws, the PTFE spacers and fixing elements, the Kapton foil with golden pads.
Detector assembly We performed all activities related to the detectors' assembly in a cleanroom environment. All the used detector components were carefully cleaned before assembly to minimize the risk of surface re-contamination. In particular, copper elements were etched with citric acid, and PTFE elements cleaned with ethanol in an ultrasonic bath. The tower assembly was performed in a class 10 cleanroom at LAL. The Li 2 MoO 4 crystal is fixed inside its copper housing with PTFE elements on top and bottom as well as surrounded by a reflecting foil. An assembled single module (top and bottom view), as well as all the CUPID-Mo detectors, are shown in Fig. 4  and Fig. 5 , respectively. In total, five towers were assembled with four detectors each (Fig. 6 ). Crystals on the lower three floors are each viewed by one LD from the top and one LD from the bottom.
Wiring A dedicated wiring scheme was designed and implemented for the CUPID-Mo experiment as the existing EDELWEISS-III readout could not accommodate the additional 20 dualreadout modules required for CUPID-Mo. We bonded gold wires from the NTDs to flat Kapton pads with gold contacts to provide the electrical readout connection as well as the weak thermal link to the heat bath. Silk-covered constantan twisted wires were soldered on the other side and run up each tower to a larger Kapton pad with gold contacts glued at the top of the tower. On this pad the constantan wires and copper wires (connection to the cold electronics) were soldered 1. This connection provides a link to Si-JFET (junction gate field-effect Fig. 6  The five assembled towers before installation in the cryogenic facility.
The experimental volume of EDELWEISS-III contains four floors (detector plates) with twelve slots each (see Fig. 8 ). The CUPID-Mo towers were inserted through the slots T3, T4, T10, T11, and T12 (see Table  1 ) and mechanically decoupled from the EDELWEISS-III detector plate with three metal springs for each tower 2. The remaining experimental space is partially occupied (tower slots T2, T5, T7, and T8) by 11 Ge bolometers for the EDELWEISS dark matter search program  [40]  and a cadmium tungstate based scintillating bolometer for CUPID R&D  [41]. We added two mixed U/Th sources made of thorite mineral to the EDELWEISS-III automatic source deployment system  [30]  (see Fig. 8 ). These sources complement the already available γ-calibration sources of 133 Ba (∼1 kBq) and 60 Co (∼100 kBq) for periodic calibration of the CUPID-Mo detectors.
Custom made room-temperature electronics modules called bolometer boxes (BBs) are mounted just outside of the cryostat to ensure short cables to limit noise pick-up. These BBs contain the electronics for the cold Si-JFET pre-amplifiers' biasing, Digital to Analog Converters (DACs) for the detectors' biasing, post-amplification, anti-aliasing filter, and ADCs to record the CUPID-Mo NTDs  [30]. All LMOs and five LDs are operated with BBs containing 16-bit ADCs, while the signal digitization for the remaining LDs is done 2 The activity of 228 Th and 226 Ra and 60 Co in the springs is ∼0. 01 Bq/kg, while the 40 K content is ∼4 Bq/kg; the total mass of the material is around 8 g. with 14-bit ADCs. The pulser system, used to inject a constant Joule power through the heaters, is based on a 4-channel pulse generator with a typical injection periodicity of a few minutes.
Data processing Two independent analysis frameworks, both exploiting the optimum filter technique  [44] , are used for the data processing: one, called DIANA  [45,?] , is adapted from the CUORE  [14]  and CUPID-0  [46]  experiments and the other was developed at CSNSM  [47]  and used for the analysis of the LU-MINEU data  [28]. The CSNSM code has been developed (using the MATLAB MULTI Integrated Development Environment) specifically for the analysis of scintillating bolometer data. It is more nimble and readily adapted to different experimental setups. In contrast, DIANA is a much broader framework, including analysis packages for larger detector arrays (in particular allowing for the analysis of coincident events). It is object-oriented C++ code with a PostgreSQL  [48]  database interface to track detector and electronics settings.
90 keV/MeV. In addition a ∼0. 1 keV/MeV difference is observed in light collection between the top (0. 74 keV/MeV) and the bottom (0. 64 keV/MeV) LDs. This effect is a result of a protrusion that is part of the crystal support, which acts as an aperture for downward going light. The obtained results are consistent with previous observations  [28, 29]. The summed light collected from two adjacent LDs is the closest estimate we have for ideal light collection. It is as high as 1. 44 keV/MeV with a median value of 1. 35 keV/MeV. The uncertainty for individual RLY estimates has been quantified from the spread in RLY estimates of three distinct 60 Co plus 208 Tl datasets. We observed a ∼4% spread around the mean (RMS), with a maximum deviation of 16% for a single detector. For this analysis, we opt to use the LD in the same detector module just below the crystal by default.
Acknowledgements This work has been partially performed in the framework of the  LUMINEU program , a project funded by the  Agence Nationale de la Recherche  ( ANR, France ). The help of the technical staff of the  Laboratoire Souterrain de Modane  and of the other participant laboratories is gratefully acknowledged. We thank the mechanical workshops of  CEA/SPEC  for their valuable contribution in the detector conception and of  LAL  for the detector holders fabrication. The group from  Institute for Nuclear Research (Kyiv, Ukraine)  was supported in part by the  IDEATE International Associated Laboratory (LIA). A. S. Barabash ,  S. I. Konovalov ,  I. M. Makarov ,  V. N. Shlegel  and  V. I. Umatov  were supported by  Russian Science Foundation  (grant No. 18-12-00003 ). O. G. Polischuk was supported in part by the project " Investigations of rare nuclear processes " of the program of the  National Academy of Sciences of Ukraine  " Laboratory of young scientists ".
The Ph. D. fellowship of  H. Khalife  has been partially funded by the  P2IO LabEx  ( ANR-10-LABX-0038 ) managed by the  ANR (France)  in the framework of the 2017 P2IO Doctoral call. C. Rusconi  is supported by the  National Science Foundation  Grant  NSF-PHY-1614611. This material is also based upon work supported by the  US Department of Energy (DOE) Office of Science  under Contract No. DE-AC02-05CH11231 ; by the  DOE Office of Science, Office of Nuclear Physics  under Contract Nos. DE-FG02-08ER41551  and de-sc0011091; by the  France-Berkeley Fund , the  MISTI-France  fund and by the  Chateaubriand Fellowship of the Office for Science & Technology of the Embassy of France in the United States. This research used resources of the  National Energy Research Scientific Computing Center (NERSC)  and of the Savio computational cluster provided by the  Berkeley Research Computing program  at the  University of California, Berkeley  (supported by the  UC Berkeley Chancellor ,  Vice Chancellor  for Research, and Chief Information Officer).
Background: The ability to compare samples or studies easily using metabarcoding so as to better interpret microbial ecology results is an upcoming challenge. A growing number of metabarcoding pipelines are available, each with its own benefits and limitations. However, very few have been developed to offer the opportunity to characterize various microbial communities (e. g. , archaea, bacteria, fungi, photosynthetic microeukaryotes) with the same tool. Results: BIOCOM-PIPE is a flexible and independent suite of tools for processing data from high-throughput sequencing technologies, Roche 454 and Illumina platforms, and focused on the diversity of archaeal, bacterial, fungal, and photosynthetic microeukaryote amplicons. Various original methods were implemented in BIOCOM-PIPE to (1) remove chimeras based on read abundance, (2) align sequences with structure-based alignments of RNA homologs using covariance models, and (3) a post-clustering tool (ReClustOR) to improve OTUs consistency based on a reference OTU database.