Is secure coding education in the industry needed? An investigation through a large scale survey

The Department of Homeland Security in the United States estimates that 90% of software vulnerabilities can be traced back to defects in design and software coding. The financial impact of these vulnerabilities has been shown to exceed 380 million USD in industrial control systems alone. Since software developers write software, they also introduce these vulnerabilities into the source code. However, secure coding guidelines exist to prevent software developers from writing vulnerable code. This study focuses on the human factor, the software developer, and secure coding, in particular secure coding guidelines. We want to understand the software developers' awareness and compliance to secure coding guidelines and why, if at all, they aren't compliant or aware. We base our results on a large-scale survey on secure coding guidelines, with more than 190 industrial software developers. Our work's main contribution motivates the need to educate industrial software developers on secure coding guidelines, and it gives a list of fifteen actionable items to be used by practitioners in the industry. We also make our raw data openly available for further research.info:eu-repo/semantics/acceptedVersio

CapablePtrs: Securely Compiling Partial Programs using the Pointers-as-Capabilities Principle

Capability machines such as CHERI provide memory capabilities that can be used by compilers to provide security benefits for compiled code (e.g., memory safety). The C to CHERI compiler, for example, achieves memory safety by following a principle called "pointers as capabilities" (PAC). Informally, PAC says that a compiler should represent a source language pointer as a machine code capability. But the security properties of PAC compilers are not yet well understood. We show that memory safety is only one aspect, and that PAC compilers can provide significant additional security guarantees for partial programs: the compiler can provide guarantees for a compilation unit, even if that compilation unit is later linked to attacker-controlled machine code. This paper is the first to study the security of PAC compilers for partial programs formally. We prove for a model of such a compiler that it is fully abstract. The proof uses a novel proof technique (dubbed TrICL, read trickle), which is of broad interest because it reuses and extends the compiler correctness relation in a natural way, as we demonstrate. We implement our compiler on top of the CHERI platform and show that it can compile legacy C code with minimal code changes. We provide performance benchmarks that show how performance overhead is proportional to the number of cross-compilation-unit function calls

Holding on to Compliance While Adopting DevSecOps: An SLR

The software industry has witnessed a growing interest in DevSecOps due to the premises of integrating security in the software development lifecycle. However, security compliance cannot be disregarded, given the importance of adherence to regulations, laws, industry standards, and frameworks. This study aims to provide an overview of compliance aspects in the context of DevSecOps and explore how compliance is ensured. Furthermore, this study reveals the trends of compliance according to the extant literature and identifies potential directions for further research in this context. Therefore, we carried out a systematic literature review on the integration of compliance aspects in DevSecOps, which rigorously followed the guidelines proposed by Kitchenham and Charters. We found 934 articles related to the topic by searching five bibliographic databases (163) and Google Scholar (771). Through a rigorous selection process, we selected 15 papers as primary studies. Then, we identified the compliance aspects of DevSecOps and grouped them into three main categories: compliance initiation, compliance management, and compliance technicalities. We observed a low number of studies; therefore, we encourage further efforts into the exploration of compliance aspects, their automated integration, and the development of metrics to evaluate such a process in the context of DevSecOps.publishedVersio

Tackling the Awkward Squad for Reactive Programming: The Actor-Reactor Model

Reactive programming is a programming paradigm whereby programs are internally represented by a dependency graph, which is used to automatically (re)compute parts of a program whenever its input changes. In practice reactive programming can only be used for some parts of an application: a reactive program is usually embedded in an application that is still written in ordinary imperative languages such as JavaScript or Scala. In this paper we investigate this embedding and we distill "the awkward squad for reactive programming" as 3 concerns that are essential for real-world software development, but that do not fit within reactive programming. They are related to long lasting computations, side-effects, and the coordination between imperative and reactive code. To solve these issues we design a new programming model called the Actor-Reactor Model in which programs are split up in a number of actors and reactors. Actors and reactors enforce a strict separation of imperative and reactive code, and they can be composed via a number of composition operators that make use of data streams. We demonstrate the model via our own implementation in a language called Stella

Continuous Security Testing:A Case Study on Integrating Dynamic Security Testing Tools in CI/CD Pipelines

Continuous Integration (CI) and Continuous Delivery (CD) have become a well-known practice in DevOps to ensure fast delivery of new features. This is achieved by automatically testing and releasing new software versions, e.g. multiple times per day. However, classical security management techniques cannot keep up with this quick Software Development Life Cycle (SDLC). Nonetheless, guaranteeing high security quality of software systems has become increasingly important. The new trend of DevSecOps aims to integrate security techniques into existing DevOps practices. Especially, the automation of security testing is an important area of research in this trend. Although plenty of literature discusses security testing and CI/CD practices, only a few deal with both topics together. Additionally, most of the existing works cover only static code analysis and neglect dynamic testing methods. In this paper, we present an approach to integrate three automated dynamic testing techniques into a CI/CD pipeline and provide an empirical analysis of the introduced overhead. We then go on to identify unique research/technology challenges the DevSecOps communities will face and propose preliminary solutions to these challenges. Our findings will enable informed decisions when employing DevSecOps practices in agile enterprise applications engineering processes and enterprise security

MicroWalk: A Framework for Finding Side Channels in Binaries

Microarchitectural side channels expose unprotected software to information leakage attacks where a software adversary is able to track runtime behavior of a benign process and steal secrets such as cryptographic keys. As suggested by incremental software patches for the RSA algorithm against variants of side-channel attacks within different versions of cryptographic libraries, protecting security-critical algorithms against side channels is an intricate task. Software protections avoid leakages by operating in constant time with a uniform resource usage pattern independent of the processed secret. In this respect, automated testing and verification of software binaries for leakage-free behavior is of importance, particularly when the source code is not available. In this work, we propose a novel technique based on Dynamic Binary Instrumentation and Mutual Information Analysis to efficiently locate and quantify memory based and control-flow based microarchitectural leakages. We develop a software framework named \tool~for side-channel analysis of binaries which can be extended to support new classes of leakage. For the first time, by utilizing \tool, we perform rigorous leakage analysis of two widely-used closed-source cryptographic libraries: \emph{Intel IPP} and \emph{Microsoft CNG}. We analyze $15$ different cryptographic implementations consisting of $112$ million instructions in about $105$ minutes of CPU time. By locating previously unknown leakages in hardened implementations, our results suggest that \tool~can efficiently find microarchitectural leakages in software binaries