How to secure DevOps

Supply-chain attacks through public repositories have become more frequent of late. Here’s how to deal with them.

Last month, IT news websites reported that RubyGems, the official channel for distributing libraries for the Ruby programming language, had been poisoned. An attacker uploaded fake packages containing a malicious script, so all programmers who used the code in their projects unwittingly infected users’ computers with malware that changed cryptocurrency wallet addresses.

Of course, it was not the first supply-chain attack to exploit a public repository. But this type of scenario seems to be gaining popularity, which is no surprise; one successful attack can compromise tens or hundreds of thousands of users. It all depends on the popularity of the software developed using code from the poisoned repository.

How do malicious packages get into repositories?

In the case of RubyGems, the cybercriminal created lots of projects in the repository with names similar to popular legitimate packages. Known as typosquatting, the technique relies on developers incorrectly entering the name of a package and downloading a malicious one by mistake, or, after getting a list of names of packages from a search query, not knowing which of them is genuine. The tactic, generally considered the most common for cyberpoisoning, has been deployed in attacks through the Python Package Index and in uploading fake images to Docker Hub.

In the Copay cryptocurrency wallet incident, the attackers used a library whose repository was hosted on GitHub. Its creator lost interest and gave away the administrator rights, compromising the popular library, which many developers used in their products.

Sometimes, cybercriminals are able to use the account of a legitimate developer without the latter’s knowledge and substitute real packages for fake ones. That happened in the case of ESLint, whose libraries were hosted in the npm (Node Package Manager) online database.

Compromise of the compilation environment

Companies developing software products are also potentially interesting targets for APT actors. Instances of their targeting the clients of such companies periodically attract the attention of security experts:

  • In August 2017, some APT actors outfitted software created by NetSarang with malicious modules. According to investigators, the attackers may have compromised the software build servers.
  • In 2018, cybercriminals infected the Piriform application build server, after which CCleaner program builds with clean source code were weaponized during compilation.
  • In 2019, our experts discovered the ShadowHammer APT campaign, during which malefactors embedded a backdoor into software products from several companies. According to the results of the investigation, the attackers either had access to the source code or introduced malicious code at the compilation stage.

Compromise of the compilation environment not only allows the “infection” of the final product, but it also leads to the distribution of weaponized malware carrying a legitimate digital signature from a trustworthy developer. That is why the development process needs enhanced protection against outside interference.

The root of the problem

In fact, the danger lies not in the use of public repositories but in a flaw in the modern approach to software development — the DevOps methodology. DevOps is a set of practices aimed at shortening the program development cycle. Development always has to balance security and usability. To remain competitive in today’s cutthroat environment, developers need to release new versions of programs as quickly as possible, but improving usability tends to cause either a drop in quality or longer TTM. As a result, developers are always trying to minimize or completely circumvent the intervention of security personnel in their activities.

As a result, information security has practically no control of that part of the infrastructure. But development, IT, and security are all working toward a common goal: a quality and safe product delivered in a timely manner. An update is no good if it contains a backdoor or spy module. Therefore, in our opinion, the industry must move to a DevSecOps methodology.

DevSecOps is an attempt to bridge the gap between security and DevOps by introducing a cybersecurity culture and practical application of checks at all stages of the software development process without compromising flexibility and speed. We offer tools to aid the technical side of this process.

Our solution

The market is short of tools that secure the software development process specifically. Therefore, in updating our Kaspersky Hybrid Cloud Security, we took into account the needs of programmers, fitting the solution’s components with technologies for integrating security tools into the development process without impacting performance. These are technologies primarily for scanning repositories, images, and containers — the very things to prevent supply-chain attacks.

Kaspersky Hybrid Cloud Security has interfaces for interoperability with continuous integration (CI) and continuous delivery (CD) platforms such as TeamCity and Jenkins. Our solution can be Integrated into the development process through the command line or an application programming interface.

That’s not the only innovation in our solution, of course. See the product page for more information about Kaspersky Hybrid Cloud Security and about protecting the DevOps process.