arXiv subjects

Clemente Izurieta

Publications and source records attributed to Clemente Izurieta.

5 recordsLinked to original sources

arXiv2026

Wicked Problem, Parsimonious Solution: Securing Electric Vehicle Charging Station Software

Electric vehicle charging infrastructure presents a suite of novel cyber-physical threats. Among this infrastructure, charging stations are the most vulnerable elements. The software in the charging station supply equipment is particularly vulnerable. Currently, the software is an attack surface that is largely unprotected and poorly characterized. To represent the vulnerabilities in this attack surface, we advocate for applying modern software quality assurance to characterize vulnerabilities in electric vehicle charging station software. Specifically, we advocate for the application of hierarchical software quality assurance (HSQA) to specialized electric vehicle charging station software. HSQA provides a comprehensive view of the code quality and security -- from the level of individual vulnerabilities (e.g., CVEs) to high level characteristics (e.g., CIA Triad). HSQA incorporates quality and security considerations throughout the software development lifecycle. Thus, our position is that HSQA is an excellent approach for assessing electrical vehicle charging station software.

cs.CR↗

arXiv2026

Automating Static Code Analysis Through CI/CD Pipeline Integration

In the contemporary landscape of software devel-opment, securing sensitive data is paramount to safeguarding organizational reputation, preventing financial losses, and pro-tecting individuals from identity theft. This paper addresses the pervasive challenge of identifying and rectifying security vulnerabilities early in the development process, emphasizing the role of Static Application Security Testing (SAST) tools. While SAST tools play a crucial role in detecting vulnerabilities, widespread adoption has been hindered by usability issues, including high false positive rates and a lack of native pipeline support. This paper proposes a novel, generalized, and automated process for aggregating SAST tool outputs and integrating them into developers' familiar issue-tracking software. The process streamlines the identification and communication of security vulnerabilities during the development lifecycle, facilitating more efficient remediation efforts. We demonstrate the successful implementation of the proposed process with the SonarQube SAST tool in a GitLab-based development environment. Developers were positive about the structured implementation, real-time feedback, and proactive vulnerability management. However, despite some challenges such as a potential learning curve and tradeoffs between secure coding and workflow disruption, the overall positive impact on security awareness and responsiveness suggests that the proposed process holds promise in enhancing the security posture of software development practices

cs.CR↗

arXiv2026

Barriers to Using Static Application Security Testing (SAST) Tools: A Literature Review

Developers face a challenging problem with no clear solution. Modern software breaches can wreak havoc on businesses and individuals alike. With code vulnerabilities being a leading cause, securing applications must be a priority for developers. Static Application Security Testing (SAST) has the potential to harden applications by assisting in the identification and resolution of security vulnerabilities. Despite this, many development teams have not adopted SAST tools into their environment. In this paper, we survey the recent literature to uncover why some developers are apprehensive towards SAST and identify what specific problems they encounter when using it. We found a variety of usability problems developers face when using SAST. Some are inherent of the tool and ultimately require some level of developer investment while others are tool shortcomings that SAST tool creators must address. Ultimately, we argue that in order to drive widespread adoption and consistent SAST usage, developers will need to embrace that some investment is required. Simultaneously, developers will be more likely to integrate SAST tools into their workflows if the creators of SAST tools simplify many aspects related to tool usage. Surmounting the primary obstacles preventing the adoption of SAST requires full consideration of both the technical and human factors.

cs.SE↗

arXiv2025

SoK: Trusted Execution in SoC-FPGAs

Trusted Execution Environments (TEEs) have emerged at the forefront of edge computing to combat the lack of trust between system components. Field Programmable Gate Arrays (FPGAs) are commonly used as edge computers but were not created with security as a primary consideration. Thus, FPGA-based edge computers are increasingly the target of cyberattacks. We analyze the existing literature to systematize the applications and features of FPGA-based TEEs. We identified 27 primary studies related to different types of System-on-Chip FPGA-based TEEs. Across a wide range of applications and features, the availability of extensible solutions is limited. Most solutions focus on specific features and applications, whereas few solutions focus on feature-rich, comprehensive TEEs that can be utilized across computer systems. Whether TEEs are specific or extensible, the paucity of published studies provides evidence of research gaps. This SoK delineates these gaps revealing opportunities for researchers and developers.

cs.CR↗

arXiv2021

Prevalence, Common Causes and Effects of Technical Debt: Results from a Family of Surveys with the IT Industry

The technical debt (TD) metaphor describes actions made during various stages of software development that lead to a more costly future regarding system maintenance and evolution. According to recent studies, on average 25% of development effort is spent, i.e. wasted, on TD caused issues in software development organizations. However, further research is needed to investigate the relations between various software development activities and TD. The objective of this study is twofold. First, to get empirical insight on the understanding and the use of the TD concept in the IT industry. Second, to contribute towards precise conceptualization of the TD concept through analysis of causes and effects. In order to address the research objective a family of surveys was designed as a part of an international initiative that congregates researchers from 12 countries -- InsighTD. At country level, national teams ran survey replications with industry practitioners from the respective countries. In total 653 valid responses were collected from 6 countries. Regarding the prevalence of the TD concept 22% of practitioners have only theoretical knowledge about it, and 47% have some practical experiences with TD identification or management. Further analysis indicated that senior practitioners who work in larger organizations, larger teams, and on larger systems are more likely to be experienced with TD management. Time pressure or deadline was the single most cited cause of TD. Regarding the effects of TD: delivery delay, low maintainability, and rework were the most cited. InsighTD is the first family of surveys on technical debt in software engineering. It provided a methodological framework that allowed multiple replication teams to conduct research activities and to contribute to a single dataset. Future work will focus on more specific aspects of TD management.

cs.SE↗