In this post, I’ll dig into some of the key EU regulations that are directly shaping supply chain security and discuss practical steps you can take to build a more resilient supply chain. When we talk about supply chain attacks, we’re not just referring to the direct targets, but to the entire ecosystem. Attackers often exploit the weakest point in the chain—perhaps an unpatched vulnerability in a third-party component or even malicious code that has been slipped into a software update. This makes supply chain security not just an IT issue, but a critical business concern.

A significant risk comes from the potential for backdoors to be introduced into widely-used software libraries. One notable example is the backdoor found in XZ Utils, a compression library used in many Linux distributions. This incident revealed how even seemingly trusted and ubiquitous software components could be compromised, providing attackers with hidden access.

EU Regulations Shaping Supply Chain Security

NIS2 Directive

The NIS2 Directive is one of the key regulations directly targeting supply chain security. It places obligations on “essential” and “important” sectors to actively manage their supply chain risks as part of their overall cybersecurity strategies. This means that organizations can’t just focus on securing their own systems—they need to also assess and manage the risks associated with their suppliers and service providers. In other words, if you’re relying on third-party software, you’re responsible for its security too.

Digital Operational Resilience Act (DORA)

DORA focuses on the financial sector and aims to ensure that financial institutions can withstand ICT-related disruptions, including supply chain incidents. A significant part of DORA’s requirements revolves around third-party risk management. Financial entities are required to monitor and manage risks stemming from their ICT service providers continuously. I find this particularly interesting because it reflects how the financial sector is being pushed to develop more rigorous and transparent supply chain security practices.

Cyber Resilience Act (Proposed)

The Cyber Resilience Act is an upcoming regulation that explicitly addresses software supply chain risks. It aims to impose mandatory cybersecurity requirements for software products, including the need to manage vulnerabilities throughout the software lifecycle. Although it’s still in the proposal stage, this act signals the EU’s intention to address software security from the development phase through to deployment, emphasizing that security isn’t just a one-time effort but a continuous responsibility.

Practical Steps for Building a Secure Supply Chain

With this evolving regulatory landscape in mind, how can businesses actually address these supply chain security concerns? Here are some practical steps:

1. Create and Use an SBOM (Software Bill of Materials) for Supply Chain Visibility

Building an SBOM (e.g., in formats like CycloneDX or SPDX) is one of the most effective ways to gain visibility into your software’s supply chain. Think of an SBOM as an ingredient list that provides detailed information about every component and dependency, including their versions and origins. By maintaining an SBOM and mapping your entire supply chain, you make it easier to identify affected components quickly when new vulnerabilities, like Log4Shell, are disclosed. It also enables you to scrutinize any changes or new additions that might introduce new risks, such as a backdoor in a dependency. Having this level of insight is crucial for addressing both security threats and regulatory requirements around supply chain transparency.

2. Regularly Assess Your Suppliers

Relying solely on certifications isn’t enough. Regular assessments of your suppliers are vital in maintaining a secure supply chain. This might involve reviewing their security practices, examining their own use of SBOMs, and conducting periodic audits. Keep an eye out for signs of compromise, such as unusual changes in the software packages they provide. By continuously evaluating your suppliers’ security measures, you reduce the risk of supply chain attacks and ensure that your suppliers are maintaining a security posture that aligns with your standards.

3. Adopt a Zero-Trust Approach

Implementing a zero-trust model in your supply chain management is an effective way to minimize the potential impact of a supplier breach. This approach assumes that no supplier is fully secure and therefore segments access to your network. By limiting the access that suppliers and third-party components have, you can contain the potential damage if one of them is compromised. This mindset not only mitigates risks but also supports a more robust, layered defense strategy that aligns well with the evolving landscape of supply chain security.

Conclusion

Supply chain security is no longer just an optional extra—it’s an essential part of any robust cybersecurity strategy, especially as the EU continues to tighten its regulatory requirements. Regulations like the NIS2 Directive and DORA directly call for organizations to address supply chain risks actively. Meanwhile, the proposed Cyber Resilience Act signals the EU’s growing focus on software security throughout its lifecycle.

