Article by Toine Siebelink.
When I started working in Open Source in 2020, I was tasked with setting up a greenfield project for a Configuration Persistence Service: CPS. It quickly evolved into two functions: CPS-Core for persisting, managing, and querying any YANG-modelled data. YANG is just another language to describe data with a data model. This could be radio network configuration (management) data or just a bookstore inventory…
Specifically for network configuration data, we developed the Network Configuration Model Proxy (NCMP). This component harmonizes access to the Configuration Management (CM) data. It hides the complexity of addressing using a node inventory. It can provide YANG data (optionally cached) and models. It leverages CPS-Core to store its own data and cache CM data.
Being a software engineer with an inherited focus on quality, I ensured that quality was built in from the start. Nowadays, security safeguards and best practices have also become a major part of what constitutes quality software.
OpenSSF Best Practices Gold Badge
When I learned of the OpenSSF Best Practices Badge Program, I realized that was an ideal instrument to prove and showcase the standard of quality in my project. We set a goal to achieve the highest level, i.e., Gold Standard. A level that was deemed unachievable by the experienced developers working with us in the ONAP project CPS was part of.
Being a Java SpringBoot project with a high level of code coverage, we quickly achieved some of the required milestones. Regarding practices for security, my team and I needed to improve our skills. But with the help of experts in the community and applying best-in-class solutions like a Kubernetes service mesh implementation, we were also able to cross the finish line. In July 2021, the project was awarded the Gold Badge. Currently, only 58 out of 9,483 projects have achieved this level—less than 1%!
Maintaining High Standards
Having achieved the Gold Standard also means we now have a team with a mentality that is focused on security and quality while evolving the product. These are the bread and butter of our daily work. Our code coverage is at 100% for all our modules and is guarded by our build jobs. The reason for this level is to prevent slippage, which typically happens in the more awkward scenarios if you allow for a lower limit. Don’t forget test-ware also functions as a great tool for describing your code, helping troubleshooting (of those awkward error scenarios), and future maintainers of the project.
The cost of maintaining this is not very high through the good test patterns that have been established over the lifetime of the project. And these costs outweigh the time gained by preventing issues, more efficient troubleshooting, etc.
Although not required by OpenSSF best practices, we also apply extensive integration tests using stubs for other components we don’t have (easy) access to. This increases the level of confidence in the product and speeds up PoCs and troubleshooting. A further extension of the integration tests is our performance tests that safeguard the performance of our components and can also be used to quantify proposed performance improvements in an efficient manner.
Regarding security, we have stepped up the speed and frequency with which we apply fixes (updates) for Common Vulnerabilities and Exposures (CVEs). Of course, we have jobs that regularly check our source base for the latest CVEs to identify those. Everyone in the development team has now also integrated SonarQube to get warnings about code quality or security issues during development. Obviously, the earlier in the process these are detected, the easier and cheaper it is to address them.
Finally, another complementary approach to reduce security risk is to reduce the number of dependencies. So, we proactively examine our dependency tree to eliminate dependencies such as libraries that are really just different flavors for the same solution as preferred by one or another developer. It might take some refactoring, but in such cases, it is better to choose one flavor and reduce the exposure to security risks.