Open Mainframe Project's Security Flaws

I was chatting with a mainframer buddy the other day, and he expressed some concerns about the overall code security of the Open Mainframe Project (OMP) particularly around member vetting. So, I spent a bit of time digging into the OMP. I love its mission. It was launched back in 2015 to be the center of gravity for open-source and Linux in the mainframe world. And it's been wildly successful at its goal: bridging the skills gap and proving the mainframe is a modern, critical platform.

But the deeper I looked, the more I realized something deeply troubling: the OMP's security posture is dangerously misaligned with the high-assurance, high-stakes world it lives in.

The entire OMP philosophy is built on an "open tent" and a 2015-era model of human trust. Its success in building a community is also its greatest liability. Its trust model is rooted in human reputation and corporate relationships, not technical proof. And that's a model that has been catastrophically exploited in attacks like the XZ Utils backdoor.

I've done a deep analysis of the project's structure, governance, and technical pipeline. What I found isn't pretty.

Here's the TL;DR of my findings:

The "Human Pipeline" is a Backdoor: The OMP's LFX Mentorship Program is its single greatest vulnerability. It’s a formalized, high-trust "golden ticket" for an unvetted person to get direct access to core projects and mentors from IBM, Broadcom, and SUSE. It’s a ready-made vector for a "mentee-to-malware" social engineering attack.
Security is Dangerously Inconsistent: The OMP is a "neutral home" for a collection of self-governed projects. This "every-project-for-itself" model means security is all over the map. The Galasa project has a robust, preventive check to block unknown code. The flagship Zowe project doesn't, and instead relies on reactive scans after code is already in the pipeline.
It's a "Black Box" Pipeline: The OMP's security practices are dated. They tout things like SBOMs and the CII Best Practices Badge. That’s great, but the XZ attacker also had a CII badge. It's security theater. I found no evidence of modern, cryptographic attestation. There's no Sigstore artifact signing (to prove who made it) and no SLSA build provenance (to prove how it was made). Consumers are flying blind.
Governance is Opaque and Unprovable: The OMP's "Root of Trust" isn't hardware —it's human reputation. Trust is delegated to committees. And when I went to find the actual rules for promoting a contributor to a committer for key projects like Zowe and Galasa? The GOVERNANCE.md files were inaccessible.

This report is an exhaustive breakdown of these vulnerabilities. Let's get into it.

I. How "Open" Governance Becomes a "Pay-to-Play" Attack Vector

To understand the problem, you have to look at how the OMP is run. It’s a "project-centric" umbrella with a two-headed governance structure: corporate business interests and project-level technical autonomy.

This federated model creates a ton of seams for an attacker to exploit.

The "Pay-to-Play" Governance Attack

The OMP is a "Directed Fund" of the Linux Foundation. This means corporate members drive the vision by funding the project.

Member Tiers: You have Platinum (think Broadcom, IBM, SUSE), Silver, and Academic members.
The Governing Board (GB): This group oversees the money and business decisions.
The Technical Advisory Council (TAC): This group supposedly "directs and coordinates" the technical community.

Here’s the problem: the official charter explicitly links your membership tier to appointed seats on both the business-focused GB and the technically-focused TAC.

This is a high-level "pay-to-play" attack vector. A well-resourced entity could buy a Platinum membership and instantly get a "vetted," legitimate, appointed agent inside the OMP's highest governance circles. This agent isn't just a coder; they're in the private meetings where budgets, strategic direction , and the acceptance of new projects are decided.

Inconsistent Security = No Security

The OMP is just an "umbrella" offering a "neutral home" for a diverse set of projects—Zowe, Galasa, Feilong, and the new AI-focused Zorse.

Each project is "self-governed". The OMP gives them a template for a SECURITY.md file , but doesn't seem to enforce a specific, mandatory security baseline.

This means the security of the "Open Mainframe Project" brand is only as strong as its weakest popular project. An attacker will just pivot to the project with the biggest blast radius (like Zowe ) that also has the weakest contribution process.

Where Are the Rules?

The most critical process in a trusted pipeline is "privilege escalation"—how a random contributor becomes a "committer" with write-access. This process should be transparent.

I went looking for it.

Zowe's GOVERNANCE.md: Inaccessible.
Galasa's GOVERNANCE.md: Inaccessible.

This is a massive security vulnerability. It means the actual process for getting keys to the kingdom is informal, ad-hoc, and based on the subjective discretion of existing committers. It's a "tap on the shoulder" model—precisely the environment a long-term social engineering attacker is built to exploit.

II. The "Human Pipeline": How to Launder an Attacker's Identity

