Demo Data from EDBT 2026 / reviewers in the wild / expert
Dan DaCosta
dblp:28/5570
· DBLP profile ↗
2ranked-venue papers
1as first author
1since 2021 · last 2021
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 2 · 1 first-author · 1 since 2021Theory of computation · 1 · 1 since 2021
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Computer networks
1 paper |
Network management and operations · 100% | |
| Computer architecture, parallel and distributed computing, and storage systems
1 paper |
Cloud and datacenter computing · 100% |
Topics — the 3 heaviest of 3, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Network management and operations
network verification |
0.5 | 1 | 2021 | Debugging Network Reachability with Blocked Paths · CAV (2) 2021 |
Network management and operations › network verification
reachability analysis |
0.5 | 1 | 2021 | Debugging Network Reachability with Blocked Paths · CAV (2) 2021 |
Cloud and datacenter computing › cloud networking
virtual private cloud |
0.1 | 1 | 2021 | Debugging Network Reachability with Blocked Paths · CAV (2) 2021 |
Methods — techniques the papers use, named apart from their topics
formal modeling · 1.0SMT solving · 1.0
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2021 | Debugging Network Reachability with Blocked PathsabstractAbstract In this industrial case study we describe a new network troubleshooting analysis used by VPC Reachability Analyzer , an SMT-based network reachability analysis and debugging tool. Our troubleshooting analysis uses a formal model of AWS Virtual Private Cloud (VPC) semantics to identify whether a destination is reachable from a source in a given VPC configuration. In the case where there is no feasible path, our analysis derives a blocked path : an infeasible but otherwise complete path that would be feasible if a corresponding set of VPC configuration settings were adjusted. Our blocked path analysis differs from other academic and commercial offerings that either rely on packet probing (e.g., tcptrace ) or provide only partial paths terminating at the first component that rejects the packet. By providing a complete (but infeasible) path from the source to destination, we identify for a user all the configuration settings they will need to alter to admit that path (instead of requiring them to repeatedly re-run the analysis after making partial changes). This allows users to refine their query so that the blocked path is aligned with their intended network behavior before making any changes to their VPC configuration. Sam Bayless, John D. Backes, Dan DaCosta, Benjamin F. Jones 0002, Nate Launchbury, Patrick Trentin, Kelsey Jewell, Sagar Joshi, Michael Q. Zeng, Nandita Mathews |
CAV (2) | 3 |
| 2003 | Characterizing the 'Security Vulnerability Likelihood' of Software FunctionsabstractSoftware maintainers and auditors would benefit from a tool to help them focus their attention on functions that are likely to be the source of security vulnerabilities. However, the existence of such a tool is predicated on the ability to characterize a function's 'security vulnerability likelihood'. Our hypothesis is that functions near a source of input are most likely to contain security vulnerability. These functions should be a small percentage of the total number of functions in the system. To validate this hypothesis, we performed an experiment involving thirty one vulnerabilities in thirty open source systems. This paper describes the experiment, its outcome, and the tools used to conduct it. It also describes the FLF (front line functions) finder, which is a tool that was developed using knowledge gathered from the outcome of the experiment. This tool automates the detection of high-risk functions. To demonstrate the effectiveness of the FLF finder, three open source applications with known vulnerabilities were tested. In addition to this test, a case study was performed on the privilege separation code in the OpenSSH server daemon. Dan DaCosta, Christopher Dahn, Spiros Mancoridis, Vassilis Prevelakis |
ICSM | 1 |