Add LICENSE, CONTRIBUTING, CODE_OF_CONDUCT, issue templates, examples/, FAQ section, and pin workflow actions to commit SHAs — open-source hygiene pass to make the repo Show HN-ready: MIT LICENSE file (was just a README badge with no actual file), example workflows pinned to verified SHAs (practising the supply-chain hygiene we preach), and a FAQ pre-empting the 'how is this different from sigstore' / 'why ECDSA-P521 over Ed25519' / 'why hash chain over Merkle log' comments that always come up.

Author: rajibcse94

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,45 @@
+---
+name: Bug report
+about: Something the action does that it shouldn't, or doesn't do that it should
+title: '[Bug] '
+labels: bug
+assignees: ''
+---
+
+## What happened
+
+<!-- One or two sentences. Include the verification-id if the run produced one. -->
+
+## What I expected
+
+<!-- One sentence. -->
+
+## How to reproduce
+
+<!-- Minimal workflow YAML that triggers the bug. Strip any secrets. -->
+
+```yaml
+- uses: ledgerprove/sign-sbom@v1
+  with:
+    api-key: ${{ secrets.LEDGERPROVE_API_KEY }}
+    sbom-file: ./sbom.json
+```
+
+## Action log output
+
+<!-- Paste the relevant section of the Actions run log. Hide your API key. -->
+
+```
+(paste here)
+```
+
+## Environment
+
+- Action version (e.g. `v1.0.0` or commit SHA): 
+- Runner OS (ubuntu-latest / macos-latest / windows-latest): 
+- SBOM format (CycloneDX 1.x / SPDX 2.x): 
+- SBOM generator (Syft, cyclonedx-cli, other): 
+
+## Anything else
+
+<!-- Optional. Links to the failing run, related issues, etc. -->

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,11 @@
+blank_issues_enabled: false
+contact_links:
+  - name: Security vulnerability
+    url: https://github.com/ledgerprove/sign-sbom/security/policy
+    about: Please report security issues privately, not via public issues. See SECURITY.md.
+  - name: Question or discussion
+    url: https://github.com/ledgerprove/sign-sbom/discussions
+    about: Use Discussions for general questions, not Issues.
+  - name: Email
+    url: mailto:hello@ledgerprove.com
+    about: For anything that doesn't fit the above.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,34 @@
+---
+name: Feature request
+about: Suggest a new input, output, or behaviour for the action
+title: '[Feature] '
+labels: enhancement
+assignees: ''
+---
+
+## What problem are you solving
+
+<!-- Describe the use case in 2-3 sentences. What can't you do today? -->
+
+## Proposed change
+
+<!-- What should the action do differently? A new input? A new output? Different default behaviour? -->
+
+## Example workflow
+
+<!-- Show how a user would use the feature. -->
+
+```yaml
+- uses: ledgerprove/sign-sbom@v1
+  with:
+    api-key: ${{ secrets.LEDGERPROVE_API_KEY }}
+    # your proposed new input goes here
+```
+
+## Alternatives you considered
+
+<!-- Any workarounds you tried, or other ways this could be solved. -->
+
+## Anything else
+
+<!-- Links to similar features in other tools, etc. -->

.github/workflows/sbom.yml

@@ -11,7 +11,7 @@ jobs:
   sign:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
       - uses: ledgerprove/sign-sbom@v1
         with:
           api-key: ${{ secrets.LEDGERPROVE_API_KEY }}

.github/workflows/self-test-auto.yml

@@ -13,7 +13,7 @@ jobs:
   auto:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
       - name: Sign with auto-generated SBOM
         id: lp
         uses: ./

.github/workflows/self-test.yml

@@ -13,7 +13,7 @@ jobs:
   smoke:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
 
       - name: Sign the sample SBOM with this Action
         id: ledgerprove

CODE_OF_CONDUCT.md

