skipper

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

Every PR is reviewed and can be commented in a team view using Github PR. Github can also compare 2 commits in diff views.

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

Every merge to master with a successful build in travis-ci creates a new, unique, incremented git tag increasing the patch version.
Auto incremented tags: https://github.com/zalando/skipper/tags Releases providing release notes and docker image: https://github.com/zalando/skipper/releases

https://github.com/zalando/skipper/tags

https://github.com/zalando/skipper/releases are used to add a human-readable summary

no publicly known vulnerabilities

Bug reports can be applied at https://github.com/zalando/skipper/issues and the process is described in https://github.com/zalando/skipper/blob/master/CONTRIBUTING.md#report-a-bug

https://github.com/zalando/skipper/issues

https://github.com/zalando/skipper/issues is used and we have an internal rule to respond to every issue within one week.

https://github.com/zalando/skipper/issues is used and we have an internal rule to respond to every issue within one week.

https://github.com/zalando/skipper/issues

https://github.com/zalando/skipper/blob/master/SECURITY.md describes to write an e-mail

https://github.com/zalando/skipper/blob/master/SECURITY.md describes to write an e-mail

no vulnerabilities were reported

Non-trivial build file in repository: https://github.com/zalando/skipper/blob/master/Makefile.

Non-trivial build file in repository: https://github.com/zalando/skipper/blob/master/Makefile.

Makefile and the Go compiler are FLOSS tools required to build the project.

The Go compiler is FLOSS tool required to test the project. Optional is the Makefile to help to test the project, which is also FLOSS.

Makefile and Go's stdlib test suite can be used to invoke the tests. Both are very common in Go projects.

A GH project badge https://codecov.io/gh/zalando/skipper shows 70% coverage.

The project uses a public visible TravisCI https://travis-ci.org/zalando/skipper that runs tests automatically and is required to pass before merge to master

For major (core) changes there is a sentence "Every change in core has to have tests included and should be a non breaking change." at https://opensource.zalando.com/skipper/tutorials/development/#core

For every non trivial change we write tests, for example https://github.com/zalando/skipper/pull/869/files We also have documented how to write tests https://opensource.zalando.com/skipper/reference/development/#writing-tests

https://opensource.zalando.com/skipper/reference/development/#writing-tests explains how to write test in the how to develop a filter https://opensource.zalando.com/skipper/reference/development/#how-to-develop-a-filter

Go is in general memory safe, additionally we use a pre-commit Makefile target running in travisCI to make sure Go fmt, Go build, Go vet, staticcheck and tests are successfully running. All these tools are FLOSS tools and can be run locally without CI.

Merge to master can not be applied if a warning from one of the tools: Go fmt, Go build, Go vet (https://golang.org/cmd/vet/), staticcheck (https://staticcheck.io/) and Go tests are failing

Merge to master can not be applied if a warning from one of the tools: Go fmt, Go build, Go vet (https://golang.org/cmd/vet/), staticcheck (https://staticcheck.io/) and Go tests are failing Exceptions from staticcheck that we allow are commented in the Makefile at https://github.com/zalando/skipper/blob/master/Makefile#L96-L101

primary developers understanding the mentioned design are https://github.com/aryszka and https://github.com/szuecs

primary developers understanding the mentioned design are https://github.com/aryszka and https://github.com/szuecs

Use Go libraries and not implement ourselves.

The project uses crypto/tls t terminate and validate TLS connections and crypto/rand crypto/cipher crypto/aes golang.org/x/crypto/scrypt to enable key rotation and add a stateful cookie to support OpenID Connect auth code flow as documented in the spec https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest. The project uses AES256 GCM to encrypt the session cookie after successful OpenID Connect and protects from CSRF https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Encrypted_Token_Pattern with an encrypted query to validate the redirect request is coming from us.

The project uses crypto/md5 only in tests to generate test content.

Everything related to cryptography is using Go standard library

Go standard library is FLOSS

TLS provided by the Go standard library and AES 256 GCM

TLS provided by the Go standard library and AES 256 GCM. MD5 is only used to generate time dependent random content in tests.

TLS provided by the Go standard library and AES 256 GCM. MD5 is only used to generate time dependent random content in tests.

TLS provided by the Go standard library

User authentication with username password is only support by Open ID Connect (we do not store external users username and password) and Basic Auth. If a user choose to use basic auth the file format used is htpasswd as in Apache2 webserver and basic auth is implemented by https://github.com/abbot/go-http-auth which supports bcrypt.

We use Go standard library crypto/rand to generate cryptographically secure random numbers if needed.

We support HTTPS

We always use https to get cryptographic signatures.

There was no security vulnerability reported

There was no security vulnerability reported. Our process involve the technical security team of the company Zalando SE.

Credentials and private keys stored in the repository are only used in tests and are clearly marked as test only

We use Go vet and staticcheck enforced by a required passing CI pipeline before merge to master. Master is a protected branch that requires a successful Travis CI pipeline run. Go vet (https://golang.org/cmd/vet/), staticcheck (https://staticcheck.io/) are both FLOSS tools

Go is a memory safe language and the software does not implement features that can be attacked by common vulnerabilities for example SQL injection or XSS. We use go vet and staticcheck https://staticcheck.io/ that checks for coding best practice and finds common errors that could lead to vulnerabilities. We use gosec https://github.com/securego/gosec to check for common security problems in our CI pipeline Both tools are run by our CI pipeline and are mandatory to be successful, before merge is allowed.

There was no exploitable vulnerability discovered with static code analysis, yet. https://github.com/zalando/skipper/issues/914 shows a run of a not yet enabled static analysis tool, but all issues reported are not relevant as these are only used for tests, wrong findings by the tool or the user has to opt-in and run the software with -insecure flag.

static source code analysis are ran as pre-commit hook enforced by the required CI pipeline before merge to master can be done.

Go is in general memory safe and we do not use CGO nor Go standard library unsafe to circumvent memory safety provided by the runtime

We do not have dynamic code analysis tools running