Connectivity has revolutionised embedded systems, shifting them from fixed-function, device-specific tools to cloud-connected platforms that support remote monitoring, updates, and feature expansion.
But with these benefits comes increased risk. A larger attack surface exposes systems to unauthorised access, often from opportunistic attackers scanning broadly for weaknesses. Their success—regardless of intent—can lead to serious consequences: liability, compliance breaches, reputational harm, and customer fallout.
Mitigating these risks requires a secure development approach. Static Application Security Testing (SAST) identifies vulnerabilities in source code early, while Dynamic Application Security Testing (DAST) exposes runtime weaknesses. Together, they reduce exposure and help secure connected systems by design.
Connected systems are central to innovation in industries such as aerospace, automotive, and healthcare. These systems rely on both cloud-based infrastructure and embedded endpoint devices, where application security is critical, but often overlooked due to external pressures.
Cybersecurity isn’t just about protecting data. It requires system designs that secure both the data and the interfaces to it. Traditional security testing is reactive, identifying vulnerabilities late through performance, penetration, and functional tests (Figure 1).
Figure 1: Traditional security testing is reactive
A better, proactive approach is to design security into software from the start. This involves using secure coding standards, tracing code to security requirements, and verifying compliance throughout development. Figure 2 illustrates the resulting Secure Software Development Life Cycle (SSDLC).
Figure 2: The Secure Software Development Life Cycle is proactive
SSDLC integrates security into each stage of development:
SSDLC shares the rigor of functional safety standards and leverages proven tools such as SAST, white box DAST, and traceability to build security into software—rather than patching it in later.
Figure 3 illustrates how SSDLC implements the “shift left” paradigm by leveraging SCSA (SAST) and SCDA (DAST) early in the development life cycle. In traditional workflows, “Red.exe” represents the point at which a system would typically begin security hardening. In contrast, “Green.exe” illustrates how SSDLC yields a robust executable by design.
Figure 3: Leveraging SAST and white-box DAST to implement the “Shift Left” paradigm
The model shown in Figure 4 integrates DevSecOps principles, embedding security checks throughout continuous integration and delivery cycles.
Figure 4: Leveraging SAST and white-box DAST in the DecSecOps model
Static Application Security Testing (SAST) SAST scans source code to identify vulnerabilities before the build stage. It provides the earliest security feedback and prevents vulnerabilities from being introduced. As part of SSDLC, SAST becomes a continuous and automated part of development.
SCSA is a SAST method focused on enforcing secure coding standards and early vulnerability detection. Unlike more basic offerings, advanced tools like the TBvision component of the LDRA tool suite detect subtle, complex issues. Its SCSA settings can be tailored for quick scans or in-depth analysis.
As the name implies, Dynamic Application Security Testing involves executing the application under test – either in part or in its entirety.
“White box” DAST involves internal testing techniques such as unit tests, coverage analysis, and robustness testing, typically used in functional safety environments. Conversely, “Black box” DAST leverages external scans such as fuzz and penetration testing to evaluate system defenses without access to the source code.
The two approaches are therefore complementary. White-box DAST is ideal for SSDLC and works in tandem with SAST to shift security left, while black-box DAST confirms that built-in protections are effective.
SCDA is a white-box subset of DAST that dynamically tests secure code behaviour, often on the target device. Unlike black-box testing, SCDA requires only the relevant part of the application to be available. It provides runtime proof that security requirements are met.
The CERT Division at SEI promotes proactive cybersecurity through secure coding practices. Their top 10 list (plus two “bonuses”) aligns well with the capabilities of the LDRA tool suite, as described in the following.
CERT best practices provide a useful reference point to put the LDRA tool suite’s SCSA and SCDA capabilities into context.
All external data should be treated as untrusted. The LDRA module of the LDRA tool suite tracks unsafe data paths, while unit testing with TBextreme verifies defensive code and robustness.
For example, there are many potential sources of untrusted data in today’s connected car, and that situation can only intensify as there is a move towards autonomy (Figure 5). This “validate inputs” practice clearly applies to each of those data sources, but perhaps less obviously it is also important that data from other domains is also considered as untrusted.
Figure 5: Automotive attack surfaces and untrusted data sources
To follow the CERT guideline for input validation, all external inputs must be checked for correct type, format, length, and range before use. The LDRA tool suite taint analysis capabilities are effective for identifying code paths where untrusted data reaches critical operations without validation, while unit testing with the TBextreme module verifies defensive code and robustness.
CERT advises treating all compiler warnings as potential vulnerabilities. Many developers tend to attend only to compiler errors during development and ignore the warnings. CERT’s recommendation is to set the warnings at the highest level available and ensure that all of them are attended to.
The TBvision component of the LDRA tool suite augments compiler checks with deep static analysis.
The TBvision component of the LDRA tool suite calculates several applicable complexity metrics to help developers evaluate their code.
This CERT practice requires that any data passed to external systems be properly sanitized.
Taint analysis can trace untrusted data flowing to output sinks. The TBrun component of the LDRA tool suite alongside the TBextreme module simulates attacks to test the sanitization of outputs.
The secure coding techniques supported by the LDRA tool suite provide an essential component for a defence-in-depth strategy. Others include secure boot to make sure that the “correct” image is loaded, domain separation to defend critical parts of the system, MILS (Least Privilege) design principles to minimize vulnerability, the minimization of attack surfaces, and the application of security focused testing.
By understanding and leveraging the strength of each component and compensating for weaknesses through other techniques, the effectiveness of the strategy overall can be optimized.
The LDRA tool suite’s support for source code level “fuzz” or robustness testing is pertinent here, and static analysis tools typified by the TBvision component of the LDRA tool suite support the automation of source code audits.
There are several pertinent secure coding standards to choose from, and every opportunity to tune them to the needs of a particular development organization.
For example, CERT C is a coding standard designed for the development of safe, reliable and secure systems that adopts an application centric approach to the detection of issues. MISRA coding guidelines offer another option, despite a common misconception that they are designed just for safety-related, not security-related, projects.
The LDRA tool suite cannot help with the definition of security requirements but the TBmanager component can demonstrate their full and exclusive implementation.
Not all the recommendations can be automated using the LDRA tool suite because they involve the adherence to design principles, not implementation or verification & validation techniques. However, in each case the TBmanager component of the LDRA tool suite can help to demonstrate the full and exclusive implementation of those designs.
They are:
The traditional approach of “build first, test later” is no longer sufficient. Penetration testing is most valuable when validating a secure system, not uncovering flaws late in development. By adopting SSDLC and embedding SCSA and SCDA early, teams can reduce risk, lower cost, and build more secure software by design.
Website: Cybersecurity
White paper: Secure code properly
White paper: Achieving the ISO/SAE 21434 software objectives
Technical overview: Applying IEC 62443-4-1 to IACS
Article: 7 steps to secure connected embedded systems
Video: Developing software to be compliant with IEC 62443-4-1
Article: Developing a safe, secure system: SEI CERT C versus MISRA C
Article: Process control cybersecurity gets serious with IEC 61508 and IEC 62443-4-1 in tandem
Webinar on demand: Application of IEC 62443 series for components and IACS
Webinar on demand: Process Control Cybersecurity Gets Serious: IEC 61508 & IEC 62443-4-1 in Tandem
Email: info@ldra.com
EMEA: +44 (0)151 649 9300
USA: +1 (855) 855 5372
INDIA: +91 80 4080 8707