Confronting the OWASP Top 10 OSS Risks for Industrial Automation Control Systems

Industrial automation and control systems (IACS) and critical infrastructure are increasingly reliant on open source software to support automation processes, visual monitoring and data processing as part of the digital transformation wave. Without proper governance and security assessments, these open source applications can become potential entry points for hackers or a cause of system failures. The “Top 10 Open Source Software Security Risks” summarized by OWASP in 2024 provides a comprehensive view of these challenges. Below, we will cite each risk using its original title and discuss its implications, common scenarios and corresponding solutions in the context of industrial automation and control systems.

OSS-RISK-1: Known Vulnerabilities in Dependencies

This risk refers to open source components that have been disclosed in CVEs or other channels as having vulnerabilities. However, in industrial automation and control systems, these components continue to be used without timely patching, ultimately giving attackers a chance to exploit “known weaknesses.”

• Common Scenario
  In IACS and critical infrastructure, once software is deployed, it often runs for an extended period. Due to concerns about the high cost of downtime, upgrade plans may be postponed, allowing previously disclosed vulnerabilities to linger and pose potential risks. Since halting a production line or critical infrastructure can lead to significant economic and societal impact, management might delay fixing known issues while weighing operational considerations.
• Mitigation
  If an immediate shutdown or resolution of compatibility issues is not possible, implement network segmentation, firewall policies and intrusion detection tools as compensating controls to block possible attack vectors. Later, test updates offline or in a staging environment to verify functionality and compatibility, then perform official patches during scheduled maintenance. At the organizational level, adopt automated or semi-automated vulnerability scanning and version inventory processes to detect and manage known vulnerabilities early, reducing exposure risks.

OSS-RISK-2: Compromise of Legitimate Package

This risk arises when an open source project or its distribution channel is breached, and malicious code is injected into what is otherwise a “legitimate” package. Users unwittingly introduce malware into their systems when they update to the latest version.

• Common Scenario
  Industrial automation and control systems, with long operational lifecycles, frequently rely on consistent update versions provided by vendors. Should an official repository or maintainer account be compromised, downstream systems can be affected on a large scale. There have been past incidents where maintainer credentials were stolen or package repositories were hacked, turning otherwise safe projects into attack platforms — often without victims realizing the compromise in the early stages.
• Mitigation
  Whenever update files are downloaded, verify authenticity or integrity by checking digital signatures or hash values before applying an “official update.” If feasible, introduce offline inspection processes or file integrity checks. Supply chain security audits are equally crucial — require suppliers to use multi-factor authentication, rigorous version control and security reviews to reduce the risk of malware being injected at the supplier stage.

OSS-RISK-3: Name Confusion Attacks

Attackers exploit names that closely resemble common packages or libraries (e.g., typosquatting, brand-jacking) to confuse users during download or installation, resulting in malicious components being mistaken for official versions.

• Common Scenario
  In development environments, engineers or external contractors sometimes rely solely on keyword searches to locate open source packages. If a package name differs by only one letter or has a similar pronunciation, it is easy to download a malicious version by mistake — unintentionally introducing it into the core of a production system.
• Mitigation
  Organizations can establish controlled repositories or mirror systems that centrally manage audited open source packages. Whether installing new software or upgrading, require offline comparison processes, verifying maintainer accounts, project documentation and community activity to ensure the downloaded version is indeed the official project. This approach helps mitigate the impact of name confusion attacks in industrial control environments.

OSS-RISK-4: Unmaintained Software

If an open source component or a particular version is no longer maintained, any functional defects or security vulnerabilities discovered subsequently will not be patched, causing risks to accumulate over time.

• Common Scenario
  Industrial automation and control systems can operate for many years or even decades. If core libraries or drivers lose support from the community or maintainers, future vulnerabilities may remain unaddressed. Historically, insufficiently maintained projects have forced downstream vendors to self-patch or fully replace them, resulting in high technical and administrative challenges.