While compliance is important, practical measures like using an SBOM and adopting a zero-trust mindset will go a long way in building a more resilient supply chain. Don’t overlook the risk of backdoors and malicious code in your dependencies. Supply chain security isn’t just about patching vulnerabilities; it’s about ensuring the integrity of every component in your software.

References

1. NIS2 Directive
2. Digital Operational Resilience Act (DORA)
3. Cyber Resilience Act (Proposal)

That said, while reading up on ITIL I see no reason why that should be the case. There does not seem to be any innate reasons why the change management process should hinder the agile or DevOps development processes. Both have a focus on ensuring the best way of working by focusing on the outcome and improving it through reviews or retrospectives.

My take is that both methods have an inherent focus on minimizing the risk in system development. The approaches are however different. To show this we first have to look at the definition of risk. Most literature define risk as the product of likelihood and impact. Traditional change management have a focus on the likelihood part of risk. Through testing and analysis the likelihood of a change impacting the production environment is reduced.

DevOps on the other hand focuses on minimising the impact by making small, revertible changes. When something goes wrong the main goal is to use the swiftness of the dev team to revert or fix the issue as quick as possible.

This miss-match is likely one of the reasons conflict often arise between development organisations and operations. This observation might not be a quick fix, but I think that if we observe the expectations of our counterpart we can get a better understanding helping us to create a way of working that fits our organization. When we see that we have the same goal (reducing risk) but different approaches we also get a common language to reach that common goal.

The first and easiest viewpoint is that of a business that isn’t producing a digital product, neither for yourself nor for your customers. Noteworthy here is that any website is acquired as a product from a third party. This means that no product development is performed in house. In this case the full extent of cybersecurity is to ensure that the IT-environment does not get breached. This means a focus on raising security through configurations and products as well as ensuring that you trust the products provided by your suppliers.

Next up we take the viewpoint of a Something as a Service (XaaS) provider. In this case you develop a digital solution and manage the data of your clients in your IT-environment. This includes both traditional software companies (such as Google) and organisations that build software to better serve there clients, e.g. the local sports team building an e-shop to sell tickets online. Now there is an extra focus on ensuring that the in-house software does not contain neither vulnerabilities nor malware. Since both these cases can have an impact on both the company themselves and the customers.

For a company that provides software that is run purely in the environment of their customer the focus might be more focused on providing software without malware. Since the impact of a vulnerability in the product is lower for them, while being part of a supplychain attack will be devastating.

With these viewpoints we note that your needs might vary, and once again we see the risk of confusion due to reading different things into the word cybersecurity. I’ve been guilty of this myself, as someone whom have worked close to vulnerabilities throughout my career I’ve had a focus on application security and delivering software without vulnerabilities. But that is just a small part of the field of cybersecurity.

But what part of this is most important? That is up to each organisation to decide. However, for a general answer we can look to the statistics. IBM has provided a report on the Cost of a Data Breach that can be used to gain some insights. In this report we see that the most common initial access vectors (entry point for bad actors) are still human related. The two most common attacks are phishing and stolen or compromised credentials. If we combine known vulnerabilities and zero days (not yet reported vulnerabilities) we end up in the same range. My conclusion is that the focus we have on vulnerabilities in the cybersecurity industry has paid of, and it is now easier to exploit the humans where the technical protections have not kept up.

Summary

Cybersecurity can be difficult due to the different meanings. One way to brake it down is into the following three focus areas:

1. Ensuring that the own internal IT-environment doesn’t get breached
2. Ensuring that delivered products are without vulnerabilities
3. Ensuring that delivered products are without malware

Depending on your organisation the priority of these might change, and one might affect another. Regardless, you need to understand what part or parts of cybersecurity is relevant to you and your customers. If not, you might be spending your money without protecting what’s important.

Lastly we have to normalize discussing the definitions of what we are talking about. Sometimes it’s not enough to ask if you know, we also need to clarify that we agree on the meaning.

