This blog post is part of a blog series outlining on the processes and tools that we at SAP apply for a secure handling of our open-source supply chain. If you haven’t read the introductory blog post, you may want to read it first
here. Find below the references to the correlated blog posts:
- Introduction to SAP tools supporting the secure development process with Open Source
- Support the selection of Open Source by security ratings (the current article)
- Performing security scans early in development
- Perform more accurate vulnerability reviews by code-centric analysis
The challenge: avoid open-source becoming a long-tail cost factor
With today’s faster software release cycles and faster time to market it is even more important to make software architecture decisions based on repetitive, coherent and comprehensible criteria. A wide variety of source-code hosting platforms support the development and build process and allow professionals but also spare-time developers to share their code with the community. On the downstream consumer side, this expands the number of potential components that could be inherited to tackle the developer’s functional challenge, drastically. In addition, that results in the need of a diligent review already at the time of selection considering the long-tail costs for maintenance and bug fixing. As a result, software applications nowadays are using more open-source than ever if not to say they built upon open-source projects and frameworks like Spring Boot, Quarkus or alike. Due to the increasing number of open-source used, the continuous quality assurance during the selection process and throughout the product lifecycle becomes far more important, especially under the consideration of security aspects.
With the analogy of a car manufacturer from the first
blog post by Michael Bernhardt in mind, you can compare this with the quality assurance for 3rd-party suppliers. Core components of a car are built by the car company, but a lot of parts like the tires or front-glasses come from external suppliers. The selection of the external suppliers must be based on broad expert experience and quality agreements. But it is not only about the selection process during the design of the car. At the end of the production, all elements whether produced by the car manufacturer or a 3rd-party provider assemble the final car. Persistent failure in one component can have quite severe consequences to the overall customer perception of the whole product.
The approach: automated ratings as a best-fit indicator
Initially developed for internal usage, Fosstars is meanwhile available as open-source for the broader community to support development teams in the selection and maintenance process of open-source. With Fosstars we started to provide ratings for open-source projects which are easy to understand but fully transparent.
What is the scope of the rating provided by Fosstars?
For us, the most important aspect in using open-source projects is how the project maintainers take care about security as well as how active the community is. Because with an active community it is more likely that security issues are found and fixed fast. The scope of rating provided so far is on security metrics but is not limited to that. In the future, it might be extended by further ratings supporting the development and governance processes.
Why introducing another security metric?
When talking about security metrics mostly the CVSS[1] and CVE[2] are mentioned. In addition, the development teams pay attention that they do not use an open-source project with a known CVE. However, this metrics are some sort of binary. If your decision to inherit an open-source mostly depends on the presence of a CVE then this criteria might change tomorrow. OpenSSL with the famous Heartbleed vulnerability[3] was a famous example that the assessment for a given community artifact can change rapidly. It was also found, only after the disclosure, that the community backing OpenSSL was not enough to handle the bug fixing and quality processes. Providing a rating thereby comes in the interest of both the downstream user as well as the community, giving clear criteria for a community applying best-practices.
How can such a rating be used as part of the product development?
Whenever a development team plans to leverage an open-source component for a functional need, the rating provides the guidance which one is the best-of-breed component resulting in a balanced security risk assessment. Throughout the product lifecycle this initial rating can be reassessed by integrating Fosstars into the CI/CD pipeline, indicating critical deviations to the initial risk assumptions. Thereby, Fosstars’ security ratings allow the development team to plan mitigations in advance, before it is confronted with an unforeseen security disclosure and an insufficient mean-time-to-fix by the community. These kinds of situations often result in high-effort and error-prone emergency workarounds endangering the quality of the whole development project. At SAP, Fosstars is integrated into central tools and processes to assure a consistent guidance for the development teams throughout the company.
Does the rating provided by Fosstars represent the ultimate truth?
Defining a security baseline is always bound to the particular need of a corporation. The judgement of a deviation may vary from one corporation to another. Fosstars’ security rating aligns on the common perception of security criteria. Due to its metrics being available as open-source, everyone can review and revise the guidance provided by it. Important to consider is also that Fosstars uses widely applied mechanism and processes to assess the project, e.g. to identify whether the project applies a proper security policy or performs static code scans. If a project deviates from these mechanics or subsequent actions are not taken by the maintainers, its rating may not be totally accurate. As a project maintainer, we are grateful for the community’s effort and contribution to indicate better means to provide more accurate ratings!
Long story short, Fosstars’ security ratings cannot be considered the ultimate truth for a corporation’s individual security need. Though, its security ratings provide security-in-depth insights about potential security risks of an open-source project, in comparison to checking for known vulnerabilities only.
Conclusion
Provision of a guiding security rating with in-depth security knowledge to developers is crucial to support the responsible selection and maintenance of open-source dependencies
Fosstars’ security ratings make the decision to use a particular open-source component a lot easier for developers and helps to justify the decision towards corporate functions. Following the ‘Shift-left’ principle in security, Fosstars’ security rating is provided to our development teams early via integration into the source code management systems. Alongside with the integration in the CI/CD landscape it ensures continuous verification that the used open-source components still have the expected quality without putting this as manual load on the development teams.
The concept introduced by Fosstars allows to be further enhanced to guide developers in the process of selecting and maintaining open-source dependencies. We welcome you to follow the
Fosstars' project page or read into the
blog post by Artem Smotrakov for more detailed information on Fosstars’ security rating. The further evolution of Fosstars depends on you bringing in your expertise as part of the discussion to reflect the development principles across corporations in the best way.
[1]:
https://nvd.nist.gov/vuln-metrics/cvss
[2]:
https://cve.mitre.org
[3]:
https://heartbleed.com/