@@ -0,0 +1,18 @@
+# Code of Conduct
+
+This project follows the [Contributor Covenant v2.1](https://www.contributor-covenant.org/version/2/1/code_of_conduct/).
+
+## Summary
+
+In short:
+
+- Be respectful and constructive in issues, PRs, and discussions
+- Focus criticism on code and design choices, not people
+- Assume good faith — most disagreements come from missing context
+- Harassment, discrimination, and personal attacks are not tolerated
+
+## Enforcement
+
+Reports go to **hello@ledgerprove.com**. Reports are confidential. Project maintainers will respond within 7 days.
+
+For the full text, see https://www.contributor-covenant.org/version/2/1/code_of_conduct/

CONTRIBUTING.md

@@ -0,0 +1,64 @@
+# Contributing to LedgerProve sign-sbom
+
+Thanks for taking the time to contribute. This is a small project with a clear scope, so most contributions are welcome — please read this first to keep the loop short.
+
+## What we accept
+
+- Bug fixes (with a failing test or reproducer)
+- New inputs/outputs on the action that match a real use case
+- README clarifications, FAQ entries, more `examples/` workflows
+- Support for additional SBOM formats already documented in the spec (CycloneDX 1.6, SPDX 2.3, etc.)
+- Improvements to the verify-without-an-account flow
+
+## What we don't accept (without discussion first)
+
+- New cryptographic primitives. We picked ECDSA-P521 + SHA-512 deliberately and won't swap silently.
+- Mandatory new external services. Optional integrations are fine.
+- Anything that breaks the public no-auth verify endpoint contract.
+- Changes that move signing logic out of the LedgerProve API (the action is intentionally thin).
+
+For any of the above, open an issue first to discuss the trade-off before opening a PR.
+
+## Local setup
+
+You'll need Node.js 22+ and pnpm or npm.
+
+```bash
+git clone https://github.com/ledgerprove/sign-sbom.git
+cd sign-sbom
+npm install
+npm run build
+```
+
+The built output goes to `dist/` and is checked in — GitHub Actions requires the compiled JS to be present.
+
+## Testing the action locally
+
+The action talks to `https://api.ledgerprove.com` by default. To test against a local API, set the `api-url` input:
+
+```yaml
+- uses: ./
+  with:
+    api-key: ${{ secrets.LEDGERPROVE_API_KEY }}
+    api-url: http://localhost:3000
+```
+
+The self-test workflows in `.github/workflows/self-test*.yml` show how we run smoke tests on every push.
+
+## Submitting a PR
+
+1. Fork the repo and branch from `main`
+2. Make your change
+3. Run `npm run build` to update `dist/`
+4. Commit both source and `dist/` changes
+5. Open the PR with a clear description of the use case
+
+## Reporting security issues
+
+Do NOT open a GitHub issue. See [SECURITY.md](SECURITY.md) for the disclosure process.
+
+## Questions
+
+- General questions: open a GitHub Discussion
+- Specific bugs: open an issue using one of the templates
+- Anything else: hello@ledgerprove.com

LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 LedgerProve Ltd
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

README.md

@@ -15,7 +15,7 @@ Cryptographically sign your SBOM, append it to a tamper-evident hash chain, and
     api-key: ${{ secrets.LEDGERPROVE_API_KEY }}
 ```
 
-That's the whole workflow step. The Action installs Syft, generates a CycloneDX SBOM of your repo, signs it with ECDSA-P521 (private key in AWS KMS), and prints a public verify URL.
+That's the whole workflow step. The Action installs Syft, generates a CycloneDX SBOM of your repo, signs it with ECDSA-P521 (hardware-backed, non-exportable signing key), and prints a public verify URL.
 
 ## Bring-your-own SBOM (full control)
 
@@ -34,7 +34,7 @@ If you already generate an SBOM in a previous step (cyclonedx-cli, custom toolin
 1. Reads your SBOM file (CycloneDX or SPDX, JSON).
 2. Hashes it with SHA-256.
 3. POSTs the hash + metadata to LedgerProve's API.
-4. The API signs your record with **ECDSA-P521** using a private key in **AWS KMS** (the key never leaves AWS).
+4. The API signs your record with **ECDSA-P521** using a private key inside a **hardware-backed KMS** — the key is non-exportable and never leaves the secure enclave.
 5. Your record is appended to a per-org **SHA-512 hash chain** — tampering with any record breaks all subsequent ones.
 6. An **RFC 3161 timestamp** is requested from a public TSA so anyone can prove when the record was signed.
 7. The Action sets `verification-url` as an output for use by later steps (PR comments, release notes, etc.).
@@ -50,7 +50,7 @@ Anyone can verify the signed SBOM at the verification URL with a single OpenSSL
 | `repo-id` | — | `${{ github.repository }}` | Repository identifier under which to record this build. |
 | `commit-hash` | — | `${{ github.sha }}` | The commit SHA to record. |
 | `build-status` | — | `PASS` | `PASS`, `FAIL`, or `WARN`. Use `FAIL` to record a failed build (e.g. tests failed, vulns found). |
-| `cve-count` | — | `0` | Number of CVEs found in this build, if known. |
+| `cve-count` | — | `0` | Optional. CVE count to bake into the signed chain payload. Most users leave this at `0` — LedgerProve runs its own CVE scan against OSV.dev after every signed build and exposes the real findings on your dashboard. This field exists for callers who want to record a count from their own scanner inside the signature. |
 | `api-url` | — | `https://api.ledgerprove.com` | Override the LedgerProve API URL. Only set this for self-hosted/staging. |
 
 ## Outputs
@@ -138,11 +138,57 @@ curl -sO https://api.ledgerprove.com/.well-known/public-key.pem
 openssl ts -reply -in token.tsr -text
 ```
 
+## FAQ
+
+### How is this different from sigstore / cosign?
+
+Sigstore uses keyless signing through a transparency log and a public Certificate Authority (Fulcio). It's a great fit if you want zero key management and are happy depending on a CA.
+
+LedgerProve doesn't use a CA. Each organisation has a long-lived ECDSA-P521 key held inside a hardware-backed KMS, and records are appended to a per-org hash chain. The trade-off:
+
+- **Sigstore wins** if you want true keyless signing with a public transparency log
+- **LedgerProve wins** if you want signing without a CA dependency, with FIPS-aligned crypto, and a single-step CI integration
+
+Both produce verifiable artifacts; the trust models differ.
+
+### Why ECDSA-P521 instead of Ed25519?
+
+P521 is FIPS-186-5 approved (matters for some customers' compliance reviews) and AWS KMS supports it for signing today; Ed25519 in KMS is still not GA. We'd switch when Ed25519 lands.
+
+### Why a hash chain instead of a Merkle tree / transparency log?
+
+A per-org hash chain is simpler operationally and gives the same tamper-evidence properties for a single organisation's history. A global Merkle log (like Rekor) gives cross-org public auditability — useful if you're publishing widely-consumed artifacts, less useful for internal SBOMs. We chose the simpler model for the MVP.
+
+### Does the action send my SBOM contents to your servers?
+
+No. The action computes a SHA-256 of the SBOM locally and sends only the hash + metadata. The SBOM body never leaves your runner. The signed record references the hash, not the file. (Trade-off: you need to keep the SBOM retrievable yourself if you want full reproducibility later — sigstore goes the other way with attestation bundles.)
+
+### What happens if your service goes down?
+
+Already-signed records remain verifiable forever using the public key at `https://api.ledgerprove.com/.well-known/public-key.pem`. If you cache the public key locally, you can verify signatures with OpenSSL even if our API is unreachable. New signings would obviously fail until we're back up.
+
+### Is there a free plan?
+
+Yes — 1 repository, unlimited builds, no credit card. The open-source action and the public verify endpoint are free on every plan. See https://ledgerprove.com/pricing for paid tiers (more repos, longer history retention, SBOM diff, CVE email alerts).
+
+### Why is `dist/` checked in?
+
+GitHub Actions runs the compiled JavaScript directly — there's no install step at action runtime. The compiled output has to be in the repo. We rebuild `dist/` on every change in `src/`.
+
 ## License
 
-ISC. Source: https://github.com/ledgerprove/sign-sbom
+[MIT](LICENSE). Source: https://github.com/ledgerprove/sign-sbom
+
+## Security
+
+For security disclosures, see [SECURITY.md](SECURITY.md) — do not report security issues via public GitHub Issues.
+
+## Contributing
+
+PRs welcome. Read [CONTRIBUTING.md](CONTRIBUTING.md) first for scope and process.
 
 ## Issues / questions
 
 - General: https://github.com/ledgerprove/sign-sbom/issues
+- Discussions: https://github.com/ledgerprove/sign-sbom/discussions
 - Email: hello@ledgerprove.com