Blog Post
Securing Embedded and IoT Development
RESCALE in the GRiSP.io Pilot
Embedded and Internet of Things platforms are built from more than application code. They combine hardware interfaces, operating environments, communication libraries, cloud services, update mechanisms, and third-party dependencies. A weakness in any one of these areas may affect the security of the complete product.
The first RESCALE pilot applies the project’s technology to GRiSP.io, a distributed cloud-to-edge and IoT platform developed by Peer Stritzinger GmbH. The pilot explores how security assessment can become part of the development process and how the resulting evidence can support more trusted deployment decisions.
A Distributed Environment with Different Trust Levels
GRiSP.io supports applications that operate across embedded devices, edge infrastructure, and cloud environments. Functions may be placed on different systems depending on factors such as processing capacity, network bandwidth, latency, and energy use. Security adds another important factor to these decisions. A component should not be deployed on a system based only on performance or availability. Its dependencies, assessment results, communication requirements, and the trustworthiness of the target environment must also be considered. The GRiSP ecosystem provides a realistic setting for this work. It includes Erlang-based software, hardware communication libraries, networking components, remote update functionality, and dependencies from several sources. Each of these elements forms part of the wider supply chain.
Bringing Security Assessment into GitHub CI
The initial pilot deployment integrated the RESCALE Static Code Analysis Module into PST’s GitHub-based CI workflow.
When the pipeline runs, it retrieves the required analysis container and executes the configured tools against the selected source code. The results are then passed to the SSCG Generator, which creates the Static Supply Chain Component Guarantee associated with the assessed software. The workflow supports two modes. The SSCG can be submitted directly to the RESCALE platform, or it can remain available as a pipeline artefact for local inspection. In both cases, the developer receives access to the generated report without having to run the complete analysis process manually. This makes security assessment part of the ordinary build process. Developers can receive structured findings during development rather than waiting for a separate assessment before release. The integration also preserves the connection between the findings, the SBOM, and the exact component version. This is essential because a report without a reliable link to the assessed software has limited value within a complex supply chain.
Supporting Different Roles in the Supply Chain
The pilot reflects the fact that supply-chain roles may change depending on the component being considered.
PST acts as the Producer of GRiSP platform components. It may also become a Consumer when it integrates or assesses a component supplied by another organisation. GRiSP.io customers can become Producers of their own applications built on top of the platform. This creates a multi-level supply chain in which platform software, customer applications, external libraries, and deployed systems all need to be connected through consistent evidence. The final use-case specification extends the workflow beyond static analysis. A Consumer can run dynamic testing against the component and generate a DSCG. TrustOR can then use the SBOM, SSCG, DSCG, and vulnerability information to create the TBOM.
The initial pilot demonstrated the GitHub CI integration and SSCG workflow. Deeper integration with the dynamic testing process and the full end-to-end TBOM lifecycle was identified as the next stage of the work. This distinction is important because the pilot documents both the progress achieved and the practical integration still required.
Lessons for Embedded Development
The GRiSP.io pilot shows that effective security integration depends on more than the quality of the analysis tools. Language support, SBOM generation, container distribution, CI configuration, report handling, and developer access to results all influence whether the technology can be used in practice. This is particularly relevant for the Erlang ecosystem, where some supply-chain and SBOM tools are less mature than their equivalents for more widely supported programming languages. The pilot helps identify where additional adaptation is required and where the RESCALE workflow can simplify the developer experience.
By bringing assessment into CI/CD and connecting the results to structured supply-chain evidence, RESCALE creates a path toward more trusted IoT and edge deployments. Security information becomes available closer to the point where software is developed, integrated, and prepared for deployment.