Application Security

Is your software supply chain secure?

When we think of a supply chain, a company in the industrial area and its factory receiving its raw materials soon comes to mind. This thought is not incorrect, but we must remember that the term “supply chain” refers to the delivery of inputs for the production of some good or service.

You can also listen to this article:

The supply chain in software production is often neglected precisely because of this vision, an image that, because it is a digital good or service, would not rely on the delivery of inputs. But think again and you will see that there are many similarities between the two forms of supply chains.

We need to understand that software production is also a process of creating a good or service, and as such has its needs during the production or construction process. 

Thinking about the security of the software supply chain is also a fundamental point to ensure the security of your applications. And in this article we don’t want to deal with pipeline security, after all, we already have an article about that. At this point, we want to address some points that may help in your planning.

What is a supply chain

We can understand the concept of “supply chain” as the process by which a company guarantees the flow of people, activities, information and also resources involved in the activity of production or creation of a good or service that has as extreme points the suppliers and customers.

We can see that, by definition, we do not have something there that says that only physical products have supply chains. After all, everything has its supply chain, and why not our software?

Thinking this way, we have to think about how our software, as products or services, will be created or produced. We also need to think about how this will be delivered to our client, since the original concept shows us that we need to think about the whole process from end to end.

A software supply chain is very similar to what we find in a more traditional industry model, and also to what we associate more easily. However, in the same way, you need to identify and trust your raw material, which in this case are the codes, the possible libraries and the packages created. 

Also, you’ll need to assemble them, use a network structure to deliver them to a storage system – which can be your data repository – so, with all this, your software can be used by your client.

It’s a complete process right down to your client. In the case of software production, the company must look both ways because at one moment it may be someone else’s client and at the other moment it could be one of your clients.

Looking both ways

It is natural that when we talk to our customers about the supply chain, we have two basic reactions

The first is that we realize that the topic is new to the company, that has never thought of producing software as a delivery platform for a product or service, which has its own supply chain.

And this is interesting because it puts us in front of a scenario where the construction of the software was often not very planned, something more organic in its construction.

From a certain point of view, this can even be a positive point. After all, it doesn’t bring vices or even previous understandings that may have been placed incorrectly. But it also brings us to a very cruel reality in the area of software development, where companies still don’t know what application security really is, and keep thinking about code security as putting tools to “sweep” the code and move it automatically on a production conveyor belt.

The second point we realize is that in cases where the company already has a perception of the software supply chain, even if there is already a delivery process or even resource use designed, there is often the belief that its supply chain takes place between the company and its supplier. In other words, it forgets that at some point it is someone else’s supplier.

To start thinking about the security of our software supply chain, we have to keep these four steps in mind:

  • Make sure that our process is consistent and has quality;
  • Identify all the resources in your pipeline (people, code, dependencies, the infrastructure);
  • Ensure the security of the code (product) both in storage and even in transit;
  • Ensure that the final product has been validated and delivered as expected.

By ensuring these points, we are consistently working to secure our production flow, and thus our supply chain.

What do your contracts require?

We increasingly need to understand that building software is not just about creating a sequence of commands and their actions. Today it is already a normal process for companies to have their software plans aligned with regulatory or even contractual needs, which must be observed. 

Regulations such as PCI-DSS place a number of points on software producers that must be observed in order for them to be understood as systems that is in conformity to their requirements. On the other hand, there are new laws that are increasingly demanding regarding how systems and applications handle and protect data. 

With this in mind, within our supply chain we have to know what the consequences will be and what the action plan will be if, for example, a data leak occurs on one of our resources – and by resources we can understand suppliers, people or even assets such as libraries that have some kind of vulnerability.

This is only possible when we can understand and perceive the entire flow of activities, resources and structures needed to produce our good or service. In other words, if you know your supply chain.

In order for this to become a somewhat easier process, it is interesting to know the entire flow of data, in both directions. This knowledge will make it easier to identify possible flaws and try to understand what and how a flaw can happen within your flow. After all, it will allow you to be prepared to act in a situation like this.

The important thing here is to seek to understand your entire flow!

Development is not just technology

It’s natural that when we talk about security in development, it goes straight to how we adopt the technology and how we build our infrastructure.

What we often forget is that development is also formed by a large and complex process, which must be fully understood.

It is very important to remember that the process can also have security implications.

In this case, there is no direct solution that can be applied and your process will immediately become safer. After all, what makes it safer is the complete understanding of it and how it can be bypassed or not. We have already talked a little about this in this other article, but we want to reinforce it with another point.

Threat Modeling can be a great tool for you to understand your process, the flow, and how this flow can be impacted by possible threats.

Using this methodology, you can understand how threats can influence the construction of your supply chain, helping you to notice points that can be improved and those that can be reinforced through validation steps.

Know your process, design your entire workflow and it will be much easier to understand.

