Plannotator Open Source Security

Plannotator OSS runs on your computer by default. It does not collect usage telemetry or analytics, and an ordinary local review does not upload your plan, document, diff, annotations, or feedback to Plannotator. The project also publishes verifiable release artifacts and runs automated security checks against its source, dependencies, secrets, and GitHub configuration.

​

Data and network boundaries

Plannotator checks GitHub for the latest release when an app surface loads, and a local Git review can contact its configured origin. These requests do not include the reviewed content. See Privacy and data flow for the complete list of automatic and optional network requests. Set PLANNOTATOR_SHARE=disabled to hide OSS share and import actions. Set PLANNOTATOR_AI=disabled to remove AI-backed features and their provider routes. Ordinary local plan, document, and code review still work.

​

Release integrity

For a release tag, the workflow builds and tests the artifacts, generates and scans the SBOM, attests the release, and then publishes it. The workflow uses Syft to generate a CycloneDX SBOM. Grype must pass the release policy before the workflow creates the attestations. Release tags must point to a commit on main and match the version in the release manifests. The GitHub Release is published only after the attestations exist. v0.27.3 was the first release to complete this pipeline. It published a CycloneDX 1.6 SBOM and a matching checksum. Its binaries have SLSA provenance and CycloneDX SBOM attestations. The SBOM describes the release-wide inventory of locked inputs and dependencies. Bun standalone binaries do not expose their bundled JavaScript package metadata to Syft. The SBOM is not an exact runtime inventory for each binary. Use Pin or verify a release to verify installer provenance or download and verify the SBOM evidence.

​

Automated security checks

On every pull request to main and every push to main, the Security Scanning workflow runs Gitleaks, zizmor, Semgrep, and Trivy. A weekly scheduled run checks for drift. Trusted runs upload SARIF results to GitHub Code Scanning. The Security Scanning and ZAP DAST workflows are in monitor mode. Tool and evidence failures fail their jobs. Findings appear in GitHub Code Scanning or retained workflow artifacts, but they do not block a merge or release.

​

Report a vulnerability privately

Do not open a public issue for a suspected vulnerability. Security fixes are provided for the latest released version. See the repository security policy for the supported-version and disclosure policy.

​

Evidence and limitations

• Latest release artifacts and checksums
• First SBOM-enabled release: v0.27.3
• Release attestations
• Release and security workflow source
• ZAP DAST workflow and run history
• GitHub Actions history
• OSS privacy and data flow

Automated checks reduce risk; they do not prove that the software has no vulnerabilities. Plannotator does not claim SOC 2, ISO 27001, or another security certification for the OSS project. The support policy covers the latest release, and this page does not describe the hosted Workspaces product.

​

Appendix: security pipeline

These diagrams show when each security control runs and how its evidence moves through the project.

​

Release trust chain

A release tag generates the SBOM and runs the Grype policy before the workflow creates attestations and publishes the release.

​

Security on every code change

The build and security workflows start from the same pull request or push. The security scanners run independently from the build workflow.

​

Scheduled security testing

The weekly workflows scan the repository and a disposable application instance. The ZAP workflow scans only the disposable instance inside an isolated CI network. Last verified on August 13, 2026, using Plannotator product commit aa0bf86. Maintained by the Plannotator project.