Filters

Settings

Now showing1 - 3 of 3
  • Some of the metrics are blocked by your 
    consent settings
    Item type:Project, Access status: without files ,
    Developer-Centred Management of Self-Admitted Technical Debt for Security
    Software developers often face complex technical challenges that, for diverse reasons, they circumvent with spurious design workarounds and sub-optimal implementations. Such compromises are likely to result in a significant amount of Technical Debt (TD), namely low-quality artefacts that can impair the future maintenance and evolution of the system being developed. TD is a long-standing, paramount problem in modern software development and it is estimated to cost projects around USD 1.5 million on average to remediate (equivalent to 27,500 developer hours). Moreover, it can introduce exploitable flaws and vulnerabilities that can compromise, to a great extent, the security of software systems. A significant portion of TD research has been conducted thanks to the analysis of Self-Admitted Technical Debt (SATD) sources. That is, artefacts such as code comments and commit messages where developers often report the shortcomings of their solutions. The systematic study of SATD has helped to identify and characterise flaws at different levels, including code, design, requirements, and documentation. Still, the security implications of TD have received little attention from researchers, leaving many open questions about its role in the emergence of software vulnerabilities. This project seeks to be at the forefront of TD security research by shifting the focus towards developer-centred SATD management. Particularly, on how security weaknesses reported inside SATD artefacts can support the timely identification, prioritisation, and repayment of vulnerability-prone TD instances. For this, we will gather actionable information on the interplay between security-related SATD and software vulnerabilities by (i) mining Open Source Software (OSS) repositories and (ii) conducting empirical studies with developers. Such evidence will be translated into the design of novel, Artificial Intelligence-enhanced methods and tools for (i) the automatic identification of such SATD instances, (ii) their security assessment, and (iii) their seamless remediation.
      14
  • Some of the metrics are blocked by your 
    consent settings
    Item type:Project, Access status: without files ,
    Design-Level Vulnerabilities Identification and Fixing
    The DeVulNix project focuses on software architecture for cybersecurity, specifically design-level vulnerabilities in software systems. Recognized as a significant threat, these vulnerabilities originate from overall architectural or design flaws. To date, their identification and remediation, which involves manual architectural modeling and threat analysis, are error-prone and time-consuming. The project aims to automate the detection and patching of design-level vulnerabilities through source code analysis and fixing. The objectives cover developing an evidence-based theory of these vulnerabilities and developing techniques for their detection and patching (based on large language models used in combination with traditional program analysis tools, abstraction techniques, and human-in-the-loop mechanisms). The research questions are: RQ1. How can we codify the nature and scope of design-level vulnerabilities into an evidence-based theory? RQ2. How can hybrid approaches leverage large language models to detect design-level vulnerability across diverse software environments? RQ3. How can hybrid approaches leverage large language models to generate high-quality, contextually appropriate fix suggestions? RQ4. How can these detection and fixing mechanisms be integrated into developer IDEs and delivery pipelines for ongoing security analysis? The project represents a novel approach to addressing design-level vulnerabilities in software systems. By bypassing the need to create architectural diagrams and dealing directly with the source code, the project seeks to offer a more efficient and accurate method for identifying and fixing these vulnerabilities. Our new foundational approach will be evaluated across programming languages, libraries, and technology stacks. The project innovatively combines security-specific software engineering methods at the design level with LLMs and integrates them into IDEs, delivery pipelines, and human feedback systems.
      21
  • Some of the metrics are blocked by your 
    consent settings
    Item type:Project, Access status: without files ,
    Security Testing of Code Components
    Software testing is the key activity for finding defects in source code, consisting of developing several test cases that evaluate a test item with specific input data and observe whether the returned results match the expected ones. This activity is primarily used to find ordinary “functional” bugs; nevertheless, it can also be used to find vulnerabilities that threaten the security properties of a test item, i.e., evaluating the degree to which it is protected from unauthorized access and permits only authorized parties to access it. In this case, the activity is called (software) security testing. Several techniques fall under this umbrella, such as SAST, DAST, and Penetration Testing. Despite all being proven efficient at finding several types of vulnerabilities, they exhibit limitations that prevent them from covering all possible scenarios in which vulnerabilities arise. For instance, SAST over-approximates the code under test and neglects its actual behavior; at the same time, DAST and penetration testing often target the entire system and require deployment, which prevents their adoption at earlier stages. Such limitations could be addressed through more fine-grained testing, creating security-focused test cases targeting specific code components whose implementations might contain security flaws. This project, named SToCC (Security Testing of Code Components), aims to make a foundational scientific contribution to component-level security testing by characterizing the profile of security tests and by experimenting with automated approaches to generate and maintain them. Specifically, SToCC plans to analyze the profile (prevalence, anatomy, and dynamics) of component-level security tests in software projects and generate new tests to detect unknown vulnerabilities. Then, it plans to assess and enhance the oracles of existing component-level security tests and evaluate their responses when the targeted code components change. This is achieved through empirical studies and a design science approach. The foreseen impact of SToCC is to raise security researchers’ awareness of component-level security testing and to stimulate further research. At the same time, software engineers can build on the exploitable artifacts produced by SToCC to develop better tools to facilitate the development and maintenance of security tests.
      4