If you discover a security vulnerability in Reed, please report it responsibly.

Do not open a public GitHub issue for security vulnerabilities.

Report via GitHub's private vulnerability reporting: Security Advisories.

Include:

• A description of the vulnerability
• Steps to reproduce
• Potential impact
• Any suggested remediation

You will receive an acknowledgement within 48 hours. Reed will publish a security advisory and release a patch as quickly as possible, crediting the reporter unless anonymity is requested.

Reed is built to publish a full Software Bill of Materials with every release, starting from v1.0.0, as a commitment to supply chain transparency. The SBOM lists every direct and transitive dependency included in Reed — their version, licence, and source. Reed has not yet had a tagged release; until then, generate an SBOM locally with the same tools listed below.

SBOMs are published in CycloneDX JSON format (v1.5), the most widely supported SBOM standard for software composition analysis tools.

Each GitHub Release includes two SBOM artifacts:

SBOMs are also available from the GitHub Container Registry image manifest via:

docker buildx imagetools inspect ghcr.io/simonives/reed:<version> --format '{{ json .SBOM }}'

SBOMs are generated automatically as part of the release pipeline:

• Application SBOM: cyclonedx-bom from the locked dependency set
• Container SBOM: Syft against the published Docker image

Both are generated from the final build artefacts — not from development dependencies or source — so they reflect exactly what ships.

An SBOM allows users and security teams to:

• Audit Reed's dependencies before deploying it in their environment
• Run the SBOM against vulnerability databases (NVD, OSV) using tools like Grype or OWASP Dependency-Check
• Verify licence compliance across the full dependency tree
• Respond quickly if a dependency is found to have a CVE — the SBOM makes it immediately clear whether Reed is affected

Reed publishes SBOMs not because it is required to, but because it is the right practice for software that runs on other people's infrastructure.

• All direct dependencies are declared in pyproject.toml with minimum version constraints
• The Docker image pins dependencies to exact versions via a lockfile at build time
• Dependencies are audited for known vulnerabilities using pip-audit, and Dependabot alerts are triaged as they arrive; per-release review will apply once tagged releases begin
• Reed has no runtime dependencies on external services — it makes outbound HTTP requests only to fetch RSS feeds and to execute user-configured share targets (webhooks, Raindrop API, etc.)

Reed is AGPL v3 licensed. All dependencies are permissively licensed (MIT, Apache 2.0, BSD). The SBOM includes the licence for every dependency.