RSS Amplifier

Daienso Lab Tech News · May 12, 2026

Participating in the global software supply chain: Security assurance for IoT-Edge-Cloud software in the era of AI

0
Sign in to vote or save

Linh Truong · Daienso Lab Tech News

Much have been said that Vietnamese software industries must develop, own and sell software components, AI/ML models, etc., reducing reliance on the low-margin outsourcing services. Additionally, in the current global trend, Vietnam’s software outsourcing services have faced great challenges with new customer acquisitions and (old) customer retention under dynamic requirements of complex AI-intensive software development, while several outsourcing software development works have been shifted to AI tools and agents. This further motivates the “develop-and-own” of key software components for the Vietnamese local market and the global market. But providing software components and AI/ML models that can be part of a global software supply chain requires Vietnamese software providers to address one crucial dimension: security assurance for software built with multi-provider components to comply with diverse regulations. Solving this dimension is especially challenging for small Vietnamese software companies and teams.

Since many years, my research and consulting have focused on software for IoT-edge-cloud ecosystems. To date, we are in the situation that the software supply chain for IoT-edge-cloud applications and services is not only about (i) (traditional) software components (executables, libraries, frameworks, service-based components, etc.) but also (ii) AI/ML models (which needs other software components to train, host and serve the inference) and (iii) the data, on which not only AI/ML models are built, but also intelligent algorithms for analytics-based decision making reply (e.g., RAG and knowledge graphs). It is challenging to deal with security assurance to meet complex, stringent regulations, while tackling emerging, unanticipated anomalies, threats and vulnerabilities. With other colleagues, I do some research on security assurance under the EU project SECASSURED. From the project research and my experiences, two aspects I want to share to a Vietnamese participant in the global software supply chain: (i) understanding of the modern software chain in edge-cloud continuum and (ii) engineering methodologies for addressing security assurance requirements/regulations for and with AI-empowered functionality.

  • Stakeholders: more than the common provider of software components, e.g., the provider of service-based components offering via SaaS API, we do have the provider of AI/ML models, and the provider of data used through the development and operations of software components and AI/ML models.

  • Stakeholders are global and not all stakeholders present a clear engagement model, security assurance relevant data, and liability definitions for their software, AI/ML models or data, although their offerings can be powerful and widely used, e.g. open sourced software and AI/ML models.

  • Often a single party - the participant - plays different roles: software provider, AI/ML model provider, and data provider. These roles from a single party are seen by other parties via a complex view of software component and artefact dependencies. Even if you develop and own your components and integrate existing, third-party components (via buy or freely reuse) for your product, you still need to manage this complex view and related, external providers of the third-party components.

Essentially, when building an IoT-edge-cloud product for internal uses or for the global market, the product relies on many different software components, AI/ML models and data provided by different stakeholders. You will have set of software products, and, for individual products, security assurance must be continuously monitored for complying with stringent regulations and supporting customer retention. Therefore, for the security assurance of the products, stakeholder management and engagement are crucial for timely security compliance related data exchange and rapid resolutions/responses to eminent and emerging live threats and vulnerabilities. People in research and industries know well the above-mentioned points. But the challenging question remains: how to approach this difficult problem in a systematic manner, say if you are a small software company or a small team?

From our understanding of the software supply chain through which we offer/provide our software components, AI/ML models and data, we need a systematic approach to address more than just continuous live, scenario-based testing, monitoring, and detection of runtime threats/vulnerabilities by enabling holistic, proactive and continuous verification, detection, validation of security compliance cases across developments and operations. Furthermore, the security assurance is for software component, AI/ML model and data together. We advocate engineering methodologies centered around: principles —> procedures —> mechanisms.

  • Principles: the why - your key reasons and values for tackling security assurance. Is that your goal is to meet the regulations from the EU Cyber Resilience Act (CRA), the EU AI Act, the IoT Cybersecurity Improvement Act of 2020, the Executive Order 14028, ISO/IEC 27001, or NIST SP 800-218 for selling your software and done? Must you need to address various regulations while continuous engaging with your customers to solve the never-ending anomalies, threats or vulnerabilities during the lifetime of your software?

  • Procedures: the what and when - fundamental steps and activities that allow you to achieve the key values and goals. Will you address security assurance at the integration and operation phases or should you start at Day 0 of the software requirement engineering? Which workflows should be defined for discovering vulnerabilities and compliance issues? What types of observability data and insights must be exchanged? When should you ask your partners to provide further data for validating the partner’s software and AI/ML models (or rather can they inform you about the situation)?

  • Mechanisms: the how - concrete tools you can use for anomaly detection, threat detection and vulnerability scanning, etc. Which traditional tools and modern agentic systems/LLM-based tools should be used? Which tools help you to determine and scope your solutions, while avoiding exceeding effort for dealing with small problems? Which tools are suitable for very different but integrated aspects of software, AI/ML models and data observability in a single product?

Often, small software companies or small teams find challenges in determining when and where they should start in the lifecycle of the product they want to develop and own, due to the cost and the complexity of regulations. Many times, naturally most of us start from mechanisms to select tools without thinking too much about the procedures, especially the type of evidence-supported assurance data and its exchange. And this is not good for adapting to the change of threats/vulnerabilities and of our own software. We may think that human operators are the main factor for security assurance breach like the case of IoT-cloud services for environment monitoring in Vietnam, but human operators may not be the main cause if we apply appropriate security assurance engineering for the data observability aspect (or least reducing the damage of breach). Lack of design knowledge and/or lack of robust engineering may be the real cause. Are you in such dilemma? If you are a Vietnamese participant in this story, Daienso is happy to hear your cases and work with you!

Acknowledgement: I am grateful to many colleagues in SECASSURED for our intensive discussions about the stakeholders, their possible tools and tasks, and the principles-procedures-mechanisms view.

References:

Read the original on daienso.substack.com

Comments

Nothing yet. Say the first thing.

    Sign in to join the conversation.