It is important for all the users of open source to understand the nature. You cannot just expect or pressure the maintainers to update their software. Especially not if you use something with a small group of maintainers or being maintained in the spare time. Instead you have to get into the open source mindset and take advantage of the fact that everything is open. This means that anyone can read the code, and if needed create a fix. If a company decides to use free open source software they cannot expect the same level of service as if they bought a commercial product, but instead be ready to either wait or do the work themselves.

In the aftermath of Log4j there have been several of examples of harsh communication with maintainers. I hope that things will get better, and that companies get a better understanding of the implications of using open source. This does not only include the implications of bugs (security or other), but also the importance of being aware of the license agreements of open source. Sadly not everyone understand what can be expected of the software, and what can and cannot be used under what circumstances.

These are just a couple of considerations when using open source software, there are many more. Each company needs to their own assessment and decide how they will work with open source software. Let’s all do our part in asking the correct questions and spreading awareness, so that everyone can use the many benefits of open source.

How far have we come in our work with cybersecurity?

It is an understandable question. We need to see that the time and money put into security are adding value to the business. However assessing the progress in a comparable way is not always easy. As luck would have it there are standards for measuring the maturity level of cybersecurity. One of these models are OWASP Software Assurance Maturity Model, SAMM for short. As it is provided by OWASP it is an open source model that can be used by anyone free of charge, and the results are comparable both over time and between organizations. There are other models that do similar things, but due to the open nature of SAMM it’s a good starting point for any organization getting started.

The SAMM model measures 15 security practices in five business areas. Each practice contains two streams, represented by a set of activities and resulting in a maturity level on a scale from 1 - 3. In addition to helping the organization find lowpoints in their work with cybersecurity the activities can give a hint of good next steps. Even though the policy in it self does not specify a way to summarize the scores for each activity, it is possible to summarize the scores into a practice or business area to get a better overview. I’ve seen other models using radar charts to display the results, and I think it would be applicable here as well. An example would be to summarize the actions for each practice and then put all 15 practices into the diagram. But which are the practices. In the table below the business areas are the headers, and then the practices are listed below.

To gain enough insight to perform an assessment in accordance to SAMM i recommend reading their website, but to gain some insight into how it is intended to work lets dive all the way down to the questions asked to perform the assessment. Let’s look at Security Architecture in the business area Design. It contains two different streams that are measured, Architecture Design and Technology Management.

For Security Architecture the first maturity level is about “Insert[ing] consideration of proactive security guidance into the software design process.” In Architecture Design this would mean that the teams are trained in basic security principles and how to use them during the design process. To help with assessing if this is achieved SAMM supplies a question, answer alternatives, and quality criteria. This is also true for every other maturity level, stream, and principle. The question in this example is “Do teams use security principles during design?” To answer this there are four alternatives:

1. No
2. Yes, for some applications
3. Yes, for at least half of the applications
4. Yes, for most or all of the applications

The quality criteria used to help with answering the question in a correct way are:

• You have an agreed upon checklist of security principles
• You store your checklist in an accessible location
• Relevant stakeholders understand security principles

Overall this model can help an organization measure their maturity in security. For me it is great that it is so detailed and help the organization down to the level of what questions to ask to asses the quality of their implementation. Therefore it can be of great help regardless if the organization is in the beginning of their security journey, or if they have grown more mature.

This line of thinking arose once more after reading the “Report on the 2020 FOSS Contributor Survey” [1]. The report highlights that developers of FOSS (Free Open Source Software) have the same view, that security is a hindrance, a necessary evil that has to be done. Something to not spend more time on than absolutely necessary since its just annoying and boring, something that we must strive to change.

Sure there are some times that we have to say no, but developers (and others) does often understand this if we just explain why. It is important to not be the nay-sayers in the corner, but rather get involved. In my eyes security must support the business and the rest of the organisation. Everyone has to be on the same team and work towards a common goal, whether that is a high quality software or good backups in case of ransomware.

