Don't take my word for it.

Every dependency in this site, with version, package URL, and integrity hash, in CycloneDX 1.5 format. It's generated deterministically from the lockfile, so the file served here is byte-identical to the one CI signs.

Components

607

Shipped to production

220

Format

CycloneDX 1.5

sha256 fe68320fe2e295e64eb52f2683bb7bfe79eb87b2bf028b8c503eb6fa77989253

$ curl -s https://krishnaneupane.com/sbom.json | shasum -a 256

Download sbom.json →

On every push, GitHub Actions generates the SBOM and signs a SLSA build provenance attestation for it with Sigstore. Verifying it proves the file came from this repository, through CI, at a specific commit.

$ curl -sO https://krishnaneupane.com/sbom.json$ gh attestation verify sbom.json -R krishna-commits/krishna-portfolio

This build: commit ddd175f on master.

Every response carries these headers. Compare them with what your terminal receives:

$ curl -sI https://krishnaneupane.com | grep -iE "content-security|strict-transport|x-frame|x-content|referrer|permissions|cross-origin"

• Content-Security-Policy
• Reporting-Endpoints
• Strict-Transport-Security
• X-Content-Type-Options
• X-Frame-Options
• Referrer-Policy
• Permissions-Policy
• Cross-Origin-Opener-Policy
• Cross-Origin-Resource-Policy

Or use an independent scanner: securityheaders.com ↗ · Mozilla Observatory ↗

The OpenSSF Scorecard independently rates the repository's practices: branch protection, pinned dependencies, token permissions, static analysis, and more. CI also runs CodeQL, secret scanning, and dependency audits on every push.

View the Scorecard ↗

Controls are only half the story. The decisions and risks behind them are written down:

• Architecture decision records → why the site is built the way it is, including the trade-offs
• Threat model → assets, trust boundaries, threats, and mitigations
• security.txt → how to report a vulnerability
• Colophon → the pipeline and performance budgets