Stock Photos from Alexander Geiger / Shutterstock

Software security, a scientific overview

By Yannick Moy, Senior Software Engineer, AdaCore

Software needs security. That's a consequence of using software to control critical systems. It's difficult because software is inherently a complex artifact, even when the code just consists of a single sequential program in a single programming language, with well-defined inputs and outputs. Of course, actual software rarely if ever has such a simple structure.


Security needs software. That's a consequence of the complexity just mentioned. No process can ensure security at scale unless it is automated by using software itself: programming languages, verification tools, software platforms.


Every provider of software security tools will readily present the superiority of its solution. Working for a software tool vendor, I do that routinely. But software security is only as strong as its weakest link, among the many links forming the final software chain, and there are often many technical and procedural angles of attack. So it's not surprising that the technical (see the Common Weakness Enumeration) and procedural (see the Building Security In Maturity Model) solutions are based on enumerations. And as enumerations do not help with prioritization, groups focused on security have come up with various lists of top 10 or top 20 things to do.

Image of a laptop with high tech screens lifting off the screen. 
Stock Photos from Andrey Suslov / Shutterstock


While such approaches are good, they are insufficient to get confidence in the security of the software built. Lists of 10 or 20 things to do feel partial (they are), lists of hundreds of things-to-do feel insurmountable and paradoxically partial, too (having hundreds of things to do does not imply completeness). Such lists don't provide enough understanding of security, or to put it more formally like the Cyber Security Body Of Knowledge (CyBOK) does: "There is a long-recognised skills gap within the cyber security sector, an issue that experts agree is compounded by a fragmented and incoherent foundational knowledge for this relatively immature field."


Getting a better handle on security through better understanding is the goal of this initiative, launched in the U.K. in 2017, which has released so far four "Knowledge Areas" (KA) documents, including a Software Security KA that fills the understanding gap mentioned above for software security. This 24-page document, while recognizing it is necessarily partial and a somewhat subjective view on software security, does a great job at covering in few words what itemized lists do not: the broad categories of software vulnerabilities and how to defend against them.


In order of decreasing benefits, the defense can prevent the vulnerability altogether, in detecting it at various stages of the software development life cycle or in mitigating the effects of the vulnerability being exploited. Software Security KA calls for:

  • Prevention first: "The most effective approaches eradicate categories of vulnerabilities by design of the programming language or API."
  • Detection next: "For existing source code where full prevention of the introduction of a class of vulnerabilities was not possible, for instance, because the choice of programming language and/or APIs was determined by other factors, it is useful to apply techniques to detect the presence of vulnerabilities [...]."
  • Mitigation as a last line of defense: "Even with good techniques to prevent introduction of vulnerabilities in new code, or to detect vulnerabilities in existing code, there is bound to be a substantial amount of legacy code with vulnerabilities in active use for the foreseeable future. Hence, vulnerability prevention and detection techniques can be complemented with techniques that mitigate the exploitation of remaining vulnerabilities."


Both anecdotal evidence and engineering common sense confirm that indeed prevention > detection > mitigation, provided they are not worked around.


In particular, this short CyBOK document does not mandate any fixed set of approaches, but it helps professionals ask the right questions and position a project in the context of state-of-the-art practice and knowledge. It covers the choice of programming language, libraries and frameworks, development and programming practices, static and dynamic program analysis, run-time monitoring, and more. It succeeds in being at the same time deep and succinct, which makes it in my opinion relevant, understandable, and actionable. Software security needs understanding, and this CyBOK doc definitely provides some.


Yannick Moy is senior software engineer at AdaCore. AdaCore, with headquarters in New York and Paris, is centered around helping developers build safe, secure, and reliable software. With over 20 years of experience working with the most respected companies in the avionics, aerospace, and defense industries, AdaCore builds tools and provide services that ease the complex and often difficult process of developing high-integrity software. The company brings its time-tested technologies, expertise, and services to help a whole new generation of developers as the need for truly secure and reliable applications expands into industries, such as automotive, medical, energy, and IoT.


Read more on software security

 Learn more

  • Bookmark to keep pace with the latest aerospace technology news & information.

  • Learn about AeroPaks to access 8,000+ SAE aerospace standards, specifications, recommended practices, and resource documents available in SAE MOBILUS.

  • Subscribe to SAE MOBILUS for access to more than 200,000 resources, including aerospace standards, technical papers, eBooks, magazines, and video.

  • Visit  SAE International's Knowledge Hubs -- access points to the best industry resources, training, and current news -- designed to provide everything you need to know about emerging mobility technologies.