{"title":"不安全的阻抗:安全语言和安全设计软件","authors":"Lee Barney, Adolfo Neto","doi":"arxiv-2407.13046","DOIUrl":null,"url":null,"abstract":"In December 2023, security agencies from five countries in North America,\nEurope, and the south Pacific produced a document encouraging senior executives\nin all software producing organizations to take responsibility for and\noversight of the security of the software their organizations produce. In\nFebruary 2024, the White House released a cybersecurity outline, highlighting\nthe December document. In this work we review the safe languages listed in\nthese documents, and compare the safety of those languages with Erlang and\nElixir, two BEAM languages. These security agencies' declaration of some languages as safe is necessary\nbut insufficient to make wise decisions regarding what language to use when\ncreating code. We propose an additional way of looking at languages and the\nease with which unsafe code can be written and used. We call this new\nperspective \\em{unsafe impedance}. We then go on to use unsafe impedance to\nexamine nine languages that are considered to be safe. Finally, we suggest that\nbusiness processes include what we refer to as an Unsafe Acceptance Process.\nThis Unsafe Acceptance Process can be used as part of the memory safe roadmaps\nsuggested by these agencies. Unsafe Acceptance Processes can aid organizations\nin their production of safe by design software.","PeriodicalId":501197,"journal":{"name":"arXiv - CS - Programming Languages","volume":"21 1","pages":""},"PeriodicalIF":0.0000,"publicationDate":"2024-07-17","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"0","resultStr":"{\"title\":\"Unsafe Impedance: Safe Languages and Safe by Design Software\",\"authors\":\"Lee Barney, Adolfo Neto\",\"doi\":\"arxiv-2407.13046\",\"DOIUrl\":null,\"url\":null,\"abstract\":\"In December 2023, security agencies from five countries in North America,\\nEurope, and the south Pacific produced a document encouraging senior executives\\nin all software producing organizations to take responsibility for and\\noversight of the security of the software their organizations produce. In\\nFebruary 2024, the White House released a cybersecurity outline, highlighting\\nthe December document. In this work we review the safe languages listed in\\nthese documents, and compare the safety of those languages with Erlang and\\nElixir, two BEAM languages. These security agencies' declaration of some languages as safe is necessary\\nbut insufficient to make wise decisions regarding what language to use when\\ncreating code. We propose an additional way of looking at languages and the\\nease with which unsafe code can be written and used. We call this new\\nperspective \\\\em{unsafe impedance}. We then go on to use unsafe impedance to\\nexamine nine languages that are considered to be safe. Finally, we suggest that\\nbusiness processes include what we refer to as an Unsafe Acceptance Process.\\nThis Unsafe Acceptance Process can be used as part of the memory safe roadmaps\\nsuggested by these agencies. Unsafe Acceptance Processes can aid organizations\\nin their production of safe by design software.\",\"PeriodicalId\":501197,\"journal\":{\"name\":\"arXiv - CS - Programming Languages\",\"volume\":\"21 1\",\"pages\":\"\"},\"PeriodicalIF\":0.0000,\"publicationDate\":\"2024-07-17\",\"publicationTypes\":\"Journal Article\",\"fieldsOfStudy\":null,\"isOpenAccess\":false,\"openAccessPdf\":\"\",\"citationCount\":\"0\",\"resultStr\":null,\"platform\":\"Semanticscholar\",\"paperid\":null,\"PeriodicalName\":\"arXiv - CS - Programming Languages\",\"FirstCategoryId\":\"1085\",\"ListUrlMain\":\"https://doi.org/arxiv-2407.13046\",\"RegionNum\":0,\"RegionCategory\":null,\"ArticlePicture\":[],\"TitleCN\":null,\"AbstractTextCN\":null,\"PMCID\":null,\"EPubDate\":\"\",\"PubModel\":\"\",\"JCR\":\"\",\"JCRName\":\"\",\"Score\":null,\"Total\":0}","platform":"Semanticscholar","paperid":null,"PeriodicalName":"arXiv - CS - Programming Languages","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/arxiv-2407.13046","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
Unsafe Impedance: Safe Languages and Safe by Design Software
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.