You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: master-thesis.md
+41-30Lines changed: 41 additions & 30 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,11 +7,8 @@ title: Open Master Thesis Topics in Project Chains
7
7
Project Chains hosts master's students for their theses, here are available topics. See [main page](/) for completed theses.
8
8
9
9
### Empirical study of vulnerability tracking processes in vulnerability reports
10
-
11
10
Contact: Yekatierina Churakova
12
-
13
11
Vulnerability scanning tools play a crucial role in the identification and collection of vulnerabilities across different systems and platforms. Having reliable and accurate report, which lists all associated vulnerabilities for the dependencies list, is crucial for supply-chain security. [SBOM](https://cyclonedx.org/capabilities/sbom/) and [VEX](https://cyclonedx.org/capabilities/vex/) productions tools (e.g. [Trivy](https://trivy.dev/), [Grype](https://github.com/anchore/grype), [DepScan](https://github.com/owasp-dep-scan/dep-scan) etc.) are used for this purpose. Every tool has a number of vulnerability database integrations to provide the most distinct report. However, vulnerability databases often use diverse naming conventions, IDs, and tracking systems, making it difficult to reveal information about a specific vulnerability. The inconsistency and fragmentation in vulnerability reporting is hapening, where different references to different vulnerability databases may use different identifiers for the same vulnerability, making it difficult to trace and assess risks consistently.
14
-
15
12
In this project we will explore the area of vulnerability tracking and aims to address the vulnerability naming problems. The thesis will be focused on studying the approach for mapping various vulnerability identifiers across different databases to their corresponding Common Vulnerabilities and Exposures (CVE) IDs. The aim is to improve vulnerability tracking, propose a way to solve the naming problem, and enhance the accuracy of vulnerability reports.
16
13
17
14
Related works:
@@ -21,10 +18,8 @@ Related works:
21
18
4.[Understanding the Quality of Container Security Vulnerability Detection Tools](https://arxiv.org/pdf/2101.03844)
22
19
23
20
24
-
<h3id="uid42">Empirical Study of Compilation Reproducibility in Solidity</h3>
25
-
21
+
<h3 >Empirical Study of Compilation Reproducibility in Solidity</h3>
26
22
Contact: Aman Sharma
27
-
28
23
<p>Description:
29
24
The reproducibility of software builds is a critical aspect of secure software development This concept has been pushed forward in the context of Solidity, the programming language
30
25
used for writing smart contracts on the Ethereum blockchain, with the notion of "verified contracts".
@@ -33,31 +28,31 @@ consistency of the results. The datasets for this study will be sourced from Eth
33
28
This research will contribute to the understanding of software integrity in the growing field of technology and could potentially inform best practices for
34
29
Solidity development.</p>
35
30
<ol>
36
-
<liid="uid43"><p><ahref="http://arxiv.org/pdf/2104.06020">Reproducible Builds: Increasing the Integrity of Software Supply Chains</a></p>
31
+
<li ><p><ahref="http://arxiv.org/pdf/2104.06020">Reproducible Builds: Increasing the Integrity of Software Supply Chains</a></p>
<h3id="uid46">Zero-knowledge software bills of materials</h3>
38
+
<h3 >Zero-knowledge software bills of materials</h3>
44
39
45
40
Contact: Javier Ron
46
41
47
42
<p>Description: Software bills of materials (SBOMs) are complete lists of software components [1], these can be helpful in tracing vulnerabilities, license compliance, etc. However, revealing an SBOM publicly also means revealing said vulnerabilities to malicious actors. Furthermore, some proprietary software developers advocate for access control for SBOM distribution [2].
48
43
Zero-knowledge proofs allows a party to convey that a statement is true without disclosing any additional information. [3]
49
44
You will design, develop, and evaluate a zero-knowledge SBOM system, which allows developers to disclose limited, but verifiable SBOM information to authorized users.</p>
50
45
<ol>
51
-
<liid="uid47"><p>The Minimum Elements For a Software Bill of Materials https://www.ntia.doc.gov/files/ntia/publications/sbomminimumelementsreport.pdf</p>
46
+
<li ><p>The Minimum Elements For a Software Bill of Materials https://www.ntia.doc.gov/files/ntia/publications/sbomminimumelementsreport.pdf</p>
52
47
</li>
53
-
<liid="uid48"><p>An Empirical Study on Software Bill of Materials: Where We Stand and the Road Ahead http://arxiv.org/abs/2301.05362</p>
48
+
<li ><p>An Empirical Study on Software Bill of Materials: Where We Stand and the Road Ahead http://arxiv.org/abs/2301.05362</p>
<h3id="uid62">Dynamic Integrity Verification & Repair for Java Applications</h3>
83
-
77
+
<h3 >Dynamic Integrity Verification & Repair for Java Applications</h3>
84
78
Contact: Martin Monperrus
85
-
86
79
<p>Description:
87
80
Attackers constantly try to tamper with the code of software applications in production.
88
81
Chang and Attalah have proposed a technique to not only detect modifications and also repairing the code after attacks by a network of small security
89
82
units called guards. These guards can be programmed to perform tasks such as checksumming the program code, and they work in concert to create mutual protection.
90
83
In this thesis, you will devise, implement and evaluate such as an approach in the context of modern Java software with dependencies. An open question is how to set up guard inside or around dependency code.</p>
91
84
<ol>
92
-
<liid="uid63"><p><ahref="https://link.springer.com/chapter/10.1007/3-540-47870-1_10">Protecting Software Code by Guards</a></p>
85
+
<li ><p><ahref="https://link.springer.com/chapter/10.1007/3-540-47870-1_10">Protecting Software Code by Guards</a></p>
93
86
</li>
94
-
<liid="uid64"><p><ahref="https://dl.acm.org/doi/abs/10.1145/353323.353383">Reflection as a mechanism for software integrity verification</a></p>
87
+
<li ><p><ahref="https://dl.acm.org/doi/abs/10.1145/353323.353383">Reflection as a mechanism for software integrity verification</a></p>
95
88
</li>
96
-
<liid="uid65"><p><ahref="https://dl.acm.org/doi/abs/10.1145/3274694.3274732">Practical integrity protection with oblivious hashing</a></p>
89
+
<li ><p><ahref="https://dl.acm.org/doi/abs/10.1145/3274694.3274732">Practical integrity protection with oblivious hashing</a></p>
97
90
</li></ol>
98
91
99
-
<h3id="uid66">Dynamic Introspection of Dependencies in Java Applications</h3>
92
+
<h3 >Dynamic Introspection of Dependencies in Java Applications</h3>
93
+
<p>Contact: Aman Sharma</p>
100
94
<p>Description: We aim to design and develop a prototype for dynamic introspection of dependencies in Java applications. This would enable real-time tracking and decision based on the dependency execution context. By leveraging Java's instrumentation capabilities, the proposed system will monitor and identify the active dependencies at any given
101
95
point during program execution. The focus will be on minimizing performance
102
96
overhead to ensure that the introspection process does not significantly impact the application's responsiveness or efficiency, while integrating seamlessly with any existing Java application.
103
97
Rigorous evaluation against various benchmarks will be one to assess its accuracy,
104
98
performance, and usability.</p>
105
99
106
-
<h3id="uid67">Automatic Backporting of Java Libraries to Older Bytecode Versions</h3>
107
-
100
+
<h3 >Automatic Backporting of Java Libraries to Older Bytecode Versions</h3>
108
101
Contact: Aman Sharma
109
-
110
102
<p>Description:
111
103
With the rapid evolution of Java, libraries often get updated to new bytecode versions. This causes compatibility issues and breakages for
112
104
applications that are still running on older versions of Java. To address this, a possible solution is to automatically backport Java libraries to older bytecode
113
105
versions. This thesis will focus on designing and implementing an automated tool for backporting Java libraries. The tool should be capable of translating new bytecode
114
106
instructions to their older equivalents, maintaining the functional behavior of the library while ensuring compatibility with older Java versions. An open question is
115
107
how to handle new language features and APIs that do not have direct equivalents in older versions.</p>
116
108
<ol>
117
-
<liid="uid68"><p><ahref="https://ieeexplore.ieee.org/abstract/document/9540328/">Back to the past–analysing backporting practices in package dependency networks</a></p>
109
+
<li ><p><ahref="https://ieeexplore.ieee.org/abstract/document/9540328/">Back to the past–analysing backporting practices in package dependency networks</a></p>
118
110
</li>
119
-
<liid="uid69"><p><ahref="https://inria.hal.science/hal-01355859/file/icsme_hal.pdf">Recommending code changes for automatic backporting of Linux device drivers</a></p>
111
+
<li ><p><ahref="https://inria.hal.science/hal-01355859/file/icsme_hal.pdf">Recommending code changes for automatic backporting of Linux device drivers</a></p>
120
112
</li>
121
-
<liid="uid70"><p><ahref="https://arxiv.org/abs/2405.07204">Transforming C++11 Code to C++03 to Support Legacy Compilation Environments</a></p>
113
+
<li ><p><ahref="https://arxiv.org/abs/2405.07204">Transforming C++11 Code to C++03 to Support Legacy Compilation Environments</a></p>
<p>This thesis will explore the concept of reproducible JIT compilation, focusing on the challenges and solutions for ensuring consistent and repeatable execution of
119
+
program compilation across different runs. By analyzing the factors that contribute to variability in JIT compilation, such as optimization heuristics, runtime conditions,
120
+
and system configurations, you will propose methodologies to achieve reproducibility. The study will involve the design and implementation of a framework that
121
+
captures and standardizes the JIT compilation process, enabling developers to reproduce the same JIT compilation results reliably. Through empirical evaluation, the thesis will
122
+
assess the impact of reproducible JIT compilation on software reliability, debugging, and performance, ultimately contributing to the development of more robust and
123
+
trustworthy software systems.</p>
124
+
<ol>
125
+
<li > [Recompilation for debugging support in a JIT-compiler](https://doi.org/10.1145/634636.586100) </li>
0 commit comments