Organizations relying on open-source software (OSS) face a significant risk of being exposed to protestware—that is, software that has been modified by a developer to express a political or social viewpoint. Protestware can take the form of banner messages, unauthorized code execution, or data exfiltration, and result in service outages or reputational damage.
Developers integrating open-source libraries may inadvertently introduce such security threats, resulting in compromised supply chain integrity. Operational disruptions have been traced to malicious updates in dependencies, resulting in application failures.
This can be particularly detrimental to financial institutions, as they are subject to strict compliance requirements: for example, standards set by the US Federal Financial Institutions Examination Council (FFIEC), the EU General Data Protection Regulation (GDPR), and the global Payment Card Industry Data Security Standard (PCI DSS).1
Senior Vice President Suryaprakash Nalluri is a seasoned cybersecurity expert with more than 20 years’ experience working with bank and financial institution clients. To mitigate risk associated with protestware, Nalluri led a team to develop and implement a multilayered defense strategy, including:
- Enhanced OSS security reviews with software composition analysis (SCA) tools
- Protestware risk indexing
- Adoption of an immutable dependencies policy to prevent unexpected disruptions
- Isolation and runtime monitoring of open-source libraries for unusual activities in production
- Security awareness and developer training to recognize protestware risk and enforce strict remediation and mandatory software bill of materials (SBOM) validation before integrating third-party code
- Centralized library distribution via an internal artifact repository with proxy controls, which requires developers to build from a centralized library repository rather than downloading code from the internet
Problems With Code Quality and Malicious Intent
Traditionally, developers manually downloaded open-source libraries directly from public repositories and committed them into internal source code repositories. In recent years, DevSecOps has enabled automated OSS ingestion, resulting in the rapid building of source packages without a vetting process. This shift, amplified by evolving geopolitical risk, has made vulnerability management more complex and significantly increased supply chain exposure.
Open-source components are frequently updated without thorough review of integrity, provenance, or governance. Nalluri identified the growing risk as not just a technical challenge, but a foundational issue requiring a resilient and trustworthy supply chain strategy.
In January 2022, for example, the maintainer of the node.js colors and node.js faker libraries tampered with his own code, resulting in the display of random messages. The applications stopped functioning and went into infinite loop mode,2 disrupting thousands of projects that depended on them. The developer had previously issued warnings about his unwillingness to continue to support commercial enterprises with his “free work.”
One of the worst examples of protestware, according to Nalluri, is node-ipc.3 The package maintainers pushed malware in an update that checks for a specific time zone. “So, if I’m executing that code, if my computer is located in specific a region, like Belarus, or in a specific time zone, it actually deletes all the files on that particular desktop,” Nalluri said. “Imagine if that script is being executed on a production server in affected geolocations. It could attempt to overwrite files with ‘peace, no war’ messages, potentially disrupting operations.”
Vulnerability scanners are based on detecting problems due to unintentionally weak coding. On the other hand, malicious code is intentionally introduced by coders with a specific agenda to fulfill. It is very difficult to detect using vulnerability scanners, noted Nalluri. Malicious code looks like regular code, he pointed out. Identifying it requires incorporating different types of techniques, such as behavioral analysis, context awareness, and threat intelligence integration, into the scanner.
“Organizations trust their developers—but developers often trust open-source code without verification. That’s where the trust chain begins to fail,” Nalluri notes.
Developers often download libraries from public repositories. If a developer mistypes a package name, the system may fetch a malicious library that was crafted by threat actors using a similar name. This form of typo squatting makes it easy for malicious packages to penetrate an organization. Once included, the malicious library behaves like a regular open-source dependency, making detection difficult. This risk can be mitigated by reviewing open-source metadata, such as package author, popularity, and download statistics.
Dependency confusion is another attack technique. Typically, organizations use a combination of open-source and proprietary code libraries. If a similar name exists, developers or automated build tools may mistakenly fetch an internal package from a public repository instead of an internal repository. Attackers can exploit this by gathering the proprietary package names and publishing malicious versions to public repositories under the same name. This risk can be prevented by ensuring proper configuration using namespace scoping, private registries, and version pinning.
Typically, developers fetch the library they want from the internet, and they do not take security into account, according to Nalluri. Then they integrate it into the organization by committing it to the code repositories. From there, it can be propagated to the build system and all the other environments, from development to user acceptance testing (UAT) to production.
“Most developers just want OSS to work and get the job done. They rarely question where it came from or what it actually does,” said Nalluri. So, they download the code from the easiest available source, which can lead to operational disruptions related to code quality and malicious intent.
When a code library enters the organization, it brings nested dependencies, and transitive packages are automatically pulled in. But developers may fail to verify who developed the library originally. Is that developer credible and actively maintaining the library? Are errors being addressed?
If not, once the offending code is inside the system, it can enable a range of attacks, from a protestware message with FFIEC repercussions to the theft of personally identifiable information, such as Social Security numbers. If the latter, then compliance issues become critical. The system could violate GDPR, the US State of California Consumer Privacy Act (CCPA), or PCI DSS.4
OSS Policy-as-Code
Every organization has legacy libraries. The original developers may no longer maintain them, but that does not mean all organizations have stopped using them. Scanning tools can identify vulnerabilities, but most of the time, they cannot be fixed, because the libraries are no longer being actively maintained.
Developers often fail to verify the integrity and reputation of the libraries, which can open the door to a malicious attack. “Open-source resiliency starts with open-source ingestion policy and standards,” Nalluri notes. Enterprises can rely on external scoring frameworks but they may need to be customized based on organizational or geopolitical needs. Nalluri’s team addressed this by creating an open-source adoption policy including a scoring framework (figure 1), risk heat mapping, and a geopolitical matrix.
Figure 1—Scoring Framework
| Metric Category | Weight % | Score Range | Scoring Guidance |
|---|---|---|---|
|
1. Project activity |
30% |
|
|
|
a. Commit frequency |
10% |
0–100 |
Daily = 100, weekly = 80, monthly = 60, |
|
b. Issue resolution time |
8% |
0–100 |
< 24 hours = 100, < 7 days = 80, |
|
c. Release cadence |
7% |
0–100 |
Monthly = 100, quarterly = 80, |
|
d. Maintainer response rate |
5% |
0–100 |
> 90% = 100, 70–90% = 75, |
|
2. Contributor trustworthiness |
20% |
|
|
|
a. Maintainer identity |
6% |
0–100 |
Corporate entity = 100, verified individual = 80, |
|
b. Contributor diversity |
5% |
0–100 |
> 10 contributors = 100, 5–10 = 75, 2–5 = 50, 1 = 30 |
|
c. Geopolitical risk |
9% |
0–100 |
Multidemocratic = 100, low-risk = 80, partial high-risk = 40, majority high-risk = 10 |
|
3. Security posture |
35% |
|
|
|
a. CVE history (3 years) |
10% |
0–100 |
None = 100, low = 80, medium = 50, high = 10 |
|
b. CVE response time |
8% |
0–100 |
< 7 days = 100, < 30 days = 80, |
|
c. Security practices |
2% |
0–100 |
Policy + bounty = 100, policy = 80, some |
|
d. Dependency security |
5% |
0–100 |
All dependencies updated = 100, < 3 outdated = 80, |
|
e. OpenSSFScoreCard5
|
10% |
0–100 |
|
|
4. Community and |
15% |
|
|
|
a. Active usage |
6% |
0–100 |
> 1,000,000 users/week = 100, 100,000–1,000,000 = |
|
b. Enterprise adoption |
4% |
0–100 |
Fortune 500 companies = 100, tech firms = 80, some |
|
c. Community engagement |
5% |
0–100 |
Active forums = 100, regular issues = 80, |
|
Total score |
100% |
0–100 |
A = 90–100, B = 80–89, |
The scoring framework consists of a column of metrics by category, such as open-source project activity or “commit frequency.” If there are more commits, that means that the project is actively being maintained. And if there is an issue with how fast function or security issues are solved, then the framework will bring it to light.
Contributor trustworthiness is an important factor to consider when geopolitical implications are involved. If libraries are maintained by contributors in countries subject to sanctions or export controls, identifying the maintainers becomes critical. It is very difficult to get maintainers’ identities, but a sort of pseudoidentity or maintainer attribution can be inferred from commit metadata, such as username, commit times, commit history, contribution patterns, and time zones. This is a crucial factor in critical infrastructure sectors such as nuclear energy, power grids, or defense systems, where dependency trust directly impacts national security.
Next comes the security posture, which provides an estimated count of common vulnerabilities and exposures (CVEs) and assigns response times to fix them. It is also important to consider what libraries the open-source application is dependent on and whether there are any leaks in the chain of dependencies.
Community adoption references how many times an open-source library is downloaded. For example, if a library is downloaded 100,000 times per month, that is considered a reliable metric—the more times a library is downloaded, the more times it is reviewed.
The weight percentages can be customized on a case-by-case basis.
To categorize risk, Nalluri’s team divided the applications into different groups: mission-critical and business-critical (figure 2). Nalluri designed an automated open-source checker workflow that considers application risk, sanctions, and geopolitical situations. This enabled secure and efficient management of the internal open-source repository.
Figure 2—Risk Heat Mapping
| Application Criticality | Risk Level | Approval Status | Notes |
|---|---|---|---|
|
Mission-critical |
Low risk (A–B) |
Approved |
Autoapproval with monitoring |
|
Mission-critical |
Medium risk (C) |
Review board |
Requires CISO approval |
|
Mission-critical |
High risk (D–F) |
Prohibited |
No exceptions permitted |
|
Business-critical |
Low risk (A–B) |
Approved |
Standard approval |
|
Business-critical |
Medium risk (C) |
Mitigation required |
Compensating controls needed |
|
Business-critical |
High risk (D–F) |
Prohibited |
Allowed only with vice president or head of IT waiver |
|
Noncritical |
Low risk (A–B) |
Autoapproved |
No review required |
|
Noncritical |
Medium risk (C) |
Approved |
Team lead’s approval |
|
Noncritical |
High risk (D-F) |
Mitigation required |
Monthly review required |
Whenever a developer requested a new library, the request first went to an internal open-source active repository. If the library existed, it was automatically supplied to the developer. If it did not exist, the request would invoke the open-source checker, which evaluates packages based on various aspects of the library, and then either approves it or sends it for review. Based on that, Nalluri’s team autoapproved the known and reputable libraries. For unknown libraries, the chief information security officer (CISO) team is required to conduct a review.
When it comes to geopolitical risk (figure 3), if the open-source library maintainer is located in Europe or the Five Eyes (Australia, Canada, New Zealand, the United Kingdom, the United States), five risk points can be assigned, meaning it is low-risk. If the maintainer comes from other geographic locations, it should be given higher risk points.6
Figure 3—Geopolitical Risk Matrix
| Maintainer Type | Location | Risk Points | Weight Multiplier | Notes |
|---|---|---|---|---|
|
Corporate entity |
European Union/ |
5 |
1 |
Low-risk multiplier |
|
Corporate entity |
Other democracies |
10 |
1.2 |
Medium-risk multiplier |
|
Corporate entity |
High-risk nations |
50 |
2 |
High-risk multiplier |
|
Verified individual |
United States/European |
10 |
1.2 |
Medium-risk multiplier |
|
Verified individual |
Other democracies |
20 |
1.5 |
Elevated risk multiplier |
|
Verified individual |
High-risk nations |
75 |
2.5 |
Very high-risk multiplier |
|
Anonymous |
United States/European |
30 |
1.5 |
High baseline risk |
|
Anonymous |
Other democracies |
50 |
2 |
Very high baseline risk |
|
Anonymous |
High-risk nations |
100 |
3 |
Extreme risk (avoid) |
A weight multiplier is applied to normalize on a scale of 0 to 100. If one does not know the maintainer or anything about the library’s source, it should be avoided. “Trust in open-source isn’t just about the code—it’s about who wrote it, where it came from, and whether it aligns with your organization’s risk profile,” Nalluri said.
“Open-source components may require legal review in addition to security analysis, especially when licensing restrictions or sanctions are involved,” said Nalluri. He added that an architectural review may also be necessary when systems are tightly coupled with high-risk open-source libraries.
The diagram in figure 4 depicts a traditional unprotected system, with poor practices depicted in red.
In a traditional scenario, tampering can occur when developers push a modified library into a repository without proper validation. The modification may be either malicious or well-intended—for example, fixing bugs. However, if the intent is malicious, it can be classified as insider threat activity, potentially introducing protestware, banner messages, backdoors, or time-triggered attacks.
“If I'm a developer and I want to introduce protestware,” Nalluri explained, “I can just slip it into the centralized repository. Once it’s in the source code management, it flows straight into the build pipelines without any verification.” In traditional setups, even if any scans happen at all, it is unlikely they will pick up the intentionally modified code. The result? Protestware is quietly introduced into production. “Trust without verification turns your software supply chain into a Trojan horse,” Nalluri notes.
Continuous monitoring remains essential even after approved libraries are deployed to production, as vulnerabilities including protestware can emerge at any time.In contrast, the secure approach is illustrated in figure 5, which depicts the policy-as-code workflow.
In the OSS policy-as-code scenario, a request will go to the internal repository. The build can communicate with the internal repository, so an automated conversation might be: “A developer is requesting this library. Do you have it in your repository?” Then the internal repository will respond, “I have it. It's already verified. You can take it.” The developer can have it immediately.
If the library does not exist, it will send the request to the OSS tool, and the tool performs all the checks. It takes the policy and scoring framework as input, and then it performs its own checks. If approved, it sends it to the organization’s repository.
“If the package requires manual, licensing, or legal reviews, then it is routed through a formal evaluation process,” said Nalluri, effectively cutting the direct connection between the developers and uncontrolled internet sources.
Continuous monitoring remains essential even after approved libraries are deployed to production, he emphasized, as vulnerabilities including protestware can emerge at any time. Tools such as the OpenSSF Malicious Package scanner7 can help identify malicious packages along with other threat intel activities.
The OSSPolicyGuard, a prototype project Nalluri developed on GitHub,8 includes screenshots that illustrate the policy-as-code concept and demonstrate the tool’s capabilities (figure 6). It is designed to assess the trustworthiness of open-source components within DevOps workflows.
“We invoked the library, and then it gave the results about this code, the criticality of it, the package manager,” Nalluri explained. “You can also see the risk levels in the output. The risk level is marked as medium-low. In this case, it's a visualization of aspects of that same output. So here it's giving you different scores: What is the project activity and what are the security aspects of it? And is it a trusted developer? And what is the community score?”
Answers to questions such as these are important for ensuring that coded applications are safe.
Business Advantages
There have been many business benefits of the project, including greater ease in managing open-source systems, impressive risk reduction, and improved operational stability.
Nalluri’s project resulted in:
- 95% reduction in unauthorized OSS package updates—Developers credited the system’s immutable dependencies policy and automated monitoring.
- Proactive detection and blocking—Developers thwarted multiple attempts to introduce malicious code post-installation.
- Enhanced developer awareness—After training, developers proactively identified and escalated more than 20 instances of suspicious package activity before deployment.
- Improved regulatory compliance—The organization’s SBOM validation aligned with industry best practices, ensuring compliance with the US National Institute of Standards and Technology Secure Software Development Framework (NIST SSDF), the EU Cyber Resilience Act, and PCI DSS.9
As part of the organization’s proactive protestware risk assessment, more than 200 open-source libraries were audited during the initial assessment phase. Post-implementation, there were no recorded security incidents directly attributed to protestware. The automated OSS risk detection and alerting mechanisms led to a 95% improvement in incident response time and enabled rapid containment of emerging threats.
Conclusion
At first glance, protestware may seem like an innocuous interference with the free flow of technology, with no major downsides to open-source application users. However, recent incidents have demonstrated its potential to disrupt critical systems. While no single solution can fully eradicate the risk, the OSS policy-as-code project significantly reduces exposure by automating guardrails against malicious updates. The project also fortified compliance and sped up response times.
Endnotes
1 Federal Financial Institutions Examination Council, “Promoting Uniformity and Consistency in the Supervision of Financial Institutions,” USA, Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation [GDPR]), ; PCI Security Standards Council, “PCI Security Standards Overview”
2 Sharma, A.; “Dev Corrupts NPM Libs 'Colors' and 'Faker' Breaking Thousands of Apps,” Bleeping Computer, 9 January 2022
3 Zhang, E.; “The Node-IPC Incident,” 19 March 2022
4 State of California Department of Justice, California Consumer Privacy Act of 2018, USA, 2018
5 GitHub, “OpenSSF Scorecard”
6 The National Counterintelligence and Security Center, “Five Eyes Intelligence Oversight and Review Council (FIORC),” USA
7 GitHub, “OpenSSF Malicious Packages”
8
GitHub, “OSSPolicyGuard”
9 National Institute of Standards and Technology (NIST) Computer Security Resource Center (CSRC), “Secure Software Development Framework SSDF,” USA, European Commission, Cyber Resilience Act, 10 December 2024
MICK BRADY
Is an internal auditor at a digital-only bank in China. He oversees continuous auditing solutions and audit analytics for the bank’s lending business, including consumer and small business lending.