Software and Embedded Cybersecurity: Develer’s Approach

Interview with Marco Giusti, Cybersecurity Director at Develer

Develer is known for the technical quality of its software and embedded projects. When and why did security become an explicit part of this approach?

Security at Develer is nothing new. It has always been part of the way we approach projects, because our clients often operate in industrial or enterprise environments where reliability is non-negotiable. A bug that goes unnoticed on a device deployed in the field, or a vulnerability that exposes sensitive data, is not just a technical issue: it can have a direct impact on the client’s business.

What has changed over the past year is that we have started to formalize this approach and make it more visible, aligning it with internationally recognized standards and introducing a dedicated role to coordinate security and compliance practices throughout the entire development lifecycle, from firmware to application software.
This was not a sudden decision. It is the natural evolution of a way of working that was already part of Develer, but until recently remained largely implicit – embedded in people’s knowledge rather than documented processes.

There is also an external factor that has accelerated this journey: the market has changed, attacks and security breaches are steadily increasing, and clients are increasingly aware of the risks. For us, security therefore concerns not only the products we deliver, but Develer as an organization and its business continuity – as well as that of the clients who rely on us.
Today, we want all of this to be structured, measurable and, above all, visible to the people who work with us.

When Develer starts a new project, what are the first things you assess from a security perspective? Do clients typically expect these questions, or do they come as a surprise?

In most cases, clients do not expect security questions to come up so early. They approach us with a product idea or a specific technical requirement, perhaps with a deadline already in mind, and expect the conversation to focus on features, technologies and timelines.
Instead, we take a moment first to ask where the device will be installed, who will have access to it, what kind of data it will handle, and what regulatory requirements apply to the industry in which it will operate.

These are questions clients often do not even realize they need to ask, because their job is to focus on the product, not on security.

For us, this initial stage is already a way of protecting the client. Identifying a risk during the analysis phase may only require a conversation; discovering the same risk once development is underway – or worse, after release – can cost time, budget and sometimes even the trust of end users.

That is why our role at this stage is not simply to execute, but also to guide: we help clients ask the right questions before a single line of code is written.

How does this focus on security translate into the way you actually develop code? What makes the difference compared with a software company that pays less attention to these issues?

The difference is visible in the details of the process rather than in an announcement or a certificate hanging on the wall.
Code review, for example, is not simply a functional quality check. When reviewing a colleague’s work, our developers also consider whether that piece of code could be exploited, whether errors are handled correctly, or whether it exposes something it should not.
These questions become second nature when security is part of the technical culture rather than a control imposed from above.

We do not believe there is a final point at which security can be considered “achieved” once and for all. We work according to a continuous improvement approach: practices, technologies, people’s skills and processes are constantly reviewed and refined, cycle after cycle.

This also means investing in the skills of the people who design and write code every day, rather than simply adding automated checks. A tool is only as effective as the person using it and interpreting its results.

Excellence in the process is something we can strive for, and that is what we work towards every day. Absolute security, on the other hand, is by definition an unattainable goal – not because of a limitation on our part, but because threats evolve, regulations change, and the tools we use today will eventually be superseded.
Even the world’s largest and most structured organizations, despite investing enormous resources in security, remain exposed to risk. For this reason, the true measure of maturity is not simply “being secure,” but being able to continuously adapt. And it is precisely this honesty that makes our approach credible to clients who understand security.

One of the less visible risks for companies commissioning software is the dependency supply chain. How do you manage it at Develer’s scale?

Modern software relies on external dependencies: libraries, frameworks and other third-party components that it would be impractical to build from scratch.
It is a risk that few clients consider when thinking about the security of their product, because they tend to imagine security as something that concerns only the code written specifically for them. In reality, a significant part of the risk surface comes from outside – from components that were not developed internally but still become part of the final product.
And this is not just about technical vulnerabilities. The license under which a dependency is distributed can also represent a risk, often overlooked, with real legal consequences if it is not carefully assessed.

Qui va fatta una distinzione che consideriamo fondamentale, e che spesso il cliente non si aspetta di sentire. Quando un progetto viene consegnato e il rapporto si conclude lì, quello che offriamo è una fotografia della sicurezza al momento della consegna: un controllo puntuale, fatto bene, che include anche la verifica delle licenze delle dipendenze utilizzate, ma legato a quel preciso istante nel tempo.