To be able to co-operate we need to build trust and ensure good communication. I have not meet a single developer that have introduced a vulnerability with malicious intent, meaning that the best way to get him to want to work with security is to make it easy. Explain your recommendations for a reasonable level of security. No-one can protect against everything, but you must find what level of risk is acceptable in the current scenario. Are you protecting against a national state or against the everyday hackers? The effort needed is greatly different.

In conclusion, security professionals cannot be a breed for them self in a corner. They need to be visible in the organisation, promoting communication and helping the organisation take decisions that improves the security. It doesn’t matter whether the decision is made by the CEO or a junior developer, they are both as important for the overall security posture of the organisation.

References

1. https://www.linuxfoundation.org/blog/2020/12/download-the-report-on-the-2020-foss-contributor-survey/

NO, CIA in this case does not stand for Central Intelligence Agency. In this case CIA stands for the three kinds of impact a vulnerability can have, Confidentiality, Integrity and Availability.

Lets dig a bit deeper, what does each of these terms mean.

Confidentiality

Confidentiality is about not exposing internal information to external parties. This could be anything from trade secrets to personal information. This is the area of security that I currently see discussed in the news. A recent example would be the Gunnebo hack [1], where the attackers stole confidential information and leaked it online.

Integrity

Integrity is in regard to ensuring that data in the system have not been changed. The banking sector excels in this area. Since they handle money and transactions, they have to be certain that no one can add a zero to the content of their bank account.

Availability

The last part of the triad is availability. Here the goal is ensuring the uptime of the system, that an attacker cannot take it down or block it in an unusable state. An availability attack is often (incorrectly) called a DDoS, or Distributed Denial of Service. This is one of the most trivial way of impacting the availability, but not the only. It is achieved by overloading the system with requests.

Media and CIA

In the years I’ve been following cybersecurity closely in media I’ve found that often the focus is on one part of the CIA triad at a time. In the last 5 years there have been a transition from availability to confidentiality. First the discussion was on cryptolockers (malware that encrypts the hard drive and requires a ransom for decryption). Since then the GDPR (General Data Protection Regulation [2]) among others, the discussion have transitioned towards the privacy of users. This highlights the importance of confidentiality of personal data.

This is where we are today, over the last few months there have been multiple instances where media have interviewed security professionals on information disclosed after a hack.

Conclusion

Regardless of what is discussed in media at the moment, all the parts of the CIA triad is important. Even though a businesses might have a prioritised area, they cannot forget the other parts. Any of them can and will have some kind of business impact, costing the organisation in the long run.

References

1. https://www.euronews.com/2020/10/27/thousands-of-sensitive-documents-stolen-in-swedish-data-hack
2. https://en.wikipedia.org/wiki/General_Data_Protection_Regulation

So why does not everyone just keep the technical debt low? There are a couple of different reasons, firstly it is a bit more expensive to add a feature neatly (reducing technical debt) than to just add it quick and dirty. This could be a part of a deliberate choice to introduce debt, either due to time constraints or due to the necessity to ship what you got and deal with the consequences. The second way technical debt can be introduced without knowing about it in the first place. The reason for this might be due to lack of research and knowledge, or only seeing the impact of decisions in hindsight.

No matter which of these types, or combinations of types, of debt can be found in a software the main point is that they add to the time it takes to develop in the codebase. It also increases the risk of introducing bugs, due to complexity, lack of automatic test cases, or any of several other reasons. The price of the debt is paid each time a change is made, and if no changes are made there are no payments.

Up until this point the information presented is mostly based on Martin Fowlers blog posts [1, 2], but I think these definitions misses one important part of technical debt, the dependencies. Joab Jackson argues that any dependency, such as libraries or frameworks, adds to the technical debt. By adding a dependency, the codebase often increases much more than needed. In doing so the amount of fluff that you need to understand to work in the codebase increases as well, increasing the time it takes and the risk of bugs being introduced. [3] However I would argue that even if there is debt introduced by third party dependencies, it can easily be worth it to use the dependency. The increase in development time and expertise needed when using dependencies save huge amounts of times in relation to the increased time it takes to maintain. One would have to weigh the technical debt from the dependency, and the debt from implementing the code inhouse to know which is the correct way forward.

