Substra

It uses git, URL is https://github.com/Substra

Uses git to track this. Repositories are on GitHub, which uses git. git can track the changes, who made them, and when they were made.

All released versions are put on git, not just final versions.

Uses git. Repositories on GitHub, which uses git. git is distributed.

Each release has a unique identifier.

Releases are tagged using 'git tag'.

CHANGELOG files are in the top directory of every main repository of the Substra project, for example: https://github.com/Substra/substra/blob/main/CHANGELOG.md

We intend to do that, though we don't know of any for-certain publicly known vulnerabilities.

Yes, uses GitHub issue tracker for every repository. For example: https://github.com/Substra/substra/issues

Yes, GitHub issue tracker.

Yes. None have been submitted since the return to open sourcing but we intend to do that.

Yes. None have been submitted since the return to open sourcing but we intend to do that.

Yes, via GitHub issue tracker on the various repositories. For example: https://github.com/Substra/substra/issues

https://github.com/Substra/substra/issues

Vulnerability reports are currently all public.

No external reports so far, so this is vacuously true.

Yes, the project includes a repository with a test suite: https://github.com/substra/substra-tests

Yes. "make test" invokes the automated test suite. This is documented in https://github.com/Substra/substra-tests/blob/main/README.md

Currently tests cover most of the Python and Go code, which represent the majority of the code.

CI is run on every PR to determine if there's a problem and a CI with all major tests is run every night. If a problem is found, the tools provide feedback via GitHub actions.

Yes. It is mandatory for the developers to add tests for every new functionality.

Tests are added as new functionality is added.

Our contributing guide specify: "When adding or changing functionality, please include new tests for them as part of your contribution." Cf: https://docs.substra.org/en/latest/contributing/contributing-guide.html

The project uses different linters to check for code quality errors : black, bandit & flake8 for Python, eslint & prettier for Typescript.

In general warnings are addressed. In some cases warnings are disabled for specific cases.

The settings for the warning tools are generally strict.

The project has several code owners with experience on how to design secure software.

The software uses PBKDF2 (Django default) to store salted hashed iterated passwords, and https+standard crypto protocols to communicate with users.

Uses https implementation built into its web server.

All required functionality is implemented using FLOSS, including cryptography.

https://docs.djangoproject.com/en/4.0/topics/auth/passwords/

The only cryptographic algorithm directly used by the program is PBKDF2, which is not broken.

The only cryptography used directly by this application is PBKDF2 (used for storing passwords as salted iterated hashes). At the time of this writing, no serious breaks are known in PBKDF2.

This application uses mTLS, which is not compromised if one of the long-term keys is compromised.

PBKDF2 used for storing local passwords.

The nonce for the salt is created by the PBKDF2.

Uses https for the frontend and TLS for the backend-orchestrator connection (mTLS can be activated to be even more secure).

Does not make this mistake.

No such vulnerabilities at this time.

No such vulnerabilities at this time.

No valid private credentials are leaked. Some files might include stub data for testing, but not the live credentials.

flake8, black & bandit are used to analyse the Python code. The Typescript client-side code is analysed with ESLint, prettier and a very strict tsconfig.

Bandit specifically looks for common vulnerabilities in Python code.

Yes. We've had no reports of vulnerabilities that apply to a deployed system for now.

All commits to GitHub are run through a CI, which performs a number of static analysis checks.

Application written using Python, Go and Typescript, not C/C++.

No vulnerabilities with dynamic code analysis.