Here, we make a distinction that we consider fundamental and that clients often do not expect to hear.
When a project is delivered and our involvement ends there, what we can provide is a snapshot of its security at the time of delivery: a thorough point-in-time assessment, including checks on the licenses of the dependencies used, but one that inevitably refers to that specific moment.

Vulnerabilities in dependencies, however, do not respect that snapshot. They may be discovered months or even years later in components that were considered secure at the time of release.

For projects where we remain involved in ongoing maintenance, the situation changes significantly. In this case, we can implement continuous monitoring that follows dependencies well beyond delivery, from both a security and license compliance perspective, allowing us to respond when a new risk emerges – even in code written long before.

It is the difference between security and compliance assessed at a single point in time and a security posture that continues to evolve over time. It is something every client should clarify with their supplier from the outset: what happens to the product’s security the day after delivery?

With the Cyber Resilience Act coming into force and Develer working towards ISO 27001, how do you combine regulatory compliance with your internal security maturity journey?

They are two different things moving in the same direction, and I think it is important not to confuse them because they follow different principles.

The Cyber Resilience Act (CRA) is a European regulation. Manufacturers of products with digital elements – including not only connected hardware, but also standalone software and firmware – will be legally required to comply with it. It is not a commercial choice or an added value to promote: it is a legal obligation with specific deadlines.

Some of our clients, particularly smaller or less structured organizations, are not yet familiar with it and risk being unprepared as those deadlines approach.

ISO 27001, on the other hand, is a voluntary certification standard. No one requires us to pursue it, but we have chosen to do so as part of our maturity journey because it provides an internationally recognized framework for structuring everything we have discussed so far: processes, continuous improvement and people’s training.

In practice, an organization that works effectively according to a standard such as ISO 27001 is better positioned to respond to a regulatory requirement such as the CRA. The fundamentals of risk management, incident response and process control overlap significantly, although the CRA introduces specific product requirements that ISO 27001, being primarily focused on organizational information security management, does not cover on its own.

For us, the message is simple: we comply with what the law requires, and we invest in what we choose to do beyond that.

Many developers now use AI tools as part of their work. How do you decide which ones to use, and how do you ensure that clients’ code remains protected?

We use AI tools in our daily development work, as many developers do today. The difference, I believe, is that at Develer this is not a decision left to individual developers, free to adopt whichever tool they prefer.

We carefully assess which tools can be used, and we have an internal policy defining how they should be used – particularly what must never be shared with an external system or third-party model.

The most sensitive aspect is client code. When we work on a project, that code is often the client’s intellectual property and can sometimes be particularly sensitive. It is our responsibility to ensure that it is not used to train external models or made accessible to anyone who should not have access to it.
It is an area where few suppliers are truly transparent, because transparency means openly stating which tools are being used and under what constraints, rather than leaving the issue vague.
For us, this has become another way to build trust with our clients: we do not simply say that we use AI – we explain how we govern its use.

What would you like a CTO or Product Manager considering Develer for a project to take away from this conversation about security?

I would like them to understand that security at Develer is not an additional layer placed on top of our technical work, something that is activated on request or billed separately.
It has always been part of the way we work. What we are doing now is making it more visible and more structured, because we believe clients should be able to see it rather than simply take it for granted.

Absolute security is an unrealistic goal, as we have already discussed. What we offer is not an impossible promise, but a structured, measurable and continuously improving approach to managing residual risk. Anyone who presents security as a definitive state that can simply be reached probably does not fully understand the field.
What I can guarantee is a process of continuous improvement: one that constantly challenges itself and adapts its security posture as the context, threats and regulations evolve.

Choosing a development partner ultimately means deciding who to entrust with something that will eventually go to market under your own name and be used by your own customers. The ultimate responsibility for the product remains with the client. That is precisely why we do not consider security an optional service, but a commitment we make together with the client from day one.

If there is one thing I would like people to take away from this conversation, it is this: with us, security is not a question we start asking only after something has gone wrong. It is a question we address together, from the very beginning.