Today we’re very excited to present FINOS Security Scanning - a FINOS initiative for driving security best practices across our hosted projects. This helps FINOS project maintainers quickly enable continuous scanning on their hosted codebase, as an additional tool of security options.

1. Proactive (triggered periodically, i.e every day) and reactive (triggered on code changes).
   
   
2. Compatible with all languages and build platforms adopted by FINOS hosted projects.
   
   
3. Easy to operate by project teams, git-based, without the need for external dashboards.
   
   
4. Integrated into FINOS project onboarding process and FINOS CVE Disclosure Policy.
   
   
5. Monitored by FINOS Staff, allowing us to provide  proactive support to our projects.

Given the wide range of platforms, languages and build systems used by FINOS projects, finding one solution that fits all requirements was not an easy task. Especially considering the incredible amount of libraries available in public library repositories, which can be easily used, embedded, integrated and re-published; this proliferation of artifacts have dramatically influenced software development:

• On average, 95% of the code shipped in a software artifact is composed of downstream libraries (aka dependencies), built, released and managed by external teams, communities and companies that the consumer has no control or influence over.
  
  
• A developer has little awareness of the codebase quality and software development process in the downstream dependencies of a project, unless going through code scrutiny, which is difficult and time consuming.
  
  
• Every programming language and build tool has a different way of consuming downstream dependencies, making security tools adoption harder and rarer. For example,more security vulnerabilities are released into public library repositories, which leads to the exponential growth of vulnerabilities and risk for all consumers using these libraries.

To address these concerns, FINOS Security Scanning focuses on library scanning, with the aim of providing a simple and efficient way to identify and manage Common Vulnerability and Exposures (or CVE). Our goal is to make this solution available to all FINOS projects and embed it in our contribution onboarding process.

The combined proactive/reactive approach is crucial to enforcing security, as it ensures that the code will always be free of CVEs, provided that changes are always submitted via Pull Requests:

• The reactive setup will fail any Pull Request where code change introduces a new CVE from the (updated) dependency list.
  
  
• The proactive setup will notify the team if a new CVE (that affects a library in the dependency list) has been published.

Based on the requirements discussed above, we consolidated a list of technical requirements:

• 6 supported build platforms - Maven, Gradle, Python (plus Poetry), Scala (with SBT), NodeJS and Rust.
  
  
• CVE scanning
• Can be configured to only scan runtime dependencies
• Scans direct and transitive dependencies
• Ability to ignore warnings/errors, using a git-hosted file
• Ability to run as part of CI/CD (GitHub actions)
  
  
• Static code analysis
• Ability to run as part of CI/CD (GitHub actions)|
  
  
• Documentation that describes how to use the scanning and what to expect

The mechanism to ignore false positives (alerts that incorrectly indicate that a vulnerability is present) should allow defining rules to ignore a specific CVE, a file, a library or a block of code. Rules should be defined in files hosted on Git, in order to provide direct access to the entire developer team, responsible for keeping it up to date to avoid getting spammed by useless alerts.

The CI/CD integration is a key requirement when used with GitHub branch protection, to make sure that  the main branch can only be updated via Pull Requests and  nobody, other than repository Administrators, can merge a Pull Request that introduces vulnerabilities (since the scanning failed). This ensures that no change can be made to the main branch, unless successfully scanned, and that’s why at FINOS we’re reaching out to our project teams to protect their main code branches.

The project landing page (i.e the README.md) should report the status of the security scanning runs (i.e Github Actions badges), in order to help consumers validate the level of scrutiny that the code has been through and decide whether to adopt it or not.

Scanning features

The FINOS Security Scanning is a collection of libraries, GitHub Actions and documentation that allows developers to quickly enable CVE scanning and Static code analysis, in a GitHub hosted code repository, across different languages and build platforms:

• Maven - uses the OWASP dependency check Maven plugin
• Gradle - uses the OWASP dependency check Gradle plugin
• Scala (with SBT) - uses the OWASP dependency check Scala plugin
• Python - uses Safety
• NodeJS - uses AuditJS (Sonatype)
• Rust - uses cargo audit

For static code analysis we found Semgrep very easy to run locally and integrate with GitHub Actions.

The repository provides documentation to test locally, define rules to ignore warnings/errors and create GitHub Actions for each supported language. Local runs are very useful, allowing developers to play with it, understand how it works, and how to maintain it efficiently.

If you have any questions, feel free to open an issue on GitHub or email help@finos.org. We’d be happy to support you.

Additional security practices

Along with Security Scanning at FINOS, we’re fully embracing the OpenSSF Best Practices Badge Program, which helps projects to follow best practices, and measures its adoption. Projects can voluntarily self-certify at no cost, by using the web application to explain how they follow each best practice. Consumers will be able to easily assess the project in terms of security, quality and compliance, which is key for highly regulated industries.

We are supporting our hosted projects to self-certify, in order to move forward towards project activation, which requires an “OpenSSF Passing Badge”. There are other 2 badges, silver and gold, that can be accomplished.

Future enhancements

The security tooling landscape is constantly evolving, so it’s important to adapt quickly and take advantage of the best tools available. We want to continuously monitor and integrate with the latest offerings from FINOS Gold Members, Mend (with Renovate), Sonatype (with Lift) and GitHub (with CodeQL and dependabot). In addition to that, we also like to review other new solutions such as, Semgrep Supply Chain.

In parallel, we want to ensure a steady rollout of security scanning across all FINOS projects. Covering more languages and build platforms is important to us, to ensure  we are prepared for future contributions - next in line are C# language and mill build tool!

If you’d like to contribute additional documentation or tooling for CVE scanning or static code analysis, feel free to open an issue on GitHub.

Credits

Congratulations to the Compliant Financial Infrastructure, FDC3 and Morphir teams, for successfully adopting the FINOS security scanning and getting their OpenSSF badge. Their collaboration, availability and support have been very important to develop this project.