By Toine Siebelink
In the world of open source, trust is our most valuable currency. ONAP is a “collection of individual, semi-standalone network automation functions that provide design, orchestration, observability, and automation of network and edge services for operators, cloud providers, and enterprises” (per ONAP). When we build software that powers global telecommunications, “good enough” isn’t an option.
Today, I am incredibly proud to share that the Configuration Persistence Service (CPS) project has officially achieved the Gold Badge from the Open Source Security Foundation (OpenSSF) Best Practices program. CPS is a component that is “designed to serve as a data repository for run time data that needs to be persistent”; vulnerabilities in this vital component could have serious impacts.
This badge level isn’t just a trophy for our shelf; CPS is the first project within the broader Linux Foundation Networking (LFN) community to reach this level of excellence. Here is the story of how we reached that milestone.
What is the Gold Badge?
Many developers want their projects to be secure, but struggle to figure out where to start. The OpenSSF Best Practices badge defines a rigorous set of criteria used by Free/Libre and Open Source Software (FLOSS) projects to implement security and development best practices. It covers a wide range of categories, from application quality and project overview to infrastructure and people. While many projects achieve the “Passing” or “Silver” levels, “Gold” requires meeting the most stringent requirements in every category.
The Three Pillars of Our Journey
Achieving Gold was not a sprint; it was a three-year marathon built on three core pillars: Code Quality, Testing Rigor, and a Security-First Mindset.
1. Code Excellence
Our foundation is built on consistency and transparency.
- Strict Standards: We adhere to the Google Java style and ONAP checkstyle to ensure our codebase is readable and maintainable.
- Bugs Over Backlog: We maintain a strict policy where resolving bugs always takes priority over adding new features.
- Rigorous Peer Review: Every piece of code must pass through a checklist with a minimum of three reviewers, including the work item owner and a senior developer.
- Uncompromising Coverage: We maintain a code coverage of 97% or higher in SonarQube (now 100% in all but one module). Crucially, we require 100% coverage and zero quality violations on all new and modified code before it can be merged.
2. Testing Rigor
We don’t just test to “pass”; we test to ensure long-term stability.
- Comprehensive Unit Testing: All code modifications undergo unit testing using the Groovy and Spock frameworks.
- Semi-Integration Excellence: By utilizing Testcontainers for our database and Kafka, alongside stubs for external dependencies, we maintain an extensive test suite that validates the integration of all internal components. While our team still performs full End-to-End (E2E) testing, we have yet to encounter an integration issue that wasn’t already caught or related to external configuration. This serves as definitive proof of the completeness and “shift-left” effectiveness of our semi-integration strategy.
- Performance Guardrails: One of our more unique practices is integrating performance testing directly into our unit tests. By using PostgreSQL containers to test algorithms, we can detect and prevent serious performance degradation early in the development cycle.
3. Security-First Mindset
Security is woven into the fabric of our Continuous Integration/Continuous Deployment (CI/CD) pipeline.
- Proactive Vulnerability Management: Our project technical leader (PTL) and team stay current on security best practices. We use SonarCloud to guard against vulnerabilities, resolving them promptly for both current and previous releases.
- Encryption in Transit: CPS is fully compatible with the ONAP service mesh implementation, ensuring encryption in transit to prevent unauthorized data breaches.
Navigating the Roadblocks
The path to Gold wasn’t without its challenges. Some requirements were outside our team’s direct control, such as ONAP-wide infrastructure policies.
A major hurdle was Two-Factor Authentication (2FA). While the CPS team had direct control over repo modifiers, certain security reports were managed by broader ONAP infrastructure where 2FA was not initially activated. Navigating these “ONAP-wide” requirements required constant communication and a push for community-wide improvements. However, we’re glad we did it; 2FA provides stronger authentication, making it much more difficult for attackers to spoof authorized users.
Why This Matters
For the CPS team, this badge is about more than just security—it’s about building a reputation for reliability. It demonstrates to our community and users that we are dedicated to mitigating vulnerabilities and following the highest industry standards.
As we celebrate this milestone, we remain committed to continuous improvement. Security isn’t a destination; it’s an ongoing process of regular reviews and updates to stay ahead of evolving threats.
Beyond the Gold: The AI Frontier
Achieving the Gold Badge is a significant milestone, but for the CPS team, it isn’t the finish line. We are moving forward. As AI reshapes the software landscape, we are already investigating how to leverage AI tools to proactively detect and prevent vulnerabilities before they ever reach a human reviewer.
We believe we are on the verge of a fundamental shift in how we define “quality.” Just as the industry evolved from assembly code to high-level languages –shifting the developer’s focus from hardware registers to complex logic –we expect code quality standards to move up another level. In the near future, the focus may shift from manual line-by-line standards to AI Specifications: ensuring that the models and parameters we use to build software meet the same rigorous standards we’ve applied to our manual work today.
Another area we’re considering is also implementing the OpenSSF “baseline” set of criteria. The “gold” badge is part of the “metal” series derived from the experiences of secure FLOSS projects. The baseline series is a more minimal checklist derived from global cybersecurity regulations and frameworks. The best practices badge site supports both metal and baseline criteria, and encourages FLOSS projects to eventually implement both (to the extent that they can). Once a project does one set of criteria, it’s typically much easier to do the other; we expect that to be true for us as well.
The journey to excellence is ongoing, and we are excited to lead the way into this next chapter.
To be continued…
About the Author
A Master Engineer at Ericsson Ireland with 25+ years of experience, Toine has a proven track record of delivering complex telecommunications software. Currently, he leads the Configuration Persistence Project as PTL within ONAP for Ericsson Software Technology. Toine is a champion of software quality and security, frequently sharing his insights at industry events including OneSummit and LFN Developer & Testing Forums.