close search bar

Sorry, not available in this language yet

close language selection

How to eliminate malicious code within your software supply chain

What is malcode, or malicious code? What makes it dangerous? How can you detect it and keep it out of your software supply chain? Learn more.

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.

Unless you learn to recognize the red flags.

What is malicious code?

Malicious code, also called malcode, is any code added to, changed within, or removed from an application that is designed to subvert the application’s intended function. It can include:

  • Time bombs
  • Trojans
  • Backdoors
  • Root-kit like behavior

Unlike “malware” such as viruses and worms, malcode is not developed as external software to penetrate your systems. Rather, malcode is suspicious bits of code that appear like normal code sitting inside your own applications. It lays in wait until a specific event or action triggers the code.

When executed, malcode 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 malcode so insidious?

Malcode 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, the sources for implanting and launching malcode can come from within your software supply chain. Culprits could be external development partners (offshore or onshore) or even disgruntled current or former employees that have access to code, administration or control management. They may be hiding illegal activity or simply have a grudge to bear.

It can be difficult to know who to trust to scan for malcode and fix any problems you find. 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 malcode can generate. If you send a malcode report to your development team, you may tip off the perpetrator who inserted the malicious code, and they will learn to evade your detection techniques.

Where do you start?

Make sure you track and record all sources of code in a central repository so you can trace back the work of any developer. This is essential to be able find the culprit in the event the code is malicious and it’s all 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 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 some passive monitoring strategies. Institute a set of logging or firewall rules to determine whether there is backdoor access to data by comparing the system state before and after any malcode is executed. You can also actively modify firewall rules to prevent external access and data loss.

You can attach a malicious code detection process into your existing static analysis program so you can identify malicious code before it goes live. In fact, this is the ideal scenario as the two programs will pair with each other but they must be kept separate.

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.

How good are your malcode detection skills?

When checking for malcode, make sure you know these common red flags:

  • Create signatures to detect subtle logic in the applications, such as URL strings that aren’t in a configuration file, or activities that launch according to time or date changes.
  • Find any “backdoors” that allow for separate ways to enter applications that subvert usual access parameters.

What hidden threats are lurking in your software supply chain?

Brenton Kohler

Posted by

Brenton Kohler

Brenton Kohler

Brenton Kohler is a managing consultant at Synopsys. He specializes in secure code review and malicious code detection and builds code review programs for some of Synopsys' major clients. Brenton attends OWASP, local security meetups, and ISSA chapter events regularly. He claims that he has not, “made application security worse than it already is, which seems like a big deal.” In addition to fixing security problems, Brenton enjoys playing Ultimate and basketball, jogging, and hanging out with is family and friends—preferably around a bonfire with a couple of beers.

More from Open source and software supply chain risks