by Michael Peters
Bookmark

Modular Programming and Increasing Need for Secure Software Development

You’re probably not a programmer. However, how your programmers work on software can majorly impact your software development process, particularly regarding security. 

Over the past few years, attackers have been able to infiltrate common software packages, specifically through modularity. Shared libraries and open repositories have led to major security issues that, while seemingly small, can bring mission-critical systems to their knees. 

This post uses real-world examples, such as the XZ hack and other notable incidents, to highlight the importance of securing the modular programming paradigm.

 

Understanding Modular Programming

Modular programming is a design technique that breaks down a program into smaller, manageable, and interchangeable modules. This method facilitates easier maintenance, testing, and debugging. It also allows developers to reuse code across different projects, saving time and resources. Common examples of modular programming include libraries, frameworks, and microservices architectures used in various applications.

It’s no understatement to say that this approach is, and has been, the primary driver of software development. It makes building more complex applications easier and eliminates the need for programmers to reinvent the wheel consistently regarding key functions. 

Despite its benefits, modular programming is not without its risks.

 

Attack Surfaces in Modular Programming

In the context of modular programming, the attack surface expands with each additional module integrated into the system. This is due to the dependency on multiple third-party modules, each of which may have vulnerabilities.

For instance, an attacker might target a seemingly secure module widely used in the industry. By exploiting a vulnerability in this module, they can access any system that incorporates it. This is often exacerbated by many developers relying on open-source modules, which may not always be rigorously audited for security flaws.

The interconnectivity between modules can create complex dependency chains, where a vulnerability in a single module can propagate through the entire system. This interconnectedness can make it challenging to identify and isolate the source of a security breach, as the compromised module might be deeply embedded within the application’s architecture.

 

Case Study: The XZ Hack

One of the most illustrative examples of the dangers of modular programming is the XZ hack. XZ is a popular data compression library used in many software projects. In this incident, attackers compromised the library by inserting malicious code into the module. This code was then propagated to all projects using the XZ library, creating a massive security breach.

The XZ hack was insidious because it exploited developers’ trust in widely used modules. The compromised code allowed attackers to execute arbitrary commands on any infected library system. As a result, sensitive data was exposed, and numerous systems were rendered vulnerable to further attacks.

 

Other Examples of Modular Library Attacks

secure software development

The dangers of modular programming are not limited to the XZ hack. Several other high-profile incidents further illustrate the vulnerabilities associated with this approach.

  • Event-Stream Incident: Event-Stream, a popular JavaScript library, was compromised when a malicious maintainer added a dependency that contained cryptocurrency-stealing malware. The malware targeted a specific application, Copay, and stole cryptocurrency from unsuspecting users. 
  • SolarWinds Attack: Perhaps one of the most notorious supply chain attacks, the SolarWinds incident involved inserting malicious code into the company’s Orion software updates. This breach allowed attackers access to numerous high-profile organizations, including government agencies and Fortune 500 companies. The attack exploited the trust in legitimate software updates, demonstrating how modular programming and dependency management can be leveraged for large-scale breaches.

These examples share common patterns: exploitation of trust, insertion of malicious code into widely-used modules, and significant impact due to the widespread use of compromised software. 

 

Mitigating the Risks of Module Supply Chain Threats

These examples highlight how software development and supply chain security quickly become non-negotiable. To mitigate the risks associated with modular programming and reduce attack surfaces, developers and organizations can adopt several best practices:

  • Vetting Dependencies: Review and audit third-party modules before integrating them into projects. Use trusted sources and avoid unverified code.
  • Regular Updates: Keep all modules and dependencies up to date with the latest security patches and updates. Outdated modules can become easy targets for attackers.
  • Monitoring and Alerts: Implement monitoring systems to detect unusual activity or changes in module behavior. Continuous monitoring can help identify potential security threats early.
  • Code Reviews: Conduct regular code reviews and security audits to identify and address potential vulnerabilities. Peer reviews can uncover issues that automated tools might miss.
  • Minimal Permissions: Apply the principle of least privilege, ensuring modules have only the permissions necessary for their function. Restricting permissions can limit the potential damage from a compromised module. Also, consider zero-trust approaches to security.
  • Dependency Management Tools: Utilize tools that help manage and secure dependencies. These tools can automate updates, track changes, and provide alerts for known vulnerabilities.

 

Keep Your Infrastructure Secure with Lazarus Alliance

While beneficial in many ways, modular programming introduces significant risks by expanding the attack surface within the software supply chain. Most modern businesses cannot wait until the next threat drops before considering how to protect themselves. Lazarus Alliance has you covered, whether to heighten software security or align with requirements like the Secure Software Development Framework. 

To learn more, contact us. 

[wpforms id=”137574″]