Eliminate malicious code in your software supply chain

Everyone wants to believe that the code developed within a trusted software supply chain is legitimate. The unfortunate reality is that malicious coders have subtle ways to secretly embed code that exposes your business to risk. Malicious code can be challenging to recognize and can remain undetected within applications long before it causes damage. Learn to recognize the red flags.

What is malicious code?

Malicious code is any code added to, changed within, or removed from an application with the intent to subvert the application’s intended function. It can include

• Time bombs
• Trojans
• Back doors
• Root-kit like behavior

Unlike malware such as viruses and worms, malicious code is not developed as external software to penetrate your systems. Rather, malicious code is suspicious bits of code that appear like normal code inside your applications. It waits until a specific event or action triggers it. When executed, it can pilfer data, download and install software, siphon money from accounts, log keystrokes, and permit outsiders to control computers remotely, among many other misdeeds.

What makes malicious code so insidious?

Malicious code can evade common application testing strategies because it blends in with normal functionality and can remain dormant for long periods of time—even years.

While it’s hard to accept, your own software supply chain can be a source of malicious code. The culprits could be external development partners (offshore or onshore), seemingly trustworthy open source project contributors, or even disgruntled current or former employees who have access to code, administration, or control management. They may be hiding illegal activity or simply have a grudge.

It can be difficult to know who to trust to scan for and fix any malicious code. For example, if an internal developer is the culprit, they know the infected application inside and out, have the inside track on how your security team looks for software vulnerabilities, and are skilled at hiding the traffic that malicious code can generate. If you send a malicious code report to your development team, you may tip off the perpetrator, and they will learn to evade your detection techniques.

Where do you start?

There are a variety of tactics and steps to prevent, detect, and respond to malicious code.

• Make sure you track and record all sources of code in a central repository, so you can trace the work of developers and sources of external dependencies. This is essential if you need to find a culprit—and it’s just good practice.
• Create a proactive plan to scan for malicious code regularly and determine in advance who will respond to any issues you find. Include external libraries, open source dependencies, binaries, design documentation, and source code in your analysis to build a story around what suspicious code may be doing and at what point in the supply chain it was inserted.
• Implement passive monitoring strategies. Institute a set of logging or firewall rules to determine whether there is backdoor access to data, and compare the system state before and after any malicious code is executed. You can also actively modify firewall rules to prevent external access and data loss.
• Add a malicious code detection process into your existing application security testing programs (e.g., software composition analysis and static analysis) so you can identify malicious code before it goes live. This creates synergy because the two programs will pair with each other. One keeps malicious code out of applications, and the other detects anything that has slipped through the cracks.
• Rely only on a small, trusted team to scan for malicious code and collect data to identify the source of any issues you find. This operation should be as secretive as possible to prevent malicious developers from hiding themselves further.