1,941 research outputs found

    What to Fix? Distinguishing between design and non-design rules in automated tools

    Full text link
    Technical debt---design shortcuts taken to optimize for delivery speed---is a critical part of long-term software costs. Consequently, automatically detecting technical debt is a high priority for software practitioners. Software quality tool vendors have responded to this need by positioning their tools to detect and manage technical debt. While these tools bundle a number of rules, it is hard for users to understand which rules identify design issues, as opposed to syntactic quality. This is important, since previous studies have revealed the most significant technical debt is related to design issues. Other research has focused on comparing these tools on open source projects, but these comparisons have not looked at whether the rules were relevant to design. We conducted an empirical study using a structured categorization approach, and manually classify 466 software quality rules from three industry tools---CAST, SonarQube, and NDepend. We found that most of these rules were easily labeled as either not design (55%) or design (19%). The remainder (26%) resulted in disagreements among the labelers. Our results are a first step in formalizing a definition of a design rule, in order to support automatic detection.Comment: Long version of accepted short paper at International Conference on Software Architecture 2017 (Gothenburg, SE

    How Does Refactoring Impact Security When Improving Quality? A Security Aware Refactoring

    Full text link
    Peer Reviewedhttps://deepblue.lib.umich.edu/bitstream/2027.42/155871/1/RefactoringSecurityQMOOD__ICSE____Copy_.pd

    Refactoring preserves security

    Get PDF
    Refactoring allows changing a program without changing its behaviour from an observer’s point of view. To what extent does this invariant of behaviour also preserve security? We show that a program remains secure under refactoring. As a foundation, we use the Decentralized Label Model (DLM) for specifying secure information flows of programs and transition system models for their observable behaviour. On this basis, we provide a bisimulation based formal definition of refactoring and show its correspondence to the formal notion of information flow security (noninterference). This permits us to show security of refactoring patterns that have already been practically explored

    Semi-automatic ladderisation : improving code security through rewriting and dependent types

    Get PDF
    Funding: This work was generously supported by the EU Horizon 2020 project, TeamPlay (https://www.teamplay-h2020.eu), grant number 779882, and UK EPSRC, Energise, grant number EP/V006290/1.Cyber attacks become more and more prevalent every day.An arms race is thus engaged between cyber attacks and cyber defences.One type of cyber attack is known as a side channel attack, where attackers exploit information leakage from the physical execution of a program, e.g. timing or power leakage, to uncover secret information, such as encryption keys or other sensitive data. There have been various attempts at addressing the problem of side-channel attacks, often relying on various measures to decrease the discernibility of several code variants or code paths. Most techniques require a high-degree of expertise by the developer, who often employs ad hoc, hand-crafted code-patching in an attempt to make it more secure. In this paper, we take a different approach: building on the idea of ladderisation, inspired by Montgomery Ladders. We present a semi-automatic tool-supported technique, aimed at the non-specialised developer, which refactors (a class of) C programs into functionally (and even algorithmically) equivalent counterparts with improved security properties. Our approach provides refactorings that transform the source code into its ladderised equivalent, driven by an underlying verified rewrite system, based on dependent types. Our rewrite system automatically finds rewritings of selected C expressions, facilitating the production of their equivalent ladderised counterparts for a subset of C. Using our tool-supported technique, we demonstrate our approach on a number of representative examples from the cryptographic domain, showing increased security.Postprin

    Traceability for the maintenance of secure software

    Get PDF
    Traceability links among different software engineering artifacts make explicit how a software system was implemented to accommodate its requirements. For secure and dependable software system development, one must ensure the linked entities are truly traceable to each other and the links are updated to reflect true traceability among changed entities. However, traditional traceability relationships link recovery techniques are not accurate enough. To address this problem, we propose a traceability technique based on refactoring, which is then continuously integrated with other software maintenance activities. Applying our traceability technique to the proven SSL protocol design, we found a significant vulnerability bug in its open-source implementation. The results also demonstrate the level of accuracy and change resilience of our technique that enable reuse of the traceability-related analysis on different implementations

    Refactoring preserves security

    Get PDF
    Refactoring allows changing a program without changing its behaviour from an observer’s point of view. To what extent does this invariant of behaviour also preserve security? We show that a program remains secure under refactoring. As a foundation, we use the Decentralized Label Model (DLM) for specifying secure information flows of programs and transition system models for their observable behaviour. On this basis, we provide a bisimulation based formal definition of refactoring and show its correspondence to the formal notion of information flow security (noninterference). This permits us to show security of refactoring patterns that have already been practically explored

    Formal Verification of Security Protocol Implementations: A Survey

    Get PDF
    Automated formal verification of security protocols has been mostly focused on analyzing high-level abstract models which, however, are significantly different from real protocol implementations written in programming languages. Recently, some researchers have started investigating techniques that bring automated formal proofs closer to real implementations. This paper surveys these attempts, focusing on approaches that target the application code that implements protocol logic, rather than the libraries that implement cryptography. According to these approaches, libraries are assumed to correctly implement some models. The aim is to derive formal proofs that, under this assumption, give assurance about the application code that implements the protocol logic. The two main approaches of model extraction and code generation are presented, along with the main techniques adopted for each approac

    From Monolith to Microservices: A Classification of Refactoring Approaches

    Full text link
    While the recently emerged Microservices architectural style is widely discussed in literature, it is difficult to find clear guidance on the process of refactoring legacy applications. The importance of the topic is underpinned by high costs and effort of a refactoring process which has several other implications, e.g. overall processes (DevOps) and team structure. Software architects facing this challenge are in need of selecting an appropriate strategy and refactoring technique. One of the most discussed aspects in this context is finding the right service granularity to fully leverage the advantages of a Microservices architecture. This study first discusses the notion of architectural refactoring and subsequently compares 10 existing refactoring approaches recently proposed in academic literature. The approaches are classified by the underlying decomposition technique and visually presented in the form of a decision guide for quick reference. The review yielded a variety of strategies to break down a monolithic application into independent services. With one exception, most approaches are only applicable under certain conditions. Further concerns are the significant amount of input data some approaches require as well as limited or prototypical tool support.Comment: 13 pages, 4 tables, 2 figures, Software Engineering Aspects of Continuous Development and New Paradigms of Software Production and Deployment, First International Workshop, DEVOPS 2018, Chateau de Villebrumier, France, March 5-6, 2018, Revised Selected Paper
    • …
    corecore