OpenSwitch (OPX)

Code repositories * https://github.com/open-switch * 59 public repositories * Provides a list of all OPX repositories which are mapped to architecture components * https://github.com/open-switch/opx-docs/wiki/Repositories

All source code is hosted on github for code version management.

Code review * OPX uses the Github Pull Request interface for code review * Overview of code review norms, practices, conventions, rules. * To what extent are external/private code review systems used? None Continuous Integration tooling * CodeFactor * BuildKite, whose pipeline consists of: * Setup * Docker Hub * Build * dbp * Smoketest * Docker Hub * AWS * Github DCO

hosted on github. https://github.com/open-switch

Each new release is numbered and incremented. Current Release 3.1.0 (December 2018)

Versions are tagged in the repositories.

sample release note: http://archive.openswitch.net/docs/3.1.0/openswitch_opx_310_rel_notes.pdf

No reported CVEs.

https://github.com/open-switch/opx-docs/wiki/Report-bugs

Go to issues in respective Github repositories.

Issue tracker is available and public: https://github.com/issues?q=is%3Aopen+is%3Aissue+user%3Aopen-switch+sort%3Aupdated-desc

https://github.com/open-switch/opx-docs/wiki/Report-bugs has an email that you can report vulnerabilities.

To report and discuss security issues, you can send an email to security@lists.openswitch.net.

The security group receives the venerability reports to a private list and can make determination on how to publish it. https://github.com/open-switch/opx-docs/wiki/Report-bugs

No vulnerabilities reported to establish response baseline.

The project provides a working build system via a Docker container and build scripts. Refer to the “opx-build” repository and its README for more information.

Common tools are used for building the software. Generally, each repository uses a “Debian-style” build and Makefile/script infrastructure.

The project is buildable using only FLOSS tools. See previous responses.

Our automated test suite is published in the “opx-test” repository. The test framework is written in Ansible and Python.

The test suite is invokable in a standard way for Ansible.

The test suite covers the “master” code branch, and it consists largely of functional tests.

Continuous integration is implemented using Buildkite. You can see that it is run on each pull-request.

The project does have an informal general policy that major new functionality should be accounted for in the automated test suite in the “opx-test” repository.

A recent example is when new scripts were recently written in the “opx-tools” repo, tests for those scripts were also added to the “opx-test” repo. You can see the PR that is about to merge: https://github.com/open-switch/opx-test/pull/25

This should be evident in each component repository’s Makefile.am in flags like COMMON_HARDEN_FLAGS, C_HARDEN_FLAGS, and LD_HARDEN_FLAGS.

The project does address warnings.

We feel that we are maximally strict with warnings where practical.

Several OPX Developers are trained on secure software development practices.

See above.

Cryptographic protocols and algorithms are not used in the software produced by the project. Where applicable, the OPX operating system relies on the standard applications provided by the underlying Debian distribution to provide cryptographic protocols and algorithms (e.g., OpenSSH, OpenSSL, etc.).

we use https for and github for download resources.

here are no unpatched publicly known vulnerabilities in our software project.

If/when vulnerabilities are reported, we will fix them rapidly.

CodeFactor is run against all pull-requests

This is provided by CodeFactor

CodeFactor is run against all pull-requests