| 5 min read
At Fluid Attacks, we work diligently to offer high-quality, open-source software products. We are therefore permanently on the lookout for development best practices we can implement to keep on with our continuous improvement. It's been a year since we satisfied the "passing" level criteria of the set of best practices established by Open Source Security Foundation (OpenSSF). Since then, we have implemented further enhancements and, this month, we achieved the gold badge as a reward for our compliance with all the required criteria of the project. This is a rare achievement, attained only by 27 out of more than 6,200 software development projects that evaluated their implementation of OpenSSF best practices at the time of this writing. Two projects by Fluid Attacks —Universe and Makes— are among those few. This achievement for Universe comes after we reached statement and branch coverages above 90% in the source code of our vulnerability scanner and platform.
What is Open Source Security Foundation?
Open Source Security Foundation (OpenSSF) is an organization that aims to advance open-source security by providing tools, services, infrastructure, training and resources that enable participants in the open-source ecosystem’s knowledge of secure development practices, creation and distribution of security policies, identification of vulnerabilities for prompt remediation, and notification about quality, supportability, defects and mitigations.
This organization is a project of Linux Foundation, which helps developers and companies identify and contribute to important open-source projects. OpenSSF, in turn, draws together the most important open-source security initiatives and the people and firms that support them.
OpenSSF best practices
OpenSSF's Best Practices for OSS Developers working group raises awareness and fosters education on best practices for secure coding. The group currently develops the OpenSSF Best Practices Badge project, to which a web application (BadgeApp) is associated. On this application, free/libre and open-source software (FLOSS) projects can self-certify their level of compliance according to the percentage of criteria they meet. Some criteria are absolutely required, whereas other, although normally required, admit valid reasons for being ignored.
In the next six lists, we summarize the best practices that, according to the working group, "well-run FLOSS projects typically already follow," that is, we think they mean, before trying to implement practices motivated by OpenSSF's project. Still, they say, "only about 10% of projects pursuing a badge achieve [this] passing level."
Best practices categorized as "Basics":
-
Showing in the project's website a succinct description of what the software does, what it should be done to obtain or provide feedback on the project and contribute to it, and what is required for such contributions to be acceptable.
-
Releasing the software product as FLOSS, ideally approved by the Open Source Initiative, and publishing the FLOSS license in the source repository.
-
Providing a basic documentation of the software product and reference documentation of its external interface. Normally, this documentation would be available in English.
-
Supporting HTTPS using TLS in the project's website(s).
-
Having at least one searchable mechanism of discussion where messages and topics can be referenced with URLs.
-
Maintaining the project by responding to significant problem and vulnerability reports. Normally, the project would accept reports in English.
Best practices related to change control:
-
Having a version-controlled source repository publicly readable that has its own URL, allows traceability and includes versions between releases subject to peer-review. It is advised that a common distributed version control software such as Git be used.
-
Having a unique version identifier for each release.
-
Providing human-readable release notes that include all the major changes and CVE IDs of eliminated vulnerabilities.
Best practices related to error and vulnerability reporting:
-
Providing users a process to submit bug reports, responding to a majority of those received in the last two to twelve months, and keeping an archive for reports and responses. Normally, projects would use issue trackers for individual issues and respond to more than half the requests for enhancements.
-
Publishing the vulnerability reporting process on the project website and informing how it works for private reports (if possible).
-
Taking a maximum of fourteen days to respond to vulnerability reports received in the last six months.
Best practices related to software quality:
-
Providing a working build system that can rebuild the software from source code, should it be necessary to build the software product for use. Normally, the tools for this would be FLOSS.
-
Using at least one automated test suite that is FLOSS. It is advised that the tests cover most functionalities, branches and input fields (i.e., that most of them have a corresponding test verifying they do what is expected of them). Further, it is advised to implement continuous integration, running automated tests to check the new or changed code.
-
Creating tests for major new functionalities and having a general policy enforcing it.
-
Enabling a tool or feature to look for common mistakes in code and addressing any warnings generated.
Best practices related to security:
-
Having at least one primary developer who is knowledgeable in secure software design, meaning he understands design principles such as open design, least privilege, input validation with allowlists, fail-safe default, economy of mechanism, and other.
-
Having at least one primary developer who is knowledgeable in common errors that lead to vulnerabilities like those exposing to SQL injection and cross-site scripting attacks.
-
Using cryptographic functions based on pre-existent, tested, secure and approved mechanisms.
-
Transmitting data using secure protocols (e.g., HTTPS) to counter man-in-the-middle attacks.
-
Having no vulnerabilities of medium or higher severity unpatched and known publicly for over 60 days. Projects are advised to eliminate critical vulnerabilities found in their product ASAP.
-
Leaking no valid private credentials intended to limit user access.
Best practices related to static application security testing (SAST) and dynamic application security testing (DAST):
-
Testing any proposed major production release with a SAST tool before it's available to end users and remediating all found vulnerabilities of medium or higher severity quickly (as required above). It is advised that SAST be conducted "on every commit or at least daily."
-
Remediating quickly (see above) all vulnerabilities of the aforementioned severity levels found through a DAST tool. It is suggested that DAST be conducted before releasing major changes. Special emphasis is made in detecting memory safety problems with DAST if the project includes code in memory-unsafe languages.
Fluid Attacks' recent OpenSSF gold badge
In August, 2022, our Universe repository got a “passing” OpenSSF badge for meeting all the criteria summarized above. (We had certified Makes with this kind of badge earlier that year, in March.) We worked further to implement many more best practices ranked in a higher level by OpenSSF's project. For some time, Universe held a "silver" badge.
We want to highlight some best practices at the silver level for their extreme relevance related to project oversight and software quality. The ones in the former category include
-
defining and documenting a clear project governance model, where the roles and responsibilities and the structure for decision-making are spelled out, and
-
adopting a publicly viewable code of conduct.
Regarding software quality, we highlight best practices like listing external dependencies and monitoring third-party components and vulnerabilities found in them.
The last achievements we documented to gain the OpenSSF gold badge for Universe corresponded to the statement and branch coverages in two of our components. Statement coverage refers to the completeness of a test suite evaluating units that state the actions to be taken with the data on which a program is to operate. Branch coverage is the completeness of a test suite evaluating decision points' (if and case statements') true and false cases. Evidencing both types of coverage being above 90% (in the case of branch coverage, 10% higher than required), we finally satisfied the pending criteria to get our gold badge this month. We are very proud of this achievement and will keep working to uphold it.
You might be interested in using our high-quality and accurate vulnerability scanner to conduct SAST, DAST, software composition analysis, and cloud security posture management in search of security issues present in your software. Then, you can manage those vulnerabilities with the help of our high-quality platform. Try it all for free for 21 days!
Recommended blog posts
You might be interested in the following related posts.
