Makes

Repository on GitHub, which uses git. git is distributed.

https://github.com/fluidattacks/makes/contribute

2FA is required at the organization level, so in order to sign-in to GitHub and approve pull requests or access the repository configuration they need to authenticate first.

GitHub normally uses a token based 2FA read from a mobile authentication app, lately, the 2FA authentication is usually push-based, so a user needs to use GitHub mobile to enter the code display in the screen.

https://fluidattacks.github.io/makes/contributing/#review-process

https://gitlab.com/fluidattacks/universe/-/merge_requests/31771/diffs

We use the Makes, which uses the Nix Package Manager under the hood. The Nix Package Manager is a reproducible build tool. Generally all that is needed is a single command and that would build anything available in the repository.

The build scripts and their Nix environment definition can be found here: https://github.com/fluidattacks/makes/tree/8aeed32054e90ef6dd577a935b35d884a238dcde/makes

We have to test many programing languages, so in order to simplify orchestration we use a build tool. Usually all a person needs to do to invoke the test suite is to: - Open a pull request, which fires automated tests automatically, or - Run locally $ m . /test<something>, for example: $ m . /tests/secretsForGpgFromEnv

https://github.com/fluidattacks/makes/blob/a4b0e3ba6c309972354852efb16bca00d0d97153/.github/workflows/dev.yml#L597

Workflows are defined, running on GitHub actions https://github.com/fluidattacks/makes/tree/main/.github/workflows

Most of the code we have (the framework) uses Nix and Shell scripting, and there is no tool to measure their coverage. For our CLI application (which uses Python), we use Pytest and Pytest-Cov, to measure statement coverage, and is executed continuously by the CI/CD system on every Pull Request. However, we also have a lot of integration tests for the Nix+Shell components, so their correctness is verified as well.

Most of the code we have (the framework) uses Nix and Shell scripting, and there is no tool to measure their coverage. For our CLI application (which uses Python), we use Pytest and Pytest-Cov, to measure branch coverage, and is executed continuously by the CI/CD system on every Pull Request. However, we also have a lot of integration tests for the Nix+Shell components, so their correctness is verified as well.

• We have an A on our GitHub repository: https://securityheaders.com/?q=https%3A%2F%2Fgithub.com%2Ffluidattacks%2Fmakes&followRedirects=on
• And a D in our documentation website: https://securityheaders.com/?q=https%3A%2F%2Ffluidattacks.github.io%2Fmakes%2F&followRedirects=on, however, there is no way for us to change the headers in the documentation website, it's static, and hosted on GitHub Pages, no private information is collected, and no tracking cookies have been added by us.

We perform security reviews on each pull request. From a conceptual and design level, the potential problems and their mitigation (threat model) have been identified here: https://fluidattacks.github.io/makes/security/threat-model/. We also make sure that the design principles are secure: https://fluidattacks.github.io/makes/security/design-principles/. Static analysis tools are used often as well: https://fluidattacks.github.io/makes/security/assurance/

The Makes CLI is a Python application, there is no hardening we can do beyond making sure it runs with a recent version of Python and with dependencies free of known security vulnerabilities: https://fluidattacks.github.io/makes/security/assurance/

We use an automated test suite for this purpose, branch coverage is enabled on it, and the critical flows are tested and verified by the CI/CD system for every change made in the project

We use raise SystemExit(code) anytime an error condition is encountered so that the CLI signals to the user that something went wrong. An error message is also normally printed. This system exits would also be caught by the dynamic analysis tool.