However, I would argue that there is another technical debt introduced, the debt of keeping the dependencies up to date. The cost of this maintenance is required throughout the whole lifecycle of the solution, to ensure that no bugs are inherited. In a worst-case scenario these bugs could be security bugs with impact on the solution.

The recurring theme when it comes to security and technical debt is that they are not directly linked. From my experience I conclude that there is not any direct security related technical debt. Instead the technical debt could have one of many impacts. For example, it increases the risk of bugs being introduced. These bugs can be functional or non-functional, usability, or security bugs. Technical debt is a general concept in software development, that can be used to communicate the state of the solution. The impacts of the technical debt are what’s explained to the leadership, such as time spent and bugs introduced. The source of the debt on the other hand could be a lack of documentation or complex code, which is what the developers have to live with.

To work with technical debt in a structured, and well documented way one could frame the debt as business risks. For example, the technical debt in the codebase introduce risks such as:

• Lack of automated testcases increase the risk of introducing bugs
• Code complexity may increase cost of introducing a new feature
• Onboarding team members consumes more time than expected due to lack of documentation
• Etc

By handling the debt as business risks, it shows how the technical debt can impact the business, and help prioritising it in relation to other risks. In doing so, technical debt and code neatness can be clearly defined together with environmental, juridical and other risks.

My conclusion is that we should be careful when splitting out different problems, calling them different things and handling them in unique ways. A bug is a bug, it might have functional or security impact, but it’s still a bug. They should be prioritised based on their impact, and not be separated out. Risks should be handled in the same way, according to a general process where they can be prioritised and acted upon, regardless of if it has security, cost or other impact.

1. https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
2. https://martinfowler.com/bliki/TechnicalDebt.html
3. https://thenewstack.io/to-reduce-tech-debt-eliminate-dependencies-and-refactoring/

The thing about the internet today is that everything is links, and many sites such as twitter and bit.ly use link shortening to track usage and hide the original address. This makes it hard to know beforehand if the link is legit, and thus might increase the risk, but the impact will be the same. Here are four risks that I see when clicking a link.

1. The most obvious risk is phishing. An attacker can create a serious looking website with the aim to trick a victim to enter sensitive information such as passwords or credit card information. This would allow the attacker to use the stolen information to either sign into the compromised account, or pay with the credit card. However, these attacks are not performed when you click the link, but rather when you enter the information on the site, meaning that this does not qualify as a risk of clicking a link.
2. There are a few different attacks, for example clickjacking or cross-site request forgery, that targets a website through a victim browsing a third-party website. These attacks allow the culprit to perform actions as a victim on the target site. Instead of infecting the computer of the victim these attacks exploit a vulnerability in the target site to perform actions as the victim.
3. A reflected Cross-Site Scripting attack, also known as an XSS would exploit a vulnerability in a website to perform actions against that website as a victim. The impact is about the same as explained in 2, but the difference is that a legitimate URL to the target site is sent to the victim. To detect this risk, look for html tags such as <script> in the URL. Like the previous attacks, these attacks cannot infect the computer of the victim, but instead performs actions on the target site.
4. The most serious risk discussed is vulnerabilities found in the victim’s web browser. These can allow an attacker to compromise the computer to install malicious software such as spy- or ransomware. The best way to protect oneself from vulnerabilities in the browser is to keep it up to date. Most modern browsers are good at fixing bugs as fast as they become known. There is still a small risk that an unknown (aka 0-day) bug is used. However, these bugs are often used in attacks against high profile targets by well-funded hackers.

In conclusion, there are still risks with clicking links, but they are not as severe for your computer as they once were. I would say that today it is more important to ensure that your software is updated, that you do not enter information to sites you do not trust, and that you use long and unique passwords for accounts. Lastly, if you notice any strange behaviour on an account on a website you use, change your password and notify the owner of the site.