Security

Reporting a vulnerability#

Every public repository under github.com/heyvaldemar has GitHub’s private vulnerability reporting switched on. Open the repository, choose Security → Report a vulnerability, and the report reaches the maintainer and nobody else. Email to [email protected] works too; the GitHub route is preferred because it keeps the report, the discussion and the fix together.

You can expect an acknowledgment within seven days. There is no bounty programme. A valid, responsibly disclosed report is credited in the release notes and the changelog of the repository it concerns, unless you ask otherwise.

Please do not open a public issue for a security report.

What is already checked#

Before a report reaches a person, the fleet has looked for the common cases itself, every day, and the results are public:

• Every upstream image is pinned by digest, and a daily job fails when upstream moves it.
• Trivy scans every pinned image on every push and daily; the results go to each repository’s Security tab.
• GitHub Actions are pinned by commit SHA and moved only by Dependabot, whose updates merge only after the repository’s own verification is green.
• Every release carries a signed archive and SLSA provenance, verifiable with cosign and slsa-verifier, with nothing from the repository trusted.
• OpenSSF Scorecard scores every repository weekly; the scores, low marks included, are on the evidence page.

Scope#

The repositories are deployment templates and operations tooling. A vulnerability in the software they deploy (Nextcloud, Keycloak, Mailu and the rest) belongs to that project’s own process; a template here is affected when it ships a vulnerable pin or a configuration that exposes one, and that is what a report to this address should describe.

Machine-readable#

/.well-known/security.txt carries the same contacts in the RFC 9116 format.