Micro Focus is now part of OpenText. Learn more >

You are here

You are here

5 ways to shift your application security team's focus to the supply chain

public://pictures/Robert-Lemos-Technology-Journalist-Lemos-Associates.jpg
Rob Lemos Writer and analyst
 

On April 12, 2017, four computers at utility-software firm Piriform, previously compromised, quietly reached out to the Internet and downloaded and installed a remote-access Trojan known as ShadowPad.

Using the malicious program, attackers silently invaded parts of Piriform's build system for creating its utility application, CCleaner, adding code that would send back information about the software users' systems.

Subsequent updates to CCleaner inadvertently added the Trojaned software to nearly 2.3 million customer systems. The program helped attackers whittle down their collection of targets to just 40 systems, which then downloaded the ShadowPad Trojan.

In the end, the group behind the attack—thought to be Chinese, because ShadowPad is commonly used by a Chinese state-sponsored group—used Piriform's developers to infect the company's customers.

While knowing the details of such an incident is rare, software-supply-chain attacks are becoming increasingly common, said Michal Salat, director of threat intelligence for Avast, which bought Piriform in 2017, just before the company discovered the breach. 

Nearly a score of attacks on the software supply chain have been documented in the past three years, targeting developers and open-source software components and aiming to infect their software and use their access to target a small selection of users.

Dealing with these threats requires that developers put renewed focus on ensuring the integrity of both their internal code and any third-party code they incorporate into their programs, software security experts agree.

That's becoming increasingly difficult. Across major open-source software platforms—from Java to Python, and from NPM to RubyGems—the number of components used has grown 75% in two years, exceeding 28 million public projects and repositories. Developers can access about 21,400 new component releases every day, according to Sonatype's 2019 State of the Software Supply Chain report.

It's a complex problem, but here are five techniques that companies use to stop malicious code from polluting their development environments.

1. Assign a security champion

The only way for a company and its developers to start focusing on security is for someone to step up and ask the question, said John McCumber, director of cybersecurity advocacy for North America at the International Information System Security Certification Consortium, or (ISC)2.

Development teams should have a security champion to act as a litmus test for design decisions and to bring up potential security issues.

There should always be a group or a person in the process who asks the questions, "What about the security elements?" and, "What about the risk management elements of this process, this application, and this development environment?"

"If you are not asking the questions, chances are you are not going to be doing good security."
John McCumber

While many development teams are on the smaller size, (ISC)2 found that size does not necessarily matter when it comes to security. Some 42% of small businesses—those with 250 workers or fewer—had at least five employees dedicated to cybersecurity, while three-quarters of larger companies—those with more than 1,000 employees—had at least 10 staff members dedicated to security.

2. Only coders should touch the code

When Avast analyzed the environment at the newly acquired Piriform, it found that the build systems and developers' computers were not properly isolated from the rest of the company. A flat network topology, where every computer can see every other computer and different groups share the same file servers, allows attackers and malicious code to quickly spread throughout a company and infect systems that otherwise should be protected.

"You need to have a pretty straightforward network separation. There are back-office parts of the company, such as HR and finance, that do not need to have any access to the code or to the build environment. So we cut them off completely from those systems."
Michal Salat

Any data or information passed among different parts of the company are subjected to additional security checks, such as antivirus scans and analysis.

3. Keep track of components

Once a development team is focused on security, it needs to start tracking the vulnerability of the libraries and components that it integrates into the code. Open-source software has become a major source of vulnerabilites because it is used extensively by developers.

Now attackers are using the lack of security in many development chains to insert backdoors and vulnerabilities into components, in hopes the malware gets propagated to the end products.

In November 2018, for example, the Node Package Manager (NPM) project warned that a malicious attacker had inserted code into EventStream, a toolkit used by an estimated 6 million developers, as part of a scheme to infect a small subset of users and steal bitcoin.

While the pollution affected a large number of projects, ultimately the attack was targeted. The polluted EventStream code would affect only developers at a specific company, CoPay, and cause the application to include malicious code that would harvest bitcoins from accounts with large balances.

The NPM project said in an analysis of the incident

"When a developer at Copay runs one of their release build scripts, the resulting code is modified before being bundled into the application. The code was designed to harvest account details and private keys from accounts having a balance of more than 100 bitcoin or 1000 bitcoin cash."

4. Use metrics suppliers' track record

While knowing the "bill of materials" that goes into each project is necessary, more mature development organizations need to go beyond that simple goal. Companies need to excise unneeded code from their development efforts, especially components from projects whose teams do not update regularly.

To do that, companies need to track a key metric: how quickly project teams remediate vulnerabilities in their code, said Matt Howard, senior vice president at Sonatype.

In its recent report, Sonatype analyzed how quickly Java developers updated more than 36,000 projects and found that the average time was 326 days—meaning it took nearly a year for the average project to fix a known vulnerability.

Developers should aim to use projects that have better track records. The top 5% of projects noted in the Sonatype report remediated a vulnerability in their software in 21 days.

The responsiveness of the software project's team becomes even more important when the trend of injecting malicious code into open-source projects is taken into account, said Howard.

"Bad actors are poisoning the well from which developers drink and having it consumed, and when it shows up downstream, they are exploiting it. Attacks are shifting left, and developers need to be ready for that."
Matt Howard

5. Automate the basics

Finally, as development teams adopt new processes, they should spend the time to automate the activity and test cases to ensure that the measures are repeatable and consistent.

"Really good engineering software teams always spend time to check their dependencies. Great engineering teams automate that process."
—Matt Howard

As automation is extended to more development activities, developers can use it to look for more subtle signs of code pollution. If a new developer joins a project whose code a company relies on, then a careful development team might do additional checks on that code.

Defend your code

The ultimate lesson, however, is that developers are no longer protected from becoming a target for attackers. With every indication that attackers will focus even more on corrupting codebases, developers need to be ready to defend their code.

The vast majority of modern software applications are built with third-party parts from outside providers, just as Toyotas are built using third-party parts, Howard said. "The question is, How well do you understand the provenance of your software supply chain?"

"Every major software provider, especially the ones that provide some kind of software for free that are used by many people, needs to expect that they might be targeted by such an attack. It goes with the popularity of the product."
—Michal Salat

Read more articles about: SecurityApplication Security