heimdall

Older versions are not yet maintained due to the age of the project. The documentation of the upgrade path is addressed on PRs with breaking changes, which always describe, what has been changed and how to adopt these changes. This information is then available in the project change log, respectively on the release page: https://github.com/dadrus/heimdall/releases

https://github.com/dadrus/heimdall/issues

No vulnerabilities have been reported, respectively discovered manually so far. In general vulnerability management is automated by making use of corresponding SCA tools included into the security analysis and build pipelines

https://github.com/dadrus/heimdall#security-ov-file

This is addressed by making use of a special set of linters, which are required to be used by the contributors. This is described in the contribution guide (https://github.com/dadrus/heimdall/blob/main/CONTRIBUTING.md) and enforced in the build pipeline as soon as a PR is submitted (see also the configuration of the CI pipeline: https://github.com/dadrus/heimdall/blob/ecc1b33f5ff4f13d1c17afd24e388cf403d15053/.github/workflows/ci.yaml#L97)

See the configuration of the CI pipeline: https://github.com/dadrus/heimdall/blob/ecc1b33f5ff4f13d1c17afd24e388cf403d15053/.github/workflows/ci.yaml#L97

Addressed in the CI/CD pipeline, and also for local builds

Debug information is removed from the resulting binaries as it is not required for productive use. There are however options in place to increase the log level to have more insights if required. A custom build with debug information preserved is however possible as well

There are no cross-dependencies in subdirectories

The project's build setup for local, as well as for automated builds follows the https://reproducible-builds.org requirements by making us of corresponding compiler flags and does not include any data, like time stamps, which would lead to a different bit-by-bit result.

There are two available options: * just download the binary, which is self contained and does not have any dependencies, or * use the available container image, available on DockerHub and also in GitHub packages. See also the options described in https://dadrus.github.io/heimdall/dev/docs/getting_started/installation/

See the description for the "Installation System" above

See https://dadrus.github.io/heimdall/dev/docs/getting_started/installation/, which describes everything related

This is part of the project dependency document: https://github.com/dadrus/heimdall/blob/main/go.mod There is also an SBOM available with each published artifact. See also https://dadrus.github.io/heimdall/dev/docs/operations/security/#_software_bill_of_material_sbom

Part of the CI build and analysis pipelines, running with each build, respectively periodically

This is part of the standard dependency management system and also automated as already mentioned in multiple places in this report

All deprecated or obsolete functions are removed from code with each release.

All available tests are executed for each PR targeting the main branch if there were code changes. This is also true for the main branch itself.

These are part of the regular tests and are always executed

Achieved by making use of CodeCov. Current coverage is 89%. See also https://codecov.io/gh/dadrus/heimdall

This is addressed in the contributing guide, the PR template and the review process of each and every PR.

The policy requires an adequate test coverage wich is not allowed to reduce the existing coverage by more than 0.5%

This is achieved by making use of many different static analysis tools which are also enforced by the automated CI pipeline

The project does not only follow the corresponding principles, it is there to solve related problems and allows teams / other projects implement such principles, as deny by default, least privilege principle, define required security mechanisms once and reuse them many times, and much more.

The project does not only not use insecure algorithms, it does not even allow usage of such while configuring the resulting software.

This is supported in all places dealing with cryptography algorithms or protocols.

The project does not have any cryptographic key material compiled in. Everything related must be configured and can even be managed externally

The software is for HTTP(s) related use cases only. As such it supports TLS, but does not allow usage of TLS versions prior to v1.2. For TLSv1.2 only the usage of secure PFS TLS ciphers is possible

Only TLSv1.2 and TLSv1.3 are supported with only a handful PFS based ciphers considered secure.

If certificates are used, certificate verification is enforced and cannot be disabled

This is given by the standard go implementation used by the project

Cosign with keyless signing is used while releasing the artifacts. Verification procedure is described in https://dadrus.github.io/heimdall/dev/docs/operations/security/#_verifying_heimdall_binaries_and_container_images

Every commit is required to be signed. Each and every release artifact is signed as well. See https://dadrus.github.io/heimdall/dev/docs/operations/security/#_verifying_heimdall_binaries_and_container_images for details

By default, everything, which could cause harm is dropped and must be explicitly configured, respectively enabled by those people, who are responsible for heimdall's operation

This is achieved by following the secure by default principles, delivering a container image configured to not run the process as root and providing deployment options which drop all privileges.

Multiple SAST tools are part of the CI build. Some of them are also running periodically and independent of the actual builds

The application is written in a memory safe language (go)