The OMP's mission is to "equip students with... skill sets" and build a "robust ecosystem". This focus on education has created a "human pipeline" that is, by design, incredibly porous.

The LFX Mentorship Program: A "Mentee-to-Malware" Attack Chain

The OMP's LFX Mentorship Program is its most celebrated human pipeline. From a security view, it's the most glaring vulnerability I've ever seen.

The XZ attack was a multi-year campaign to build trust. The OMP Mentorship Program accelerates this entire process and hands it to an attacker on a silver platter.

Here's the attack chain:

Infiltration: A state-sponsored actor ("Alice") applies to the LFX Mentorship Program with a polished resume.
Vetting Failure: Who reviews the 1,100 applications for 13 spots? "Our program's incredible mentors". These mentors are vetting for skills and passion, not for being a covert operative. Alice is selected for the Feilong project.
Trust Assignment: Alice is now an official "mentee". She isn't a random, untrusted contributor; she's a vetted participant. She's immediately paired with high-level mentors from IBM and SUSE.
Building Social Capital: Alice now works closely with these "leaders in the mainframe community" , gaining their personal trust. Her code is reviewed, but with the positive bias of a mentor-mentee relationship.
Graduation: At the end, Alice is "exposed to potential employers" and is now a "graduate." Her association with her prestigious mentors becomes a social proxy for trust, allowing her to bypass the normal skepticism and angle for committer status.

The Opaque Path to Committer

The goal of this long-con is to get committer status. Zowe's docs say you need a Developer Certificate of Origin (DCO) (a legal-only step) and that committing "requires additional access rights"... but as we've seen, the document defining those rights is missing.

In this vacuum, an attacker just needs to submit a series of "hypocrite merge requests" —seemingly good contributions that are part of the long con. In a system with no public rules, the promotion to committer will be based on social consensus—exactly what the attacker has been manufacturing.

Corporate and Academic Member Vetting

This presents another "pay-to-play" vector for trust. The formal OMP Participation Agreement details the vetting for organizations. This vetting is entirely focused on finance, legal status, and IP, with zero mention of security.

Vetting Criteria: Must be a Corporate Member of the LF, an academic institution, or a non-profit.
Member Responsibilities: The agreement is explicit about IP (GPLv2, Apache 2.0) and payment schedules. It is silent on any member responsibility to maintain a secure development posture.

An organization (e.g., a state-sponsored front company) can buy a seat at the table, gain legitimacy, and then nominate their own people for the Mentorship Program or appoint representatives to the TAC.

III. The "Trusted" Code Pipeline: A Tale of Two Projects

Let's say our attacker is in. What's to stop their malicious code? This is where I found the most glaring technical inconsistency.

CI/CD Infrastructure as a Target

The OMP provides centralized "mainframe infrastructure for your CI/CD needs". This central build system is a high-value target, susceptible to "dependency confusion" (where a public package tricks an internal build) or CI/CD pipeline attacks that steal tokens to "inject nefarious code".

Case Study 1: Zowe (The Flagship)

Zowe is the OMP's most important project. Its security process is mature, but it's reactive. It’s designed to catch bad code, not prevent it.

A contributor submits code.
It goes through a human code review (which we know is fallible ).
It's scanned by static analysis tools like SonarCloud.
A Security Workgroup meets bi-weekly to review the scan results.

