October 20, 2026

The Hidden Risk Inside Modern Software

What is the security issue?

By Htet Wai Yan

3 min read

What is the security issue?

Imagine you are building a house; you would not make all the windows and doors by your own, you would definitely use ready-made parts because it is much faster and usually cheaper. Software developers do the same thing. Instead of building each and every part from the start, they usually use libraries, which are ready-made pieces of code written by other developers for tasks such as processing payments, saving logs, or handling logins. But if one of those parts has a defect, every software built with it will have the same defect. Libraries include other libraries within themselves; hence, an application may have several hundred components that were not chosen by its developers.

Why does it matter?

Real-world fact #1: Log4Shell (2021). Log4j is a commonly-used Java software that logs the activities of the application, keeping an 'application journal'. A critical vulnerability dubbed Log4Shell was revealed in December 2021. If a malicious actor got the message into the application log, the program would execute the attacker's code. This vulnerability was rated by the security organizations of five countries (US, Australia, Canada, New Zealand, and the UK) as severe due to three factors: ubiquity of the language, ease of exploitation, and complexity of remediation.

Real-world fact #2: Equifax (2017). The data storage company Equifax was breached because of a vulnerability in the Apache Struts library. As per a US Government Accountability Office (GAO) report, hackers started scanning for the vulnerability in the code two days after the flaw was announced. Equifax failed to scan its system in time to detect the vulnerable code. It took 76 days for the hackers to breach 51 databases and access the details of at least 145.5 million people.

In either case, the weakness did not lie in the code that the company had written; it lay in the code that the company used.

What is the deeper problem?

Analysis by me:

  1. You cannot fix something that you cannot see. In the aftermath of Log4Shell, many organizations struggled to answer a very simple question — "Do we even use Log4j?" A library nested within another library is difficult to notice.

  2. Attackers act faster than software updates. In Equifax, attackers operated just a few days after the announcement. Most companies need weeks or even months to update software.

  3. "Everyone uses it, so it must be safe." Popularity provides a sense of quality, however, a widespread library can also become a bigger target. A single vulnerability in it will threaten thousands of businesses simultaneously.

  4. No one is accountable. Application development team may believe that security issues in the library should be managed by its creators, and vice versa. The problem lies in between.

OWASP, an established web security organization, identifies "Vulnerable and Outdated Components" as one of their Top 10 vulnerabilities. They pose three basic questions for consideration: Do you know which components are in use? Are they vulnerable? How quickly can you remediate them?

What is my judgment?

"Use libraries carefully" isn't specific enough. Here's how I would deal with this problem, and how each decision comes at a cost.

Maintain an ingredients list. Organizations need to maintain a current list of all the libraries that their applications are using, including those that are not visible. Such a list is known as a Software Bill of Materials (SBOM). In case of the next Log4Shell, organizations will be able to answer "Are we affected?" in minutes instead of days.

Scan automatically. Automated free and paid options can scan your libraries against known vulnerabilities. The Secure Software Development Framework from the National Institute of Standards and Technology includes verification of third party software (practice PW.4.4). Limitation: such tools will find only known flaws and will raise a lot of alarms to go through.

Update quickly, but securely. Prepare to update security rapidly and test before deployment. Risk: updates can break something; updating rapidly is not always safe. Proper automation reduces risk greatly.

Use fewer and better chosen libraries. Ask yourself before introducing a library if it is actively maintained and if it is really needed. Tradeoff: It takes more time to do it yourself and your code may also be buggy. Aim for fewer and better chosen libraries rather than no libraries at all.

Lesson: If your application uses other people's code, then their bugs are your bugs. Not your code, but still your responsibility.

References