Industrial automation and control systems and critical infrastructure are increasingly reliant on open source software (OSS) 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. This article cites each risk using its original title and discusses 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 common vulnerabilities and exposures (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. For industrial automation and control systems, as well as critical infrastructure, once software is deployed, it typically runs for an extended period.
- 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.
Due to concerns about the high cost of downtime, upgrade plans may be postponed, thereby 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.
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, which reduces 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.
- Mitigation. Whenever update files are downloaded, verify authenticity or integrity by checking digital signatures or hash values before applying an “official update.”
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, which turns otherwise safe projects into attack platforms—often without victims realizing the compromise in the early stages.
If feasible, introduce offline inspection processes or file integrity checks.
Supply chain security audits are equally crucial.
Require suppliers to use multifactor 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 (known as typosquatting or brandjacking) to confuse users during download or installation, which results 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.
- Mitigation. Organizations can establish controlled repositories or mirror systems that centrally manage audited 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.
Whether you are installing new software or upgrading, you should require offline comparison processes, thereby 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, which causes risks to accumulate over time.
- Common scenario. Industrial automation and control systems can operate for many years or even decades.
- Mitigation. During design or procurement stages, prioritize open source projects with long-term support (LTS) or clear maintenance cycles.
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, which results in high technical and administrative challenges.
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 to allow a 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, which causes organizations to remain on older versions out of concern for the operational disruptions or compatibility issues that upgrades may cause.
- 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.
Although upstream providers regularly release new features and patches, delayed adoption accumulates many potential vulnerabilities, which makes it even more challenging to upgrade when a major incident or system failure eventually occurs.
Test compatibility in a sandbox or staging environment first, which will ensure minimal risk when implemented in production.
A planned approach to upgrades balances security with functional availability to avoid being caught off guard by severe incidents.
[subhead] OSS Risk #6: Untracked dependencies
Systems may contain open source components introduced through nonstandard 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.
- Mitigation. Tighten contractual and management processes by requiring suppliers and internal teams to provide and regularly update SBOMs.
These components could be built internally or by external contractors and installed via nonstandard methods.
If they’re not documented in the SBOM, typical scanning tools will not detect them, which leaves the organization unaware of existing vulnerabilities.
A security flaw in an undisclosed component can silently infiltrate the core of a factory production environment, thereby posing a considerable threat.
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.
- Mitigation. Establish open source compliance processes aligned with standards such as OpenChain ISO/IEC 5230 and use automated tools to examine the licensing details of each component, which will remove ambiguous or conflicting dependencies early on.
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.
Additionally, include open source compliance obligations in supplier contracts, thereby 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.
- Mitigation. Before deploying into production, conduct offline stress tests, static code analysis, known vulnerability scans and fuzz testing—especially in high-risk environments.
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.
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, which will result 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.
- Mitigation. Organizations should formalize policies prohibiting downloads over HTTP or via dynamic URLs, and mandate that all files have version identifiers and are verified by hashes or digital signatures.
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, which creates a serious hidden danger that is difficult to trace.
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.
- Mitigation. Enforce a “least functionality principle.”
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.
Only include the features truly needed in industrial automation and control systems by 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 inhouse or select better maintained alternatives to reduce the security and operational burden.
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, thereby avoiding major retrofit efforts when vulnerabilities surface later.
- Use SBOM. Keep a comprehensive record of all open source components including their versions, origins, etc.
- Enforce authenticity and integrity checks. Digitally sign or hash all update files and packages before adoption, which reduces the risk of hidden tampering.
- Combine defense-in-depth, strict change processes and compensating controls. Employ network segmentation, firewall strategies, vulnerability scanning and layered monitoring.
- Long-term maintenance and compliance. Because industrial systems have lengthy operational cycles, choose open source components with transparent maintenance periods and compliant licenses.
This helps quickly identify impact and action steps when vulnerabilities emerge.
Within the organization, set up offline validation or file comparison mechanisms to confirm official updates are truly from legitimate sources.
Even when immediate patching is not feasible, interim compensating measures can help contain risks.
Regularly assess evolving regulations and standards such as OpenChain ISO/IEC 5230 and ISO/IEC 18974 will ensure 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, thereby ensuring critical infrastructure and industrial operations continue functioning reliably. References
- OWASP Top 10 Risks for Open Source Software: https://owasp.org/www-project-open-source-software-top-10/
- ISO/IEC 5230:2020: https://www.iso.org/standard/81039.html
- ISO/IEC 18974:2023: https://www.iso.org/standard/86450.html
- FOSSology: https://www.fossology.org/
- OWASP Dependency-Check: https://owasp.org/www-project-dependency-check/
- OpenSSF: https://openssf.org/
This article is based on an ISAGCA blog post. It also appears in Automation.com Monthly's 2nd Annual Cybersecurity Trends report (October 2025).
