{"slug": "four-supply-chain-badges-for-a-one-person-open-source-project-in-a-day", "title": "Four supply-chain badges for a one-person open-source project, in a day", "summary": "A solo maintainer of schemagate, an open-source library and MCP server that prevents AI agents from reading database tables a user isn't authorized to access, earned four supply-chain security badges in a single day: OpenSSF Best Practices (100%), OpenSSF Baseline (100%), REUSE compliance (238 of 238 files), and SLSA build provenance verified with slsa-verifier. The maintainer documented the process, including a branch-protection gap that was closed and a documentation bug where the published `--source-tag v1.3.1` verification command fails because workflow_run provenance records refs/heads/main instead of the tag.", "body_md": "I maintain [schemagate](https://github.com/ashishsinha1602/schemagate), an open-source library and MCP server that stops an AI agent from seeing database tables the user isn't allowed to read. It's a security tool, so \"trust me\" isn't good enough. A security team looking at it reasonably asks: is the project run properly, is the licensing clean, and is the package on PyPI really built from this repository?\n\nThere are free, public answers to all three questions. This week I went through them in one sitting. Here's what each one took, including the parts that didn't go as expected.\n\n[bestpractices.dev](https://www.bestpractices.dev) is the Linux Foundation's self-certification: about 60 criteria covering how you take bug reports, how you handle vulnerabilities, whether you test, whether you use static analysis. You sign in with GitHub and it pre-fills what it can detect (licence, HTTPS, public repo).\n\nThe honest part is that every answer needs a justification, and most of mine were links to files that already existed: `SECURITY.md` for private vulnerability reporting, `CONTRIBUTING.md` for the test policy, CodeQL for static analysis. Before answering \"no open static-analysis findings\", I checked the code-scanning API instead of assuming. CodeQL had zero alerts. The 19 open alerts were all Scorecard repository-settings findings, which is a different claim.\n\nOne criterion I answered \"Unmet\": dynamic analysis. There's no fuzzer yet. It's only *suggested* at this level, and a badge with an honest \"no\" in it is worth more than one without.\n\n**Result:** passing, 100%.\n\nBaseline is the newer, shorter OpenSSF checklist, aimed at security controls. Almost everything was already true. The one gap was branch protection: `main` required CI to pass but didn't stop a direct push. Requiring a pull request (zero approvals, so a solo maintainer can still merge) and turning off the admin bypass closed it.\n\n**Result:** baseline-1, 100%.\n\n[REUSE](https://reuse.software) checks that every file in the repository has machine-readable copyright and licence information. That matters to anyone whose legal team scans dependencies. You don't have to add a header to every file: one `REUSE.toml` can annotate whole globs.\n\nRunning `reuse lint` was the useful part, because it made me find the third-party code I'd forgotten about:\n\nThen you register at api.reuse.software, confirm by email, and their checker runs against the public repo.\n\n**Result:** compliant, 238 of 238 files.\n\nThis is the one that answers \"is the file on PyPI really built from this repo\". I used the official [slsa-github-generator](https://github.com/slsa-framework/slsa-github-generator). Its generic generator runs as an isolated reusable workflow and signs a provenance statement for whatever hashes you give it.\n\nThe design choice that matters is *which* hashes. I didn't rebuild the package in the provenance job. After the publish workflow finishes, a separate workflow downloads the exact wheel and sdist PyPI serves, checks them against PyPI's own sha256 digests, and attests those. The provenance then names the files people actually install.\n\nThen I verified it the way a user would, with the official `slsa-verifier`, after checking the verifier binary's own hash against its published checksums. Both files from PyPI passed. A deliberately tampered file failed, and so did a wrong source repository.\n\n**The gotcha:** my docs told users to verify with `--source-tag v1.3.1`, and that **fails**. A workflow triggered by `workflow_run` runs on the default branch, so the provenance records `refs/heads/main` and the commit, not the tag. `--source-branch main` passes, and the commit it names is the one the tag points to. If you trigger provenance after publish, test the verification command you document, not just the generation.\n\nThe badges are on the README: [https://github.com/ashishsinha1602/schemagate](https://github.com/ashishsinha1602/schemagate). Everything above is reproducible with free tools, and a weekend is plenty.", "url": "https://wpnews.pro/news/four-supply-chain-badges-for-a-one-person-open-source-project-in-a-day", "canonical_source": "https://dev.to/ashish_sinha_5241c7673d93/four-supply-chain-badges-for-a-one-person-open-source-project-in-a-day-mn4", "published_at": "2026-10-10 23:43:25+00:00", "updated_at": "2026-10-10 23:47:40.146857+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "mlops"], "entities": ["schemagate", "OpenSSF", "REUSE", "SLSA", "slsa-github-generator", "slsa-verifier", "PyPI", "GitHub"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/four-supply-chain-badges-for-a-one-person-open-source-project-in-a-day", "markdown": "https://wpnews.pro/news/four-supply-chain-badges-for-a-one-person-open-source-project-in-a-day.md", "text": "https://wpnews.pro/news/four-supply-chain-badges-for-a-one-person-open-source-project-in-a-day.txt", "jsonld": "https://wpnews.pro/news/four-supply-chain-badges-for-a-one-person-open-source-project-in-a-day.jsonld"}}