Static analysis is notoriously bad at finding clever, obfuscated backdoors (like XZ's). The primary defense is a human review, which is exactly what a "hypocrite merge request" is designed to pass. While Zowe has a mature process for handling vulnerabilities after they're found (including "Limited Public Disclosure" and a CVE process ), its preventive controls are weak.

Case Study 2: Galasa (The Fortress)

In stark contrast, I looked at the Galasa project's automation repository. They get it.

The github-verify Tool: The Galasa CI/CD pipeline has a custom tool.
What it does: It verifies that a user submitting a pull request is already an "approved code-committer or code-admin" before it proceeds with a build.
The Workflow: If an unknown user (like our attacker, "Alice") submits a PR, the build is not triggered. Nothing is executed. A comment is posted telling the author they need manual approval just to run the build.

This is a zero-trust model. It is the single most effective pipeline control I found. It forces a human committer to make an auditable decision ("I approve this build") before any of the OMP's resources are used to execute or test an attacker's code.

The fact that Galasa has this, and the flagship Zowe project does not, is the smoking gun for inconsistent security. An attacker, finding Galasa hardened, will simply pivot to Zowe, where their malicious PR will be built, giving them a "free" oracle to test their attack against SonarCloud.

Table 1: Comparative Security Posture of OMP Core Projects

Security Control	Zowe (Flagship Project)	Galasa (Test Framework)	Feilong (z/VM Connector)
Governance Model	TSC-led ; "Squads" ; Security Workgroup.[14, 54]	Technical Steering Committee (TSC).[56, 57, 58]	TSC-led (inferred from mentor orgs ).
Governance Transparency (Committer Promotion)	Inaccessible (`GOVERNANCE.md` ). Process is opaque.	Inaccessible (`GOVERNANCE.md` ). Process is opaque.	Not documented in research. Likely opaque.
Pre-Build Contribution Gate	None identified. Relies on post-commit/pre-merge checks.	Yes (`github-verify`). Blocks builds from non-approved committers.	Not documented in research.
CI/CD Security Checks	Human Code Review Static Analysis (SonarCloud) - DCO Sign-off	DCO Sign-off (inferred from OMP standard)	Mentorship-based review `pep8` and unit tests
Vulnerability Reporting Process	Mature. Publicly documented ; formal CVE process ; Limited Public Disclosure.	Not documented in research. Likely uses OMP template.[40, 41]	Not documented in research. Likely uses OMP template.[40, 41]
Foundational Attestation (CII/SBOM)	Yes. CII Best Practices Badge ; SBOMs.[15, 59]	Yes. (Inferred OMP-wide policy ).	Yes. (Inferred OMP-wide policy ).
Modern Attestation (Sigstore)	None identified.	None identified.	None identified.
Modern Attestation (SLSA Provenance)	None identified.	None identified.	None identified.
Modern Attestation (Reproducible Builds)	None identified.	None identified.	None identified.

IV. The Black Box: OMP's 2015-Era Supply Chain Security

This is the part that truly worries me. In a post-SolarWinds world, a "trusted pipeline" must produce cryptographic proof of its integrity.

The OMP's pipeline is a total black box.

Current Posture: The "CII Badge" Era

OMP projects proudly state they have SBOMs (required by the LF ) and have "earned the Core Infrastructure Initiative (CII) Best Practice Badge".

This is security theater.

The XZ Utils project also had a CII Best Practices Badge. The badge is a "voluntary self-certification" checklist. It proves you have a SECURITY.md file , not that your code is safe. Relying on this creates a false sense of trust.

The Gaps: Where is the Real Security?

1. Critical Gap: No Artifact Signing (Sigstore) The modern standard for trusting a binary is sigstore. It allows projects to cryptographically sign their releases. I found zero evidence that any OMP project uses it, even though the Linux Foundation promotes it. Without Sigstore, a user downloading a Zowe binary has no cryptographic proof that it was actually released by the OMP and hasn't been tampered with.

2. Critical Gap: No Build Provenance (SLSA) SLSA (Supply-chain Levels for Software Artifacts) is a framework that generates a "provenance" file —a signed attestation of how, where, and from what source a binary was built. I found zero evidence any OMP project is SLSA compliant. This is the core failure of the trusted pipeline. Without SLSA, you cannot verify that the binary you downloaded was built from the "safe" source code on GitHub. An attacker could compromise the build system itself and inject a backdoor after the code review, and it would be undetectable.

3. Critical Gap: No Reproducible Builds Reproducible builds are the gold standard. They let you re-run the build process and get a bit-for-bit identical binary. I found zero evidence any OMP project, including Zowe , is even attempting this.

Users cannot sign the artifact (no Sigstore), cannot verify the build process (no SLSA), and cannot reproduce the build themselves. The entire mainframe ecosystem is forced to operate on 100% blind trust.

V. Conceptual Vulnerabilities (And Why They Matter)

Let's get a bit abstract. The OMP's entire philosophy is vulnerable.

1. The "Root of Trust" Gap

A "Root of Trust" (RoT) is supposed to be inherently trusted. It's an anchor. In a secure system, this is a piece of hardware—like a Hardware Security Module (HSM) or a TPM—that is secure by design and protects against insider attacks.

The OMP's security model has no technical RoT. Its Root of Trust is human reputation.

The system trusts a commit because it trusts the committer.
It trusts the committer because they were vouched for by a mentor or appointed by a member company.

A human-based RoT is vulnerable to attacks a hardware RoT is designed to prevent: phishing , "kompromat" , and long-term social engineering. The XZ Utils attack is the canonical example of a human-based RoT being successfully exploited.

2. The "Provable Governance" Gap

This is a big one for me. "Architecting Provable Governance" implies a system where rules are not just written down but are technically enforced and auditable. It’s about "provable proof" that a process was followed, aligning IT with business goals.

The OMP's governance is the opposite of provable. It is delegated.

Delegated Governance: The community delegates trust to the GB , the TAC , and the project TSCs to make decisions.
Unprovable Process: When Zowe's Security Workgroup meets , you cannot cryptographically verify this happened. When a mentor "selects" a mentee , it's an opaque, human decision. And the GOVERNANCE.md files that would describe the process are missing.

You cannot prove that OMP's stated security policies were actually followed for the binary you're about to install.

3. The New Threat: "Anchoring Agentic AI Governance"

Just when you thought it was safe, OMP has exposed itself to a brand-new attack vector. This concept, "anchoring agentic AI governance," addresses the risks of autonomous AI agents. In October 2024, OMP announced the "Zorse" project.

Zorse Project: Its goal is to "train and evaluate large language models (LLMs) for mainframe programming languages" and "collect large, production-quality datasets".
The Vulnerability: An attacker (like our "mentee" Alice) can now target Zorse.
- Memory Poisoning: Alice can contribute poisoned data to Zorse's "production-quality datasets". This data could be subtly flawed COBOL, designed to train the LLM to produce vulnerable code.
- Backdoor: Alice could contribute to the "evaluation tool" itself.

This is a next-generation supply chain attack. An AI assistant (Zorse) that "helps" a developer write COBOL could be subverted to always inject a buffer overflow. OMP is now at the forefront of this new threat.

VI. So, What's the Fix? (Strategic Recommendations)

The Open Mainframe Project is at a crossroads. It has fostered a vibrant community , but it built that community on an exploitable foundation of human-based trust.

Here is a clear, actionable plan to fix it.

Harden the Human Pipeline: The Mentorship Program is a critical mission, but it must be treated as a high-risk security vector.
- Mandate Security Training: All mentors and mentees must complete the LF's "Developing Secure Software" (LFD121) training.
- Implement "Two-Person Rule": All code from mentees (or any contributor with <1 year of tenure) must be approved by two tenured committers from different member organizations. This breaks the "trusted mentor" vulnerability.
Adopt Modern, Provable Security: OMP must move to a zero-trust posture.
- Mandate Sigstore: The OMP TAC must mandate project-wide adoption of Sigstore for signing all release artifacts.
- Mandate SLSA: The TAC must mandate that all projects achieve, at minimum, SLSA Build Level 2 , generating verifiable, non-forgeable provenance.
- Enforce Reproducible Builds: Start a working group to get Zowe's core components on a path to reproducible builds.
Standardize Pipeline Controls: The fragmented security posture is unacceptable.
- Mandate the "Galasa Model": The robust, pre-build github-verify control should be standardized and required for all OMP projects. Unknown code must never execute in a build pipeline without explicit, auditable approval.
Enforce Governance Transparency: Opacity is a vulnerability.
- Mandate Public Governance: The OMP TAC must enforce that all hosted projects have a public, clear, and comprehensive GOVERNANCE.md and SECURITY.md file. The fact that Zowe's and Galasa's files are inaccessible is a critical failure that must be fixed today.
Move Trust Toward Hardware: To fix the "Root of Trust" gap , OMP must anchor its trust in hardware, not reputation.
- Mandate Hardware Keys: The OMP TAC should require all committers with write-access to core repositories to use a hardware-backed key (e.g., YubiKey, HSM) for all code-signing and commit operations. This mitigates the risk of committer-account compromise.

References

Open Mainframe Project. (2025). Project Template. https://github.com/openmainframeproject/project-template
Topelson Ritvo, D., Hessekiel, K., & Bavitz, C. T. (2017). Organization & Structure of Open Source Software Development Initiatives. Harvard Law School. https://clinic.cyber.harvard.edu/wp-content/uploads/2017/03/2017-03_governance-FINAL.pdf
The Linux Foundation. (2025). Open Mainframe Project Directed Fund Participation Agreement. httpss://cdn.platform.linuxfoundation.org/agreements/open-mainframe-project.pdf
Sharma, D. (2025). Mentorship Series: Give Love to the Bugs List. Open Mainframe Project. https://openmainframeproject.org/blog/mentorship-series-give-love-to-the-bugs-list-my-mid-term-journey-with-the-open-mainframe-project-by-divij-sharma/
GitHub. (2025). Open Mainframe Project Foundation Repository. https://github.com/openmainframeproject/foundation
OpenSSF. (2025). Predictions for Open Source Security in 2025: AI, State Actors, and Supply Chains. https://openssf.org/blog/2025/01/23/predictions-for-open-source-security-in-2025-ai-state-actors-and-supply-chains/
GitHub. (2025). Open Mainframe Project Artwork Repository. https://github.com/openmainframeproject/artwork
GitHub. (2025). Open Mainframe Project TAC Repository. https://github.com/openmainframeproject
Open Mainframe Project. (2025). Open Mainframe Project Blog. https://openmainframeproject.org/
Reproducible Builds. (2025). Reproducible Builds Reports. https://reproducible-builds.org/reports/2025-03/
Zowe.org. (2025). Zowe Security Policy. https://www.zowe.org/security
arXiv. (2024). The Rising Specter of Governance Attacks in Open-Source Gen AI. https://arxiv.org/html/2405.08597v1
GitHub. (2025). Galasa Community Repository GOVERNANCE.md (Inaccessible).(https://www.google.com/search?q=https://github.com/galasa-dev/community/blob/main/GOVERNANCE.md)
Ladisa, P., et al. (2023). A General Taxonomy for Attacks on Open-Source Supply Chains. arXiv. https://oaklandsok.github.io/papers/ladisa2023.pdf
Mohammed, T. (2025). Summer Mentorship 2025: Tasneem Mohammed. Open Mainframe Project. https://openmainframeproject.org/blog/summer-mentorship-2025-tasneem-mohammed/
Open Mainframe Project. (2025). Mentorship Program Resources. https://github.com/openmainframeproject-internship/resources
OWASP. (2025). State of Agentic AI Security and Governance. https://mediate.com/state-of-agentic-ai-security-and-governance-summary-for-legal-and-compliance-professionals/
Open Mainframe Project. (2025). Security Innovation and Collaboration Fuel Mainframe Transformation. https://openmainframeproject.org/blog/securing-the-software-that-matters/
Open Mainframe Project. (2025). Should You Be Concerned About Security With Zowe? https://openmainframeproject.org/blog/should-you-be-concerned-about-security-with-zowe/
webmethodman.com. (2025). The Root of Trust. https://www.webmethodman.com/p/the-root-of-trust
GitHub. (2025). Zowe Community Repository GOVERNANCE.md (Inaccessible).(https://www.google.com/search?q=https://github.com/zowe/community/blob/master/GOVERNANCE.md)
IBM. (2025). What Is a Neural Network? https://www.ibm.com/think/topics/neural-networks
The Linux Foundation. (2025). Linux Foundation Welcomes the AGNTCY Project. https://www.linuxfoundation.org/press/linux-foundation-welcomes-the-agntcy-project-to-standardize-open-multi-agent-system-infrastructure-and-break-down-ai-agent-silos
Reddit. (2025). MCP Is So Mickey Mouse, Here's Why. https://www.reddit.com/r/modelcontextprotocol/comments/1jz4gz7/mcp_is_so_mickey_mouse_heres_why/
Open Mainframe Project. (2025). OMP Summer 2025 Mentorship. https://openmainframeproject.org/blog/omp-summer-2025-mentorship/
Open Mainframe Project. (2025). Our Projects. https://openmainframeproject.org/our-projects/
OpenSSF. (2025). OpenSSF Best Practices Badge Program. https://www.bestpractices.dev/en
GitHub. (2025). Galasa Automation Repository. https://github.com/galasa-dev/automation
Open Mainframe Project. (2025). Open Mainframe Project Home. https://openmainframeproject.org/
slsa.dev. (2025). SLSA Provenance. https://slsa.dev/provenance
GitHub. (2025). Zowe CLI Repository. https://github.com/zowe/zowe-cli
Security Boulevard. (2024). Securing the Software Supply Chain with the SLSA Framework. https://securityboulevard.com/2024/10/securing-the-software-supply-chain-with-the-slsa-framework/
Open Mainframe Project. (2025). Governing Board. https://openmainframeproject.org/about/governing-board/
Reproducible Builds. (2025). Reproducible Builds Home. https://reproducible-builds.org/
Open Mainframe Project. (2025). Mentorship Program. https://openmainframeproject.org/community/mentorship-program/
Reddit. (2023). How Do You Do Code Review?https://www.reddit.com/r/SoftwareEngineering/comments/18h76u4/how_do_you_do_code_review_what_strategy_should_be/
Open Mainframe Project. (2025). Category: Announcements. https://openmainframeproject.org/category/announcements/
Open Mainframe Project. (2025). Security Innovation and Collaboration. https://openmainframeproject.org/blog/security-innovation-and-collaboration-fuel-mainframe-transformation/
The Linux Foundation. (2024). A Guide to Open Source Software Supply Chain Security.
Open Mainframe Project. (2025). The US Executive Order and OMP. https://openmainframeproject.org/blog/the-us-executive-order-and-omp/
Open Mainframe Project. (2025). Mentorship Program. https://openmainframeproject.org/projects/mentorship/
Medium. (2025). Agentic AI Governance: What It Is and Why It Matters. https://medium.com/@ayushi.gautam_11469/agentic-ai-governance-what-it-is-and-why-it-matters-343a0bf5b9ff
OWASP. (2025). OSS-RISK-2: Compromise of Legitimate Package. https://owasp.org/www-project-open-source-software-top-10/0-1-risks/OSS2-Compromise-Legitimate-Package
Endor Labs. (2025). OWASP OSS Risk 2: Explore the Compromise of Legitimate Open-Source Packages. https://www.endorlabs.com/learn/owasp-oss-risk-2-compromise-of-legitimate-package
Zowe.org. (2025). Zowe Home. https://www.zowe.org/
Zowe Docs. (2025). Zowe Overview. https://docs.zowe.org/stable/getting-started/overview
sigstore.dev. (2025). Sigstore Home. https://www.sigstore.dev/
Seers, L. (2025). Galasa Updates. Open Mainframe Project. https://openmainframeproject.org/blog/galasa-updates/
Reddit. (2015). How Do Developers Trust That 3rd Party JS Isn't Nefarious? https://www.reddit.com/r/javascript/comments/b4fonl/how_do_developers_trust_that_3rd_party_js_isnt/
Krishnan, A. (2025). Exploring OpenTelemetry Priorities for Mainframes. Open Mainframe Project. https://openmainframeproject.org/blog/exploring-opentelemetry-priorities-for-mainframes-insights-from-survey-responses/
Open Mainframe Project. (2025). Zowe Build Open Source With Open Source. https://openmainframeproject.org/blog/zowe-build-open-source-with-open-source/
contributing.md. (2025). Leadership and Governance of Open Source Projects. https://contributing.md/leadership-and-governance-of-open-source-projects/
GitHub. (2025). Galasa-dev Organization. https://github.com/galasa-dev
Reddit. (2013). A Simple Way of Defeating the Compiler Backdoor? https://www.reddit.com/r/programming/comments/1m4mwn/a_simple_way_of_defeating_the_compiler_backdoor/
GitHub. (2025). Open Mainframe Project Artwork Repository SECURITY.md (Inaccessible).(https://www.google.com/search?q=https://github.com/openmainframeproject/project-template/blob/main/SECURITY.md)
Open Mainframe Project. (2025). Join the Open Mainframe Project. https://openmainframeproject.org/about/join/
Hacker News. (2024). Discussion on XZ Utils Backdoor. https://news.ycombinator.com/item?id=40267666
lwn.net. (2024). Reproducible Builds Report. https://lwn.net/Articles/985739/
Open Mainframe Project TAC. (2025). Project Review Cycle. https://tac.openmainframeproject.org/process/review_cycle.html
Zowe Docs. (2025). Contributing to Zowe. https://docs.zowe.org/stable/contribute/contributing
Endor Labs. (2025). Hypocrite Merge Request. https://www.endorlabs.com/learn/owasp-oss-risk-2-compromise-of-legitimate-package
Open Mainframe Project. (2025). The US Executive Order and OMP. https://openmainframeproject.org/blog/the-us-executive-order-and-omp/
Medium. (2025). Is Your Mainframe Software Supply Chain Secure? https://medium.com/modern-mainframe/is-your-mainframe-software-supply-chain-secure-39de2ea3610b
Reddit. (2024). Open Source Integrity and Nefariousness. https://www.reddit.com/r/opensource/comments/1izz7ny/open_source_integrity_and_nefariousness/
OpenSSF. (2025). OpenSSF Best Practices Badge Program. https://openssf.org/projects/best-practices-badge/
bestpractices.dev. (2025). OpenSSF Best Practices Badge Program. httpss://www.bestpractices.dev/en
GitHub. (2025). CII Best Practices Badge Repository. https://github.com/coreinfrastructure/best-practices-badge
OpenSSF. (2025). Sigstore Graduates. https://openssf.org/blog/2024/03/20/sigstore-graduates-a-monumental-step-towards-secure-software-supply-chains/
OpenSSF. (2025). Sigstore Project. https://openssf.org/projects/sigstore/
OpenSSF. (2025). OpenSSF Blog. https://openssf.org/tag/and-slsa/
Open Mainframe Project. (2025). Walking the Open Source Trail. https://openmainframeproject.org/blog/walking-the-open-source-trail-toward-supply-chain-integrity-and-security-video/
Zowe Docs. (2025). Setting Up Your Development Environment. httpss://docs.zowe.org/stable/extend/extend-cli/cli-setting-up/
GitHub. (2025). Zowe Advocacy Council (ZAC) Repository. https://github.com/zowe/zac
Zowe Docs. (2025). Zowe Docs PDF (v2.9.x). https://docs.zowe.org/zowe-docs-v2.9.x.pdf
Zowe Docs. (2025). Contribute to Zowe. https://docs.zowe.org/stable/contribute/roadmap-contribute
GitHub. (2025). Zowe zowe.github.io Repository. https://github.com/zowe/zowe.github.io
GitHub. (2025). Open Mainframe Project Foundation Repository. https://github.com/openmainframeproject/foundation
Open Mainframe Project. (2025). Services for Projects. https://openmainframeproject.org/our-projects/services-for-projects/
Open Mainframe Project. (2025). Embracing Open Source Excellence. https://openmainframeproject.org/blog/embracing-open-source-excellence/
Open Mainframe Project. (2025). OMP Summer 2024 Mentorship Program. https://openmainframeproject.org/blog/open-mainframe-projects-summer-2024-mentorship-program/
Open Mainframe Project. (2025). OMP Mentorship Summer 2024. https://openmainframeproject.org/blog/omp-mentorship-summer-2024/
Open Mainframe Project. (2025). Feilong Project. httpss://openmainframeproject.org/projects/feilong/
Open Mainframe Project. (2025). My LFX Journey: The Zowe App Store UI Project. https://openmainframeproject.org/blog/my-lfx-journey-the-zowe-app-store-ui-project/
Open Mainframe Project. (2025). Get Your Mentorship On. https://openmainframeproject.org/blog/get-your-mentorship-on-open-mainframe-project-opens-annual-mentorship-application/
The Hacker News. (2024). GitHub Vulnerability Artipacked Exposes. https://thehackernews.com/2024/08/github-vulnerability-artipacked-exposes.html
Open Mainframe Project. (2025). Secure Development Practices Within Zowe. https://openmainframeproject.org/blog/secure-development-practices-within-zowe/
Open Mainframe Project. (2025). Security Innovation and Collaboration. https://openmainframeproject.org/blog/securing-the-software-that-matters/
Open Mainframe Project. (2025). Should You Be Concerned About Security With Zowe? https://openmainframeproject.org/blog/should-you-be-concerned-about-security-with-zowe/
Zowe.org. (2025). Zowe Security Policy. https://www.zowe.org/security
Open Mainframe Project. (2025). Secure Development Practices Within Zowe. https://openmainframeproject.org/blog/secure-development-practices-within-zowe/
bestpractices.dev. (2025). Zowe CII Badge Status. https://www.bestpractices.dev/projects/2226
GitHub. (2025). Galasa Automation Repository. https://github.com/galasa-dev/automation
Zowe Docs. (2025). Zowe Docs PDF (v2.13.x). https://docs.zowe.org/zowe-docs-v2.13.x.pdf
Seers, L. (2023). Galasa: My First 6 Months. Open Mainframe Project. https://openmainframeproject.org/blog/galasa-my-first-6-months/
Seers, L. (2025). Galasa Updates. Open Mainframe Project. https://openmainframeproject.org/blog/galasa-updates/
Open Mainframe Project. (2023). OMP Welcomes Galasa. https://openmainframeproject.org/press/omp-welcomes-galasa-into-its-ecosystem/
Open Mainframe Project. (2025). Embracing Open Source Excellence. https://openmainframeproject.org/blog/embracing-open-source-excellence/
Open Mainframe Project. (2025). The US Executive Order and OMP. https://openmainframeproject.org/blog/the-us-executive-order-and-omp/
OpenSSF. (2025). OpenSSF Best Practices Badge Program. https://openssf.org/projects/best-practices-badge/
Open Mainframe Project. (2025). Zowe 1.0 Announcement. https://openmainframeproject.org/news/open-mainframe-project-advances-modern-mainframe-with-production-ready-zowe-1-0/
OpenSSF. (2025). Sigstore Project. httpss://openssf.org/projects/sigstore/
sigstore.dev. (2025). Sigstore Home. httpss://www.sigstore.dev/
GitHub. (2025). Sigstore Blog: How to Sign a Release. https://blog.sigstore.dev/how-to-sign-a-release-of-oss-e96ee94286fc/
OpenSSF. (2025). Sigstore Graduates. httpss://openssf.org/blog/2024/03/20/sigstore-graduates-a-monumental-step-towards-secure-software-supply-chains/
Reddit. (2024). How Do Developers Trust That 3rd Party JS Isn't Nefarious? httpss://www.reddit.com/r/javascript/comments/b4fonl/how_do_developers_trust_that_3rd_party_js_isnt/
Checkmarx. (2025). Malicious Code Guide. https://checkmarx.com/learn/supply-chain-security/malicious-code-guide/
Reddit. (2014). Open Source Integrity and Nefariousness. https://www.reddit.com/r/opensource/comments/1izz7ny/open_source_integrity_and_nefariousness/
slsa.dev. (2025). SLSA Home. https://slsa.dev/
slsa.dev. (2025). SLSA Provenance. https://slsa.dev/provenance
Medium. (2025). SLSA Compliance at Scale. https://medium.com/@mikeystrauss/slsa-compliance-at-scale-provenance-generation-with-scribe-447cd3ad1ba2
Security Boulevard. (2024). Securing the Software Supply Chain with the SLSA Framework. https://securityboulevard.com/2024/10/securing-the-software-supply-chain-with-the-slsa-framework/
Reproducible Builds. (2025). Reproducible Builds Home. https://reproducible-builds.org/
lwn.net. (2024). The Reproducible Builds Project in 2024. https://lwn.net/Articles/985739/
Reproducible Builds. (2025). Reproducible Builds Reports. https://reproducible-builds.org/reports/2025-03/
Zowe Docs. (2025). Zowe Overview.
Zowe Docs. (2025). Setting Up Your Development Environment. httpss://docs.zowe.org/stable/extend/extend-cli/cli-setting-up/
webmethodman.com. (2025). Architecting Provable Governance. https://www.webmethodman.com/p/architecting-provable-governance
webmethodman.com. (2025). Anchoring Agentic AI Governance. https://www.webmethodman.com/p/anchoring-agentic-ai-governance-to-a-hardware-root-of-trust
Synopsys. (2025). What Is a Root of Trust? https://www.synopsys.com/glossary/what-is-root-of-trust.html
Thales. (2025). What Is a Root of Trust? https://cpl.thalesgroup.com/faq/hardware-security-modules/what-root-trust
Entrust. (2025). What Is a Root of Trust? https://www.entrust.com/resources/learn/what-is-root-of-trust
Rambus. (2025). Hardware Root of Trust. https://www.rambus.com/blogs/hardware-root-of-trust/
Microchip. (2025). Basics of a Root of Trust Solution. https://www.youtube.com/watch?v=CdZgQsvxNVU
Medium. (2025). Agentic AI Governance: What It Is and Why It Matters. https://medium.com/@ayushi.gautam_11469/agentic-ai-governance-what-it-is-and-why-it-matters-343a0bf5b9ff
YouTube. (2025). Effective Enterprise Architecture Governance. https://www.youtube.com/watch?v=svmNUF4kc0w
YouTube. (2025). Enterprise Architecture Governance. https://www.youtube.com/watch?v=RA2d9bb_rfY
YouTube. (2025). Architect's Approach to Governance. https://www.youtube.com/watch?v=8dy7HAw-KWM
YouTube. (2025). What Is Enterprise Architecture Governance.(https://www.youtube.com/watch?v=HylObBTWR1s)
Atlassian. (2025). How Atlassian & Okta Govern AI Agents. https://www.youtube.com/watch?v=Mv35WmjizeA
OWASP. (2025). State of Agentic AI Security and Governance. https://mediate.com/state-of-agentic-ai-security-and-governance-summary-for-legal-and-compliance-professionals/
The Linux Foundation. (2024). OMP Redefines Developer Experience on the Mainframe with AI. https://www.linuxfoundation.org/press/omp-redefines-developer-experience-on-the-mainframe-with-ai
Open Mainframe Project. (2025). OMP Redefines Developer Experience. https://openmainframeproject.org/announcements/open-mainframe-project-turns-10-and-celebrates-at-ibm-techxchange-and-gs-uk/
GitHub. (2025). Galasa-dev Project Management Repository. https://github.com/galasa-dev/projectmanagement
Open Mainframe Project. (2025). Open Mainframe Project 2024 Annual Report. https://openmainframeproject.org/wp-content/uploads/sites/14/2025/02/omp_ar24_0202425a.pdf
Medium. (2025). Is Your Mainframe Software Supply Chain Secure? https://medium.com/modern-mainframe/is-your-mainframe-software-supply-chain-secure-39de2ea3610b
arXiv. (2023). A General Taxonomy for Attacks on Open-Source Supply Chains. https://oaklandsok.github.io/papers/ladisa2023.pdf

The Open Mainframe Project Has a Trust Problem.