While connected systems offer easier monitoring, upgrading and enhancement, these improvements have introduced security-critical devices such as xx to new vulnerabilities. Securing embedded software for these devices has consequently become even more essential, but far too often, companies still “design first, test later,” invariably creating insecure code that puts industry and individuals at risk.

With traditional software development, requirements flow to design, to code (perhaps via a model), and to test. With agile development, requirements are built up iteratively in layers from the inside out, each with its own loop of requirements, design, code, and test. With either methodology, ensuring that security requirements are an integral part of the development process will lead to a far more satisfactory—and less costly—outcome than merely looking for vulnerabilities at the end. This proactive approach to designed-in security is referred to as “shift left” of the software development life cycle.

Defense-in-depth and the V-model

Shift left implies a systematic development process where the code is:

• written in accordance with secure coding standards
• traceable to security requirements
• tested to demonstrate compliance with those requirements as development progresses

Shift left integrates security-related best practices into the V-model software development lifecycle that should be familiar to developers in the functional safety domain. The resulting Secure Software Development Life Cycle (SSDLC) represents a shift left for security-focused application developers and provides a practical approach to ensuring that vulnerabilities are quickly addressed.

These same design principles can be applied to the DevOps lifecycle, resulting in what has become known as DevSecOps. Although the context differs between DevSecOps and the SSDLC, shift left implies the same thing for both: an early and ongoing consideration of security, with functional and security requirements established at the outset (V-model) or before each iteration (DevSecOps).

Regardless of the process followed, developers should test early and often using the appropriate tools, tests and techniques. In the V model, these are largely analogous and complementary to the processes usually associated with functional safety application development (figure 1).

(Figure 1)

In the DevSecOps model, the DevOps life cycle is superimposed with security-related activities throughout the continuous development process (figure 2).

Figure 2: Use of security test tools and techniques in the DevSecOps process model

Requirements traceability is maintained throughout the development process in the case of the V-model, and for each development iteration in the case of the DevSecOps model (shown in orange).

Some SAST (static) tools confirm adherence to coding standards, ensure that complexity is kept to a minimum, and check that code is maintainable. Others check for security vulnerabilities but only to the extent that such checks are possible on source code without the context of an execution environment.

White-box DAST (dynamic) enables compiled and executed code to be tested in the development environment, or even better, on the target hardware. Code coverage confirms that all security is fulfilled by the code, and that all code fulfills one or more requirements. Source to object code traceability can also be confirmed if required.

Robustness testing can be used within the unit test environment to help demonstrate the resiliency of specific functions, whether in isolation or in the context of their call tree.

Fuzz and penetration black-box testing techniques traditionally associated with software security remain of considerable value, but in this context are used to confirm and demonstrate the robustness of a system designed and developed with a foundation of security.

Provide bidirectional traceability

The IEEE Standard Glossary of Software Engineering Terminology defines traceability as “the degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another.” Most functional safety standards require evidence of bidirectional traceability, which means that traceability paths are maintained both forward and backward. Automation with tools such as the LDRA tool suite makes it much easier to maintain traceability in a changing project environment.

Shift left in practice

Building security into the software life cycle from the start by following best practices familiar to developers of safety-critical applications is a cohesive and highly effective approach to developing safe, secure, and reliable embedded software for critical connected devices.

By Mark Pitchford, Technical Specialist, LDRA
Published by Electronic Engineers  1st June 2024

Read published article here – Electronics for Engineers May 2024 :: 24 (yudu.com)