Every layer we run, and how to verify it
Buyer diligence usually arrives as a security questionnaire. Vendor fills it out, buyer takes it on faith. We'd rather publish the actual scaffolding and give you the URLs to verify each claim independently. Below: 17 defensive layers running across the Kinetic Gain estate, what each one does, and a public artifact you can read or query without talking to us. No "compliant" or "certified" claims appear on this page. That vocabulary belongs to audits, not to scaffolding.
uses: lines1. Disclosure surface
How a researcher reports a vulnerability matters more than how nicely we phrase the rest of this page. Use the contact and repository links below to reach the right owner.
| Layer | What it is | Verify |
|---|---|---|
| RFC 9116 security.txt | Machine-readable security contact at a well-known URL, with a link to the disclosure policy below. | /.well-known/security.txt |
| SECURITY.md on the SDK | Per-repo coordinated-disclosure policy for the Kinetic Gain Embedded SDK, which can run in customer environments. | github.com/mizcausevic-dev/kinetic-gain-embedded/blob/main/SECURITY.md |
| Marketplace Action disclosures | Check the affected Action repository for its current SECURITY.md. If it has none, use the contact in the apex security.txt and identify the Action in your report. | github.com/mizcausevic-dev |
2. Supply chain
The supply chain is where almost every real-world software compromise starts. Five layers cover four phases: what we pull in, what we publish, what an attacker could substitute, and what changed since last week.
| Layer | What it is | Verify |
|---|---|---|
| Dependabot (org-wide) | Weekly grouped updates across npm, pip, cargo, gomod, bundler, composer + github-actions. Security advisories open their own PRs immediately at any severity. | 410 repos |
| npm provenance | Every @kineticgain/embedded release is published with --provenance. Sigstore signs the build at publish time, npm verifies the supply-chain attestation, the green ✓ on the registry page is the visible proof. | npmjs.com/package/@kineticgain/embedded |
| CycloneDX SBOM | Every KGE release attaches a CycloneDX 1.5 SBOM to its GitHub Release. MCP Kinetic Gain ships one too. Lists every direct + transitive dep with versions + license info. | Release assets → sbom/cyclonedx.json |
| Action SHA pinning | Every uses: org/action@vX in our workflows is pinned to a 40-char commit SHA with the tag preserved in a trailing comment. Defeats sliding-tag substitution attacks (compromise the action repo, repoint v4 to a malicious commit, our workflows still run the audited SHA). | 558 lines pinned across 98 repos |
| npm audit CI gate | The KGE CI workflow runs npm audit --omit=dev --audit-level=info on every push + PR. Surfaces known CVEs in production deps before they merge. | KGE CI workflow runs on each PR |
3. Static analysis
Finds the classes of bug that humans miss on review, taint flow, dangerous workflow patterns, deprecated triggers, shell-injection in run: steps.
| Layer | What it is | Verify |
|---|---|---|
| CodeQL (default-setup) | GitHub's CodeQL with the security-extended query suite. Languages auto-detected per repo (JS/TS, Python, C#, Java, Go, Actions). Findings land in each repo's Security tab. | 98 repos (5 strategic + 93 squad-era v1.0-prod) |
| actionlint | Static analysis specifically for GitHub Actions workflows. Catches what runtime can't: bad triggers, invalid expressions, dangerous shell patterns, missing job deps. Path-filtered so it only runs when workflow files change. | 93 repos |
| CodeScan (org-wide github-actions language) | The CodeQL default setup includes the actions language, which scans workflow YAML itself for dangerous patterns (script injection via ${{ github.event.* }}, etc.). Distinct from actionlint's lexical checks. | per-repo Security → Code scanning |
4. Posture monitoring
The OpenSSF Scorecard is an industry-standard scoring rubric for open-source security posture. It's run by an independent project (Google + OpenSSF maintainers), not by us, and it grades repos against a published checklist (branch protection, pinned actions, signed releases, license, weak deps, exposed secrets, etc.).
| Layer | What it is | Verify |
|---|---|---|
| OpenSSF Scorecard | The apex workflow is configured for weekly and main-branch runs, with publish_results: true. Its analysis job skips when this private repository lacks code-scanning access. A schedule and publication setting are not evidence that a current public score exists; check the linked viewer for the referenced repo's latest result. | apex workflow (repository access required); KGE score viewer |
| Workflow permissions scoping | Workflow and job YAML declare the permissions each run requests. For example, the apex Scorecard workflow sets contents: read, actions: read, security-events: write, and id-token: write at workflow scope. Check each workflow's effective permissions before treating an estate-wide count as a least-privilege result. | Inspect the relevant repository's .github/workflows/ files |
5. Cryptographic signing
The 11 Suite JSON documents listed in our signing policy and AI Procurement Pulse receipts use one ed25519 keypair. The dated apex attestation uses a separate key. A signature lets a verifier detect changes only when it checks against a public key it already trusts; it does not prevent a compromised host from replacing files or prove that the current deployment is covered. The manual GitHub root-upload workflow checks the 11 Suite signatures before its upload. Other release paths need their own explicit verification.
| Layer | What it is | Verify |
|---|---|---|
| Suite/Pulse ed25519 keypair | The 11 listed Suite JSON documents and AI Procurement Pulse receipts use this key. The dated apex attestation has a different public key; other /.well-known/ files are outside this Suite/Pulse signing claim. | /.well-known/pulse-signing.json |
| 11 Suite docs signed | The listed JSON documents carry embedded signatures. A verifier must compare each signature's key with a trusted copy of the Suite/Pulse key. | Individual signed docs and the verification method are linked from /trust/signing-policy/ |
| Manual root-upload signature check | When the apex GitHub workflow is manually dispatched for a root upload, it compares the Suite/Pulse key with a reviewed fingerprint, checks all 11 Suite signatures, and stops that upload on failure. A push or verify-only dispatch does not run this check; the local SFTP path requires a separate check. | signing-policy/ |
6. Transport + browser-layer headers
Defense against the user's own browser being weaponized, clickjacking frames, mixed content, leaking referrers, MIME-sniffing, cross-origin embedding.
| Header | What it blocks | Where |
|---|---|---|
| HSTS (1-year, includeSubDomains) | Strips the ability to downgrade to HTTP, even on first visit if user is on the preload list. | apex + 100+ subdomains |
| Content-Security-Policy | Locks default sources to 'self'; restricts frame-ancestors to 'none'; blocks object-src; upgrades insecure requests. | apex .htaccess |
| X-Frame-Options: DENY | Belt-and-suspenders alongside CSP frame-ancestors. Defeats classic clickjacking. | apex .htaccess |
| Referrer-Policy: strict-origin-when-cross-origin | Limits what gets leaked in the Referer header to external sites. | apex .htaccess |
| COEP / COOP / Permissions-Policy | Cross-origin isolation; disables sensors, geolocation, autoplay, payment, microphone, camera, etc. for the entire estate. | apex + spokes |
What this page is not
Honest scope
What this page is: a public inventory of the defensive scaffolding running across the Kinetic Gain estate, with verifiable links for each claim.
What this page is not: an audit report, a SOC 2 attestation, a HIPAA Business Associate Agreement, an ISO 27001 certificate, a GDPR adequacy decision, or any other framework attestation. None of the layers below "satisfy" or "meet" any compliance framework on their own. They organize what we already do so that audit conversations can be specific instead of vague.
The Trust Pack vocabulary discipline applies: readiness · evidence · posture · controls · scaffolding, never "certified" or "compliant" unless we're truly audited and currently attested. We aren't. We say so out loud.
Coordinated disclosure
Report suspected vulnerabilities privately to miz@kineticgain.com or through GitHub Security Advisories on the affected repository. Include the affected URL or product, steps to reproduce, impact, and a way to contact you. Do not include customer data or credentials in an initial report.
We accept reports about the Kinetic Gain-operated apex, subdomains, and products we publish, including the package, Action, and extension families described in the apex security.txt. That file applies to the apex and our published products; RFC 9116 does not extend an apex file to every subdomain. A subdomain needs its own security.txt for that domain's machine-readable scope.
Third-party properties that Kinetic Gain does not own or publish, including domains measured by Procurement Pulse, are outside our scope. Please avoid accessing other users' data, disrupting services, or testing third-party systems. This reporting channel does not by itself grant permission to test.
We review reports privately and coordinate remediation and disclosure timing with the reporter based on the issue. We offer credit with the reporter's consent. We do not advertise a fixed acknowledgement or fix deadline here.