• Mitigation
  During design or procurement stages, prioritize open source projects with long-term support (LTS) or clear maintenance cycles. If an already deployed component lacks maintenance, consider seeking alternative solutions within the community or internally “forking” the project to maintain necessary functions in-house. Additionally, implement mechanisms to track project activity and budget enough resources for security, allowing swift response to potential replacement or enhancement requirements.

OSS-RISK-5: Outdated Software

Systems continue using outdated software even though newer versions or security patches are available upstream. Failing to upgrade in a timely manner accumulates known vulnerabilities and compatibility risks.

• Common Scenario
  Industrial control environments place a high value on stability and availability, causing organizations to remain on older versions out of concern for the operational disruptions or compatibility issues that upgrades may cause. Although upstream providers regularly release new features and patches, delayed adoption accumulates many potential vulnerabilities, making it even more challenging to upgrade when a major incident or system failure eventually occurs.
• Mitigation
  At the organizational level, use a Software Bill of Materials (SBOM) to regularly inventory all critical open source components and consider incremental or major upgrade strategies based on offline testing. Test compatibility in a sandbox or staging environment first, ensuring minimal risk when implemented in production. A planned approach to upgrades balances security with functional availability and avoids being caught off-guard by severe incidents.

OSS-RISK-6: Untracked Dependencies

Systems may contain open source components introduced through non-standard or indirect channels, and neither development nor operations teams are aware of them. As a result, these components remain unmonitored for potential vulnerabilities or compliance issues.

• Common Scenario
  During the development and maintenance of industrial automation and control systems, third parties might supply “custom drivers,” “protocol interface libraries” or other add-on code. These components could be built internally or by external contractors and installed via non-standard methods. If they’re not documented in the SBOM, typical scanning tools will not detect them, leaving the organization unaware of any existing vulnerabilities. A security flaw in an undisclosed component can silently infiltrate the core of a factory production environment, posing a considerable threat.
• Mitigation
  Tighten contractual and management processes by requiring suppliers and internal teams to provide and regularly update SBOMs. Use multiple scanning tools (e.g., FOSSology, Dependency-Check) for cross-verification to include all direct and indirect dependencies in security reports. Once a hidden component is discovered, quickly assess its maintenance status and license compliance, then integrate it into standard operations to prevent it from becoming a lurking threat.

OSS-RISK-7: License and Regulatory Risk

If the licensing terms or regulatory compatibility of an open source package conflicts with an organization’s business model or industry regulations, it can cause legal and compliance issues. A lack of clear licensing can also expose the organization to infringement lawsuits.

• Common Scenario
  Some open source projects may not specify their license clearly or include restrictions unsuitable for industrial control contexts. If an organization incorporates such software without prior review, it may face significant risks later regarding government procurement, export controls, or customer contracts. The organization could also be forced to discontinue use due to licensing disputes.
• Mitigation
  Establish open source compliance processes aligned with standards like OpenChain ISO/IEC 5230, and use automated tools to examine the licensing details of each component, removing ambiguous or conflicting dependencies early on. Additionally, include open source compliance obligations in supplier contracts, requiring them to ensure license conformance for all used components. Organizations may also refer to the OpenChain ISO/IEC 18974 standard for open source security to ensure comprehensive risk management in industrial environments.

OSS-RISK-8: Immature Software

Immature open source projects often lack thorough testing, version control and code reviews. As a result, code quality and security cannot be guaranteed, and the software may crash or expose severe vulnerabilities under high loads or specific scenarios.

• Common Scenario
  Industrial control environments demand extremely high system stability and availability. If an organization adopts a new, untested package that lacks robust security checks, the production line could face large-scale downtime or equipment failures under high workload or unexpected conditions. Many early-stage open source projects do not have sufficient test coverage or review mechanisms in place.
• Mitigation
  Before deploying into production, conduct offline stress tests, static code analysis, known vulnerability scans and fuzz testing, especially in high-risk environments. Perform additional penetration testing to evaluate potential attack vectors. Observe a project’s community support, release frequency and code review processes — particularly checking if it has integrated testing in CI/CD or DevOps pipelines — to gauge whether it meets industrial requirements for stability and security. If it appears immature, consider more stable alternatives or invest resources to strengthen its testing framework and ensure it meets the standards required for industrial systems.

