marquez

Releases page on Github: https://github.com/MarquezProject/marquez/releases Example PyPI package with history: https://pypi.org/project/marquez-airflow/#history Example Maven library page with previous versions: https://mvnrepository.com/artifact/io.github.marquezproject/marquez-java

For our bug-reporting process, see the Issues tab on our Github repository: https://github.com/MarquezProject/marquez/issues

While we do have a process in place for vulnerability reporting (see: https://github.com/MarquezProject/marquez/blob/main/CONTRIBUTING.md), this is N/A because none have been reported.

The main readme contains instructions for reporting vulnerabilities: https://github.com/MarquezProject/marquez/blob/main/README.md

For Java, the primary language in the project, we use https://github.com/google/google-java-format, which is enforced by the PMD and Spotless plugins for Gradle.

We use a Gradle file with configuration of PMD and Spotless for Java code linting: https://github.com/MarquezProject/marquez/build.gradle.

For builds, the project uses Gradle, which supports this functionality. See: https://docs.gradle.org/current/userguide/build_environment.html.

For builds, the project uses Gradle, which supports this functionality. See: https://docs.gradle.org/current/userguide/command_line_interface.html#sec:command_line_debugging.

The project does not recursively build subdirectories.

Gradle supports this functionality. See: https://docs.gradle.org/current/userguide/command_line_interface.html#command_line_order_safety.

In every case we use common, industry-standard tools. For Java, we distribute Marquez libraries via Maven Central (https://mvnrepository.com/search?q=marquez), and the artifacts can be installed using standard Maven or Gradle tools. For Python, we use PyPI, and users can install/uninstall via PIP (https://pypi.org/search/?q=marquez).

Please see above. Our tools (Maven and PyPI) follow these conventions.

Please see our contributing guide at https://github.com/MarquezProject/marquez/blob/main/CONTRIBUTING.md, where we explain how contributors can trigger builds and tests on GitHub Actions and CircleCI, standard tools in the industry.

For Java, the build.gradle files (e.g., https://github.com/MarquezProject/marquez/blob/main/build.gradle) can be processed.

For dependency monitoring, we use Dependabot, which is a built-in tool offered by GitHub. We use the default configuration, so no configuration file is needed (https://github.com/MarquezProject/marquez/settings/security_analysis).

Our build system allows us to meet this requirement.

We avoid these issues in part through the use of static code analysis tools that are run automatically on commits (such as Spotless and PMD for Java: https://github.com/MarquezProject/marquez/blob/main/build.gradle).

Our workflows on CircleCI include tests. For the details, see: https://github.com/MarquezProject/marquez/blob/main/.circleci/config.yml

For an example of the project's automated testing process, see the test suite in the Java client: https://github.com/MarquezProject/marquez/blob/main/clients/java/build.gradle.

For another part of our automated test suite, see the tests directory in the Python client: https://github.com/MarquezProject/marquez/tree/main/clients/python/tests. The project also uses Codecov. You can see how we deploy this tool here: https://github.com/MarquezProject/marquez/blob/main/.circleci/config.yml.

The checklist in our PR template states our expectation that changes should be accompanied by tests: https://github.com/MarquezProject/marquez/blob/main/.github/pull_request_template.md.

As noted above, the checklist in our PR template states our requirement that changes be accompanied by tests if relevant: https://github.com/MarquezProject/marquez/blob/main/.github/pull_request_template.md. Our CONTRIBUTING.md file specifies that changes may require the creation of new tests: https://github.com/MarquezProject/marquez/blob/main/CONTRIBUTING.md.

Warnings are used by the static code analysis tools employed by the project. See: We avoid these issues in part through the use of static code analysis tools that are run automatically on commits (such as PMD for Java: https://github.com/MarquezProject/marquez/blob/main/build.gradle).

Ours is primarily a Java project, so there is no provisioning model in the project. The operations do not require the users to have direct access to functions, so these issues do not apply.

This functionality is supported through environment variables and configuration files.

Our use of HTTPS for network communications means that we meet this security threshold.

Our use of OpenSSL means that our support for SSL is up to date.

Please see above.

This functionality is built-in thanks to our use of HTTPS.

Our releases on PyPI and Maven are cryptographically signed, as are the ones on GitHub.

We do not deal with direct user input, so this is not applicable.

Snyk is used for reporting vulnerabilities. See: https://snyk.io/test/github/MarquezProject/marquez.

The threat model is largely determined by the deployment scenario and the consuming organization, both of which vary. We are able and happy to provide examples of threats and mitigation strategies to organizations wishing to deploy Marquez.

For this reason, a single assurance case would be misleading. A general code security and analysis assurance statement is available to users in our main GitHub repository: https://github.com/MarquezProject/marquez/blob/main/CODE_QUALITY_AND_SECURITY.md.

Please see this build.gradle file showing usage of PMD and Spotless tools for Java linting: https://github.com/MarquezProject/marquez/blob/main/build.gradle. We also use Snyk for additional checking: https://snyk.io/test/github/MarquezProject/marquez.

We use Java (and some Python), so this is not applicable.