When it comes to IT infrastructure security, many people believe that only the production system needs protection. However, this is not the case. If a developer has access to a production server but their workstation gets hacked, it often becomes easy for attackers to gain access to the production server as well. That’s why the rule is: Wherever there is software, there is also potential risk.
Source: https://www.reversinglabs.com/blog/software-supply-chain-risk-demands-our-attention
New, more sophisticated attacks are targeting the entire software supply chain. The most prominent example is the xz vulnerability in a library used by OpenSSH. The attacker (or attackers) spent over three years gaining the trust of the library's maintainers before inserting a backdoor.
Cyber Resilience Act
Additionally, the European Union has passed new regulations (cyber resilience act) that will take effect in 2027. Software vendors wishing to operate in the European market must comply with these requirements. Failure to do so could result in severe fines or even market exclusion. One of these many regulations requires software vendors to provide a Software Bill of Materials (SBOM)—a file that lists all third-party components bundled as part of the product. And that’s exactly what we are doing now: We generate these files.
You can download them here in the download archive:
https://dev.axonivy.com/download/archive/unstable
Transparency with Dependency Track
That’s already a great step forward. You can now see exactly what ingredients make up our software. However, the real goal of an SBOM is to provide transparency about the components used and to check whether any known vulnerabilities (such as CVEs) exist in those versions. Naturally, we want to avoid using components with known security issues.
To manage this automatically, we use Dependency-Track. Dependency-Track can analyze SBOM files and generate vulnerability reports, helping us stay on top of potential risks.
This way, we have built quality assurance into our software development process and can respond quickly and efficiently to security vulnerabilities in third-party libraries.
Keep up to date with Renovate
To respond quickly in the event of a security vulnerability in a third-party library, it’s important to keep these libraries as up-to-date as possible. This ensures that we can quickly apply a patched version without the need for extensive code changes that could impact the functionality of the software. That’s why we keep our third-party libraries up to date across all LTS (Long-Term Support) tracks. We use Renovate for this purpose. Many are familiar with Dependabot, but Renovate is a competitor that acts more intelligently and requires less configuration.
Renovate, like Dependabot, analyzes the code repositories and checks for new versions of third-party components. If a new version is found, it creates a pull request to update the components. Here is an example:
https://github.com/axonivy/dev.axonivy.com/pull/437
Supply Chain Security
One more word on supply chain security. In this article, I’ve only discussed updating third-party components. However, supply chain security goes much further. For example, it's crucial that no one can easily take over an account with the ability to commit code (e.g., enabling multi-factor authentication on GitHub). In the event that such a takeover occurs, it would be wise to ensure that release branches are protected and that merging can only happen through pull requests. And there are many other measures as well.
