| Version | Supported |
|---|---|
| v0.x | ✅ |
Only the latest minor release receives security patches. This project is pre-release; the API and security posture are actively evolving.
Please do not report security vulnerabilities through public GitHub issues.
Use GitHub Security Advisories to report vulnerabilities. This provides a private channel for coordinated disclosure.
- Description of the vulnerability and its impact
- Steps to reproduce or a proof-of-concept
- Affected versions and components (core, file, syslog, webhook, audit-gen)
- Any suggested mitigation or fix
- Acknowledgement: within 48 hours of report
- Triage: within 7 days — we will confirm whether the report is a valid vulnerability, request additional information, or close as not-a-vulnerability
- Fix timeline: depends on severity — critical issues are prioritised for the next patch release
These timelines are best-effort commitments for a pre-release project with a small maintainer team.
We follow coordinated disclosure with a 90-day window:
- Reporter submits via GitHub Security Advisories
- We acknowledge and triage within the timelines above
- We develop and test a fix
- We publish a patched release and a GitHub Security Advisory
- Reporter may publish their findings after the advisory is published, or after 90 days from the initial report — whichever comes first
If you believe you have found a flaw in the library's own defences — not in how a consumer uses it — we want to hear about it. Examples of what we consider in scope:
- A way to bypass the webhook output's SSRF protection so that requests reach private networks despite the guard being enabled
- A flaw that forces a TLS connection to downgrade below the configured minimum version
- The library itself leaking credentials (e.g., webhook auth headers appearing in error messages or log output)
- A way to cause the library to consume unbounded memory or CPU through crafted taxonomy definitions or configuration, independent of the audit data a consumer passes in
The following are normal usage, bugs, or consumer responsibility and should be reported as regular GitHub issues, not security reports:
- Consumers passing arbitrary data in audit fields — the library records what it is given; it is not responsible for sanitising application-level content
- Bugs in formatting, field ordering, or output structure
- Performance issues
- Consumer misconfiguration (e.g., choosing to disable TLS validation
or setting
AllowInsecureHTTP) - Issues in test infrastructure or CI/CD pipelines
- Feature requests
Every release includes SBOMs in two formats, published as assets in the GitHub Release:
| Format | Filename | Use Case |
|---|---|---|
| CycloneDX | audit_<version>_sbom.cdx.json |
Vulnerability scanners (Trivy, Grype, Dependency-Track) |
| SPDX | audit_<version>_sbom.spdx.json |
License compliance tools, regulatory reporting |
Both SBOMs list all direct and transitive dependencies across every module in the repository, including versions and license identifiers.
Scan for vulnerabilities:
# Download the SBOM from the GitHub release, then:
trivy sbom audit_v0.1.0_sbom.cdx.jsonGenerate a local SBOM from source (requires syft):
make sbom # generates CycloneDX + SPDX in sbom/
make sbom-validate # validates JSON structure