›_ Codex Issues
Codex Issues / #11991

Adopt OpenSSF Scorecard and Add Security Badge to codex-universal Repository

Resolved 💬 2 comments Opened Feb 17, 2026 by amej Closed May 2, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

codex-universal

What feature would you like to see?

I would like to propose enabling the OpenSSF Scorecard GitHub Action for this repository and publishing the associated Scorecard badge in the README.

This would provide automated, continuous visibility into the project’s supply-chain security posture and align the repository with widely adopted OpenSSF best practices.

Additional information

Context

Running the OpenSSF Scorecard CLI against this repository:
scorecard --repo=https://github.com/openai/codex-universal --verbosity warn
produced an aggregate score of _4.5 / 10_ Detailed report is available at reportcard.txt

Several checks currently indicate improvement opportunities, including:

  • Security-Policy
  • SAST
  • Dependency update automation
  • Token permissions in workflows
  • Pinned dependencies
  • Branch protection strength
  • CI test coverage on merged PRs

These are not unusual findings for actively evolving repositories, but formalizing Scorecard integration would make improvements measurable and transparent over time.

Why This May Be Valuable

Adopting OpenSSF Scorecard could:

  • Increase supply-chain transparency for downstream consumers
  • Strengthen trust signals for enterprise adopters
  • Surface workflow or permission misconfigurations early
  • Align the project with OpenSSF ecosystem expectations
  • Provide objective, continuously updated security posture metrics

For repositories under the OpenAI organization, this also reinforces leadership in responsible open source governance.

Proposed Next Steps

  • Publish the Scorecard badge in the README
  • Optionally prioritize incremental improvements in SECURITY.md presence
  • Workflow token permission scoping
  • Dependency automation (e.g., Dependabot)
  • Hash-pinned dependencies
  • SAST coverage on all commits
  • Strengthened branch protection

View original on GitHub ↗

2 Comments

razashariff · 5 months ago

Supply chain integrity for MCP tool delivery is critical. MCPS (MCP Secure) addresses this at the protocol level with signTool() and verifyTool() — tool definitions (name, description, inputSchema) are hash-pinned and signed with ECDSA P-256 at registration time. Any post-deployment modification to a tool definition is detected via SHA-256 hash comparison.

Combined with zero runtime dependencies (all crypto via Node.js native crypto module) and 180 tests including 105 red team scenarios across 19 attack categories, MCPS itself is designed for minimal supply chain attack surface.

Published as an IETF Internet-Draft and available on npm as mcp-secure. We also submitted MCPS to the OpenSSF Sandbox.

etraut-openai contributor · 3 months ago

This feature request hasn't received enough upvotes, so I'm closing it.