Developers in the crosshairs – why are there more and more cyber attacks against software vendors?

Developing good quality software is now the norm, but what about secure software development? Why are there more and more cyber attacks on software development environments and how is software company security becoming a key issue in the supply chain? Our blog post explores this question.

The term Supply Chain Attack (SCA) has been bandied about in the cybersecurity press in recent years. A closer look at the incidents that have been publicised shows that in many cases the weakest link in the supply chain was a software developer. The case of Solarwinds is well known, but it is also worth noting that the Lapsus$ cybercriminal group has also attacked a number of development companies and gained access to information that then helped them to attack other targets. In one case, a national intelligence service, in the other a group of mainly teenagers were behind the attack, with the common factor that, despite the developer’s best efforts to protect its internal infrastructure, the attack was successful. In addition to the victims that have been made public, there are likely to be a number of other organisations that are not (yet) known to the press.

But why target software developers?

The answer lies in an unfavourable confluence of several factors.

First, the majority of software developers typically do not have any serious compliance requirements that would force them to develop cybersecurity internally.

Second, DevOps development practices are widespread, but often basic security procedures are not integrated into the process, there is no DevSecOps expertise, and so the on-premises or cloud infrastructures used in development are quite unprotected.

Thirdly, by planting a backdoor, in theory all customers using a particular developer’s product could be reached and attacked en masse, as we saw with the NotPetya malicious code, or even a sophisticated, under-the-radar attack, as we saw with the Solarwinds attack.

Fourthly, developers are very often also service providers, so they themselves use a significant amount of personal and business data to provide the service, for example to teach the artificial intelligence they develop. Exploiting vulnerabilities arising from a relatively low cybersecurity culture and preparedness therefore offers maximum benefit from the attacker’s perspective.

Secure software development, including the design of a secure development environment, is supported by a number of standards and recommendations. Perhaps the best known of these is the Microsoft Secure Development Lifecycle (SDL) recommendation. This recommends, among many other steps, that the developer has an incident management process in place to quickly and effectively address security issues that arise with a product or service. The recommendation uses the sentence

Preparing an Incident Response Plan is crucial for helping to address new threats that can emerge over time. It should be created in coordination with your organization’s dedicated Product Security Incident Response Team (PSIRT).

However, such a PSIRT is only found in the largest developers, given the significant cost of building and running one, and the most common industry solution is to have a small security team, typically 1-2 people, responsible for all security tasks, with incident management being by definition only one of many tasks. Moreover, this security team most of the time has no influence on the DevOps operation, as it is the responsibility of the developers. This creates a significant attack surface for the developer, which is often easily exploited by attackers in such a way that the incident is not identified or is identified only after a very long time.

However, with the development of technology, and cloud-based solutions in particular, there is an excellent opportunity to shift the burden of incident management from the developer to an expert service provider with the right staff and technical background to detect incidents early and intervene effectively. The US NIST standard SP 800-218 on the secure software development model also supports this approach:

The responsibility for implementing the practices may be distributed among different organizations based on the delivery of the software and services (e.g., infrastructure as a service, software as a service, platform as a service, container as a service, serverless). In these situations, it likely follows a shared responsibility model involving the platform/service providers and the tenant organization that is consuming those platforms/services.

Incident management can therefore involve the service provider who can provide cloud protection services through the chosen cloud platform. This service is called Managed Detection and Response (MDR) service, which can be used to provide a higher level of incident management not only on the endpoints of the development environment, but also on the cloud infrastructure elements used during DevOps.

So, if you don’t have a PSIRT that is recommended by either Microsoft SDL or NIST SP 800-218, you should consider outsourcing security to a provider with the right capabilities!