Audit your supplier

There is a very interesting saying on the American market: “trust but verify!” It sounds rude, but think of it as your guarantee for your product.

Whenever we talk about security in the supply chain, we often ask how the supplier’s development process is guaranteed.

It’s not difficult to have the answer that the process and the security guarantees are put into contract, and that’s how both the security and the delivery of the product are guaranteed. It’s not wrong at all, but we understand that this is by no means a guarantee that your supplier is following all the points placed in the contract. 

We know that by means of a contract it would be possible to seek redress for any problem. However, have you stopped to think what the cost of this problem would be?

As much as your supplier is and has your trust, help him in this process. Together with your supplier, build a secure development process, create validation and audit schedules so that this process is maintained and executed.

In this regard, the two gain: you, by making sure your code is being handled correctly, and your supplier, who now has a more suitable process for producing more secure codes.

Remember that there is currently a very high turnover value for development professionals. And this impacts directly on companies that work with software factory models. With this in mind, is it if they are ensuring that this exchange of professionals does not affect the security of your product?

How’s your support?

Ensuring the security of a supply chain is an exhausting, complex and difficult process and necessarily needs the support of managers. How is yours?

This support is of utmost importance, as ensuring the security of your supply chain can affect two key points within the software production process.

The first point can be time. It’s possible that because you don’t use a lot of care and or processes that give you more security, your production time is really very low. 

This can fool everyone, showing that your process is efficient and that you can deliver products earlier. However, how is the final product security? Does it help to put a product with security problems into production quickly, which will end up generating stress and rework?

This point can arise during discussions to improve the security of the supply chain process. How will this affect the speed of delivery? Well, this is very relative, but it can affect and slow delivery. However, a more reliable supply chain can ensure better security in the final product, eliminating a number of problems later on. 

The second point is investment!

There is no way, you will need investment to take the necessary actions to ensure the security of your supply chain. 

For example, how will you justify the time and hours worked to implement or validate a secure development process at your supplier, since the normal thinking is that this is a point that should be taken by the supplier ?

To help in this process, start by creating some categories of risk, In addition to helping in the search for support, demonstrating what you are actually looking to solve, this shows the manager the importance of investments in this area.

We can suggest some points like:

  • Business Risks, which may be for regulatory, contract or even legal reasons;
  • Operational risks;
  • Market risks, e.g. dependence on a single supplier;
  • People risk;

These are just some examples. In this way you can identify what may be most relevant within your organisation and seek to demonstrate the gains from the right investment in security.

Have you looked at your cloud?

It is not easy to find nowadays a development process that has not been affected by cloud computing concepts. This aspect brings a new point into the companies and that can often be neglected.

Here we have two points to highlight when it comes to the supply chain.

First, we can look at our cloud vendors and understand how they can help us or ensure the security of our platform within the contracted space. Often these guarantees are for the delivery of tools and services that can be used to ensure this security, but they need to be operated in a correct way.

Ensuring that our teams have the proper understanding and knowledge of these resources is critical to ensuring the security of both the product itself and the workflow within the supply chain.

Remember the previous topic? Here can be a point about operational risks that you can raise and demonstrate their importance.

A second point is about the portability of your business among cloud providers – is that possible in your case?

From a business risk point of view, you need to understand whether or not you’re going to have your business plastered with your supplier’s technology, this can prevent its migration or even evolution.

Understand and map the structure and services of your cloud provider. Also, understand whether it is possible to migrate from one vendor to another without having any or little impact on your business.


We believe we can deliver to our reader a text that can at least stimulate them to seek to understand and improve the security of their supply chain. Of course we can help in each of these steps but, much more importantly of placing ourselves as service providers, we want to be knowledge builders and that’s why we always try to bring points that affect software security.

Ensuring supply chain security is a complex but very important process and we know that it is a difficult process to “sell” in many companies, but we believe that with this text we can help.

As an example of possible damage caused by supply chains, we want to suggest a few more links to read, and we also want to know your opinion on the subject. Leave us your comments.

I’ll see you next time!

Nova call to action
About author


Over 15 years of experience in Information Security and Applications, graduated in Data Processing worked as a Professor and participated actively as an instructor on trainings to more than 6000 developers and IT teams. Father of two daughters and trader on free time.
Related posts
Application Security

Finding classes for exploiting Unsafe Reflection / Unchecked Class Instantiation vulnerabilities in Java with Joern

During a pentest engagement we found a Java application vulnerable to unsafe reflection [1]. This…
Read more
Application Security

Mitigating Vulnerabilities: Elevating Security Proficiency in Software Development

In the ever-evolving digital landscape, the significance of software security cannot be overstated.
Read more
Application Security

The Importance of Supply Chain to Application Security

When we think about software development, we usually think about complex technical concepts…
Read more

Deixe um comentário