CPS Reached OpenSSF Gold: the practices behind the badge

CPS says it achieved OpenSSF Best Practices Gold by enforcing review gates, deep CI testing, and security-in-pipeline controls—and by pushing org-wide chan

2026-05-08 GIGATAP Team #security
#open-source-security#supply-chain#OpenSSF

CPS Hit OpenSSF Gold: what “secure OSS” looks like in practice

The Open Source Security Foundation (OpenSSF) says the Configuration Persistence Service (CPS) project has reached the OpenSSF Best Practices “Gold” badge level. CPS is described as a persistence-focused data repository component inside ONAP (Open Network Automation Platform), which is used for telecom and network automation workloads where reliability and integrity failures can be high-impact.

This is not a vulnerability disclosure or an exploit write-up. It is a process story: how one open source project claims it met the highest tier of a widely referenced security and development practices checklist, and what other teams can take from that without over-romanticizing badges.

What happened (and what the badge actually signals)#

OpenSSF Best Practices badges are intended to show that a Free/Libre and Open Source Software (FLOSS) project follows a set of documented practices across areas like project governance, code quality, testing, and security controls. The OpenSSF post frames Gold as the most stringent level across all categories, above “Passing” and “Silver.”

In the post, CPS is positioned as the first project in the broader Linux Foundation Networking (LFN) community to reach Gold. That “first” claim matters mostly as a signal of organizational maturity: it implies the project not only improved its own repo, but also pushed on shared infrastructure and community-wide requirements.

What the badge does not prove on its own:

  • That CPS is “secure” in an absolute sense.
  • That CPS is free of vulnerabilities.
  • That CPS has perfect runtime defenses against misconfiguration, operator error, or supply chain compromise.

It does suggest the project has documented and (per the post) enforced a set of engineering and security controls that reduce the likelihood of preventable mistakes slipping through.

What CPS says it changed: quality gates, test depth, and security-in-CI#

The OpenSSF post describes a three-year effort built on three pillars: code quality, testing rigor, and a security-first mindset.

Code quality: enforceable standards and review friction#

CPS reports that it:

  • Follows Google Java style and ONAP checkstyle to keep code consistent and maintainable.
  • Prioritizes bug resolution over new features as a policy.
  • Requires a merge checklist with at least three reviewers, including the work item owner and a senior developer.

None of these is novel, but the key detail is enforcement. “We have a style guide” is cheap; “your change does not merge unless it matches style and passes review minimums” is a real control.

Testing: shift-left integration and performance checks early#

CPS describes a multi-layer test strategy:

  • Unit tests on code changes, using Groovy and Spock.
  • A “semi-integration” layer using Testcontainers (for the database and Kafka) and stubs for external dependencies.
  • Separate full end-to-end testing is still done by the team, but the post claims they have not seen an internal integration issue that wasn’t already caught earlier (or was due to external configuration).

A notable practice mentioned is performance testing integrated into unit tests. The post gives an example of using PostgreSQL containers to test algorithms and detect regressions early.

That last point is easy to miss, but it is pragmatic: many projects only notice performance collapse after release because performance tests live “somewhere else” (or nowhere). Pulling performance checks into routine CI makes them harder to ignore.

Coverage gates: what’s claimed, and what’s not specified#

The post references SonarQube/SonarCloud and states that coverage is now 100% in all but one module, and that the project requires 100% coverage and (separately) “on all new and modified code” before merge.

The source text appears truncated in places (some numbers/phrases are missing), so it’s not possible from this excerpt alone to precisely restate every metric (for example, the exact historic coverage level is not present). The operational takeaway is still clear: CPS treats coverage thresholds as a merge gate for changed code, not as a dashboard vanity number.

Security-first in CI/CD: scanning, release hygiene, and transport protection#

CPS describes security controls as embedded in pipeline work:

  • Staying current on best practices via the project technical leader (PTL) and team.
  • Using SonarCloud to detect vulnerabilities and resolving findings for current and previous releases.
  • Compatibility with ONAP’s service mesh implementation, with the post emphasizing encryption in transit to reduce unauthorized data exposure.

These are largely “table stakes” practices for high-dependency infrastructure components. The important part is that the post frames them as continuous work, not a one-time hardening sprint.

The hard part wasn’t code: shared infrastructure and 2FA#

One of the more useful sections is the “roadblocks” discussion. CPS says some Gold requirements were outside the team’s direct control because they depended on ONAP-wide infrastructure policies.

The concrete example is two-factor authentication (2FA). CPS could control 2FA for repo modifiers it managed, but some security reports were managed in a broader infrastructure area where 2FA was not initially enabled.

This is a common pattern:

  • Many supply chain controls are org-level, not repo-level.
  • A project can do “everything right” inside its repository and still fail a higher standard because account security, identity, and permissions live elsewhere.

If you are trying to raise your project’s assurance level, you should expect this friction. “Just enable 2FA” can become a multi-team migration with social, policy, and tooling dependencies.

Why this matters for supply chain and OSS consumers#

Badges can become cargo cults. But the underlying practices described in the post map closely to the failure modes that keep repeating in open source supply chain incidents:

  • Unreviewed or under-reviewed changes slipping in.
  • Tests that don’t resemble production behavior.
  • Regressions discovered late because CI is shallow.
  • Identity compromise (weak auth) enabling unauthorized changes.

For consumers of OSS, the value here is not the Gold label itself. It is the ability to ask better questions when you evaluate dependencies:

  • Does the project gate merges on review minimums?
  • Are tests only unit tests, or do they include containerized integration-style checks?
  • Are security scans wired into CI, and are findings actually remediated?
  • Is strong authentication enforced for maintainers and release pipelines?

Even if you never look at the OpenSSF criteria directly, this post gives a practical outline of what “serious” looks like.

Practical takeaways (what you can copy without chasing a badge)#

If you maintain an open source project, or rely on one, these are low-drama actions suggested by the CPS story:

  • Turn expectations into merge gates. Style, tests, review counts, and coverage targets only matter when the build blocks unsafe merges.
  • Add a semi-integration layer with Testcontainers. It’s often the best cost/benefit move between unit tests and full E2E.
  • Make performance regressions a CI problem. Even small, targeted performance checks can prevent slow-motion outages.
  • Treat 2FA as a baseline, not a nice-to-have. If the requirement spans org infrastructure, plan for the coordination cost early.
  • Separate “we scan” from “we fix.” Security scanning without remediation is theater; the post’s emphasis is on resolving findings.

What not to overclaim#

Based on the source excerpt, it would be a mistake to conclude:

  • that CPS has no vulnerabilities,
  • that Gold guarantees secure operation in every environment,
  • or that every control described is independently verified outside the project’s own reporting.

OpenSSF badges can be meaningful signals, but they are not the same thing as a third-party security audit of the codebase and deployment.

What to check next#

If you want to use this as more than a feel-good milestone, verify a few things:

  • Look up CPS’s OpenSSF Best Practices badge entry and the specific criteria it meets.
  • Review CPS’s CI configuration and contribution rules (review policy, coverage gates, security checks) in the public repo.
  • For organizations consuming CPS/ONAP components, confirm how identity controls (2FA), signing, and release workflows are enforced across the broader ecosystem—not only in one repo.

The CPS story is most useful as an operations memo: higher assurance in open source usually comes from boring discipline applied consistently, plus the willingness to fight for shared infrastructure improvements when the checklist forces the issue.