Software Supply Chain Risks for Low- and No-Code Application Development

Supply chain attacks occur when a third-party vendor or partner with less robust security measures is breached, allowing attackers to indirectly gain access to an organization. This can happen through backdoors planted in software updates, as seen in incidents like SolarWinds and Kaseya.

New architectures such as multi-cloud and microservices have made consistent security controls more difficult, and the use of open-source CI/CD and dev solutions has increased the attack surface. Vulnerability management is also becoming increasingly challenging, with a shrinking window between vulnerability disclosure and the first exploits, and attacks often carried out by ransomware affiliates, botnets, and nation-states.

The economics of attacks have shifted with the rise of ransomware, and defenses must be constantly updated to stay ahead of these evolving threats, especially in new and emerging technologies.

Software Supply Chain Attacks

New architectures such as multi-cloud and microservices have made consistent security controls more difficult, and the use of open-source CI/CD and dev solutions has increased the attack surface. Open-source module repositories such as NPM, PyPI, and can also be a point of vulnerability for software supply chain attacks. These repositories provide a large number of community-owned libraries and modules that can easily be integrated into software development, but they also represent a potential attack vector. Attackers can compromise a library or module and then use it to gain access to the systems of organizations that use that library. This is called a software supply chain attack and typically performed by typosquatting, where the attackers create a package with a similar name to a popular one and wait for someone to install it by mistake. Additionally, attackers can also take over ownership of an open-source package, create a new dependency by tricking maintainers into accepting new code edits or exploit a vulnerability in the package to integrate or distribute malicious code.

In 2018, an npm package called event-stream was found to contain a malicious package named flatmap-stream. The malware was used to steal bitcoins from users of the Copay and Bitpay open-source cryptocurrency wallets. The attacker, going by the GitHub handle right9ctrl, reportedly offered the original maintainer to help maintain the library. The original maintainer, likely aiming to help his users, agreed, granting right9ctrl publishing rights. Note that transferring ownership is a fairly common practice in the world of open source and is used to help maintain projects when the original authors are no longer able or willing to do so. Unfortunately, the new owner proceeded to add a malicious library called flatmap-stream to the event-stream package as a dependency. The malicious dependency remained undetected for 2.5 months.

In 2022, the Rust Security Working Group was notified of the existence of a malicious crate named rustdecimal, which contained malware. The crate was named intentionally similar to the popular rust_decimal crate. The crate contained identical source code and functionality as the legit rust_decimal crate, except for the Decimal::new function. When that function was called, it checked whether the GITLAB_CI environment variable was set and if so, it downloaded a binary payload into /tmp/git-updater.bin and executed it. The binary payload supported both Linux and macOS, but not Windows. The objective of the attack is unknown because an analysis of the binary payload was not possible, as the download URL didn’t work anymore at the time the analysis was performed.

In 2021, a python package named jeIlyfish (typosquatting the package jellifish by replacing the first L with a capital I) was found on PyPI, the Python Package Index. The jeilyfish library remained undiscovered on PyPI for nearly a year and contained malicious code to steal environment variables and ssh keys from developers’ systems that used the module.

In 2022, Checkmarx uncovered a collection of nearly 200 poisoned npm packages that could be traced back to a single organized cybercrime operation. Know as Loftygang, the group dealt in stolen credit cards and streaming service credentials and acquired them through software supply chain attacks. The group was organized, persistent, and operated for over a year before being detected.

No-code and low-code, the new hunting grounds for software supply chain attacks?

No-code and low-code platforms are software development tools that allow users to create applications without the need for ‘traditional’ coding. They are designed to make it easy for non-technical users to create and manage their own applications. These platforms emerged from a need for custom functionality and reporting by users in several business resource planning, customer relationship management and plant automation systems.

No-code platforms are the most user-friendly of the two, they allow users to create applications by dragging and dropping pre-built components and configuring them to their needs, without writing any code. Low-code platforms provide a more flexible approach, they allow users to create applications with a visual interface and a drag-and-drop interface, but also allow them to write code.

Examples of no-code/low-code platforms include:

  • Appian
  • Microsoft PowerApps
  • Salesforce Lightning
  • OutSystems
  • Mendix

These platforms can be used for a wide range of applications, including building web and mobile apps, automating business processes, creating dashboards and reports, and integrating with other systems. They can also be a great tool for small and medium-sized businesses, which may not have the resources to invest in a team of developers.

However, it is important to note that while no-code/low-code platforms can make it easier to create and manage applications, they also introduce new security risks. These risks include the lack of control over the code, the lack of visibility into the underlying infrastructure and the lack of transparency in the data flow, which can make it harder to identify and address vulnerabilities. Therefore, it is important to consider the security implications of using no-code/low-code platforms and to take steps to mitigate them.

I expect that low and no-code platforms will come to depend even more on third-party and open-source ecosystems and might become an important target for threat actors looking to steal sensitive information or halt critical business processes by crypto locking the underlying data lakes where de no- or low-code application had access to. Especially given the nature of data and control those applications have access to within on organization.

Software Bill of Materials (SBOM)

A Software Bill of Materials (SBOM) is a list of the software components and their versions that make up an application, including any open-source libraries, frameworks, and other dependencies. It can be used to help identify and manage the security risks associated with the use of open-source software.

SBOM can help with identifying and managing vulnerabilities in the software supply chain. By providing a comprehensive inventory of all the components and dependencies used in an application, organizations can better understand the attack surface and identify potential vulnerabilities. This can help organizations prioritize their vulnerability management efforts and make informed decisions about which vulnerabilities to patch and when.

Additionally, SBOM can also help organizations to comply with regulations and industry standards, such as the OWASP Software Assurance Maturity Model (SAMM).

Concluding remark

To mitigate the risk of the software supply chain, organizations should ensure that they use package managers and repositories from third parties with a good reputation, use packages from well-known and reputable sources, and regularly audit the packages and all dependencies in their systems. No- and low-code should become an integral part of the SBOM.

Pascal Geenens

As the Director, Threat Intelligence for Radware, Pascal helps execute the company's thought leadership on today’s security threat landscape. Pascal brings over two decades of experience in many aspects of Information Technology and holds a degree in Civil Engineering from the Free University of Brussels. As part of the Radware Security Research team Pascal develops and maintains the IoT honeypots and actively researches IoT malware. Pascal discovered and reported on BrickerBot, did extensive research on Hajime and follows closely new developments of threats in the IoT space and the applications of AI in cyber security and hacking. Prior to Radware, Pascal was a consulting engineer for Juniper working with the largest EMEA cloud and service providers on their SDN/NFV and data center automation strategies. As an independent consultant, Pascal got skilled in several programming languages and designed industrial sensor networks, automated and developed PLC systems, and lead security infrastructure and software auditing projects. At the start of his career, he was a support engineer for IBM's Parallel System Support Program on AIX and a regular teacher and presenter at global IBM conferences on the topics of AIX kernel development and Perl scripting.

Contact Radware Sales

Our experts will answer your questions, assess your needs, and help you understand which products are best for your business.

Already a Customer?

We’re ready to help, whether you need support, additional services, or answers to your questions about our products and solutions.

Get Answers Now from KnowledgeBase
Get Free Online Product Training
Engage with Radware Technical Support
Join the Radware Customer Program


An Online Encyclopedia Of Cyberattack and Cybersecurity Terms

What is WAF?
What is DDoS?
Bot Detection
ARP Spoofing

Get Social

Connect with experts and join the conversation about Radware technologies.

Security Research Center