Table of Contents
Fetching ...

Unsafe Impedance: Safe Languages and Safe by Design Software

Lee Barney, Adolfo Neto

TL;DR

The paper addresses the gap between formal memory-safety declarations and actual software security by introducing unsafe impedance as a pragmatic metric for evaluating language safety across traditional safe languages and BEAM languages (Erlang/Elixir). It defines a framework for comparing languages, analyzes nine languages against a BEAM baseline, and proposes an Unsafe Acceptance Process (UAP) to govern the use of native unsafe code (NIFs) to raise impedance and improve security outcomes. Key contributions include the explicit formalization of unsafe impedance, a cross-language assessment with concrete examples of how unsafe code can be introduced, and a governance blueprint (UAP) to promote secure-by-design software in practice. The work aims to provide organizations with a concrete, process-oriented path to secure software roadmaps that complement memory-safety declarations, potentially reducing the attack surface in modern, large-scale systems.

Abstract

In December 2023, security agencies from five countries in North America, Europe, and the south Pacific produced a document encouraging senior executives in all software producing organizations to take responsibility for and oversight of the security of the software their organizations produce. In February 2024, the White House released a cybersecurity outline, highlighting the December document. In this work we review the safe languages listed in these documents, and compare the safety of those languages with Erlang and Elixir, two BEAM languages. These security agencies' declaration of some languages as safe is necessary but insufficient to make wise decisions regarding what language to use when creating code. We propose an additional way of looking at languages and the ease with which unsafe code can be written and used. We call this new perspective \em{unsafe impedance}. We then go on to use unsafe impedance to examine nine languages that are considered to be safe. Finally, we suggest that business processes include what we refer to as an Unsafe Acceptance Process. This Unsafe Acceptance Process can be used as part of the memory safe roadmaps suggested by these agencies. Unsafe Acceptance Processes can aid organizations in their production of safe by design software.

Unsafe Impedance: Safe Languages and Safe by Design Software

TL;DR

The paper addresses the gap between formal memory-safety declarations and actual software security by introducing unsafe impedance as a pragmatic metric for evaluating language safety across traditional safe languages and BEAM languages (Erlang/Elixir). It defines a framework for comparing languages, analyzes nine languages against a BEAM baseline, and proposes an Unsafe Acceptance Process (UAP) to govern the use of native unsafe code (NIFs) to raise impedance and improve security outcomes. Key contributions include the explicit formalization of unsafe impedance, a cross-language assessment with concrete examples of how unsafe code can be introduced, and a governance blueprint (UAP) to promote secure-by-design software in practice. The work aims to provide organizations with a concrete, process-oriented path to secure software roadmaps that complement memory-safety declarations, potentially reducing the attack surface in modern, large-scale systems.

Abstract

In December 2023, security agencies from five countries in North America, Europe, and the south Pacific produced a document encouraging senior executives in all software producing organizations to take responsibility for and oversight of the security of the software their organizations produce. In February 2024, the White House released a cybersecurity outline, highlighting the December document. In this work we review the safe languages listed in these documents, and compare the safety of those languages with Erlang and Elixir, two BEAM languages. These security agencies' declaration of some languages as safe is necessary but insufficient to make wise decisions regarding what language to use when creating code. We propose an additional way of looking at languages and the ease with which unsafe code can be written and used. We call this new perspective \em{unsafe impedance}. We then go on to use unsafe impedance to examine nine languages that are considered to be safe. Finally, we suggest that business processes include what we refer to as an Unsafe Acceptance Process. This Unsafe Acceptance Process can be used as part of the memory safe roadmaps suggested by these agencies. Unsafe Acceptance Processes can aid organizations in their production of safe by design software.
Paper Structure (12 sections, 2 tables)