OSS-RISK-9: Unapproved Change (Mutable)

If the download process for open source components does not ensure that versions are fixed or transmitted via secure channels, attackers may intercept and modify files, resulting in a final codebase that differs from what was intended and introducing potential security risks.

• Common Scenario
  Industrial automation and control systems are sensitive to version changes. If developers or engineers download updates over HTTP or use dynamic, versionless links, they could unknowingly receive tampered files. Such “unapproved changes” can find their way into production areas unnoticed, creating a serious hidden danger that is difficult to trace.
• Mitigation
  Organizations should formalize policies prohibiting downloads over HTTP or via dynamic URLs, mandating that all files have version identifiers and are verified by hashes or digital signatures. Only after acceptance in a test environment should they be introduced into production. Combining these practices with rigorous change management, record-keeping and configuration control ensures that file sources, corresponding versions, checksums and audit trails are well-documented for rapid incident response and accountability.

OSS-RISK-10: Under/Over-Sized Dependency

Whether the software is too small or too large, it can bring disproportionate security and maintenance risks. In the former case, if the maintainer’s account is hacked, all downstream users suffer. In the latter, including many unnecessary modules expands the attack surface and increases potential vulnerabilities.

• Common Scenario
  Some small-scale projects are maintained by only a handful of developers. If the maintainer discontinues the project or their account is compromised, all users are affected. Conversely, large libraries may carry many unused modules in an industrial setting, all of which present a broader attack surface. This imbalance often complicates system operation and maintenance.
• Mitigation
  Enforce a “least functionality principle.” Only include the features truly needed in industrial automation and control systems, avoiding the indiscriminate accumulation of either too many tiny components or overly extensive libraries. If a large library is necessary, use network segmentation and feature isolation to contain unnecessary or high-risk modules in secondary zones. Where possible, develop lightweight functionalities in-house or select better-maintained alternatives to reduce the security and operational burden.

Conclusion: Open Source Supply Chain Security for Industrial Control

Overall, the 10 risks summarized by OWASP are particularly pronounced in industrial automation and control systems and critical infrastructure. Because of the long system lifecycle and stringent requirements for stability and compliance, any unmanaged or vulnerable open source component can lead to large-scale downtime or even public safety risks. To address these challenges, consider building security in from the design phase and carefully planning the entire supply chain.

• Adopt Secure by Design
  Integrate security considerations into system architecture and development processes from the outset, avoiding major retrofit efforts when vulnerabilities surface later.
• Use SBOM (Software Bill of Materials)
  Keep a comprehensive record of all open source components, including their versions, origins, etc. This helps quickly identify impact and action steps when vulnerabilities emerge.
• Enforce Authenticity and Integrity Checks
  Digitally sign or hash all update files and packages before adoption, reducing the risk of hidden tampering. Within the organization, set up offline validation or file comparison mechanisms to confirm “official updates” are truly from legitimate sources.
• Combine Defense-in-Depth, Strict Change Processes, and Compensating Controls
  Employ network segmentation, firewall strategies, vulnerability scanning, and layered monitoring. Even when immediate patching is not feasible, interim compensating measures can help contain risks.
• Long-Term Maintenance and Compliance
  Because industrial systems have lengthy operational cycles, choose open source components with transparent maintenance periods and compliant licenses. Regularly assess evolving regulations and standards such as OpenChain ISO/IEC 5230 and ISO/IEC 18974 ensures long-term open source supply chain compliance and security.

In an era of digital transformation, these strategies help industrial organizations improve operational efficiency while maintaining resilience and security — ensuring critical infrastructure and industrial operations continue functioning reliably.

References

1. OWASP Top 10 Risks for Open Source Software, https://owasp.org/www-project-open-source-software-top-10/
2. ISO/IEC 5230:2020, https://www.iso.org/standard/81039.html
3. ISO/IEC 18974:2023, https://www.iso.org/standard/86450.html
4. FOSSology, https://www.fossology.org/
5. OWASP Dependency-Check, https://owasp.org/www-project-dependency-check/
6. OpenSSF, https://openssf.org/